Так Ли Полезен Hsts, Как Его Описывают?

HTTP Strict Transport Security (HSTS, хотя согласно RFC – просто СТС) – название столь же «разрекламированное», сколь и переоцененное.

Этот заголовок сообщает пользовательскому агенту, что с сайтом, отправившим его, следует обращаться только как «Вы» и шепотом по защищенному протоколу HTTP – HTTPS. Он говорит после того, как к сайту был получен доступ, а именно через HTTPS. Если агент обратился к сайту по HTTP, то цитирую RFC: UA должен игнорировать любые существующие поля заголовка STS. .

То есть, если агент получил ответ от сайта по HTTP, он должен игнорировать HSTS-заголовок и продолжать общение по незащищенному протоколу (если только его не заставят переключиться на защищенный, но тогда какой смысл отправлять заголовок?) Чтобы понять этот смысл, вспомним, что соответствующий RFC был принят в 2012 году, а разработка началась не позднее 2008 года, когда HTTPS еще не был обязательным, крайне желательным, создавал дополнительную нагрузку на веб-сервер и стоил совсем других денег (спасибо вы, Let’s Encrypt!), а клиенты могут не знать, как использовать HTTPS, и не будут показывать на них пальцем.

Заголовок объяснял клиентам две вещи:

1. Поскольку когда-то они заходили на сайт по HTTPS, то и в дальнейшем им следует делать то же самое, даже если сайт доступен и по HTTP.
2. Все, что они хотят загрузить с этого сайта по HTTP, должно быть загружено по HTTPS, даже если протокол не указан или указан небезопасный протокол (и файлы cookie тоже, даже если флаг Secure не установлен).

Обычное поведение — сообщить об ошибке и предложить пользователю выбор: бежать без оглядки или игнорировать просроченный/самозаверенный/неправильный TLS-сертификат и прочие подобные «мелочи».

Заголовок HSTS сообщает клиенту, что он должен закрыть соединение и не устанавливать его «пока не будет разрешено», даже если пользователь готов поэкспериментировать.

HSTS также позволяет немного ускорить загрузку с сайта и снизить нагрузку на сервер за счет конвертации URI с http:// в URI с https:// на стороне клиента и тем самым избавляя сервер от нелепых жестов, возвращающих код состояния HTTP 301 Moved Permanently, но это история о производительности, а не безопасности.

И, наконец, если HTTPS на сайте по каким-то причинам отвалился и сервер начал общаться с клиентами по HTTP, HSTS-заголовок поможет администратору быстро получить обратную связь от пользователей: ай-ай, сайт недоступен! Чтобы не вставать дважды, упомяну еще о нестандартной директиве Preload, продвигаемой Google. Директива, вдруг, предназначена не для пользовательского агента, а исключительно для специализированного Google-бота, поддерживающего реестр доменов, доступ к которым возможен только через HTTPS .

Если администратор вручную добавил свой домен в реестр Google, бот компании проверит правомочность добавления по наличию директивы Preload в заголовках, отправленных с соответствующего веб-сервера, а затем пользовательские агенты, опирающиеся на этот реестр, даже отправить первый запрос на сайты, включенные в него по HTTPS. Кажется, хуже не станет, если заранее не прочитать заявление об отказе от ответственности Beaver Corporation: Удаление домена из списка предварительной загрузки может занять 6–12 недель, чтобы охватить большинство пользователей Chrome, и может занять больше времени для других браузеров.

.

Вольный перевод: если вам нужно (временно) отключить HTTPS на вашем сайте, то без директивы Preload вы сможете сделать это за секунду и пользователи даже ничего не заметят (кроме смены префикса с https:// на http: // в адресной строке), а с директивой — дождитесь, пока Google проверит ваше приложение, иначе посетители застрянут на HTTPS и будут отвернуты, т.к.

Google сообщил им, что доступ к этому сайту через HTTP невозможен.

Однако вы можете создать себе подобную проблему и без помощи Google, если последуете распространенной рекомендации установить дату истечения срока действия заголовка HSTS «не менее года».

Напомню: принудительный HTTPS для здорового человека обеспечивается не с помощью этого заголовка, который для этого не предназначен, а средствами веб-сервера.

Краткое содержание

1. Если сайт обслуживается только по протоколу HTTPS (как и должно быть сегодня), наличие HSTS-заголовка не добавит ему безопасности от слова вообще.

2. Если на сайте есть проблемы с HTTPS, шапка поможет администратору быстро узнать о них и (возможно частично) нейтрализовать их негативные последствия.

3. Если сайт обслуживается как по HTTP, так и по HTTPS, заголовок ничего не даст клиентам, подключающимся через незащищенный HTTP, но позволит другим избежать смешанного контекста безопасности.

Теги: #информационная безопасность #разработка сайтов #tls #HTTPS #SSL #hsts

• Имея Оффшорные Офисы В Коста-Рике, Компания Price Per Head Является Ведущим Поставщиком Программного Обеспечения Для Ставок На Спорт.

  19 Oct, 24

• Настройка Vlan На Микротике Совместно С Cisco

  19 Oct, 24

• Фокус На Vdi: Система Хранения Данных Netapp All-Flash Fas

  19 Oct, 24

• Linux Switchdev В Стиле Mellanox

  19 Oct, 24

• Finder — Альтернативы

  19 Oct, 24

• Как Создать Публичный Api, Который Будет Использоваться

  19 Oct, 24

• Финальные Точки В Войнах Redtram И Marketguide

  19 Oct, 24

• Советы По Службам Отчетов Microsoft Для Начинающих

  19 Oct, 24

• Максимальная Адаптивность При Минимальном Количестве Медиазапросов Или Метод Обратной Адаптивности.

  19 Oct, 24

• Новые Функции Io.js, Которые Вы, Возможно, Не Используете.

  19 Oct, 24