Назад | Перейти на главную страницу

Отключение HSTS для управляемых браузеров

Как я могу отключить HSTS как для новых сайтов, так и для тех, которые встроены в браузер?

Использование проверки HTTPS по своей сути изменяет отпечаток пальца сайта, действуя как человек посередине; посещение ранее посещенного сайта без проверки HTTPS или одного из предварительно загруженных сайтов приведет к недоступности сайта. Какие варианты - если они есть - у меня есть, кроме отключения проверки?

Вот пример Gmail в Chrome с проверкой HTTPS:

Задний план

Я устанавливаю новый брандмауэр и пытаюсь очистить правила проверки HTTPS. я действительно не хотите добавлять в список сайты, содержание которых может быть предоставлено пользователями, например mail.google.com / gmail.com.

С тех пор, как я это делал последний раз Строгая безопасность транспорта HSTS / HTTP стал намного более распространенным.

Примечание. Я попытался сохранить это общее, поскольку это могло быть проблемой для множества различных настроек. Я надеюсь на метод кросс-ОС / кроссбраузерности, который был бы применим к любому брандмауэру, но это требует многого. Сосредоточение внимания на (IE, Chrome, Firefox) с использованием Windows (7+) было бы отличным началом. Также были бы очень полезны методы, основанные на групповой политике.

Вы смешиваете здесь несколько разных вещей, и я подозреваю, что это приводит вас к некоторым ложным выводам.

  • HSTS («Строгая безопасность транспорта HTTP») требует (только!) Обязательного использования HTTPS для подключений к указанным сайтам. Он ничего не требует о том, какие ключи, сертификаты и т. Д. Используются для аутентификации соединения.
  • Закрепление открытого ключа указывает, что, если соединение HTTPS установлено с заданным именем, цепочка сертификатов должна включать один из заданного белого списка открытых ключей, в противном случае соединение считается недействительным.

Поскольку проверка HTTPS является (к сожалению) широко распространенной практикой, общая практика среди браузеров заключается в том, что цепочки сертификатов, заканчивающиеся локально установленным корневым сертификатом CA, освобождаются от проверок закрепления открытого ключа. Я нашел заявление Адама Лэнгли из Chrome о поведении Chrome (раздел «Что насчет прокси MITM, Fiddler и т. д.?»), но мой опыт аналогичен для других браузеров.

Я вполне уверен, что проблема, указанная на вашем снимке экрана, заключается не в том, что браузер зависает на булавке, а в том, что он вообще не может распознать сертификат как связанный с сертификатом доверенного ЦС. Это вызовет сбой HSTS, потому что «использование HTTPS» более правильно определяется как «использование должным образом защищенного HTTPS, включая безопасные шифры и доверенный сертификат для аутентификации». Я бы посоветовал дважды проверить, что сертификат корневого CA прокси-сервера MitM установлен правильно и распознается используемым браузером (-ами) как действительный.