HSTS задаёт требование HTTPS, HPKP — дополнительное ограничение ключей цепочки у поддерживающего клиента. Один механизм не доказывает наличие другого.
Практический смысл
Почему это важно
У механизма есть три разные характеристики: документ IETF, реализация в конкретном клиенте и эксплуатационный риск закреплённого набора. Проверка только одной из них даёт неверную картину.
Доказательная часть
Что подтверждено
На 8 сентября 2026 года RFC 7469 сохраняет статус Proposed Standard и не переведён в Historic. Сам этот статус не подтверждает наличие поддержки HPKP в конкретном браузере.
Граница применимости: Статус документа RFC 7469 на указанную дату; сведения о реализации конкретного клиента проверяются отдельно.
HSTS требует защищённого транспорта для известного узла, а HPKP вводит ограничение на ключи принимаемой цепочки у поддерживающего клиента. Наличие HSTS не доказывает настроенное закрепление ключей.
Граница применимости: Сопоставление RFC 6797 и RFC 7469; свойства механизмов разделены, поддержка HPKP современным клиентом не предполагается.
Если применяемое клиентом закрепление допускает прежний набор ключей, а после замены доступна только цепочка вне этого набора, обычной корректности TLS-сертификата недостаточно для принятия соединения. Поэтому ротацию проверяют вместе с конкретным механизмом закрепления и путём восстановления доступа.
Граница применимости: Условный эксплуатационный вывод из ограничения ключей HPKP и жизненного цикла ключей NIST; не предписание разворачивать HPKP и не обещание одинакового восстановления у разных клиентов.
Граница терминов
Не путать
Ротация заменяет рабочий материал. Если клиент дополнительно закрепляет ключи, план должен учитывать именно его допустимый набор и поведение при смене.
Перед спецификацией
Что проверить
- Назовите конкретный механизм закрепления.
- Проверьте его поддержку и версию клиента.
- Разделяйте статус RFC и поддержку реализации.
- Учтите влияние смены ключа на допустимый набор.
- Проверьте риск потери доступа и предусмотренный путь восстановления.
- Не переносите историю HTTP HPKP на все виды закрепления ключей.
Открытые основания
Первоисточники
Public Key Pinning Extension for HTTP
Internet Engineering Task Force · RFC 7469, April 2015
Редактор проверил 8 сентября 2026 года: статус Proposed Standard, не Historic. Статус RFC и поддержка браузера рассматриваются раздельно.
Открыть первоисточникHTTP Strict Transport Security
Internet Engineering Task Force · RFC 6797, November 2012
Определяет browser policy, принуждающую известный HSTS host использовать secure transport и прекращать соединение при TLS errors.
Открыть первоисточникRecommendation for Key Management: Part 1 — General
National Institute of Standards and Technology · NIST SP 800-57 Part 1 Revision 5, May 2020
Определяет key-management functions, lifecycle states, cryptoperiods, protection, backup/recovery, compromise и destruction.
Открыть первоисточник