HPKP на веб-сервере работает путем добавления заголовков к ответам, содержащим хеши различных открытых ключей, так что по крайней мере один из хешей имеет вид действительный = сертификат в цепочке сертификатов текущего сертификата сервера, и по крайней мере один недействительный = не встречается в цепочке и считается резервным сертификатом. Существует несколько стратегий выбора сертификата для представления действительной записи:
Первый вариант проблематичен, поскольку он оставляет довольно большая поверхность для атаки (т. е. кто-то может обманом или принудить упомянутый CA подписать вредоносный сертификат для вашего хоста). Второй вариант страдает от этого в меньшей степени, но, что более важно, промежуточное звено может внезапно измениться при продлении, что приведет к блокированию вашего сайта (если вы не использовали резервную копию CSR для продления). Третий вариант наиболее специфичен, но требует, чтобы вы изменили заголовок HPKP в соответствии с очень конкретным сроком и планированием на месяц или независимо от времени ожидания, которое вы используете с заголовком HPKP.
Интересно, есть ли перекрестное подписание с личным (ненадежным) CA может помочь, то есть: Будет ли работать следующий сценарий?
Я получаю свой сертификат AAA от широко известного и надежного центра сертификации XXX , который использует промежуточный YYY для подписи AAA . Кроме того, я подписываю свой сертификат AAA с моим неясным, совершенно ненадежным и никогда не слышанным CA ZZZ . Теперь я настраиваю свой веб-сервер для выдачи заголовков HPKP с AAA, SSS, ZZZ , где SSS - это надежно хранимая резервная копия CSR, используемая в случаях бедствий.
После продления я делаю то же самое со своим новым сертификатом BBB , т. Е. У меня он подписан доверенным центром сертификации (возможно, другим, например XX2 и промежуточным YY2 ) и подпишите его своим ZZZ ; и я настраиваю заголовок HPKP так, чтобы он читался как BBB, SSS, ZZZ . (На самом деле, заголовок HPKP может быть оставлен на SSS, ZZZ с самого начала и никогда не изменяться)
Почему я думаю, что это должно работать? Допустим, посетитель заходит после переключения с AAA на BBB . Соединение TLS может быть инициировано, поскольку мой сервер настроен на использование BBB и промежуточного сертификата YY2 , а также ZZZ . Клиента это устраивает, потому что по крайней мере YY2 подписан XX2 , и это один из хорошо известных центров сертификации клиента. Затем он проверяет заголовок HPKP. Это либо свежее, либо содержащее BBB, ZZZ, SSS , и это нормально. Или старая версия AAA, ZZZ, SSS используется повторно, что также нормально из-за ZZZ .
Вопрос: Возможен ли описанный выше метод? Будут ли с ним работать все браузеры, поддерживающие HPKP? Или это даже явно запрещено спецификациями?
Дополнительный вопрос: Как вы на самом деле выполняю вышеуказанный план (с точки зрения команд openssl
и конфигурации apache
)?
Нет, это не сработает.
Браузер не знает о сертификате ZZZ - если вы не собираетесь возвращать его вместе с официальным промежуточным сертификатом XXX и / или XX2? Даже если вы это сделаете, браузер полностью проигнорирует его как ненадежный и вместо этого построит путь только с доверенным корнем.
HPKP добавляет поверх доверенного корневого хранилища браузера - он не заменяет его.