Отключение HSTS для управляемых браузеров
Какие есть варианты отключения HSTS как для новых сайтов, так и для тех сайтов, которые запечены в браузере?
Использование проверки HTTPS по своей сути меняет отпечаток большого пальца сайта, действуя как человек посередине; посещение ранее посещенного сайта без проверки HTTPS или одного из предварительно загруженных сайтов приведет к недоступности сайта. Какие варианты - если таковые имеются - у меня есть, кроме отключения проверки?
Вот пример, Gmail в Chrome с проверкой HTTPS:
Фон
Я устанавливаю новый брандмауэр и пытаюсь очистить правила проверки HTTPS. Я действительно хочу избегать добавления в список сайтов, которые могут содержать добавленный пользователем контент, например mail.google.com / gmail.com.
С тех пор, как я это делал в последний раз, HSTS / HTTP Strict Transport Security стала намного более распространенной.
Примечание. Я попытался сохранить это универсальное значение, так как это может быть проблемой для множества различных настроек. Я надеюсь, что метод кросс-ОС / кросс-браузер будет применим к любому продукту брандмауэра, но это требует много. Ориентация на (IE, Chrome, Firefox) с использованием Windows (7+) будет отличным началом. Методы, основанные на групповой политике, также будут очень полезны.
1 ответ
Здесь вы смешиваете несколько разных вещей, и я подозреваю, что это приводит вас к ложным выводам.
- HSTS ("HTTP Strict Transport Security") - это (только!) Требование о том, чтобы HTTPS использовался для соединений с указанными сайтами. Он не предписывает, какие ключи, сертификаты и т. Д. Используются для аутентификации соединения.
- Прикрепление открытого ключа указывает, что, если HTTPS-соединение установлено с данным именем, цепочка сертификатов должна включать один из заданного белого списка открытых ключей, иначе соединение считается недействительным.
Поскольку проверка HTTPS является (к сожалению) широко распространенной практикой, общая практика среди браузеров заключается в том, что цепочки сертификатов, которые заканчиваются локально установленным сертификатом корневого ЦС, освобождаются от проверок закрепления открытого ключа. Я нашел утверждение Адама Лэнгли из Chrome о поведении Chrome (раздел "Что насчет прокси-серверов MITM, Fiddler и т. Д.?"), Но мой опыт похож на другие браузеры.
Я вполне уверен, что проблема, указанная на вашем снимке экрана, заключается не в том, что браузер зависает на булавке, а в том, что он вообще не может распознать сертификат как цепочку к доверенному сертификату CA. Это вызовет сбой HSTS, потому что "использование HTTPS" более правильно определено как "использование должным образом защищенного HTTPS, включая безопасные шифры и доверенный сертификат для аутентификации". Я хотел бы предложить еще раз проверить, правильно ли установлен корневой сертификат CA прокси-сервера MitM и признан ли он действующим браузером (ами).