Как открыть сайт с отозванным сертификатом
Перейти к содержимому

Как открыть сайт с отозванным сертификатом

  • автор:

Ошибки подключения SSL и как их исправить

Бывает, вы переходите на сайт, а браузер вместо него показывает ошибку. Сюда, мол, не пущу, подключение не защищено.

Причины возникновения ошибки бывают разными, но смысл всегда один — браузер не смог подключиться к сайту по HTTPS. Это значит, что вводить на этом сайте личные данные небезопасно. Вот браузер и показывает предупреждение.

В этой статье разберемся, какие бывают ошибки подключения SSL, с чем они связаны и как их исправить.

SSL-сертификаты Let’s Encrypt перестали работать на старых устройствах

С 30 сентября 2021 на некоторых устройствах сайты с сертификатами Let’s Encrypt будут открываться с предупреждением, что на сайте небезопасно. Это связано с тем, что компания перешла на новый корневой сертификат, которому пока не доверяют некоторые устройства. Из-за этого сайт с Let’s Encrypt и может отображаться как ненадёжный. Даже если на самом деле с ним всё в порядке.

Подробнее на эту тему читайте в статье в нашем блоге. Там же вы найдёте список устройств, на которых Let’s Encrypt не будет работать. А чтобы быстро решить проблему с совместимостью вы можете установить на сайт платный сертификат.

Что внутри

  1. Причины возникновения
    • Кэш
    • Неправильные настройки даты и времени
    • Настройки антивируса или файервола
    • Устаревшая версия браузера
    • Протокол QUIC
    • Конфликт между протоколами TLS
  2. Примеры ошибок
    • Ошибка «Подключение не защищено»
    • Ошибка «Часы спешат» / «Часы отстают»
    • Ошибка «Подключение к сайту защищено не полностью» / «Части этой страницы не защищены»
    • Ошибка «Этот сайт не может обеспечить безопасное соединение»
    • Ошибка «На сервере используется слабый эфемерный открытый ключ Диффи-Хелмана»

Причины возникновения

Все ошибки подключения SSL можно разделить на две группы:

  1. Ошибки на стороне браузера. Посетитель может исправить их сам.
  2. Ошибки на стороне сайта. Их может исправить только владелец сайта.

Чтобы определить, какой тип ошибки в вашем случае, проверьте сайт при помощи сервиса decoder.link.

Если при проверке появилась надпись “It’s all good. We have not detected any issues”, проблема на стороне браузера. Если вместо надписи есть какая-то ошибка, проблема на стороне сайта.

Ошибка подключения SSL. Сервис проверки ошибок decoder.link.

С ошибками на стороне сайта всё понятно: если вы не владелец сайта, тут ничего не сделать. Возможно, истёк срок годности сертификата или его неправильно установили. А может что-то не так с настройками сервера. Остаётся только ждать, когда владелец сайта заметит и устранит ошибку.

Разберёмся с ошибками подключения SSL на стороне браузера. Обычно их можно быстро исправить и всё-таки попасть на сайт. Вот основные причины, из-за которых они возникают.

Кэш

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

Как вариант можно зайти на сайт с другого браузера или устройства. Если заходит, значит скорее всего проблема именно в кэше.

Неправильные настройки даты и времени

Браузеру может показаться, что установленный на сайте сертификат недействителен, если время у вас на компьютере и на сервере, где лежит сайт, отличается. Убедитесь, что у вас стоит правильные время и дата.

Настройки антивируса или файервола

Бывает, антивирус не даёт зайти на сайт, потому что по ошибке добавил его в черный список или закрыл 443 порт, через который и происходит SSL подключение. Попробуйте отключить антивирус и зайти на сайт снова.

Устаревшая версия браузера

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

Протокол QUIC

QUIC — это новая технология передачи данных в интернете. Она используется только в Google Chrome и браузерах, сделанных на движке Chromium: Opera, Microsoft Edge, Brave.

Поскольку технология новая, более старые версии серверов её не поддерживают. Из-за этого могут возникать ошибки.

Как вариант можете попробовать отключить QUIC и зайти на сайт ещё раз. Чтобы сделать это в Google Chrome, перейдите по адресу chrome://flags и введите в поиске QUIC. Затем выберите в выпадающем списке опцию Disabled.

Ошибка подключения SSL. Как отключить протокол QUIC.

Конфликт между протоколами TLS

Протокол TLS — это набор правил, по которым браузер устанавливает безопасное соединение с сервером, где лежит сайт. Что-то вроде инструкции для компьютеров, которая помогает им договориться о шифровании.

На момент написания статьи есть семь версий этого протокола. Половину из них уже признали небезопасными, но на некоторых сайтах устаревшие протоколы всё ещё используют.

Иногда бывает так, что браузер использует последнюю версию TLS, а сервер — нет. В итоге появляется ошибка подключения SSL, потому что стороны не могут договориться о шифровании.

Сайт может начать открываться, если вы разрешите своему браузеру использовать устаревшие протоколы, но это небезопасно. Личные данные, которые вы введете на сайте после этого могут украсть. Делайте это только в крайнем случае, а потом лучше верните всё, как было.

В Internet Explorer/Microsoft Edge нажмите для этого сочетание клавиш Windows+R и введите inetcpl.cpl.

Ошибка подключения SSL. Разрешаем более старые версии протокола TLS.

В открывшемся окне перейдите на вкладку «Дополнительно» (Advanced) и включите все протоколы SSL и TLS. Затем, нажмите «ОК». Не забудьте перезагрузить компьютер.

Ошибка подключения SSL. Протоколы TLS в свойствах браузера.

В старых версиях Google Chrome по умолчанию поддерживаются все версии протокола, кроме новейшего TLS 1.3. Чтобы его включить, введите в адресной строке chrome://flags/#tls13-variant. Затем в первой же строке установите значение “Default”.

Ошибка подключения SSL. Версия TLS в Google Chrome.

В Mozilla Firefox введите в адресной строке about:config. Затем найдите параметр security.tls.version.min и установите значение «1» вместо «2».

Ошибка подключения SSL. Минимальная версия TLS в Mozilla Firefox.

Затем найдите параметр security.tls.version.max и установите значение «4» вместо «3».

Ошибка подключения SSL. Максимальная версия TLS в Mozilla Firefox.

Примеры ошибок

1. Ошибка «Подключение не защищено»

В англоязычной версии браузера: Your connection is not private.

Ошибка подключения SSL: Ваше подключение не защищено. Домен не совпадает.

Код ошибки: ERR_CERT_COMMON_NAME_INVALID.

Что означает: доменное имя сайта не совпадает с именем в SSL-сертификате.

Что делать: почистить кэш или зайти на сайт с другого браузера.

Ошибка подключения SSL: Ваше подключение не защищено. Неизвестный центр сертификации.

Код ошибки: ERR_CERT_AUTHORITY_INVALID.

Что означает: SSL-сертификат выпустил неверный/неизвестный центр сертификации.

Что делать: почистить кэш или зайти на сайт с другого браузера.

Ошибка подключения SSL: Ваше подключение не защищено. Отозванный сертификат.

Код ошибки: ERR_CERT_REVOKED.

Что означает: центр сертификации отозвал сертификат. Обычно это бывает, когда сертификат забыли продлить после истечения срока действия. На сайте он по-прежнему стоит, но уже не действует.

Что делать: почистить кэш или зайти на сайт с другого браузера.

Ошибка подключения SSL: Ваше подключение не защищено. Устаревшая технология HPKP.

Код ошибки: ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN.

Что означает: на сайте используется устаревшая технология HPKP (HTTP Public Key Pinning).

Что делать: почистить кэш или открыть сайт в другом браузере. Если не помогло, проблема на стороне веб-сайта.

2. Ошибка «Часы спешат» / «Часы отстают»

В англоязычной версии браузера: Your clock is behind / Your clock is ahead.

Ошибка подключения SSL: Ваше подключение не защищено. Часы спешат.

Код ошибки: ERR_CERT_DATE_INVALID.

Что означает: неправильная дата выпуска или истечения сертификата. Обычно такая ошибка возникает из-за того, что время на компьютере и сервере отличаются.

Решение: проверьте время и дату на устройстве. Если дата и время правильные, попробуйте очистить кэш.

3. Ошибка «Подключение к сайту защищено не полностью» / «Части этой страницы не защищены»

В англоязычной версии браузера: Your connection to this site is not fully secure / Parts of this page are not secure.

Ошибка подключения SSL: Ваше подключение не защищено. Смешанный контент (Firefox).

Ошибка подключения SSL: Ваше подключение не защищено. Смешанный контент (Google Chrome).

Что означает: после установки SSL-сертификата на сайте ещё остались элементы, которые загружаются по HTTP. Например, изображения. Если их загружали до установки сертификата, в ссылках останется HTTP.

Что делать: владельцу сайта придётся обновить ссылки вручную.

Просматривать сайт со смешанным контентом безопасно, но личные данные на нём лучше не оставлять.

4. Ошибка «Этот сайт не может обеспечить безопасное соединение»

В англоязычной версии браузера: This site can’t provide a secure connection.

Ошибка «Этот сайт не может обеспечить безопасное соединение». Ошибка TLS.

Код ошибки: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Что означает: произошла ошибка при выборе протокола TLS. Обычно появляется, если сайт работает на сервере с устаревшим ПО или версия браузера слишком старая. В первом случае это ошибка на стороне сайта, во втором — на стороне посетителя.

Что делать: обновить браузер или использовать другой. Если не помогло, сайт использует более старые протоколы, которые можно включить только вручную. В этом случае есть риск, что личные данные, которые вы введете на сайте, попадут в руки мошенников.

Ошибка «Этот сайт не может обеспечить безопасное соединение». Ошибка настроек антивируса.

Код ошибки: ERR_BAD_SSL_CLIENT_AUTH_CERT.

Что означает: браузер и сервер в последний момент не смогли установить безопасное соединение. Часто случается из-за антивируса. В его настройках что-то по ошибке не дает браузеру и серверу договориться, в итоге происходит сбой аутентификации.

Что делать: отключите антивирус или отключите в его настройках фильтрацию протоколов SSL/TLS.

5. Ошибка «На сервере используется слабый эфемерный открытый ключ Диффи-Хелмана»

В англоязычной версии браузера: Server has a weak ephemeral Diffie-Hellman public key.

Ошибка подключения SSL. Слабый сертификат.

Код ошибки: ERR_SSL_WEAK_EPHEMERAL_DH_KEY.

Что означает: на сайте стоит слабый SSL-сертификат.

Что делать: лучше закройте сайт, если увидели такое предупреждение. Ваши данные здесь не в безопасности.

Отзыв сертификатов не работает

Прямо сейчас у нас есть небольшая проблема, но на мой взгляд, со временем ситуация может только ухудшиться. Всё больше и больше сайтов получают сертификаты — необходимые документы для внедрения HTTPS — но у нас нет механизма для защиты от злоупотреблений.

Сертификаты

Мы сейчас видим настоящую золотую лихорадку вокруг сертификатов, поскольку всё больше сайтов внедряют HTTPS. Кроме очевидных преимуществ безопасности и приватности, есть и другие выгоды от внедрения защищённых соединений, которые я перечислил в статье «Вы всё ещё думаете, что вам не нужен HTTPS?». Обычно именуемые «SSL-сертификаты» или «HTTPS-сертификаты» разлетаются со скоростью, которой мы никогда не видели в истории интернета. Каждый день я исследую сайты из первого миллиона по посещаемости и анализирую различные аспекты их безопасности, а каждые 6 месяцев публикую отчёт. Вы можете изучить эти отчёты здесь, но сейчас посмотрим на темпы внедрения HTTPS.

Процент сайтов из первого миллиона самых популярных сайтов по статистике Alexa, где стоит редирект на версию HTTPS

Мы не просто продолжаем внедрять HTTPS, но скорость внедрения тоже увеличивается. Так выглядит настоящий прогресс. Процесс получения сертификата со временем становится более простым, благодаря великолепному Let’s Encrypt, к тому же ещё и сертификаты стали бесплатными. Если вкратце, мы просто отправляем запрос на получение сертификата (Certificate Signing Request, CSR) в центр сертификации (CA), а тот предлагает доказать факт владения доменом. Обычно это делается с помощью изменения записи DNS TXT или размещения специального кода где-нибудь по случайному URL на нашем домене. Как только задание выполнено, CA выдаёт сертификат, и мы можем предъявлять его браузерам и наслаждаться зелёным замком и указанием HTTPS в адресной строке.

Я написал несколько инструкций по этому процессу, в том числе с чего начать, как грамотно обновить и как использовать двойные сертификаты. Это всё здорово, не правда ли? Но в чём проблема? А проблема возникнет тогда, когда всё пойдёт не по плану и у вас случится плохой день.

Нас хакнули

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

Если злоумышленник завладел нашим секретным ключом, то он может выдать себя за нас. Повторим это: кто-то в интернете может доказать, что он — это вы, хотя в реальности он таковым не является. Это реальная проблема, и прежде чем вы подумаете «Со мной такого никогда не произойдёт», вспомните Heartbleed. Этот крошечный баг в библиотеке OpenSSL позволял злоумышленнику украсть ваш секретный ключ, даже если вы соблюдали все меры безопасности. Кроме этого, было бесчисленное множество случаев, когда секретные ключи утекали из-за случайности или небрежности. Реальность такова, что мы можем потерять наш секретный ключ, а когда это случается, нам требуется способ помешать злоумышленнику использовать наш сертификат. Нужно его отозвать.

Отзыв

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

Как только мы узнаём о факте взлома, мы связываемся с CA и просим отозвать наш сертификат. Нужно доказать факт владения сертификатом, и как только мы сделали это, то CA помечает сертификат как отозванный. Теперь нужен способ сообщить об этом факте каждому клиенту, которому может потребоваться данная информация. Прямо в этот момент браузер, конечно, ничего не знает, и это проблема. Есть два механизма, которые используются для распространения информации: это список отозванных сертификатов (Certificate Revocation List, CRL) и протокол проверки статуса сертификата (Online Certificate Status Protocol, OCSP).

Списки отозванных сертификатов

CRL — действительно очень простая концепция, это просто список всех сертификатов, которые CA пометил как отозванные. Клиент может отправить запрос к серверу CRL и скачать копию списка. Имея копию этого списка, браузер сверяет с ним предъявленный сертификат. Если он там присутствует, то браузер знает, что сертификат недействителен и ему нельзя доверять, он тогда выдаст ошибку и разорвёт соединение. Если сертификата нет в списке, то всё нормально — и браузер продолжит работу.

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

Протокол проверки статуса сертификата

OCSP предлагает намного более красивое решение проблемы и имеет значительное преимущество перед CRL. Здесь мы спрашиваем у CA статус единственного, конкретного сертификата. Это значит, что CA должен вернуть только простой ответ: сертификат либо хороший, либо отозван, и такой ответ гораздо меньше по размеру, чем список CRL. Отлично!

Действительно, OCSP превосходит CRL по скорости получения ответа, но за это преимущество нужно платить (вы тоже ненавидите, когда такое случается?). Цена довольно высока — это ваша приватность… Если подумать о сути запроса OCSP, это очень конкретный запрос на единственный сертификат HTTPS. По сути, происходит утечка информации. Когда вы отправляете запрос OCSP, вы буквально спрашиваете у центра сертификации:

Сертификат для pornhub.com валидный?


Так что это не идеальный сценарий. Вы теперь выдаёте историю посещённых сайтов некоей третьей стороне, о которой даже ничего не знаете, и всё ради HTTPS, который вроде как должен повысить вашу приватность и безопасность. Но погодите, есть ещё кое-что.

Полный сбой

Выше я говорил о CRL и OCSP, двух механизмах проверки сертификатов браузером, и они выглядят таким образом.

После получения сертификата браузер обратится к одному из этих сервисов и отправит запрос для окончательного выяснения статуса сертификата. А что, если у вашего CA плохой день и его инфраструктура в офлайне? Что, если ситуация выглядит так?

Здесь у браузера только два варианта. Он может отказаться принимать сертификат, поскольку не способен проверить его статус. Или взять на себя риск и принять сертификат, не зная его статус, отозван он или нет. У обоих вариантов есть свои преимущества и недостатки. Если браузер откажется принимать сертификат, то каждый раз при уходе инфраструктуры CA в офлайн ваши сайты тоже уходят туда же. Если браузер продолжит принимать сертификаты, то он рискует принять сертификат, который был украден, и подвергает пользователя риску. Это трудный выбор, но прямо сейчас, сегодня, ничего такого на самом деле не происходит…

Частичный сбой

На самом деле сегодня браузеры выполняют так называемую проверку отзыва сертификата с частичным сбоем. То есть браузер попытается проверить статус сертификата, но если ответ не пришёл совсем или не пришёл за короткий промежуток времени, то браузер просто забывает об этом. Ещё хуже, что Chrome даже не пытается проверить сертификат. Да, вы прочитали правильно, Chrome даже не пытается проверить статус сертификата, который ему поступает. Вы можете найти это странным, но я полностью согласен с их подходом и я рад сообщить, что Firefox тоже, вероятно, скоро начнёт работать так же. Позвольте объяснить. Проблема с полным сбоем очевидна: если у CA плохой день, то у нас тоже он будет, вот так мы пришли к логике частичного сбоя. Браузер теперь пытается осуществить проверку сертификата на предмет отзыва, но полностью отказывается от неё, если она занимает слишком много времени или если кажется, что CA ушёл в офлайн. Погодите, какие были последние слова? Проверка сертификата на предмет отзыва отменяется, «если кажется, что CA ушёл в офлайн». Интересно, может ли злоумышленник имитировать такие условия?

Если вы осуществляете атаку MiTM, то вам нужно всего лишь блокировать запрос на проверку сертификата и создать впечатление, что CA не работает. Браузер тогда столкнётся с частичным сбоем проверки и продолжит радостно использовать отозванный сертификат. Если вас никто не атакует, то каждый раз при проверке этого конкретного сертификата вы тратите время и ресурсы на проверку, что сертификат не отозван. И один раз, когда вас атакуют — тот единственный раз, когда вам по-настоящему нужна такая проверка — злоумышленник просто блокирует соединение, и браузер проходит через частичный сбой. Адам Лэнгли из Google лучше всех описал, что такое отзыв сертификата: это ремень безопасности, который рвётся в момент аварии, и он прав. Вы каждый день садитесь в машину и пристёгиваете ремень безопасности — и он даёт вам приятное и комфортное ощущение безопасности. А потом в один день что-то идёт не по плану — вы попадаете в аварию, и вот тут вы вылетаете в ветровое стекло. В тот единственный раз, когда он действительно нужен, ремень безопасности вас подводит.

Исправление проблемы

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

Проприетарные механизмы

Если сайт скомпрометирован и злоумышленник получил секретный ключ, то он может подделать этот сайт и причинить некоторый вред. Здесь ничего хорошего, но могло быть и хуже. Что если CA скомпрометирован и злоумышленник получил секретный ключ для промежуточного сертификата? Это было бы катастрофой, потому что тогда злоумышленник может подделать буквально любой сайт, который захочет, подписав собственный сертификат. Поэтому вместо онлайновой проверки промежуточных сертификатов на предмет отзыва у Chrome и Firefox есть собственные механизмы для той же задачи.

В Chrome он называется CRLsets, а в Firefox — OneCRL. Эти механизмы проверяют списки отозванных сертификатов, объединяя доступные CRL и выбирая оттуда сертификаты. Так проверяются особо ценные сертификаты вроде промежуточных, но что насчёт обычных, наших с вами?

OCSP Must-Staple

Чтобы объяснить, что такое OCSP Must-Staple, нужно сначала вкратце разобраться, что такое OCSP Stapling. Я не хочу здесь вдаваться в лишние подробности, вы можете получить всестороннюю информацию из моего блога по OCSP Stapling, но вот суть. OCSP Stapling избавляет браузер от необходимости отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе.

На первый взгляд это кажется немного странным, потому что сервер как будто «сам удостоверяет» собственный сертификат как неотозванный, но всё работает правильно. Ответ OCSP действует только короткий промежуток времени и подписан CA точно так же, как сертификат. Так что если браузер может удостовериться, что сертификат подписан CA, то точно так он может удостовериться, что ответ OCSP тоже подписан этим CA. Это устраняет большую проблему приватности и избавляет клиента от бремени выполнять внешний запрос. Лучший вариант! Но на самом деле не лучший, извините. OCSP Stapling — отличная вещь, и все мы должны поддерживать эту технологию на своих сайтах, но действительно ли мы думаем, что её будет поддерживать злоумышленник? Нет, я так не думаю, конечно же он не будет этого делать. Что нам на самом деле нужно — так это заставить сервер поддерживать OCSP Stapling, и вот для чего нужен OCSP Must-Staple. При запросе нашего сертификата у CA мы просим его установить на нём флаг OCSP Must-Staple. Этот флаг указывает браузеру, что сертификат должен поставляться с откликом OCSP или он будет отвергнут. Установить флаг легко.

После установки этого флага мы должны гарантировать, что используется OCSP Staple, иначе браузер отвергнет сертификат. В случае компрометации, если злоумышленник получит наш ключ, ему также придётся использовать OCSP Staple вместе с нашим сертификатом, а если он не включит OCSP Staple, то ответ OCSP скажет, что сертификат отозван, и браузер его не примет. Тада!

OCSP Expect-Staple

Хотя Must-Staple кажется отличным решением проверки отзыва сертификатом, это не совсем так. На мой взгляд, одной из самых больших проблем является то, что я как оператор сайта не могу точно знать, насколько надёжны метки OCSP Staple и как их принимает клиент. Без включенного OCSP Must-Staple это не является проблемой, но если включить OCSP Must-Staple и мы не уверены в надёжности или правильности OCSP Staple, это проблема для сайта. Чтобы попытаться и получить некую обратную связь о качестве меток OCSP Staple, мы можем активировать функцию под названием OCSP Expect-Staple. Я писал о ней раньше, и вы можете узнать все подробности в блоге OCSP Expect-Staple, но здесь тоже объясню вкратце. Вдобавок к списку предзагрузки HSTS вы запрашиваете браузер прислать отчёт, удовлетворён ли он меткой OCSP Staple. Вы можете собирать отчёты сами или использовать мой сервис report-uri.io, в обоих случаях вы точно узнаете, когда ваш сайт столкнулся с проблемами при работе OCSP Must-Staple. Поскольку использование списка предзагрузки HSTS не настолько очевидно, как мне бы хотелось, я также написал спецификацию для определения нового заголовка безопасности под названием Expect-Staple, чтобы обеспечивать ту же функциональность ценой меньших усилий. Идея в том, что теперь вы можете установить этот заголовок и включить функцию отправки отчётов, которые так нам нужны, ещё до активации Must-Staple. Установка заголовка будет простой, как и всех остальных заголовков безопасности:

Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io/r/d/staple"; includeSubDomains; preload

Поддельные сертификаты

Если мы говорим об отзыве сертификатов, то должны рассмотреть тему их подделки. Если некто пытается скомпрометировать CA или как-то ещё получить сертификат, который ему не положен, то как он будет действовать? Если я прямо сейчас взломаю CA и получу сертификат на ваш сайт, то вы не узнаете об этом до тех пор, пока об этом не сообщат в новостях. У вас в компании даже может быть инсайдер, который получит сертификат в обход внутренних процедур, и он будет делать с ним всё что захочет. Нам нужна стопроцентная прозрачность, и скоро мы её получим. Это Certificate Transparency.

Certificate Transparency

CT — новое требование, которое станет обязательным в начале следующего года. Оно предусматривает, что все сертификаты должны заноситься в публичный журнал, чтобы браузер им доверял. Вы можете почитать статью с более подробным описанием CT, но суть в том, что CA заносит все выданные сертификаты в журнал CT.

Эти журналы полностью открыты, и любой может посмотреть их, так что если кто-то получит сертификат на ваш сайт, то вы об этом узнаете. Например, здесь вы можете увидеть все сертификаты, выданные на мой домен, и поискать свой собственный. Есть также сервис CertSpotter от sslmate для той же цели, а я использую инструмент Facebook Certificate Transparency Monitoring, который присылает вам письмо каждый раз, когда выдан сертификат на заданный домен. Стандарт CT — это фантастическая идея, и я не могу дождаться, когда он станет обязательным, но есть одна оговорка. Дело в том, что CT — это только первый шаг. Знать об этих сертификатах хорошо, но у нас по-прежнему остаются все упомянутые проблемы с их отзывом. Тем не менее, мы можем решать только по одной проблеме за раз, и даже самые лучшие в мире механизмы отзыва неэффективны, если мы не знаем, какие сертификаты нужно отзывать. CT по крайней мере даёт нам эту информацию.

Авторизация центров сертификации

Предотвратить выдачу сертификата намного проще, чем пытаться отозвать его, и именно для этого нужна авторизация центров сертификации (CAA). Опять же, подробности есть в статье по ссылке, но вкратце суть в том, что мы можем авторизовать только конкретные центры сертификации выдавать нам сертификаты, в отличие от нынешней ситуации, когда мы не можем указать вообще никаких предпочтений. Авторизация делается так же просто, как создание записи DNS:

scotthelme.co.uk. IN CAA 0 issue «letsencrypt.org»

Хотя авторизация CA — не особенно сильный механизм, и он не способен помочь во всех ситуациях некорректной выдачи сертификатов, но в некоторых случаях он полезен, так что следует заявить о своих предпочтениях, создав запись CAA.

Заключение

В настоящий момент существует реальная проблема, что мы не можем отозвать сертификат, если кто-то получил наш секретный ключ. Только представьте, во что это выльется при раскрытии следующей глобальной уязвимости масштаба Heartbleed! Одна вещь, которую вы можете попытаться сделать — это ограничить размер ущерба от утечки, сократив срок действия своего сертификата. Вместо трёх лет указывайте один год или даже меньше. Let’s Encrypt выдаёт только сертификаты, которые действительны всего лишь 90 дней! С сокращением времени жизни вашего сертификата у злоумышленника будет меньше времени для злоупотреблений. Кроме этого мы мало что можем сделать.

Для демонстрации проблемы и того, насколько она реальна, попробуйте зайти на новый поддомен, который я открыл на своём сайте, revoked.scotthelme.co.uk. Как вы вероятно догадываетесь, к этому поддомену прикреплён отозванный сертификат, и вполне вероятно, что он нормально загрузится в вашем браузере. Если нет, если ваш браузер выдаст предупреждение об истёкшем сроке действия, то это значит, что ваш браузер по-прежнему отправляет запросы OCSP и вы только что сообщили в CA о том, что посетили мой сайт. Для доказательства, что такая проверка с мягким сбоем бесполезна, можете добавить в hosts домен ocsp.int-x3.letsencrypt.org с IP-адресом 127.0.0.1 или блокировать его каким-нибудь другим способом — и повторить попытку подключения. На этот раз страница нормально загрузится, потому что проверка отозванного сертификата не сработает, а браузер продолжит загружать страницу. Толку от такой проверки…

Я бы хотел закончить статью вопросом: следует ли нам исправлять процедуру отзыва сертификатов? Впрочем, это тема для другой статьи.

  • Информационная безопасность
  • Веб-разработка
  • Криптография

Как браузер работает с SSL сертификатами

Независимо от каких-либо расширений браузеры должны всегда проверять основную информацию о сертификате, такую как подпись или издатель. Шаги проверки информации о сертификате:

Проверка целостности сертификата. Выполняется с помощью криптографической операции Verify , выполняемой с открытым ключом. Если подпись недействительна, то сертификат считается поддельным, который был изменён после его выдачи третьей стороной, и отклоняется.

Проверка действительности сертификата. Выполняется с помощью криптографической операции Decrypt и считыванием сопутствующей информации. Сертификат считается действительным в течение оплаченного клиентом периода либо срока годности. Срок годности сертификата – это срок гарантии подлинности владельца со стороны Удостоверяющего центра, осуществившего его выпуск. Браузеры отклоняют любые сертификаты со сроком годности, истёкшим до или начавшимся после даты и времени проверки.

Проверка статуса отзыва сертификата. Выполняется с помощью криптографической операции Decrypt , загрузкой и сверкой c CRL. Ряд обстоятельств, например, обращение правоохранительных органов, обнаружение изменения исходной информации или подтверждение факта компрометации закрытого ключа сервера могут привести к тому, что сертификат станет недействительным до истечения срока его действия. Для этого сертификат добавляют в CRL на стороне Удостоверяющего центра. Центры сертификации на периодической основе выпускают новую версию подписанного CRL, который распространяется в общедоступных репозиториях. Браузеры получают и просматривают последнюю версию CRL при проверке сертификата. Главный недостаток такого подхода заключается в ограничении проверки периодом выдачи CRL. Браузер будет уведомлён об отзыве только после того, как получит актуальный CRL. В зависимости от политики подписывающего Удостоверяющего центра период обновления CRL может исчисляться неделями. При работе с TLSv2 и TLSv3 браузер может использовать протокол определения состояния сетевого сертификата OCSP, описанного в RFC 6960. OCSP позволяет браузеру запрашивать статус отзыва определённого сертификата в режиме онлайн (операция reply). При корректной настройке OCSP проверка наличия сертификата в CRL выполняется намного быстрее и позволяет избежать использования фактически отозванных сертификатов до следующего обновления CRL. Существует технология OCSP Stapling, позволяющая включать копию ответа на запрос состояния сертификата от Удостоверяющего центра в заголовки HTTP-ответов веб-сервера, что в свою очередь повышает производительность и скорость обмена данными.

Проверка издателя сертификата по цепочке сертификатов. Сертификаты обычно связаны с несколькими Удостоверяющими центрами: корневым, который является владельцем открытого ключа подписи сертификатов, и рядом промежуточных, которые ссылаются на предыдущего владельца открытого ключа вплоть до корневого. Браузеры проверяют сертификаты каждого Удостоверяющего центров на предмет нахождения в цепочке доверия с корневым во главе. Для дополнительной безопасности большинство реализации PKI также проверяют, что открытый ключ Удостоверяющего центра совпадает с ключом, которым был подписан текущий сертификат. Таким образом, определяются самоподписанные сертификаты, т.к. они имеют одного и того же издателя только на том сервере, где были выпущены, либо были добавлены в список корневых сертификатов. Формат X.509 v3 позволяет определять какие именно сертификаты цепочки следует проверить. Данные ограничения редко влияют на обычного пользователя Интернета, хотя они довольно часто встречаются в корпоративных системах на этапе разработки и отладки.

Проверка ограничения доменного имени

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

Проверка политики выпуска сертификата

Политика выпуска сертификатов – это юридический документ, опубликованный Удостоверяющим центром, в котором подробно описываются процедуры выдачи и управления сертификатами. Удостоверяющие центры могут выдавать сертификат в соответствии с одной или несколькими политиками, ссылки на которые добавляются в информацию выпущенного сертификата, чтобы проверяющие стороны могли валидировать данные эти политики, прежде чем принять решение о доверии этому сертификату. Например, могут накладываться ограничения регион или временн ы е (на период технологического обслуживания программного обеспечения Удостоверяющего центра) рамки.

Проверка длины цепочки сертификата

Формат X.509 v3 позволяет издателям определять максимальное количество промежуточных удостоверяющих центров, которые могут поддерживать сертификат. Данное ограничение было введено после того, как в 2009-м году была продемонстрирована возможность подделки действительного сертификата путём включения самоподписанного сертификата в очень длинную цепочку.

Проверка назначения открытого ключа

Браузер проверяет назначение открытого ключа, содержащегося в сертификате шифрование, подписи, подпись сертификата и так далее. Браузеры отклоняют сертификаты, например, в случае обнаружения сертификата сервера с ключом, предназначенным только для подписи CRL.

Проверка остальных сертификатов цепочки

Браузер выполняет проверку каждого сертификата цепочки. Если данные проверки завершились без ошибок, то вся операция считается действительной. Если возникают какие-либо ошибки, то цепочка помечается как недопустимая, и безопасное соединение не устанавливается.

Как посмотреть сведения о сертификате и проверить, что все работает корректно

Сертификат безопасности можно проверить непосредственно в браузере. Все современные браузеры отображают сведения о сертификате непосредственно в адресной строке. Признак установки защищённого соединения с веб-ресурсом представлен в виде замка в левой части адресной строки браузера. В случае ошибки будет отображаться перечёркнутое слово «HTTPS» или пиктограмма в виде открытого замка. В зависимости от вида браузера и его версии вид пиктограмм и поведение при работе с SSL-сертификатами может отличаться. Ниже приведены примеры изображений для различных версий современных браузеров:

Как на безопасность сайтов повлияет отзыв SSL-сертификатов у банков

У попавших под санкции банков и Центробанка отозвали SSL-сертификаты, обеспечивающие безопасность сайта и сохранность персональных данных. Они уже получили новые сертификаты и угрозы данным клиентов нет

Фото: Владислав Шатило / РБК

Фото: Владислав Шатило / РБК

После внесения в санкционный список ЦБ, ВТБ, Совкомбанка и Промсвязьбанка сайты этих организаций на некоторое время могли снизить уровень защиты специальным сертификатом, хотя банки утверждали, что санкции не повлияют на уровень безопасности. Первым на это во вторник, 1 марта, обратил внимание «Деловой Петербург». По его информации, хостинг-провайдер DigiCert (США) отозвал у Центробанка сертификат TLS — один из версий протокола SSL, который обеспечивает подлинность сайта и защиту персональных данных на нем. В тот же день сайт ВТБ не позволил провести транзакцию из-за просроченного SSL-сертификата, убедился корреспондент РБК. На сайте банка отображалась ошибка cert_revoked — что означает, что сертификат отсутствует (или неправильно установлен, или просрочен, или отозван), пояснил РБК один из участников ИТ-рынка. Согласно информации из Telegram-каналов, до недавнего времени у ВТБ был SSL-сертификат от Thawte Consulting (ЮАР).

Что такое SSL-сертификат SSL-сертификат отображается в левом углу адресной строки браузера в виде закрытого замка. Так пользователь может определить, является ли сайт надежным или фишинговым. Во втором случае персональные и платежные данные, оставленные на таком сайты, попадут злоумышленникам, как и сам платеж. SSL-сертификаты выпускают удостоверяющие центры — специальные организации, они также поддерживают их работу. Как пояснил руководитель направления ГОСТ VPN компании «Ростелеком-Солар» Александр Веселов, существуют три основные цели использования таких сертификатов: шифрование данных между пользователем и сайтом; сертификат выступает в качестве своеобразного «удостоверения личности» для организации и защищает пользователя от фишинговых сайтов; улучшает ранжирование в поиске — сайты, у которых сертификат отсутствует, опускаются ниже в выдаче.

Какие риски существуют

В среду, 2 марта, сайт Центробанка получил новый сертификат, подтвержденный бельгийской компанией GlobalSign. Он действителен до 2 апреля 2023 года. ВТБ еще 1 марта получил новый сертификат, и он одобрен удостоверяющим центром.

Фото:Евгений Разумный / Ведомости / ТАСС

В Центробанке и ВТБ не ответили на запрос РБК. Представитель технической поддержки DigiCert на вопрос, действительно ли они отозвали сертификат у ЦБ и намерены ли поступать так же с другими российскими организациями, сообщил, что компания «действует в соответствии с законодательством своей страны и внимательно отслеживает международную обстановку, а именно — все санкции, которые вводятся против России со стороны США и других стран». Аналогичный ответ предоставил представитель Thawte. 24 февраля США, ЕС и ряд других стран объявили о санкциях в отношении ЦБ, ряда банков и физлиц из России в ответ на проведение спецоперации на Украине. ВТБ, банк «Открытие», Совкомбанк, Промсвязьбанк и Новикомбанк попали под самые жесткие санкции из-за аффилированности с госструктурами России: их активы и счета в долларах США заблокированы, карты перестанут работать за границей, они не смогут поддерживать сервисы Apple Pay, Google Pay и Samsung Pay. Среди перечисленных банков 1 марта новый сертификат появился также у Совкомбанка и Промсвязьбанка, следует из технической информации на их сайтах.

Фото:Victor J. Blue / Bloomberg

  • пойти к другому удостоверяющему центру;
  • сделать свой «самописный» сертификат, используя программное обеспечение удостоверяющего центра;
  • попробовать получить сертификат у российских удостоверяющих центров.

Он привел в пример удостоверяющие центры при Центробанке и Казначействе. В то же время Лукацкий предположил, что коммерческие компании могут воспользоваться услугами ФНС, так как взаимодействие с налоговой подразумевает получение у последней сертификата, однако «до этого такая практика не применялась». Также эксперт напомнил, что Минцифры работает над созданием российского головного удостоверяющего центра, но его пока не успели запустить, для этого необходимо доработать законодательство. «Есть еще вариант запустить в России свой национальный удостоверяющий центр, который будет выдавать SSL-сертификаты российским компаниям и ведомствам. Однако не уверен, что все коммерческие компании на это согласятся, так как это предоставит возможность полностью контролировать трафик, перехватывать персональные данные и т.д.», — рассуждает Лукацкий.

Фото:Андрей Рудаков / Bloomberg

Александр Веселов напомнил, что это уже не первый случай отзыва SSL-сертификатов у российских сайтов. Например, в 2018 году американская компания GeoTrust отозвала сертификат у сайта Торгово-промышленной палаты России. Он также отметил, что ряд сайтов российских госорганов работает вообще без них, «это объясняется тем, что такие сайты выполняют преимущественно информационную функцию: там нет форм авторизации и личного кабинета».

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

При этом браузер может не одобрить SSL-сертификат, тогда у пользователей будет на сайте отображаться предупреждение, что сайт не безопасен, указывает Лукацкий. «Тогда отличить фишинговый сайт от сайта с непринятым сертификатом будет сложнее», — предупредил эксперт.

Фото:Андрей Любимов / РБК

Эксперт по безопасности «Лаборатории Касперского» Денис Паринов говорит, что при посещении сайта с отозванным сертификатом все браузеры реагируют по-разному. «Как правило, показывают предупреждение о недоверенном сертификате, но при этом позволяют открыть сайт. При посещении сайта, использующего отозванный сертификат, могут возникнуть неудобства, ошибки при работе, например, в личном кабинете. Чтобы это исправить, администраторы сайтов могут выписать новый сертификат в авторизованном центре сертификации», — комментирует он. По его мнению, сейчас нет признаков массовых отзывов, пока «речь идет о единичных случаях отзывов сертификатов, выписанных Thawte».

По мнению ведущего специалиста отдела аудита Infosecurity в Softline Анатолия Сазонова, отзыв сертификатов может стать массовой историей в условиях, когда большая часть удостоверяющих центров находится за рубежом, а «отечественный глобальный удостоверяющий центр находится в процессе создания». «Но даже при условии запуска российского центра его сертификат тоже может быть не принят, как это было с китайским центром China Internet Network Information Center», — выражает опасения он.

Впрочем, менеджер по продуктам хостинг-провайдера REG.RU Антон Бобков заверил, что они находятся на связи со всеми ключевыми удостоверяющими центрами и на данный момент не видят предпосылок к прекращению сотрудничества. В то же время он оговорился, что прогнозировать отказ всех иностранных удостоверяющих центров сложно.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *