Как DNSCrypt решил проблему просроченных сертификатов, введя срок действия 24 часа / Хабр

Что произойдет 30 сентября?

Срок действия DST Root CA X3 подходит к концу 30 сентября 2021 14:01:15 GMT, что произойдет после этого?

Те системы, которые недоверяют ISRG Root X1, перестанут доверять сертификатам, выпущенным Let’s encrypt (системы будут выдавать предупреждения при посещении сайтов, использующих сертификаты Let’s Encrypt). За исключением Android >= v2.3.6, т.к. Android не учитывает срок действия своих доверенных корневых сертификатов.

Проблема с доверием возникнет также у систем, использующих OpenSSL версии меньше 1.1.0. Даже если у таких систем ISRG Root X1 входит в список доверенных сертификатов, особенность проверки сертификата в OpenSSL 1.0.x приведёт к тому, что наличие в цепочке истекшего DST Root CA X3, несмотря на наличие доверия к ISRG Root X1, будет приводить к отрицательному результату проверки на доверие. Аналогичная проблема у OpenSSL 1.0.x возникла 20 мая 2020 года с истекшим сертификатом AddTrust External CA Root.

Ошибка ssl.срок действия его сертификата безопасности истек вчера. что делать?

Linux

Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let’s Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.

Брандмауэр или антивирус, блокирующие сайт

Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет.

Включенный экспериментальный протокол quic

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

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

• После этого просто перезапустите браузер.

Этот способ работает и в Windows и в Mac OS.

Использование ssl-сертификата версии 3.0

Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):

• Откройте браузер и перейдите в раздел «Настройки».
• Прокрутите страницу настроек вниз и нажмите «Дополнительные».
• В разделе «Система» найдите параметр «Настройки прокси-сервера» и кликните на него.

• Откроется окно. Перейдите на вкладку «Дополнительно».
• В этой вкладке вы увидите чекбокс «SSL 3.0».

• Поставьте галочку в чекбоксе, нажмите кнопку «Ок» и перезагрузите браузер.

Как dnscrypt решил проблему просроченных сертификатов, введя срок действия 24 часа

Раньше сертификаты часто истекали из-за того, что их нужно было обновлять вручную. Люди просто забывали это сделать. С появлением Let’s Encrypt и автоматической процедуры обновления вроде бы проблема должна быть решена. Но недавняя история с Firefox показывает, что на самом деле она по-прежнему актуальна. К сожалению, сертификаты продолжают истекать.

Если кто-то пропустил эту историю, в полночь 4 мая 2021 года внезапно прекратили работать почти все расширения Firefox.

Как выяснилось, массовый сбой возник из-за того, что у Mozilla истёк срок действия сертификата, который использовался для подписи расширений. Поэтому они отмечались как «невалидные» и не проходили проверку (технические детали). На форумах в качестве обходного пути рекомендовали отключить проверку подписей расширений в about:config или переводом системных часов.

Mozilla оперативно выпустила патч Firefox 66.0.4, который решает проблему с невалидным сертификатом, а все расширения возвращаются в нормальный вид. Разработчики рекомендуют установить его и не использовать никакие обходные пути для обхода проверки подписей, потому что они могут конфликтовать с патчем.

Тем не менее, эта история ещё раз показывает, что истечение срока действия сертификатов остаётся актуальной проблемой и сегодня.

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

DNSCrypt — протокол шифрования DNS-трафика. Он защищает DNS-коммуникации от перехватов и MiTM, а также позволяет обойти блокировки на уровне DNS-запросов.

Протокол оборачивает DNS-трафик между клиентом и сервером в криптографическую конструкцию, работая по транспортным протоколам UDP и TCP. Чтобы его использовать, и клиент, и DNS-резолвер должны поддерживать DNSCrypt. Например, с марта 2021 года его включил на своих DNS-серверах и в браузере «Яндекс». О поддержке объявили и некоторые другие провайдеры, в том числе Google и Cloudflare. К сожалению, их не так много (на официальном сайте перечислено 152 публичных DNS-сервера). Но программу dnscrypt-proxy можно установить вручную на клиентах под Linux, Windows и MacOS. Есть и серверные имплементации.

Про сертификаты:  Ограждение кровли со снегозадержанием H=600мм L=2000мм купить по недорогой цене в Москве

Как работает DNSCrypt? Если вкратце, то клиент берёт публичный ключ выбранного провайдера и с его помощью проверяет его сертификаты. Уже там находятся краткосрочные публичные ключи для сессии и идентификатор набора шифров. Клиентам рекомендуется генерировать новый ключ для каждого запроса, а серверам — менять ключи каждые 24 часа. При обмене ключами применяется алгоритм X25519, для подписи — EdDSA, для блочного шифрования — XSalsa20-Poly1305 или XChaCha20-Poly1305.

Один из разработчиков протокола Фрэнк Денис пишет, что автоматическая замена каждые 24 часа решила проблему просроченных сертификатов. В принципе, эталонный клиент dnscrypt-proxy принимает сертификаты с любым сроком действия, но выдаёт предупреждение «Период dnscrypt-proxy ключей для этого сервера слишком велик», если он действителен более 24 часов. Одновременно был выпущен образ Docker, в котором реализовали быструю смену ключей (и сертификатов).

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

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

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

В то же время, если автоматизация настроена нормально, то не имеет значения, как часто производится смена ключей: каждый год, каждый квартал или три раза в день. Если всё работает более 24 часов, то будет работать вечно, пишет Фрэнк Денис. По его словам, рекомендация ежесуточной смены ключей во второй версии протокола вместе с готовым образом Docker, реализующим это, эффективно уменьшило количество серверов с истёкшими сертификатами, одновременно улучшив безопасность.

Однако некоторые провайдеры всё-таки решили по каким-то техническим причинам установить срок действия сертификата более 24 часов. Эту проблему в основном решили с помощью нескольких строк кода в dnscrypt-proxy: пользователи получают информационное предупреждение за 30 дней до истечения срока действия сертификата, другое сообщение с более высоким уровнем серьёзности за 7 дней до истечения срока действия и критическое сообщение, если у сертификата осталось менее 24 часов. Это относится только к сертификатам, изначально имеющим длительный срок действия.

Такие сообщения дают пользователям возможность сообщить операторам DNS о предстоящем истечении срока действия сертификата, пока не стало слишком поздно.

Возможно, если бы все пользователи Firefox получили такое сообщение, то уж кто-нибудь наверняка сообщил разработчикам и те бы не допустили истечения срока действия сертификата. «Я не помню ни одного DNSCrypt-сервера из списка общедоступных DNS-серверов, у которых истёк срок действия сертификата за последние два или три года», — пишет Фрэнк Денис. В любом случае, наверное, лучше сначала предупреждать пользователей, а не отключать расширения без предупреждения.

Про сертификаты:  Кто может проверять тахографы и РТО на трассе – Безопасность и страхование – АТИ, Центр: Система грузоперевозок

---

На стороне сервера

На стороне сервера от вас мало что зависит. Если вы используете сертификаты от Let’s Encrypt на своем сервере, то должны понимать, что после 30 сентября 2021 14:01:15 GMT к вашему серверу смогут без проблем подключиться только клиенты, доверяющие ISRG Root X1 (см. список выше), а также использующие Android >= v2.3.6. При этом, если клиенты используют OpenSSL, то они должны пользоваться версией OpenSSL >= 1.1.0.

При этом, у вас есть выбор – ценой отказа от поддержки старых Android (оставив поддержку Android >= 7.1.1), вы можете сохранить поддержку OpenSSL 1.0.x без манипуляций на стороне клиента.

Для этого нужно использовать предлагаемую Let’s Encrypt альтернативную цепочку доверия для своих сертификатов. В этой цепочке исключен DST Root CA X3 и выглядит она так: 

ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Отсутствие обновлений операционной системы

Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.

Ошибки «invalid csr» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

Причины возникновения ошибок ssl-соединения

Когда сертификат работает корректно, адресная строка браузера выглядит примерно так:

Но при наличии ошибок она выглядит несколько иначе:

Существует множество причин возникновения таких ошибок. К числу основных можно отнести:

• Некорректную дату и время на устройстве (компьютер, смартфон, планшет и т.д.);
• Ненадежный SSL-сертификат;
• Брандмауэр или антивирус, блокирующие сайт;
• Включенный экспериментальный интернет-протокол QUIC;
• Отсутствие обновлений операционной системы;
• Использование SSL-сертификата устаревшей версии 3.0;
• Появление ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера.

Давайте рассмотрим каждую из них подробнее.

Проблемы с датой и временем

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

Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался