Закрепление открытого ключа HTTP

Закрепление открытого ключа HTTP (HPKP ) - устаревшая версия Интернета механизм безопасности, доставляемый через заголовок HTTP , который позволяет веб-сайтам HTTPS противостоять выдаче себя за другое лицо злоумышленниками, использующими неправильно оформленные или мошеннические цифровые сертификаты. Сервер использует его для доставки клиенту (например, веб-браузеру ) набора хэшей открытых ключей, которые должны появиться в цепочке сертификатов будущих подключений к то же самое доменное имя.

Например, злоумышленники могут взломать центр сертификации, а затем неправильно выпустить сертификаты для веб-источника. Для борьбы с этим риском веб-сервер HTTPS обслуживает список «закрепленных» хэшей открытых ключей, действительных в течение заданного времени; при последующих подключениях в течение этого срока действия клиенты ожидают, что сервер будет использовать один или несколько таких открытых ключей в своей цепочке сертификатов. Если это не так, отображается сообщение об ошибке, которое пользователь не может (легко) обойти.

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

Из-за сложности механизма HPKP и возможности случайного неправильного использования браузеры устарели и удалили поддержку HPKP в пользу Expect-CT.

• 1 Механизм
• 2 Отчетность
• 3 Критика и отклонение
• 4 Поддержка и устаревание браузера
• 5 См. Также
• 6 Ссылки

Сервер передает политику HPKP пользовательскому агенту через HTTP поле заголовка ответа с именем Public-Key-Pins(или Public-Key-Pins-Report-Onlyтолько для отчетов).

Политика HPKP определяет хэшей информации об открытом ключе субъекта одного из сертификатов в аутентичной цепочке сертификатов открытого ключа X.509 веб-сайта (и хотя бы один резервный ключ) в директивах pin-sha256, и период времени, в течение которого пользовательский агент должен принудительно закреплять открытый ключ в директиве max-age, необязательно includeSubDomainsдиректива для включения всех поддоменов (домена, отправившего заголовок) в политику закрепления и необязательную директиву report-uriс URL-адресом для отправки отчетов о нарушениях закрепления. По крайней мере, один из открытых ключей сертификатов в цепочке сертификатов должен совпадать с закрепленным открытым ключом, чтобы пользовательский агент считал цепочку действительной.

На момент публикации RFC 7469 разрешал только хэш-алгоритм SHA-256. Хэши для политики HPKP могут быть сгенерированы с помощью команд оболочки, упомянутых в Приложении A. RFC 7469, или сторонних инструментов.

Оператор веб-сайта может выбрать закрепление открытого ключа корневого сертификата определенного корневого центра сертификации, позволяя только этому центру сертификации (и всем промежуточным органам, подписанным его ключом) выдавать действительные сертификаты для домена веб-сайта и / или для закрепления ключа (ов) одного или нескольких промежуточных сертификатов, или для закрепления открытого ключа конечного объекта.

Должен быть закреплен хотя бы один резервный ключ на случай замены текущего закрепленного ключа. HPKP недействителен без этого резервного ключа (резервный ключ определяется как открытый ключ, отсутствующий в текущей цепочке сертификатов).

HPKP стандартизирован в RFC 7469. Он расширяет возможности статического закрепления сертификата , который жестко кодирует хэши открытых ключей известных веб-сайтов или служб в веб-браузерах и приложениях.

Большинство браузеров отключают закрепление для цепочек сертификатов с частными корневыми сертификатами для включения различных корпоративных сканеров проверки содержимого и инструментов веб-отладки (таких как или Fiddler ). Стандарт RFC 7469 рекомендует отключать отчеты о нарушениях закрепления для «определяемых пользователем» корневых сертификатов, где для браузера «приемлемо» отключение проверки PIN.

Если пользовательский агент выполняет PIN-код и не может найти действительный отпечаток SPKI в цепочке обслуживаемых сертификатов, он отправит POST-сообщение в формате JSON о нарушении на хост, указанный в директиве report-uri, содержащий подробную информацию о нарушение. Этот URI может обслуживаться через HTTP или HTTPS ; однако пользовательский агент не может отправлять отчеты о нарушении HPKP на URI HTTPS в том же домене, что и домен, для которого он сообщает о нарушении. Хосты могут использовать HTTP для report-uri, использовать альтернативный домен или использовать службу отчетов.

Некоторые браузеры также поддерживают Public-Key-Pins-Report- Только, который только запускает этот отчет, не показывая пользователю ошибку.

Сообщалось, что во время максимальной адаптации HPKP использовалось 3500 из 1 миллиона ведущих интернет-сайтов, и к концу 2019 года эта цифра снизилась до 650.

Критика и беспокойство касались сценариев злонамеренных действий или ошибок человека, известных как HPKP Suicide и Ransom PKP. В таких сценариях владелец веб-сайта будет иметь возможность публиковать новое содержимое в своем домене, что серьезно затруднено из-за потери доступа к своим собственным ключам или объявления новых ключей злоумышленником.

• Компрометация центра сертификации
• Прозрачность сертификата
• Строгая безопасность транспорта HTTP
• Список полей заголовка HTTP
• Авторизация центра сертификации DNS
• Расширение закрепления открытого ключа для HTTP (HPKP) на веб-документации MDN

.