Кратко

  • Сервер мог приложить к обмену TLS подписанный ответ OCSP о состоянии сертификата. Доставка не давала ему права самостоятельно создавать такой ответ и не отменяла проверку со стороны клиента.
  • Повторное использование ответа сокращало обращения к внешней службе, но требовало следить за его свежестью. Обещание функции в сертификате могло сделать отсутствие ответа значимым и одновременно связать ввод сертификата в работу с готовностью доказательства.

Несовпадение двух готовностей

Сертификат выдан, ключ установлен, сервер готов его предъявлять. Всё же может недоставать ещё одного объекта: ответа о статусе, который клиент вправе ожидать вместе с сертификатом.

Это не вымышленная авария, а последовательность, отдельно разобранная в RFC 7633. Документ 2015 года рекомендовал не начинать использование нового сертификата до появления необходимых ответов OCSP. Иначе даже законно выданный сертификат мог сопровождаться конфигурацией, не выполняющей заявленное условие.

Почему проверке понадобилась такая связка? Ответ лежит в более раннем решении: передать серверу доставку сведений, не передавая ему полномочия определять их содержание.

Проверяемая сторона стала доставщиком

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

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

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

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

Сокращение маршрута началось в 2003 году

В июне 2003 года RFC 3546 уже описывал status_request: клиент мог попросить сведения о статусе, сервер — передать ответ OCSP вслед за сертификатом. Среди причин назывались ограниченные сетевые ресурсы, передача списков отзыва и лишние обмены.

В январе 2011 года RFC 6066 изложил расширение в последующей системе TLS. Ответ целиком переносился отдельным сообщением CertificateStatus. Поэтому считать 2011 год датой возникновения идеи было бы неверно: это более позднее описание уже существующего механизма.

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

Подпись сохраняется дольше, чем полезность

Ответ выгодно было подготовить заранее и использовать повторно. Лёгкий профиль RFC 5019, опубликованный в сентябре 2007 года, рассматривал предварительное производство, распространение и кэширование как средства масштабирования.

Однако подлинность не устраняет возраст. thisUpdate обозначает момент, когда указанный статус был известен как правильный; producedAt — момент подписания; nextUpdate — срок, к которому станет доступна более новая информация. Поздняя подпись не делает прежнее наблюдение новым.

Лёгкий профиль требует наличия nextUpdate и проверки по точному источнику времени. В базовом OCSP поле может отсутствовать. Нельзя переносить требование одного профиля на все ответы протокола. Не защищённые подписью HTTP-заголовки кэширования также не могут сами по себе продлить допустимость подписанного статуса.

Сохранённый ответ мог помочь пережить временную недоступность службы. Но только пока он оставался приемлемым по правилам клиента. Когда этот запас времени исчерпывался, прежняя экономия запросов уже не решала проблему. Более свежий отзыв не изменял автоматически все ранее разосланные ответы good.

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

Молчание не было ответом об отзыве

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

RFC 6066 прямо предупреждал о злоумышленнике с скомпрометированным ключом, который мог притвориться сервером без поддержки расширения. Клиенту, требующему проверки OCSP, следовало обратиться к ответчику непосредственно либо прервать попытку. Полученный, но неприемлемый ответ был другой ситуацией, требовавшей прекращения согласования. Отсутствие, неизвестный статус, устаревание и отзыв нельзя объединять в один сигнал.

Расширение X.509 TLS Feature из RFC 7633 позволяло записать status_request в сертификат. Это основа механизма, обычно называемого Must-Staple. Поддерживающий клиент получал аутентифицированное ожидание, с которым мог сравнить фактическое поведение сервера.

Документ не заставлял все клиенты реализовать любую функцию и предусматривал альтернативные способы проверки. Поэтому речь не шла об одном глобальном переключателе отказа. Но сервер должен был выполнять заявленное. Так становится понятна осторожность с новым сертификатом: выдача и готовность всего комплекта для предъявления — разные события.

Контейнер сменился, разделение осталось

RFC 8446 в 2018 году поместил статус TLS 1.3 в расширение соответствующей записи CertificateEntry, а не в прежнее отдельное сообщение. Перемена упаковки не сделала сервер источником полномочий и не отменила проверку времени.

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

Источники

RFC 3546, RFC 6066, RFC 6960, RFC 5019, RFC 7633 и RFC 8446. Выводы о распределении работы следуют из требований документов; данные о современной распространённости здесь не заявляются.