foboss23 мар 2014 в 06:30

и заставить браузер всегда использовать HTTPS

4 мин

115K

Информационная безопасность * Веб-разработка *

+35

Комментарии 33

Q2W 23 мар 2014 в 06:54

Непонятно, что защитит клиента, который впервые заходит на мой сайт, и использует http, а не https, если нас атакуют с помощью man in the middle.
Если я отдам редирект на https или в html'ке подсуну ссылку на https, то что помешает человеку-посередине подменить оба адреса на http?
А итоге мой клиент так никогда и не обратится по https и не узнает о сабжевом чудо заголовке.

SleepwalkerOne 23 мар 2014 в 07:16

Похоже, автор считает, что этот «магический» заголовок передастся пользователю голубинной почтой в обход того самого man 'a…

SleepwalkerOne 23 мар 2014 в 07:33

"… 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.… " и т.д. и т.п. В общем, спорная штука…

foboss 23 мар 2014 в 07:53

Если приставить человеку пистолет к голове, количество уязвимостей, доступных для эксплуатации растет быстрее геометрической прогрессии.

Если у ДБО банка есть HSTS и пользователь дома спокойно им пользовался, то в поездке он в ловушку man'a не попадется.

SleepwalkerOne 23 мар 2014 в 08:11

с этим я согласен, не спорю.

foboss 23 мар 2014 в 07:54

HSTS не предназначен для защиты _первого_ соединения. Это лишь один из механизмов защиты, вкупе с валидными SSL-сертификатами и проч.

dsx 24 мар 2014 в 00:35

Что значит «валидный SSL-сертификат»? Точное определение можно?

dsx 24 мар 2014 в 16:54

Я очень люблю, как хабровчане с радостью минусуют любой провокационный вопрос. Ищите «rouge gmail ssl certificate», желательно не в Гугле по вполне понятным причинам. И после этого задайтесь вопросом: так что же такое на самом деле «валидный SSL-сертификат»?

toxicdream 24 мар 2014 в 21:12

Ну вот вы и сказали бы нам, что должен означать термин "«валидный SSL-сертификат", а не обижаться и посылать всех не в гугл…

dsx 26 мар 2014 в 13:17

Я не обижаюсь. Просто забавный факт. Термин «валидный 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

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

Кстати, именно вот в гугл я и не посылал. Гугл всё же фильтрует выдачу и успешно «размывает» результаты.

Homakov 23 мар 2014 в 10:05

Встраивают в браузеры политики самых популярных сайтов

amarao 23 мар 2014 в 11:18

Абсолютно от MitM не защищает.

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

Дальше:

пользователь хочет зайти на сайт. Ему отдают фальшивый адрес. Пользователь обращается на сайт. Его запрос проксируют на настоящий сайт, удаляют все признаки https/hsts, лишние заголовки, и отдают пользователю по http. У пользователя всё работает, никаких предупреждений.

foboss 23 мар 2014 в 14:09

Если приставить человеку пистолет к голове, количество уязвимостей, доступных для эксплуатации растет быстрее геометрической прогрессии.

amarao 23 мар 2014 в 14:17

При чём тут «пистолет к голове»? Предлагается решение для защиты трафика, в частности, от mitm. При том, что в Китае описанная атака уже вполне используется, а в России с большой вероятностью начнёт использоваться в обозримое будущее (ну там, национал-предателей отлавливать), я показываю, что никакой проблемы предлагаемое решение не решает.

foboss 23 мар 2014 в 15:17

Предлагаете уйти на персональные ключи шифорвания? Как вообще можно от такого сценария защищаться? Если так посудить, можно у провайдера через уязвимость в маршрутизаторе весь трафик абонента собирать. Или жаде проще — через вирус на его ПК, подписанный валидной цифровой подписью (как в stuxnet).

amarao 23 мар 2014 в 16:51

Я могу подарить вам весь мой трафик, идущий через провайдера. Там всё шифрованное. Кроме кук на сайтах типа хабрахабра, но это уже другой вопрос.

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

Насчёт «решения» — дурацкую архитектуру костыли не исправят. WoT — наше всё.

foboss 23 мар 2014 в 16:56

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

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

amarao 23 мар 2014 в 17:22

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

Адекватное шифрование не выпускает нешифрованный трафик за пределы хоста. Что бы производители хардварных vpn не говорили.

foboss 24 мар 2014 в 02:01

Да вот же он, один из самых прекрасных слайдов, от которых google оч оскорбился и клятвенно ч-то там наобещал:

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

muon 24 мар 2014 в 01:12

> Как вообще можно от такого сценария защищаться?

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

borisko 23 мар 2014 в 14:37

Если пользователь до этого хотя бы раз зашел не на фальшивый сайт, то Ваша схема не сработает.

amarao 23 мар 2014 в 16:43

ок, пользователь зашёл на https://github.com

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

foboss 23 мар 2014 в 16:54

Браузер сам подставит https://

Если сертификат сайта окажется невалидным, не пропустит дальше.

amarao 23 мар 2014 в 17:17

А, в этом смысле, да. До ближайшей чистки истории.

ZyXI 23 мар 2014 в 17:55

Сильно подозреваю (https://support.mozilla.org/ru/questions/919498, не нашёл аналогичной ссылки для chromium), что HSTS обслуживается отдельно от истории.

ZyXI 23 мар 2014 в 17:57

не нашёл аналогичной ссылки для chromium

А, вот: stackoverflow.com/questions/10629397/how-to-disable-http-strict-transport-security: тоже говорится никак не о чистке истории.

catharsis 22 апр 2014 в 10:18

Тогда HSTS-хранилище пользователя сможет частично компрометировать историю посещений.
Потребуются отдельные опции на очистку журнала и HSTS (в firefox, предположительно, галочка «Настройки сайтов» в диалоге «Удалить недавнюю историю»).

muon 24 мар 2014 в 01:18

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

По-моему, простейшая схема выглядит чуть проще: сосед — студент 4 курса специальности, связанной с ИТ — врезается в провайдерский кабель и модифицирует любой проходящий трафик.

mwizard 24 мар 2014 в 01:05

Почему хорошим людям просто не собраться и не запретить незащищенные соединения? Вычислительная сторона SSL давно перестала быть проблемой для современного железа, разве нет?

Meklon 24 мар 2014 в 04:58

А как же тогда MitM проводить если надо? Не, так не пойдёт.

foboss 24 мар 2014 в 06:10

Если очень надо, можно внедрить бэкдор в алгоритм шифрования.

Meklon 24 мар 2014 в 06:34

Или компрометация корневых сертификационных центров, что проще, имхо. Иллюзия безопасности есть и сертификаты можно штамповать без проблем. С самоподписанными сертификатами не пройдет, но кто их будет вручную в браузер ставить?

Artiom1988 18 июн 2018 в 11:06

подскажите, а к ответам сервера вроде 404 или 500 Strict-Transport-Security должен цепляться или по сути все равно?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий