Вы заходите на сайт своего банка www.yourbank. Естественно, вы хотите, чтобы сообщения в банк передавались в зашифрованном виде (иначе злоумышленник сможет перехватить их и украсть ваши деньги). Чтобы шифровать сообщения вам (если точнее – вашему браузеру) и сайту банка нужно выработать общий секретный ключ. Чтобы это осуществить, используется криптография с открытым ключом.
Ликбез по открытым ключам
У Алисы и Боба есть по два ключа: закрытый ключ хранится в секрете, а открытый публикуется во всеобщем доступе. Обменявшись открытыми ключами, Алиса и Боб могут сгенерировать общий секретный ключ Подробно.Но вам как-то нужно убедится, что публичный ключ действительно принадлежит вашему банку. В противном случае, вы можете общаться с злоумышленником, который читает всю вашу переписку. Эта атака называется Man-in-the-middle – “человек посередине”.
Пример:
Разберём как подобная проблема решается в жизни. У вас есть подруга Таня. Однажды на собеседование к вам приходит кандидат Марина и говорит, что она от Тани. Как вам это проверить? Самый простой способ – это позвонить Тане и подтвердить рекомендацию.
∎
Цепочки сертификации
Аналогичная система применяется в интернете, только вместо устных рекомендаций – электронные подписи, а вместо Тани особый участник – Удостоверяющий центр (УЦ). УЦ все считают абсолютно честным и авторитетным, его публичный ключ всем известен (вы получаете его, устанавливая браузер). Перед тем как сайт www.yourbank опубликует открытый ключ, он обращается в УЦ. УЦ проверяет и подписывает ключ, удостоверяя, что этот ключ действительно принадлежит сайту www.yourbank. Когда браузеру нужно проверить ключ, он проверяет подпись УЦ.
Публичные ключи публикуются в виде специальных электронных документов – сертификатов. Помимо открытого ключа, сертификат содержит подпись УЦ, срок действия, уникальный номер и другую информацию. Собственный сертификат УЦ называется корневым сертификатом. Он подписан своим же ключом (помним, что УЦ все доверяют).
Корневых удостоверяющих центров не так много. Чтобы уменьшить нагрузку, они делегируют проверку сертификатов удостоверяющим центрам уровня ниже. Корневой УЦ подписывает только сертификат нижестоящего УЦ, а тот уже – сертификаты сайтов. Так образуется цепочка сертификации.
Чтобы подтвердить сертификат A нужно:
- Проверить, что A подписан сертификатом B
- Проверить, что B подписан сертификатом С
- Убедиться, что С – это корневой сертификат
Отзыв сертификата
Бывают ситуации, когда нужно отозвать действующий сертификат. Например, если секретный ключ был украден. В этом случае владелец сертификата обращается в УЦ. УЦ отзывает сертификат: помещает его в специальный список отозванных сертификатов. Таким образом, помимо цепочки подписей при проверке сертификата сайта ваш браузер должен проверить, что сертификат не отозван. Для этого есть различные механизмы:
CRL – скачивается список всех отозванных сертификатов и проверяется по списку. Минус здесь в нерациональности: список большой, а проверить нужно всего один сертификат
OCSP – запрос к УЦ о статусе сертификата по его номеру. УЦ отвечает отозван сертификат или нет. Первый минус: браузер должен обращаться к УЦ каждый раз, когда вы посещаете любой сайт. Получается, УЦ знает всю вашу историю просмотра, что не есть хорошо. Второй минус – большая нагрузка на УЦ: каждый раз когда кто-то посещает сайт, он обращается в УЦ для проверки
OCSP Must-Staple – периодически сайт сам обращается в УЦ и получает подписанное свидетельство о том, что сертификат не отозван. Браузер требует это свидетельство у сайта вместе с сертификатом. Теперь браузер не обращается к УЦ, и УЦ не знает какие сайты вы посещаете, к тому же снижена нагрузка на УЦ
В зависимости от браузера и его настроек используется конкретный метод или их комбинация.
Сертификат Минцифры
Что произойдёт, если УЦ отзовёт сертификат у сайта? Сайт перестанет открываться: у вас в браузере будет всплывать предупреждение об опасности. Вы либо покидаете сайт, либо миритесь с угрозой “человек посередине”. А теперь представьте, что отозвали сертификаты у всех российских сайтов. Кажется, что такое невозможно? Однако совсем недавно такая ситуация была вполне реальна, потому что все корневые УЦ были иностранные. С 2022 года в РФ появился свой УЦ – НУЦ Минцифры РФ, и многие сайты выпускают сертификаты за подписью этого УЦ. Так как сертификат Минцифры не встроен в популярные браузеры (исключение – браузер Яндекса), чтобы проверка работала, его нужно установить вручную.
Часто можно услышать опасение, что из-за сертификата Минцифры весь ваш трафик может быть расшифрован и прочитан. Это не совсем так просто. Сертификат Минцифры – это корневой сертификат, то есть он подтверждает правильность других сертификатов. Непосредственно на нём трафик не шифруется. Но открывается возможность атаки человек посередине: если хакер завладеет секретным ключом, то сможет выпустить корректный сертификат для любого сайта. Если он сможет направить вас на свою версию www.yourbank, то браузер не заметит проблемы, потому что сертификат сайта будет верный. Это позволит хакеру получить все ваши платёжные данные.
Практикум: проверка сертификата по OSCP с помощью openssl
Получаем сертификат wikipedia.ru:
openssl s_client -connect wikipedia.ru:443 -servername wikipedia.ru
Всё, что находится между —–BEGIN CERTIFICATE—– и —–END CERTIFICATE—– (включая эти строки) копируем в файл wiki.pem
Получаем адрес проверки OCSP:
openssl x509 -noout -ocsp_uri -in wiki.pem
Ответ: http://r3.o.lencr.org
В вашем случае адрес может отличаться. Если ничего не вернулось, значит возможности проверки по OCSP нет
Теперь получаем цепочку сертификатов:
openssl s_client -connect wikipedia.ru:443 -showcerts
Сертификат с номером 0 - это сертификат wikipedia.ru, он у нас уже есть. Все остальные сертификаты в том же порядке сохраняем в файл chain.pem
Делаем проверку:
openssl ocsp -issuer chain.pem -cert wiki.pem -text -url http://r3.o.lencr.org
В случае успеха увидим, что сертификат прошёл проверку:
Response verify OK
wiki.pem: good