От чего спасает https?

Котиков в интернете смотреть приятнее.

от соседа-хакера Васи, снифающего вай-фай. Или врезавшегося в кабель. От СОРМа, кровавой гэбни, моссадов (хотя тут не уверен). От NSA скорей всего нет :)

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

Ну например от кражи данных через открытые wifi сетки, в теории. Т.е. по идее что-то покупать в инете карточкой становится можно не только из доверенной сетки, но и сидя в кафе. Хотя я все-равно не стал бы таким макаром использовать не виртуальную карту.

Что значит «в теории», от снифинга любого вида вообще-то HTTP(s) защищает гарантировано.

От СОРМа, кровавой гэбни, моссадов (хотя тут не уверен).

При грамотном использовании подобной силы - нет. Клиент не сможет различить сертификат пришедший от злодея и от реального сервера, если оба будут одинаковыми. Суть в том, что злодей выступает в роли хитрого прокси и все зашифрованное с твоей стороны (и обратной) расшифровывает, просто потому, что у него имеется все для этого: приватный и публичные ключи. Такой способ кажется трудноосуществимым, но имеет место в жизни.

Что значит «в теории», от снифинга любого вида вообще-то HTTP(s) защищает гарантировано

И от атак Man in the middle помимо этого (если исходить из допущения, что ни один из центров сертификации не скомпрометирован).

http://www.securitytube.net/video/100

И от атак Man in the middle помимо этого (если исходить из допущения, что ни один из центров сертификации не скомпрометирован).

И из допущения, что, например, тот же протокол SSL одним из ведомств не был взломан, что тоже очень может быть.

Смотря на каком уровне тебя снифают. Если снифер с тобой в одной системе, в составе DLP например - ни от чего не спасает вроде.

// а хотя стоп, фурифокс сразу палит и кидает исключение безопасности. ИЕ по барабану, а вот хром не пробовал.

Угу, если метод шифрования никто еще не поломал ;)

Ну вот как-раз от таких способов https и спасает. Если только не используется протокол шифрования, который уже поломали.

даже если успеть проснифать процесс handshake?

потому, что у него имеется все для этого: приватный и публичные ключи

А откуда у него имеются приватные ключи, если он не имеет доступ к удостоверяющему центру?

Это видео для кулхацкеров, для тех у кого есть сила таким заморачиваться вообще не надо:

1. кидаем сертификат от mitm (есть все ключи)
2. кидаем поддельный ответ от CA (если все же не сумели клонировать оригинальный сертификат)
3. проксируем и дешифруем все налету
4. ...
5. PROFIT!!!

При этом, основа силы это изменение TCP/IP-пакетов с модификацией отправителя/получателя. Т.е. DNS-спуфинг в таком случае вообще не нужен. Думаешь DPI придумали ради сниффинга? Китайцам осталось внедрить подобный механизм (а до этого недалеко, если уже не сделали) и тогда весь трафик построенный на известных и любимых протоколах будет под колпаком. Поэтому хацкерами считается, что лучший протокол/шифр - это свой протокол/шифр, пусть даже основанный на известных криптографических алгоритмах.

А откуда у него имеются приватные ключи, если он не имеет доступ к удостоверяющему центру?

Детали описывать не буду, но это делается через клонирование сертификата, при этом атакующий делает свою копию сертификата (процесс сложный) на основе своих приватных ключей. Более того, есть выход проще - сломать сервер CA, как было недавно, там ребята наклепали действующие сертификаты гугла и еще десяти известных компаний.

Если снифер с тобой в одной системе, в составе DLP например - ни от чего не спасает вроде

Снифер тебе не поможет. У тебя только один шанс — «прикинуться» целевым сервером.

mikhalich

а что за способ вскрытия когда производятся непонятные действия с корневым сертификатом на машине жертвы?

CA может участвовать в механизме расшифровки шифра сервера и клиента, когда используется доступ по клиентским сертификатам. В общем случае, клиент должен сверить, что сертификат сервера подписан известным клиенту центром сертификации и может доверять сертификату сервера (не просрочен, не находится в черном списке и т.п).

Сервер генерирует сертификат на основе запроса (делает клиент) и подписывает его сертификатом центром сертификации. В случае авторизации по клиентским сертификатам, сервер также производит проверку, что сертификат клиента валидный (подписан тем же ключом CA, не просрочен, заполнены те или иные поля, не попал в список запрещенных).

Поэтому, если подделать сертификат CA, который разрешает работать с сертификатами атакующего, то клиент будет считать его валидным. Фурифокс, возможно, проверяет checksum для сертификатов по своей базе и в случае расхождения ругается (самый простой способ, что пришел в голову).

Тоже самое, но на английском (и чел более подробно расписал): http://stackoverflow.com/questions/589622/ssl-question-how-does-a-root-ca-ver...

О атаке с использованием левого валидного CA можно почитатьна википедии

Да прям от всего, ето панацея просто. С http мои волоси били сухие и мертвие, с https они вечно мокрие и шевелтся.

А по делу, весь трафик шифруется и при перехвате тяжелее узнать што именно передалось.

Дополнительный вопрос - шифруется только само содержание пакета? Пункт назначения всё равно известен? Ну т.е. агент ФСБ, который живет у меня за стенкой всё равно знает где я качал котиков, но не знает, каких?

cast Harald, Nagwal, soslow, gh0stwizard, Dobriy_i_Prostoy, Sadler, mikhalich, Ttt.

Пункт назначения всё равно известен?

Очевидно, HTTPS никак не влияет на работу DNS.

Ну т.е. агент ФСБ, который живет у меня за стенкой всё равно знает где я качал котиков, но не знает, каких?

Агент ФСБ надыбает спецтехнику для съёма ПЭМИН и будет из-за стенки наблюдать экран твоего монитора (да, с LCD сложнее, но где-то читал, что реально). Ну, либо тупо аккуратно просверлит стенку.

Дополнительный вопрос - шифруется только само содержание пакета?

Да.

Пункт назначения всё равно известен?

Зависит от ситуации. Если запрос проходит через VPN-сервер на другом конце света, то нет. Но это другая история. Однако, агенту будет известно, что ты делал какие-то запросы на vpn-сервер, но куда и зачем, а также, что было внутри - нет. HTTPS в таком случае нужен, чтобы хозяин vpn-сервера случайно не начал читать, что ты шлешь :) И опять же, хозяину vpn-сервера ты либо доверяешь, либо нет, при очень большом желании он может отсылать тебе поддельные сертификаты.

с LCD сложнее, но где-то читал, что реально

Это основано на шумах в электропроводке. Если взять ноут или мобильник, которые не подключены к сети этот вариант не прокатит. Но можно попытаться использовать подобный анализ частот для wifi. Более того, сколько ж агентов надо чтобы следить за всей страной ? А ведь нужно еще посматривать за самими агентами :)

От чего спасает https?

от «Лиги Безопасного Интернета». в случае если она вдруг захочет заблокировать отдельные страницы сайта (а не весь ip адрес)

# P.S.: комменты не читал — зврвнее признаю в этом свою вину.

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

поэтому самоподписаные сертификаты не рулят

протокол SSL одним из ведомств не был взломан, что тоже очень может быть.

оставь свои фантазии при себе :)

сломать сервер CA, как было недавно, там ребята наклепали действующие сертификаты гугла и еще десяти известных компаний.

так это быстро обнаружилось и лавочку прикрыли

пункт назначения известен

так это быстро обнаружилось и лавочку прикрыли

Спец-сертификаты жили целую неделю, ага. Еще раз, левые сертификаты были в первую очередь от гугля, чтобы читать письма ничего не подозревающих жертв. Сколько действительно времени был скомпроментирован diginotar неизвестно. В любом случае, все остались довольны.

поэтому самоподписаные сертификаты не рулят

Я не говорил про самоподписанные сертификаты. Читай мои посты выше про клонирование сертификатов.

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

а давай что ли пруфлинк тогда, на всякий случай.

https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates

ага, спасибо

оставь свои фантазии при себе :)

Не дождётесь :)

Поэтому, если подделать сертификат CA, который разрешает работать с сертификатами атакующего

для этого нужен физический доступ к компьютеру атакуемого

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

сможет, т.к. у них будут разные ключи

для этого нужен физический доступ к компьютеру атакуемого

ну в моем вопросе это предусматривалось, да. Я указал, DLP всякие там

ну дак если комп уже скомпрометирован, зачем заморачиваться man-in-the-middle, когда можно сразу расшифрованные данные читать

Суть DLP не в том, чтобы читать что есть. Суть читать, что ходит по сети же.

сможет, т.к. у них будут разные ключи

В каком именно моменте? Еще раз, у атакующего есть приватный ключ и клон целевого сертификата, который был сгенерирован через первый. Публичный сертификат выглядит один-в-один как оригинал.

Еще раз, у атакующего есть приватный ключ

где он его взял?

где он его взял?

Сгенерировал у себя. Такая техника обсуждалась года два назад, особых подвижек не было, но практически удавалось создавать клоны только для ряда сертификатов (т.е некоторые невозможно было так подделать). Пруф лень искать.

Все, отбой.

https://www.sslshopper.com/article-md5-weakness-allows-fake-ssl-certificates-...

Тут в деталях: http://www.win.tue.nl/hashclash/rogue-ca/

Я как-то чужой траффик смотрел. Жаль ничего интересного не увидел.

Это при условии, что ты помнишь сертификаты всех посещаемых сайтов

А разве не браузер должен этим заниматься?

Наблюдателю известно, на какой IP ты ходил и приблизительные размеры трафика. Больше ничего не известно.

Если наблюдатель имеет контроль над компаниями, чьим сертификатам верит твой браузер (например США), то реализуема атака MitM. Защита - тщательная проверка сертификата, сверка с сертификатом, который видят другие люди.

Если злоумышленник контролирует весь трафик между тобой и миром, включая пути получения тобою софта, он может внедрить тебе свои ключи таким образом, что сможет прикидываться доверенным центром для твоего браузера и осуществить атаку MitM. Также возможно осуществить атаку на твой компьютер используя уязвимости в ПО, внедрить зловредное ПО и дальше всё как в предыдущем варианте. Защита - тщательная проверка сертификата, сверка с сертификатом, который видят другие люди, стандартные меры безопасности для защиты от вредоносного ПО.

В целом сценарии атаки больше гипотетические. Если ты не фигура уровня Каддафи, не используешь Windows то HTTPS обеспечивает 100% защиту.

А разве не браузер должен этим заниматься?

теоретически должен. Но не занимается :)

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

Но ведь с нормальными сайтами такого не происходит?
Думаю, в случае с гуглом/facebook/vk на хром/лису все же можно положиться. В конце концов, что мы теряем?