Кратко

  • По сообщению APNIC, отозванный сертификат Let's Encrypt находился в CRL. В описанном опыте Chrome и Safari не распознали отзыв, Firefox распознал.
  • Это результат одного испытания, а не универсальное свойство всех версий браузеров. Подпись под списком, доставка списка и отказ клиента — разные события.
  • Сокращение срока сертификатов, OCSP, прикрепление ответа и DNSSEC/DANE меняют разные временные и доверительные границы, но сами по себе не доказывают немедленную защиту.

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

Отчёт APNIC от 21 сентября пересказывает демонстрацию главного научного сотрудника организации Джеффа Хьюстона. Он выпустил и отозвал сертификат Let's Encrypt; запись появилась в списке отзыва. Chrome и Safari в испытании не распознали отзыв, Firefox распознал. Отчёт не содержит полной воспроизводимой таблицы версий, платформ, настроек, сетевых условий и точного времени каждого подключения. Из него нельзя заключать, что какой-либо браузер никогда не проверяет статус или что известна доля подвергшихся риску пользователей.

У отзыва несколько часов. Сначала обнаруживают проблему, затем запрашивают отзыв, CA формирует и публикует новую запись, распространители обновляют данные, клиент получает и применяет их; независимо наступает срок окончания сертификата. CRL подписан и имеет время выпуска и следующего обновления. В апрельском разборе Хьюстон объясняет, почему ранее полученная копия может ещё считаться допустимой, хотя в ней нет нового отзыва, и почему загрузка большого списка при каждом TLS-соединении стоит времени. APNIC приводит пример еженедельного списка с 17 527 записями и семидневного цикла. Это масштаб доставки, а не число пострадавших или измеренная длительность вреда.

OCSP позволяет спросить о конкретном сертификате без загрузки полного списка. За это приходится платить зависимостью от доступности сервера ответов, задержкой и возможностью раскрыть ему историю обращений к сайтам. Подписанный ответ имеет внутренние границы времени; верная подпись не превращает вчерашнее «действителен» в сегодняшнюю истину. При OCSP stapling ответ приносит сам сервер. Прямая проверка становится менее затратной, но сервер, который по-прежнему предъявляет отозванный сертификат, не обязан добровольно сообщать новую неприятную информацию. Политика клиента при отсутствии ответа остаётся отдельным выбором.

В апрельском тексте описана другая проверка браузеров, связанная с OCSP: Safari там вёл себя иначе, чем в сентябрьском опыте с CRL. Эти наблюдения не следует усреднять. Механизм, кэш и условия различны; доказательство относится к каждому эксперименту в его собственных границах.

Короткий срок действия сокращает остаточный период использования старого сертификата, если клиент проверяет дату и оператор надёжно обновляет все узлы. Это не мгновенный отзыв украденного ключа; ошибки продления могут вызвать простой. В материалах APNIC 62 Хьюстон предлагает рассмотреть DNSSEC и DANE с более короткими сроками жизни записей DNS. Предложение не является свидетельством повсеместного перехода браузеров на такую архитектуру.

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

Источники