Комментарии 23
>наличие заголовка HSTS не добавит ему безопасности от слова совсем
Без hsts я могу своим wifi (или прочим MITM'ом) отдать тебе свой сайтик, без https, видя твой трафик и подменяя запросы/ответы.
Да, проблема курицы и яйца. Если пользователь заходит на сайт впервые, он никак не сможет узнать, что ему сделали sslstrip (ну, если он невнимателен).
Поэтому есть HSTS Preload List, в который попадают домены у которых HSTS установлен на год.
Строго говоря, они не попадают туда сами по себе. Нужно отправить туда домен вручную, предварительно установив заголовки HSTS — preload и includeSubDomains, ну и время действия.
Мне кажется, это (hsts, список) костыли переходного периода и современный веб весь должен работать по защищенному протоколу. Браузер и так поддерживает в актуальном состоянии свежий список корневых сертификатов, зачем ещё какие-то списки?
Когда в Firefox появилась опция использования https по умолчанию (с предупреждением, когда протокол недоступен и возможностью опуститься до http), я активировал её сразу. Знаете, как случился тот единственный момент, когда я начал испытывать трудности? Когда провайдер случайным образом стал сбрасывать соединения на 443 порт, а подключение по http редиректил на заглушку с довольно ироничным содержимым. Можно сказать, я стал жертвой MITM от Ростелекома, и это не прошло для меня незамеченным, так как браузер предупреждал о каждой такой ситуации.
Мой опыт, безусловно, слишком частный, чтобы делать какие-то выводы, но для себя я их давно сделал.
Заглушка РТК, от которой фейспалм
Вы, наверное, не понимаете, как работает sslstrip. Человек посередине запрашивает сайт по https и отдает браузеру жертвы по http, выступая прокси.
Если жертва заранее была на сайте и получила HSTS-заголовки, или браузер жертвы актуализировал preload списки, то атака не получится.
Если жертва ничего не знает про (не)доступность сайта по незащищенному протоколу - получится.
Как я уже написал выше, поможет только повсеместный переход на https, только хардкор. Остальное костыли
Стандартный кейс: Вы всегда проверяете почту с телефона через браузер. Приходите в ресторан, подключаетесь к wifi с вирусом в маршрутизаторе. Без HSTS, вы получите http и предложение ввести логин и пароль заново. С HSTS, браузер туда не пойдёт.
Если сайт отдается только по 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 тут помог бы.
Не верное утверждение. Безопасность будет выше, если пользователь уже заходил на сайт, и браузер запомнил, что нужно подключаться по HTTPS.
Если, если, если. Я не призываю всех убрать HSTS, а лишь не палагаться на него, как на «серебрянную пулю».
но обычно не возникает случаев, когда HTTPS не работает, а http работает
Шутить изволите? Сертификат протух и все, HTTPS не работает с точки зрения HSTS. Совсем экзотический вариант — хостер что-то нахимичил. Вариантов масса.
Заголовок HSTS не применяется в одного, его настраивают с переадресацией с http
Не должен применяться, но жизнь намного разнообразнее ;)
Если, если, если.
Вы берете топор, и говорите , что он бесполезен. Однако, я утверждаю, что в целом он полезен, если применять по назначению, а не варить из него суп. Но вы лишь замечаете "если если если", а не его полезность. Конкретно ваше утверждение:
не добавит безопасности совсем
Очень явно говорит, что HSTS абсолютно во всех ситуациях не добавляет безопасности, на что я дал аргументированный ответ.
Шутить изволите? Сертификат протух и все, HTTPS не работает
Значит пусть пользователи хотя бы смогут небезопасной версией пользоваться (и подвергать их риску перехвата), чем нажимать на кнопку "все равно продолжить" в браузере? Какое может быть оправдание этому? И так, для общего развития (никакой агрессии к вам, но если бы вы знали это, то не говорили бы так): certbot (да, от упоминаемого вами lets encrypt) при настройке и установке в одну команду прописывается в крон, чтобы каждый день проверять дату сертификата, и обновлять его за несколько недель до истечения. И только у криворуких админов что то может пойти не так, но при чем здесь HSTS ?
Не должен применяться, но жизнь намного разнообразнее ;)
Согласен, если сервер криво настроен, то тут проблема того места, откуда руки растут, а не HSTS. Вы ругаете HSTS за то, что он не делал и не должен делать. При этом ссылаетесь на сомнительные источники "которые хвалят HSTS как серебряную пулю", пытаясь их опровергнуть делаете некорректный вывод, что он совсем бесполезный и советуете его никому не ставить, что является вредительством чистой воды.
советуете его никому не ставить
Вас не затруднит процитировать соответствующий фрагмент из статьи? А то у меня складывается впечатление, что Вы дискутируете не с ней, а с каким-то неизвестным не текстом. У меня-то в тексте вроде как 2 из 3 доводов «за» HSTS, но именно что «топор — это столярный инструмент, а не всюду годится»…
Если сайт отдается только по HTTPS (как и должно быть сегодня), наличие заголовка HSTS не добавит ему безопасности от слова совсем.
Если честно, hsts создавался, чтобы когда пользователь хочет перейти на определенный сайт, чтобы когда вы подключались к сайту, браузер автоматом коннектился с сайтом по https, а не http. Это защищает трафик от прослушки и перехвата третьими лицами, например провайдером и государственными органами, а также подмены провайдером контента на сайте(например, рекламы). Ничего плохого я в нём не вижу. Если сайт работает по https, hsts установить на него необходимо.
Так ли полезен HSTS, как его малюют?