Кратко
- Staple — подписанное утверждение о конкретном CertID в определённые моменты. Подпись подтверждает полномочие ответчика, а не знание всех последующих отзывов и не создание ответа для данного соединения.
producedAt,thisUpdate,nextUpdate, получение, HTTP-возраст, установка, часы клиента и допустимый максимум — разные границы.- TLS переносит доказательство, но решение принимает клиент. Нужны CertID, делегирование, статус, время, происхождение кэша, позиция в цепочке, Must-Staple и явная политика отказа.
Ответ пережил событие
Ответчик подписал good в 09:55, сервер получил его в 09:57, а отзыв произошёл через десять минут. Проверка подписи и временного окна не могла задним числом добавить новое событие.
CertID связывает вопрос с хэшами имени и ключа издателя, серийным номером и алгоритмом. Правильный ответ для другого номера — ответ на другой вопрос; состояние конечного сертификата не покрывает автоматически промежуточный.
RFC 6960 даёт good узкий минимум: действующий сертификат с таким номером не числится отозванным. Это не всегда доказывает факт выдачи и не обещает мгновенного поступления событий после thisUpdate.
Подписывать должен издатель либо явно уполномоченный OCSP-ответчик. Верная подпись ключом без делегирования не имеет полномочий; уполномоченный ключ может подписать прежнее состояние. Поэтому сохраняют CertID, позицию в цепочке, сертификат ответчика, делегирование, результат подписи и хэш исходных байтов.
Время и кэш входят в модель безопасности
producedAt — время подписи, thisUpdate — последний известный правильный статус, nextUpdate — граница появления более новой информации. RFC 6960 допускает предварительную подготовку, а RFC 9919 строит профиль вокруг кэширования и требует nextUpdate.
В эксплуатации добавляются момент отзыва, загрузка у ответчика, Date/Age HTTP, получение, повторная проверка, установка, handshake и часы клиента. Допуск рассинхронизации не создаёт свежесть. Будущий thisUpdate, прошедший nextUpdate и превышенный локальный возраст — отдельные причины отказа.
Кэш уменьшает задержку, защищает приватность и не ставит доступность ответчика на путь каждого handshake. Сервер должен записывать источник, HTTP-заголовки, хэш, получение, перепроверку, установку и срок обновления. Ответ, действительный при запуске, ничего не говорит о работающем обновлении.
Nonce, TLS и Must-Staple имеют разные полномочия
Nonce связывает запрос с ответом. Общий staple обычно не имеет нового nonce каждого клиента; его актуальность опирается на подписанный интервал, предел возраста и обновление. Новый handshake не означает новый ответ.
До TLS 1.2 клиент предлагает status_request, сервер может прислать CertificateStatus; TLS 1.3 привязывает статус к записям сертификатов. Код IANA подтверждает механизм, но не переговоры и принятие.
Наличие не равно пригодности: BoringSSL отдаёт сырые байты без гарантии корректного формата; OpenSSL разделяет запрос, установку и чтение. Отсутствие может означать, что клиент не просил статус, сессия возобновлена без сертификатов или действует soft fail.
Must-Staple регулирует отсутствие: клиент может отвергнуть соединение без требуемого статуса. Это не универсальная реализация и не исправление неверного CertID, делегирования, подписи, времени, unknown или revoked.
Решает работающий контур обновления
TLS 1.3 может нести ответы для нескольких позиций цепочки, старые версии обычно — один для конечного сертификата. Число и позиции нельзя сводить к enabled=true. Возобновление без обмена сертификатами не является новой проверкой OCSP.
OpenSSL отдельно выполняет поиск CertID, чтение статуса, проверку времени с допуском/максимальным возрастом и полномочий подписи. GnuTLS интегрирует проверку, но требует периодического обновления и иногда смены активных credentials. BoringSSL рекомендует получать и обновлять ответы вне handshake.
Негативные тесты: чужой серийный номер, неуполномоченный ответчик, будущий thisUpdate, истёкший nextUpdate, древний ответ без лимита, повреждённые байты, отсутствие обязательного staple, неполная цепочка, неверный учёт возобновления, остановленный обновитель и перевод часов назад. Тревога должна появиться раньше массового отказа.
Источники
- https://www.rfc-editor.org/rfc/rfc6960.html
- https://www.rfc-editor.org/rfc/rfc9919.html
- https://www.rfc-editor.org/rfc/rfc8954.html
- https://www.rfc-editor.org/rfc/rfc6066.html
- https://www.rfc-editor.org/rfc/rfc9846.html
- https://www.rfc-editor.org/rfc/rfc7633.html
- https://www.rfc-editor.org/rfc/rfc9325.html
- https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
- https://docs.openssl.org/3.6/man3/SSL_CTX_set_tlsext_status_cb/
- https://docs.openssl.org/3.6/man3/OCSP_resp_find_status/
- https://www.gnutls.org/manual/html_node/OCSP-stapling.html
- https://www.gnutls.org/manual/html_node/OCSP-API.html
- https://boringssl.googlesource.com/boringssl/+/refs/heads/main/include/openssl/ssl.h
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
