Если же агент зашел на сайт по HTTP, то цитирую RFC: UA must ignore any present STS header field(s). То есть, если агент получил ответ от сайта по HTTP, он должен проигнорировать заголовок HSTS и продолжать общаться по незащищенному протоколу (если его принудительно не переключат на защищенный, но тогда какой смысл посылать заголовок?)
Чтоб понять этот смысл, давайте вспомним, что соответствующий RFC приняли в 2012 году, а разрабатывать начали не позже 2008, когда HTTPS еще не был
Заголовок объяснял клиентам две вещи:
- Раз уж они однажды зашли на сайт по HTTPS, впредь следует поступать так же, даже если по HTTP сайт тоже доступен.
- Все, что они хотят загрузить с этого сайта по HTTP, требуется загружать по HTTPS, даже если протокол не указан или указан незащищенный протокол (и куки тоже, даже если не установлен флаг Secure).
Опциональная директива includeSubDomains требовала, чтобы тот же подход применялся и к субдоменам: только HTTPS, только хардкор!
Таким образом, сегодня, на сайте, который поддерживает только HTTPS (принудительно переключает на него с HTTP средствами сервера), единственный практический смысл этого заголовка в переопределении поведения клиента при ошибке защищенного соединения. Обычное поведение – сообщить об ошибке и предложить пользователю выбор: убежать без оглядки или проигнорировать просроченный/самоподписанный/левый TLS-сертификат и прочие подобные «мелочи». Заголовок HSTS говорит клиенту, что он должен разорвать соединение и не устанавливать его «до устранения», даже если пользователь не против поэкспериментировать.
HSTS позволяет также слегка ускорить загрузку с сайта и снизить нагрузку на сервер, преобразуя еще на стороне клиента URI с http:// в URI с https:// и, тем самым, избавляя сервер от нелепых телодвижений с отдачей кода состояния HTTP 301 Moved Permanently, но это уже история про производительность, а не безопасность.
И, наконец, если HTTPS на сайте почему-то отвалился и сервер начал общаться с клиентами по HTTP, заголовок HSTS поможет админу быстрее получить фидбек от пользователей: а-а-а, сайт недоступен!
Чтоб два раза не вставать, упомяну и проталкиваемую Google нестандартную директиву Preload. Директива, внезапно, предназначена не для агента пользователя, а исключительно для специализированного бота Google, поддерживающей реестр доменов, к которым следует обращаться только по HTTPS. Если админ вручную добавил свой домен в реестр Google, бот компании проверит правомочность добавления по наличию директивы Preload в заголовках, отдаваемых с соответствующего веб-сервера, и тогда агенты пользователя, полагающиеся на этот реестр, будут даже первый запрос к внесенным в него сайтам посылать по HTTPS.
Вроде как хуже не будет, если заранее не прочесть disclaimer Корпорации Бобра: preload list domain removal may take 6-12 weeks to reach most Chrome users, and may take longer for other browsers. Вольный перевод: если вам понадобится (временно) отключить HTTPS на своем сайте, то без директивы Preload вы это можете сделать за секунду и пользователи даже ничего не заметят (кроме смены префикса с https:// на http:// в адресной строке), а с директивой – подождите, пока Google рассмотрит вашу заявку, иначе посетители будут долбиться по HTTPS и получать от ворот поворот, т.к. Google сказала им, что по HTTP на этот сайт – нельзя.
Впрочем, подобную проблему вы можете создать себе сами, без помощи Google, если последуете распространенной рекомендации устанавливать время действия заголовка HSTS в «минимум год». Напоминаю: принудительный HTTPS здорового человека обеспечивается не с помощью этого заголовка, который не для того предназначен, а средствами веб-сервера.
Резюме
- Если сайт отдается только по HTTPS (как и должно быть сегодня), наличие заголовка HSTS не добавит ему безопасности от слова совсем.
- Если на сайте случатся проблемы с HTTPS, заголовок поможет админу быстрее узнать о них и (возможно, частично) нивелировать их негативные последствия.
- Если сайт отдается и по HTTP, и по HTTPS, заголовок ничего не даст клиентам, подключившимся по незащищенному HTTP, но позволит остальным избежать mixed security context.
P.S.: в рамках проекта «Монитор госсайтов» мы обнаруживаем на исследуемых сайтах госорганов заголовок HSTS примерно в 1% случаев, причем едва ли не в половине из них этот заголовок передается с ошибками.
Комментарии (23)
TimsTims
18.09.2021 12:43+1Если сайт отдается только по HTTPS (как и должно быть сегодня), наличие заголовка HSTS не добавит ему безопасности от слова совсем.
Не верное утверждение. Безопасность будет выше , если пользователь уже заходил на сайт, и браузер запомнил , что нужно подключаться по HTTPS.
Если на сайте случатся проблемы с HTTPS, заголовок поможет админу быстрее узнать о них и (возможно, частично) нивелировать их негативные последствия.
Конечно все зависит от ситуации, но обычно не возникает случаев, когда HTTPS не работает, а http работает. И в большинстве случаев , переход на http не стоит отказа от HTTPS и снижением уровня безопасности до такого уровня.
Если сайт отдается и по HTTP, и по HTTPS, заголовок ничего не даст клиентам, подключившимся по незащищенному HTTP, но позволит остальным избежать mixed security context.
Заголовок HSTS не применяется в одного, его настраивают с переадресацией с http. Вы в статье сфокусировались на единственном методе безопасности HSTS, и утверждаете что он абсолютно бесполезен, что является правдой, в некоторых случаях, например когда он используется один без 301. Но из этих исключительных ситуаций не следует, что он не нужен и ничего не делает.
Update: вот вспомнил ещё такой кейс, тоже относится к разновидности mitm: вы уже бывали на сайте , и сами для себя знаете, что сайт должен быть с замочком. При входе на сайт, браузер открывает http версию. И даже делает для вас привычный редирект на HTTPS версию. Но вместе с ним, он также и генерирует заранее вам cookie сессию со своим известным session id. Для вас открылся обычный сайт с замочком, и вы привычно авторизуетесь. Но злоумышленник знает вашу cookie (он ведь сам её сгенерировал), и пользуется сайтом вместо вас. Следуя вашей логике, наличие замочка и HTTPS тоже было бы бессмысленным в данной ситуации. Но конечно же от такой ситуации надо защищаться совсем другими способами (например запрет на прием пользовательских cookie, и смена cookie после авторизации), но тот же HSTS тут помог бы.
ifap Автор
18.09.2021 22:28Не верное утверждение. Безопасность будет выше, если пользователь уже заходил на сайт, и браузер запомнил, что нужно подключаться по HTTPS.
Если, если, если. Я не призываю всех убрать HSTS, а лишь не палагаться на него, как на «серебрянную пулю».но обычно не возникает случаев, когда HTTPS не работает, а http работает
Шутить изволите? Сертификат протух и все, HTTPS не работает с точки зрения HSTS. Совсем экзотический вариант — хостер что-то нахимичил. Вариантов масса.Заголовок HSTS не применяется в одного, его настраивают с переадресацией с http
Не должен применяться, но жизнь намного разнообразнее ;)TimsTims
19.09.2021 00:28+1Если, если, если.
Вы берете топор, и говорите , что он бесполезен. Однако, я утверждаю, что в целом он полезен, если применять по назначению, а не варить из него суп. Но вы лишь замечаете "если если если", а не его полезность. Конкретно ваше утверждение:
не добавит безопасности совсем
Очень явно говорит, что HSTS абсолютно во всех ситуациях не добавляет безопасности, на что я дал аргументированный ответ.
Шутить изволите? Сертификат протух и все, HTTPS не работает
Значит пусть пользователи хотя бы смогут небезопасной версией пользоваться (и подвергать их риску перехвата), чем нажимать на кнопку "все равно продолжить" в браузере? Какое может быть оправдание этому? И так, для общего развития (никакой агрессии к вам, но если бы вы знали это, то не говорили бы так): certbot (да, от упоминаемого вами lets encrypt) при настройке и установке в одну команду прописывается в крон, чтобы каждый день проверять дату сертификата, и обновлять его за несколько недель до истечения. И только у криворуких админов что то может пойти не так, но при чем здесь HSTS ?
Не должен применяться, но жизнь намного разнообразнее ;)
Согласен, если сервер криво настроен, то тут проблема того места, откуда руки растут, а не HSTS. Вы ругаете HSTS за то, что он не делал и не должен делать. При этом ссылаетесь на сомнительные источники "которые хвалят HSTS как серебряную пулю", пытаясь их опровергнуть делаете некорректный вывод, что он совсем бесполезный и советуете его никому не ставить, что является вредительством чистой воды.
ifap Автор
19.09.2021 00:49советуете его никому не ставить
Вас не затруднит процитировать соответствующий фрагмент из статьи? А то у меня складывается впечатление, что Вы дискутируете не с ней, а с каким-то неизвестным не текстом. У меня-то в тексте вроде как 2 из 3 доводов «за» HSTS, но именно что «топор — это столярный инструмент, а не всюду годится»…
Egor_Malashevsky
16.10.2021 17:06Если сайт отдается только по HTTPS (как и должно быть сегодня), наличие заголовка HSTS не добавит ему безопасности от слова совсем.
Если честно, hsts создавался, чтобы когда пользователь хочет перейти на определенный сайт, чтобы когда вы подключались к сайту, браузер автоматом коннектился с сайтом по https, а не http. Это защищает трафик от прослушки и перехвата третьими лицами, например провайдером и государственными органами, а также подмены провайдером контента на сайте(например, рекламы). Ничего плохого я в нём не вижу. Если сайт работает по https, hsts установить на него необходимо.
Bo0oM
>наличие заголовка HSTS не добавит ему безопасности от слова совсем
Без hsts я могу своим wifi (или прочим MITM'ом) отдать тебе свой сайтик, без https, видя твой трафик и подменяя запросы/ответы.
ifap Автор
Без https HSTS не работает.
up40k
Да, проблема курицы и яйца. Если пользователь заходит на сайт впервые, он никак не сможет узнать, что ему сделали sslstrip (ну, если он невнимателен).
Bo0oM
Поэтому есть HSTS Preload List, в который попадают домены у которых HSTS установлен на год.
Darkhon
Строго говоря, они не попадают туда сами по себе. Нужно отправить туда домен вручную, предварительно установив заголовки HSTS — preload и includeSubDomains, ну и время действия.
Bo0oM
Ок, был не прав, видимо автоматически не попадает.
up40k
Мне кажется, это (hsts, список) костыли переходного периода и современный веб весь должен работать по защищенному протоколу. Браузер и так поддерживает в актуальном состоянии свежий список корневых сертификатов, зачем ещё какие-то списки?
Когда в Firefox появилась опция использования https по умолчанию (с предупреждением, когда протокол недоступен и возможностью опуститься до http), я активировал её сразу. Знаете, как случился тот единственный момент, когда я начал испытывать трудности? Когда провайдер случайным образом стал сбрасывать соединения на 443 порт, а подключение по http редиректил на заглушку с довольно ироничным содержимым. Можно сказать, я стал жертвой MITM от Ростелекома, и это не прошло для меня незамеченным, так как браузер предупреждал о каждой такой ситуации.
Мой опыт, безусловно, слишком частный, чтобы делать какие-то выводы, но для себя я их давно сделал.
Заглушка РТК, от которой фейспалм
ifap Автор
Именно, и сегодня он уже потерял свою актуальность, но некоторые продолжают молиться на него как папуас на идола. Тот же Qualis SSL Test снижает баллы за отсутствие HSTS даже сайтам, которые только по HTTPS отвечают.
ifap Автор
Скорее проблема настроек веб-сервера, который в 2021 зачем-то пускает к себе по http.
up40k
Вы, наверное, не понимаете, как работает sslstrip. Человек посередине запрашивает сайт по https и отдает браузеру жертвы по http, выступая прокси.
Если жертва заранее была на сайте и получила HSTS-заголовки, или браузер жертвы актуализировал preload списки, то атака не получится.
Если жертва ничего не знает про (не)доступность сайта по незащищенному протоколу - получится.
Как я уже написал выше, поможет только повсеместный переход на https, только хардкор. Остальное костыли
ifap Автор
MitM может подсунуть и max-age=0, тут только в сторону DNSSEC с ECH работать…
n0isy
Стандартный кейс: Вы всегда проверяете почту с телефона через браузер. Приходите в ресторан, подключаетесь к wifi с вирусом в маршрутизаторе. Без HSTS, вы получите http и предложение ввести логин и пароль заново. С HSTS, браузер туда не пойдёт.
ifap Автор
Я понимаю о чем речь, но если мы сталкиваемся с активным MitM, то один HSTS нас ни от чего не спасет.
Bo0oM
Да видно, что вы не понимаете)
Zwerg
и таки и правда не понимаете. HSTS как раз от этого гарантированно спасает.
ifap Автор
Обратите внимание на раздел Security Considerations в RFC, из которого очевидно, что не гарантированно.
dartraiden
Есть такая штука, как HTTPS RR (последняя версия Firefox уже такое понимает). Так вот, там вообще не требуется, чтобы пользователь заранее побывал на сайте. Браузер узнаёт, что на сайт нужно идти по HTTPS, из специальной DNS-записи.
ifap Автор
Это шаг в верном направлении, но тоже не панацея, если MitM может влезть в общение с DNS-сервером.