Целью HTTP Strict Transport Security, которая подробно описана в RFC 6797, является обеспечение безопасной отправки запросов в соответствии с политикой соответствующего сайта. Это не протокол безопасности сам по себе; он просто инструктирует веб-браузер принудительно использовать безопасный транспорт (HTTPS), а не незащищенный транспорт (HTTP) для определенного хоста и в течение заранее определенного периода времени.
Существует несколько возможностей отключить HSTS для хоста, но все они требуют доступа к незашифрованным данным зашифрованного потока HTTPS. По сути, это означает, что если вы в состоянии отключить HSTS для хоста, то вы уже в состоянии манипулировать связью с этим хостом, и поэтому вам не нужно отключать HSTS для этого хоста.
Наиболее очевидная возможность - это то, что изложено в разделе 6.1.1 RFC, при установке директивы max-age на 0. Это приведет к тому, что совместимый клиент (веб-браузер) удалит имя хоста из списка известных хостов HSTS.
Альтернативой может быть непосредственное управление хранилищем HSTS браузера. Поставщик браузера может сделать это более трудным путем использования различных криптографических методов (код для которых уже написан, так как он все равно необходим для HTTPS) или путем разделения привилегий.
Однако, даже если вы сделаете это, заголовок HSTS и / или постоянное перенаправление для использования HTTPS, вероятно, будут повторно переданы при следующем запросе на тот же хост, что приведет к тому, что клиент восстановит статус защищенного хоста для продолжительность указана сервером.
Раздел 12 RFC дает рекомендации по внедрению для клиентов. В частности, в разделе 12.1 говорится, что в случае ошибок, связанных с безопасностью, пользователь не должен прибегать к помощи.
Однако, конечно, поскольку HSTS - это просто механизм, позволяющий клиенту использовать HTTPS вместо HTTP для заданного имени хоста, все соответствующие атаки на HTTPS остаются. Это означает, например, что если вы можете контролировать хранилище корневых сертификатов клиента или если вы можете получить сертификат для хоста, для которого вы управляете закрытым ключом, у вас есть возможность успешно MITM такого сеанса. Это не зависит от наличия или отсутствия HSTS на конкретном имени хоста.
Многие атаки на HTTPS могут быть значительно усложнены за счет реализации надлежащего DNSSEC в сочетании с тем, что клиент выполняет правильную проверку DANE (RFC 6698, RFC 7218). Например, сочетание HSTS, правильной проверки DNSSEC и надлежащей проверки DANE, вероятно, сделало бы невозможным перехватывающий SSL прокси-сервер Lenovo Superfish .
