Pull to refresh

Comments 33

Непонятно, что защитит клиента, который впервые заходит на мой сайт, и использует http, а не https, если нас атакуют с помощью man in the middle.
Если я отдам редирект на https или в html'ке подсуну ссылку на https, то что помешает человеку-посередине подменить оба адреса на http?
А итоге мой клиент так никогда и не обратится по https и не узнает о сабжевом чудо заголовке.
Похоже, автор считает, что этот «магический» заголовок передастся пользователю голубинной почтой в обход того самого man 'a…
"… The HSTS header can be stripped by the attacker if this is the user's first visit. Google Chrome and Mozilla Firefox attempt to limit this problem by including a «pre-loaded» list of HSTS sites.… " и т.д. и т.п. В общем, спорная штука…
Если приставить человеку пистолет к голове, количество уязвимостей, доступных для эксплуатации растет быстрее геометрической прогрессии.

Если у ДБО банка есть HSTS и пользователь дома спокойно им пользовался, то в поездке он в ловушку man'a не попадется.
HSTS не предназначен для защиты _первого_ соединения. Это лишь один из механизмов защиты, вкупе с валидными SSL-сертификатами и проч.
Что значит «валидный SSL-сертификат»? Точное определение можно?
Я очень люблю, как хабровчане с радостью минусуют любой провокационный вопрос. Ищите «rouge gmail ssl certificate», желательно не в Гугле по вполне понятным причинам. И после этого задайтесь вопросом: так что же такое на самом деле «валидный SSL-сертификат»?
Ну вот вы и сказали бы нам, что должен означать термин "«валидный SSL-сертификат", а не обижаться и посылать всех не в гугл…
Я не обижаюсь. Просто забавный факт. Термин «валидный SSL-сертификат» имеет смысл только когда известны критерии валидности. Для кого-то это «подписан одним их 'официальных' УЦ», для кого-то может и «все числа в fingerprint чётные», для кого-то это может быть «fingerprint совпадает с полученным через out of band connection для этого домена». В любом случае, надеяться, что раз браузер на сертификат не ругается, то стало быть и всё в порядке как минимум беспечно. И в любом случае необходимо в первую очередь трезво оценивать риски.

Историй с дубликатами SSL-сертификатов на текущий момент уже достаточно, чтобы не доверять УЦ. И правильства (Франции в частности) выписывали через УЦ сертификат на gmail.com, чтобы следить за какими-то тёмными личностями, и частная компания умудрилась получить такой же «левый» сертификат для gmail.com для слежки за своими сотрудниками. Взломы УЦ тоже были в прошлом и не всегда было известно сколько времени прошло между самим взломом и обнаружением факта взлома. В общем, получается, что доверять можно только собственноручно созданному корневому сертификату и другим подобным, входящим в твой WoT. Остальное слишком легко обходится при текущей реализации. И рассматривать «валидные SSL-сертификаты» поставляемые с браузером как один из механизмов защиты в контексте HSTS по-моему несколько беспечно.

С учётом акций в Турции по запрету Твиттера, много ли доверия нижеследующим сертификатам?

TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
TURKTRUST_Certificate_Services_Provider_Root_1.pem
TURKTRUST_Certificate_Services_Provider_Root_2007.pem
TURKTRUST_Certificate_Services_Provider_Root_2.pem

А они есть и включены по умолчанию.

Кстати, именно вот в гугл я и не посылал. Гугл всё же фильтрует выдачу и успешно «размывает» результаты.
Встраивают в браузеры политики самых популярных сайтов
Абсолютно от MitM не защищает.

Простейшая схема: китайские спецлужбы с целью компрометации правозащитника, протестующего против фальсификаций на выборах (на которых было 146%) компрометирует DNS провайдера (пришла с приказом и скомпрометировала), или с помощью прозрачного NAT'а 8.8.8.8 завернула на свой сервер.

Дальше:

пользователь хочет зайти на сайт. Ему отдают фальшивый адрес. Пользователь обращается на сайт. Его запрос проксируют на настоящий сайт, удаляют все признаки https/hsts, лишние заголовки, и отдают пользователю по http. У пользователя всё работает, никаких предупреждений.
Если приставить человеку пистолет к голове, количество уязвимостей, доступных для эксплуатации растет быстрее геометрической прогрессии.
При чём тут «пистолет к голове»? Предлагается решение для защиты трафика, в частности, от mitm. При том, что в Китае описанная атака уже вполне используется, а в России с большой вероятностью начнёт использоваться в обозримое будущее (ну там, национал-предателей отлавливать), я показываю, что никакой проблемы предлагаемое решение не решает.
Предлагаете уйти на персональные ключи шифорвания? Как вообще можно от такого сценария защищаться? Если так посудить, можно у провайдера через уязвимость в маршрутизаторе весь трафик абонента собирать. Или жаде проще — через вирус на его ПК, подписанный валидной цифровой подписью (как в stuxnet).
Я могу подарить вам весь мой трафик, идущий через провайдера. Там всё шифрованное. Кроме кук на сайтах типа хабрахабра, но это уже другой вопрос.

Так что в нормальной системе mitm не должен быть проблемой.

Насчёт «решения» — дурацкую архитектуру костыли не исправят. WoT — наше всё.
В какой-то точке оно же расшифровывается. Не на узлах провайдера, так дальше.

Судя по презентациям Сноудена — внутри ДЦ публичных сервисов сплошь HTTP.
Как будто Сноуден знает, что там в ДЦ происходит. В NSA — может быть. В ДЦ — врят ли.

Адекватное шифрование не выпускает нешифрованный трафик за пределы хоста. Что бы производители хардварных vpn не говорили.
Да вот же он, один из самых прекрасных слайдов, от которых google оч оскорбился и клятвенно ч-то там наобещал:


Даже если отключить у себя 80й порт полностью и ходить только по https-only ресурсам, между фронтэндом и бэкэндом самого сайта может быть что угодно.
> Как вообще можно от такого сценария защищаться?

Так никак же. Собственно, я сюда и зашёл из-за такого многообещающего заголовка — решена одна из фундаментальных проблем, уже начал открывать шампанское, а оказалось… Да, от MitM можно защититься, но при некоторых условиях.
Если пользователь до этого хотя бы раз зашел не на фальшивый сайт, то Ваша схема не сработает.
ок, пользователь зашёл на https://github.com

Завтра установили mim-атаку. Каким образом «схема не сработает?». Человек пишет github.com, открывается http://github.com. Какой проницательностью нужно обладать, чтобы заметить отсутствие https?
Браузер сам подставит https://

Если сертификат сайта окажется невалидным, не пропустит дальше.
А, в этом смысле, да. До ближайшей чистки истории.
Тогда HSTS-хранилище пользователя сможет частично компрометировать историю посещений.
Потребуются отдельные опции на очистку журнала и HSTS (в firefox, предположительно, галочка «Настройки сайтов» в диалоге «Удалить недавнюю историю»).
> Простейшая схема: китайские спецлужбы с целью компрометации правозащитника, протестующего против фальсификаций на выборах (на которых было 146%) компрометирует DNS провайдера (пришла с приказом и скомпрометировала), или с помощью прозрачного NAT'а 8.8.8.8 завернула на свой сервер.

По-моему, простейшая схема выглядит чуть проще: сосед — студент 4 курса специальности, связанной с ИТ — врезается в провайдерский кабель и модифицирует любой проходящий трафик.
Почему хорошим людям просто не собраться и не запретить незащищенные соединения? Вычислительная сторона SSL давно перестала быть проблемой для современного железа, разве нет?
А как же тогда MitM проводить если надо? Не, так не пойдёт.
Если очень надо, можно внедрить бэкдор в алгоритм шифрования.
Или компрометация корневых сертификационных центров, что проще, имхо. Иллюзия безопасности есть и сертификаты можно штамповать без проблем. С самоподписанными сертификатами не пройдет, но кто их будет вручную в браузер ставить?
подскажите, а к ответам сервера вроде 404 или 500 Strict-Transport-Security должен цепляться или по сути все равно?
Sign up to leave a comment.

Articles