перовое хочу всех "заспокоить" да это очередные проделки небратиков никакой опасности это не несет. я вообще не лестно обычно отзываюсь об РКН его собратьях, но здесь, я считаю, поступили абсолютно правильно.
ну а теперь пробуем разобраться для чего это нужно и как это работает. сейчас весь интернет https s значит security т.е. безопасность. т.е. протокол http завернут в протокол TLS, который обеспечивает шифрование данных и проверку подлинности.
про шифрование говорить особо не буду - нас сейчас больше интересует подлинность, но смысл это операции в том чтобы установить клиенту и серверу симметричные ключи которые будут шифровать данные отправителя и получателя. при этом обмен ключами надо произвести так чтобы никто эти ключи не смог перехватить. я не буду подробно рассматривать современные алгоритмы обмена ключами - кому интересно почитаете википедию.
в основе проверки подлинности лежат два алгоритма - вычисление хеш суммы это такой отпечаток данных - изменение любого бита в данных послуживших для создания такой суммы изменит хеш. и асимметричное шифрование. суть его в том что зашифровать данные может кто угодно публичным ключем, а расшифровать только тот у кого есть приватный ключ. т.е. эти два ключа связаны. в данном контесте происходит обратная ситуация - публичный ключ используется для проверки данных подписанных закрытым ключом.
а вот теперь дайте на пальцах опишем как работает проверка подлинности. ведь вы обращаетесь к сайту с неким именем и вам нужно быть уверенным что это именно тот сайт.
- т.е. вы обратились к сайту он вам ответил: "я этот сайт вот мой сертификат." браузер проверяет сертификат и действительно имя по которому вы обращаетесь совпадает с именем извлеченным из сертификата. но тут возникает вопрос: а мог ли кто-то другой подделать этот сертификат?
- для этого есть подпись издателя сертификата - удостоверяющего центра (УЦ). УЦ берет все данные сертификата сайта (включая его имя, публичный ключ и др.) и вычисляет от них криптографическую хэш-сумму. затем УЦ шифрует эту хэш-сумму своим закрытым ключом. полученная шифрованная хэш-сумма и есть цифровая подпись. она "привязана" к каждому байту данных в сертификате.
- браузер проверяет издателя сертификата браузер проверяет подпись с помощью публичного ключа УЦ - вроде все ок. но может ли быть фальшивый издатель сертификата?
- для проверки сертификат издателя точно так же подписывается, но чем? это корневой сертификат. его предварительно устанавливаем в систему т.е. мы этой информации доверяем. т.е. из правильного источника установили правильный сертификат. ну или он был установлен вместе с операционной системой или браузером. для любого удостоверяющего центра их корневые сертификаты находятся в системе.
т.е. в общем-то ничего страшного. сертификат это набор цифр, которые не исполняются непосредственно процессором, грубо говоря это буквы. непосредственная опасность от них незначительная, но как вы понимаете, если использовать поддельный сертификат можно сбить с толку проверку аутентичности - мы устанавливаем сертификаты УЦ которых до этого не было. т.е. существует опасность подмены сертификата, а уже такая подмена может быть очень чувствительна.
например есть некий SNI youtube.com подписанный неким удостоверяющим центром, а мы издаём другой сертификат подписанный другим удостоверяющим центром. но опасность сомнительная - браузер и так знает много удостоверяющих центров. кроме того всегда можно вышвырнуть сертификат удостоверяющего центра если его репутация сомнительная.
сам сертификат мало на что влияет. на его основании не шифруются данные, для этого как правило используются симметричные ключи, о чем скажу ниже. он нужен в основном для проверки подлинности. т.е. сертификаты минцифры и есть наш ДОПОЛНИТЕЛЬНЫЙ удостоверяющие центр. т.е. после установки сертификатов минцифры браузер знает еще один удостоверяющий центр. т.е в браузер дополнительно устанавливаются корневой и издающие сертификаты.
кстати говоря. если вам предлагают что-то запустить для установки сертификата - шлите на фиг без разговоров и ничего не запускайте -поверьте так будет проще. как я уже сказал сертификаты это набор цифр, а не команд и они должны быть не исполняемом формате. в текстом редакторе ("блокнот") сертификат выглядит так:
-----BEGIN CERTIFICATE-----
MIIFwjCCA6qgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwcDELMAkGA1UEBhMCUlUxPzA9BgNVBAoMNlRoZSBNaW5pc3RyeSBvZiBEaWdpdGFsIERldmVsb3BtZW50IGFuZCBDb21tdW5pY2F0aW9uczEgMB4GA1UEAwwXUnVzc2lhbiBUcnVzdGVkIFJvb3QgQ
. . .
EYVMxjh8zNbFuoc7fzvvrFILLe7ifvEIUqSVICAzplMJxw7buXFeGP1qVCBEHq391d/9RAfaZ12zkwFsl+IKwEOZxW8AHa9i1p4GO0YSNuczzEm4=
-----END CERTIFICATE-----
можно сказать, что если если приватный ключ сохранить, то можно легко расшифровывать трафик зашифрованный этим колючем в теории можно даже "на лету"...
это не совсем так. дело в том что трафик защищён симметричным шифрованием. производится обмен симметричные ключами способом делающий перехват крайне сложным. эти ключи используются только на одну сессию, обеспечивая эфемерность этих самых ключей. как правило используются алгоритмы на эллиптических кривых (Elliptic-Curve ECDHE). на сегодняшним момент нужны очень значительные вычислительные ресурсы для подбора такого ключа. в теории лёгкий подбор таких ключей может быть осуществлён с помощью квантового компьютера. для защиты от такого подбора используются пост квантовые криптографические алгоритмы.