HPKP: что скрывается за расширением для HTTP, обеспечивающим защиту с помощью публичных ключей

Безопасные каналы передачи данных являются важным условием для работы с цифровыми данными. Особенно важно иметь полностью защищенный путь при передаче данных, когда вы отправляете и получаете пакеты данных удаленно или в пути. Не случайно конфиденциальная информация передается только через VPN или SSL/TLS-соединения. Предприятия и учреждения с собственными DNS-серверами и выбранными органами сертификации гарантируют, что эти протокольные технологии практически неприкосновенны. Однако пользователи, действующие вне этих структур, подчиняются общедоступной иерархии DNS и сертификатов сайтов, что значительно повышает вероятность атаки «человек посередине» на их данные.

Основной причиной повышенных рисков безопасности являются поддельные сертификаты, выданные сомнительными или проникшими в систему центрами сертификации. Пользователь полагается на безопасность соединения и всех своих данных, а доверяющий ему центр, как ни парадоксально, отвечает за обратное. С помощью так называемого HTTP Public Key Pinning (HPKP) компания Google в 2011 году предложила решение, которое теперь доступно в стандарте RFC 7469.

Что такое HPKP?

Привязка открытого ключа — это расширение протокола передачи гипертекста (HTTP), которое позволяет назначить хосту набор открытых ключей для будущих соединений SSL/TLS. Таким образом, клиент, получающий доступ, узнает, каким открытым ключам он может доверять при первом соединении с этим хостом. Это также называется ‘Trust on First Use’ (‘Доверие при первом применении’). Каждая запись проверенного ключа называется пином, откуда механизм и получил свое название. Все созданные пины отправляются клиенту в заголовке HTTP и сохраняются на определенное время.

При новом запросе на соединение клиент проверяет, содержит ли цепочка сертификации, предложенная для передачи SSL/TLS, открытый ключ, который ранее был отправлен через HPKP. Если это не так, например, если это был поддельный сертификат, будет выдано сообщение об ошибке, и соединение не будет установлено. Этот процесс проверки также называется валидацией пинов. Записи пинов в заголовке HTTP выглядят примерно так:

Public-Key-Pins:
  pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
  pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
  pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
  max-age=2592000; includeSubDomains; report-uri="http://example.com/pkp-report"

В примере показаны все четыре директивы, которые могут содержать запись pin в заголовке HTTP:

  • pin: Директива pin является наиболее важной частью записи и состоит из имени и значения. Имя содержит сведения об алгоритме, используемом для шифрования. SHA256 — единственный возможный на сегодняшний день. Хеш-значение, заключенное в кавычки, представляет собой закодированную в Base64 строку, также называемую отпечатком пальца. Для каждого ключа (и для резервных копий) всегда должна быть установлена отдельная директива pin.
  • max-age: Директива max-age задает период действия пина в секундах. Она указывает клиенту, в течение какого времени он должен считать открытый ключ надежным. В примере, использованном здесь, указанные пины удаляются через 30 дней (2.592.000 секунд).
  • includeSubDomains: Утверждение includeSubdomains является необязательным и не требует значения. Оно сигнализирует клиенту, что определенные правила сертификации применяются не только к вызываемому домену, но и ко всем поддоменам, принадлежащим хосту.
  • report-uri: Если установлена директива report-uri, все ошибки проверки пин-кода отправляются на указанный URL. Он не обязательно должен находиться в том же домене Интернета, что и связанный с ним хост, который затем информируется о неудачных попытках установки.

Как работает привязка сертификата на отдельных серверах?

Чтобы использовать возможности HPKP, сначала необходимо решить, какой открытый ключ (ключи) вы хотите «прикрепить». В принципе, вы можете выбрать любой открытый ключ, включенный в цепочку сертификации, будь то корневой, промежуточный или ваш собственный сертификат сервера. Однако при выборе внешних органов сертификации следует помнить, что все сертификаты этого сайта впоследствии будут проверены клиентами и приведут к успешной проверке pin.

Если пин-ключ хранится на собственном сервере, это может стать проблемой, если ключ станет нестабильным или будет потерян из-за дефекта оборудования. Поскольку клиенты сохранили пин-код в первой точке доступа на определенный срок действия, они не примут новый пин-код до истечения этого срока.  В этом случае ваш сервер будет недоступен для пользователей. Для предотвращения такого сценария стандарт HPKP (RFC 7569) предусматривает дополнительное использование резервного пина. Он также передается через HTTP-заголовок и может быть использован для выпуска нового сертификата для соответствующего домена в случае возникновения проблемы. Этот вариант называется запросом на подписание сертификата (CSR).

Совет

Такие браузеры, как Mozilla Firefox и Google Chrome, основаны на стандарте RFC 7469 и поэтому игнорируют заголовки HPKP или выдают сообщения об ошибках, если задан только один пин. Поэтому для оптимальной поддержки HPKP браузерами необходимо указать как минимум два действительных открытых ключа или резервный пин, чтобы проверка пина работала.

Вычисление пинов открытых ключей

Если на вашем сервере работает http public key pinning, необходимо, чтобы HTTPS уже был настроен. Так как необходимо привязать как минимум два открытых ключа, создание этих ключей — первый шаг, который необходимо сделать. Самый простой способ вычислить хэш-значения существующих открытых ключей — это приложение с открытым исходным кодом openssl, которое вы можете использовать через командную строку вашей системы. RFC 7469 предоставляет стандартную команду для сертификатов X.509:

openssl x509 -noout -in certificate.pem -pubkey | 
  openssl asn1parse -noout -inform pem -out public.key
openssl dgst -sha256 -binary public.key | openssl enc -base64

Вот как создается последовательность Base64 для ключа public.key для примера сертификата certificate.pem. Она выводится на стандартный вывод и всегда заканчивается знаком равенства («=»).

На следующем этапе вы создаете запрос на подпись сертификата (здесь: backupcsr) для резервного ключа (здесь: backup.key):

openssl genrsa -out backup.key 2048
openssl req -new -key backup.key -out backup.csr

Затем используйте openssl для вычисления хэш-значения этого ключа:

openssl req -noout -in backup.csr -pubkey | 
  openssl asn1parse -noout -inform pem -out backup.key
openssl dgst -sha256 -binary backup.key | openssl enc -base64

Защита резервных контактов

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

Критика привязки открытых ключей

Благодаря подходу «Доверие при первом использовании», HPKP сразу же приступает к созданию связи с клиентом с первой точки контакта. Однако первая точка контакта, в которой сервер передает привязанный ключ, фактически не защищена. Обычно этот небольшой пробел приводит к проблемам только в отдельных случаях, а большое количество непреднамеренных атак на SSL/TLS-соединения ваших сайтов практически невозможно. Основная критика, выдвигаемая против шифрования с открытым ключом, заключается в следующем сценарии атаки, который возможен только благодаря технологии шифрования:

  1. Злоумышленник получает доступ к вашему серверу.
  2. Он устанавливает новый сертификат SSL/TLS, а затем создает свой собственный набор ключей.
  3. Он также генерирует соответствующее хэш-значение для открытого ключа и помещает это значение в соответствующую область заголовка пиннинга сертификата вместо вашего пиннинга.
  4. Пользователи или клиенты, впервые обращающиеся к вашему сайту, получат неправильный PIN-код и впоследствии не смогут установить безопасное соединение с вашим сервером.
  5. Если злоумышленник снова удалит сертификат с вашего сервера, эти пользователи будут лишены доступа к вашей странице до тех пор, пока не истечет срок действия неправильного пина.
  6. Помимо нанесения ущерба в результате потери трафика, злоумышленник также имеет возможность потребовать деньги за разблокировку неверного сертификата и может шантажировать вас.

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

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

Оцените статью
cdelat.ru
Добавить комментарий