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

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

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

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

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

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

DNSCrypt

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

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

Как работает 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-серверов, у которых истёк срок действия сертификата за последние два или три года», — пишет Фрэнк Денис. В любом случае, наверное, лучше сначала предупреждать пользователей, а не отключать расширения без предупреждения.

Источник: habr.com