Могу ли я использовать кросс-подпись для облегчения управления HPKP?

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

  • корневой сертификат вашей любимой CA
  • промежуточный сертификат вашего любимого CA
  • Ваш листовой сертификат

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

Интересно, может ли помочь перекрестная подпись с личным (ненадежным) ЦС, а именно: сработает ли следующий сценарий?

Я получаю свой сертификат AAA от широко известного и доверенного CA 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, и это среди известных CA клиента. Затем он сверяется с заголовком HPKP. Это либо свежий и содержит BBB,ZZZ,SSS и так хорошо. Или более старая версия AAA,ZZZ,SSS используется повторно, что также хорошо из-за ZZZ.

Вопрос: возможен ли описанный выше метод? Будут ли все браузеры, поддерживающие HPKP, работать с ним? Или это даже явно запрещено спецификациями?

Дополнительный вопрос: как вы на самом деле выполните вышеуказанный план (с точки зрения openssl команды и apache конфигурация)?

1 ответ

Нет, это не сработает.

Браузер не знает о сертификате ZZZ - разве вы собираетесь его вернуть, а также официальный промежуточный сертификат XXX и / или XX2? Даже если вы сделаете это, браузер полностью проигнорирует его как ненадежный и вместо этого построит путь только с доверенным корнем.

HPKP добавляет поверх доверенного корневого хранилища браузера - он не заменяет его.

Другие вопросы по тегам