Антивирусная правДА!TM

7 ноября 2022

В одном из прошлых выпусков «Антивирусной правды» мы рассказывали о том, зачем стоит переходить на российские браузеры. На тот момент уже было известно о скором истечении срока действия цифровых сертификатов многих российских сайтов, включая портал «Госуслуги». Для пользователей это грозило проблемами с подключением к таким сайтам при использовании зарубежных браузеров. С тех пор вопрос доступа к популярным российским ресурсам и онлайн-сервисам стал еще актуальнее, так как у части цифровых сертификатов, выданных зарубежными удостоверяющими центрами, срок действия уже истек, а у других — подходит к концу. Пользователи действительно столкнулись с перебоями: сайты могли не открываться в привычных браузерах либо принудительно переходили на незащищенный протокол HTTP.

В настоящий момент общественности чаще всего предлагается два варианта действий для решения проблемы: переход на использование российских браузеров или установка в операционную систему корневого сертификата Национального удостоверяющего центра Минцифры России. На фоне всех этих событий в интернете появилось большое количество противоречивой информации: одни предостерегают от установки сторонних корневых сертификатов, другие, напротив, считают этот метод наиболее удобным, а кто-то вообще предлагает уйти из интернета. При этом у пытливого пользователя может возникнуть больше вопросов, чем появиться ответов: за что отвечают сертификаты? Почему сайты перестанут работать? Как все это отразится на моей безопасности?

Это хорошие вопросы, и сегодня мы постараемся на них ответить. И для полноты картины мы хотели бы сделать небольшое отступление и сперва рассказать, о чем вообще идет речь и как это все работает.

Достаточно давно, 15-20 лет назад, посещение большинства веб-сайтов в интернете предполагало использование незащищенного протокола HTTP (протокол передачи гипертекста). Это значит, что передача данных между вашим браузером и веб-сервером сайта осуществлялась по открытому каналу — это все равно, что обмениваться с адресатом письмами в прозрачных конвертах или разговаривать с собеседником по обычной рации. При желании третье лицо могло перехватить, прочитать или даже модифицировать ваши сообщения. По мере развития интернет-торговли, появления социальных сетей и онлайн-банков использование незащищенных соединений становилось все менее приемлемым. Так, большинство организаций, работающих с данными клиентов, начали внедрять на своих сайтах различные защитные механизмы. Основной мерой стал переход на использование протокола HTTPS (защищенный протокол передачи гипертекста) — по сути обычного HTTP, но работающего «внутри» специальных криптографических протоколов. Проще говоря, шифрование пошло в массы. Сейчас уже нечасто можно встретить «живой» сайт коммерческой фирмы, который не поддерживал бы протокол HTTPS. А если речь идет о работе с чувствительными данными (персональными, банковскими и т. п.), то в этих случаях поддержка защищенного соединения обязательна.

Нашим читателям наверняка знакомы такие аббревиатуры как SSL и TLS. Также часто можно встретить понятия «SSL-сертификат» и «TLS-сертификат». С технической точки зрения именно в них кроется причина того, что привычные российские сайты вскоре не будут работать в зарубежных браузерах. Но обо всем по порядку.

SSL и TLS — это криптографические протоколы, которые помимо прочего обеспечивают работу HTTPS и позволяют обращаться к сайтам в интернете по защищенному каналу. Это разные протоколы (TLS является развитием SSL), но в обиходе их часто отождествляют. Далее по тексту мы будем упоминать TLS как более современный и широко используемый протокол. Подробное описание принципов его работы выходит за рамки этой статьи, поэтому мы остановимся лишь на ключевых особенностях, которые, надеемся, будут вам интересны.

Криптографический протокол TLS реализует три главных механизма защиты данных:

1. Шифрование.
2. Проверку целостности.
3. Аутентификацию.

В совокупности эти механизмы призваны гарантировать конфиденциальность и целостность защищаемых данных, а также подлинность общающихся сторон. Конфиденциальность обеспечивается шифрованием. Данные передаются по сети в закрытом виде и для третьей стороны выглядят как случайной набор символов. Расшифровка осуществляется непосредственно на стороне участников коммуникации. Проверка целостности защищает передаваемые данные от изменений третьей стороной. Специальные механизмы позволяют математически сверять полученные сообщения с тем, какими они были в момент отправки. Но кроме этого на этапе установки соединения очень важно убедиться, что вы начинаете общение с подлинной стороной, а не подмененным лицом или посредником, который выдает себя за настоящего участника коммуникации.

Как же все это работает?

Итак, вы собираетесь посетить интернет-банк и отправить денежный перевод своему другу. Ваше устройство (клиент) и сайта банка (сервер) поддерживают работу по протоколу HTTPS, поэтому после установки соединения в адресной строке браузера вы увидите значок замка и будете знать, что ваш канал связи защищен. Да, данные будут зашифрованы и целостны, но как определить, что вы общаетесь с настоящим банком, а не со злоумышленником? Именно за это и отвечает механизм аутентификации. И здесь на сцену выходят цифровые подписи, TLS-сертификаты, цепочки доверия и так называемые удостоверяющие центры, которые упоминались в начале статьи.

Проверка подлинности участников коммуникации происходит на этапе установки соединения, который включает в себя так называемое TLS-рукопожатие (англ. handshake). Это очень интересный процесс обмена ключами, который задействует ассиметричные протоколы шифрования. Мы не будем подробно останавливаться на этом, а лишь отметим, что результатом «рукопожатия» является наличие у вашего устройства и сервера банка общего уникального секрета, который известен только этим двум машинам во всем интернете. С помощью этого секрета и происходит дальнейший обмен зашифрованными данными. Но чтобы генерация секрета состоялась, стороны сначала должны идентифицировать и проверить друг друга.

В большинстве случаев (и это касается нашего примера) проверке подлинности подлежит только сервер. Мы же должны быть уверены, что обращаемся в настоящий банк, а не к мошенникам. Для этого на сервере должен быть установлен специальный цифровой TLS-сертификат. Проверка подлинности сервера происходит следующим образом. Ваш браузер обращается к серверу банка и «сообщает», что хочет установить с ним защищенное соединение. Сервер отвечает и вместе с ответом передает браузеру свой цифровой сертификат. Но как узнать, что сертификат настоящий и действительно принадлежит нужному банку? Логично предположить, что нужна некая третья авторитетная сторона, которая могла бы заверить цифровой сертификат сервера. При этом важно, что такая подпись будет, во-первых, известна браузеру, а во-вторых, он будет безоговорочно ей доверять. Для этой цели и были созданы удостоверяющие центры или центры сертификации. Их можно рассматривать как третью сторону, которой априори доверяют остальные участники коммуникации в интернете, а ее подпись широко известна. В их задачи входит выпуск и подтверждение подлинности цифровых сертификатов. В операционных системах и в частности в Windows существует специальное хранилище цифровых сертификатов. При этом дистрибутив ОС уже содержит определенный список сертификатов доверенных корневых и промежуточных центров сертификации. Этот список со временем корректируется и дополняется по мере выпуска обновлений для операционной системы.

Но вернемся к нашему примеру. После того как сервер банка отправил вашему браузеру TLS-сертификат, браузер проверяет его подпись и сравнивает ее со списком установленных сертификатов в системе. Если сертификат сервера подписан доверенным центром сертификации, и браузеру известна эта подпись, то проверка подлинности проходит успешно. Отдельно стоит заметить, что в сертификате сервера также содержится набор данных (так называемый «открытый ключ»), который используется для генерации общего секрета и установки зашифрованного соединения на этапе рукопожатия. Таким образом, TLS-сертификат воедино связывает «цифровую личность» сервера и его открытый ключ.

Вы уже наверняка догадались, в чем заключается проблема недействительных сертификатов. Современные браузеры устроены так, что в случае неудачной проверки подлинности на этапе установки защищенного соединения, запрашиваемая страница не открывается, либо инициируется соединение по незащищенному протоколу HTTP. До недавнего времени общедоступные российские сайты, включая банки, пользовались услугами зарубежных центров сертификации. Часть выданных сертификатов была отозвана, иные — попросту не будут продлены. Сейчас многие отечественные сайты уже начали переход на российские сертификаты, выдаваемые Национальным удостоверяющим центром (НУЦ). Однако такие сертификаты по умолчанию не установлены в ОС, поэтому зарубежные браузеры не могут успешно проверить их подлинность и выдают ошибку.

Первый способ решения проблемы — использовать отечественные браузеры, которые по умолчанию доверяют корневому сертификату НУЦ. Например, Яндекс Браузер имеет свой собственный список доверенных сертификатов, куда входит и сертификат Russian Trusted Root CA. Работу с этим сертификатом также поддерживает браузер Atom. Это значит, что они будут открывать сайты, TLS-сертификаты которых выпущены российским центром сертификации.

И второй способ, о котором говорилось в начале статьи, — установить нужный корневой сертификат НУЦ в хранилище операционной системы, чтобы любая программа, в том числе браузер, могла доверять сайтам, которые «предъявляют» российский сертификат. Оба способа будут работать, однако следует учитывать фактор безопасности.

Основная опасность самостоятельной установки корневого сертификата в ОС заключается в вероятности установить не тот сертификат. Можно сказать, что сложившаяся ситуация — раздолье для злоумышленников. Ведь под видом легитимного сертификата Минцифры можно предложить пользователю загрузить подменный сертификат. Такой сертификат, установленный в качестве доверенного на уровне всей ОС, будет являться опаснейшим бэкдором и сделает систему уязвимой для атаки типа «человек посередине». Например, при помощи подмены DNS или файла hosts (о котором мы рассказывали в одном из прошлых выпусков) злоумышленник сможет через подконтрольное «защищенное» соединение перенаправить пользователя на фишинговый сайт банка. Разумеется, для системы такой сайт будет являться доверенным. Кража банковских данных останется лишь делом техники.

С другой стороны, чистые дистрибутивы российских браузеров должны минимизировать подобные риски. Если вы привыкли к зарубежным браузерам, но не хотите устанавливать корневой сертификат в ОС, то разумным подходом видится использование отдельного браузера с поддержкой российских сертификатов исключительно для посещения онлайн-банков, портала Госуслуг и подобных ресурсов. В этом случае вы на уровне приложений разграничите свою повседневную интернет-активность и, скажем, финансовые операции.