HTTPS активно продвигается Интернет сообществом и основная идея перевести весь Интернет к определённому году на шифрованный трафик, благо современные машины это позволяют. HTTPS — это всегда хорошо. Но нужно знать и подводные камни связанные с ним.
Задача данной статьи — показать возможность слушать HTTPS трафик пользователя (назовём его Степан), и чтобы он этого не заметил.
Мы не будет брать последние исследования и эксплоиты в области взлома HTTPS. Пойдём лучше к основам и рассмотрим давно известные и простые способы.
HTTPS — это HTTP + SSL. Http — это открытый протокол передачи данных, открытый означает, что данные передаются в открытом виде. SSL — это протокол, обеспечивающий безопасное соединение посредством шифрования. То есть, наша задача состоит именно в том, чтобы перехватить чистый трафик нашего Степана и вывести его на чистую воду, какие же ХХХ сайты он смотрит по вечерам. Но мы ведь не как наш Степан и не смотрим XXX, поэтому для примера возьмём поисковик bing, который пока ещё может работать как по https, так и по http.
Ниже на картинке пример как выглядит перехваченный трафик при помощи WireShark на один и тот же запрос в bing для HTTP и для HTTPS.
HTTPS действительно криптует все данные включая урл-адреса, которые генерирует клиент. Но HTTPS построен на базе TCP/IP, то есть, информацию о том, куда направляется трафик, можно получить в незашифрованном виде. Мы говорим о Mac-адресах, IP адресах и портах.
С помощью онлайн инструментов (например, whois.domaintools.com) можно узнать, что это за IP адрес, кому принадлежит, а простым запросом в bing можно узнать, какие сайты крутятся на этом IP адресе (например, www.bing.com/search?q=ip:204.79.197.200).
Продолжим и подумаем вот о чём. Веб-сервер может хостить несколько сайтов, и у каждого может быть свой SSL сертификат. Следовательно, наличие просто IP адреса является недостаточным. Веб-сервер, когда к нему приходит первый запрос, должен знать, с каким именно сайтом необходимо установить соединение. Шифрования ещё нет, потому что его ещё необходимо установить. Значит, ещё до начала шифрования клиент должен передать каким-то образом информацию о домене сайта, чтобы веб-сервер мог зароутить клиентский запрос на необходимый ресурс. Следовательно, необходимо посмотреть на самый первый запрос от клиента на сервер, который инициирует начало самого шифрования. Снова возьмём наш любимый WireShark и посмотрим.
Здесь мы можем найти кое-что интересное:
- Первый запрос действительно содержит доменное имя сайта в незашифрованном виде, с которым будет инициироваться HTTPS соединение
- Второй запрос возвращает сам сертификат в незашированном виде на клиента, который содержит информацию, для какого домена он выдан. В случае с bing, сертификат ещё включает и расширенное поле Subject Alternative Name, в котором перечисляются домены, для которого сертификат может быть использован (в Bing сертификате можно найти даже адреса на staging среду).
HTTP проксики типа Fiddler-а (на рисунке выше) уже умеют делать экстракт этой информации из трафика.
Казалось бы всё, но есть ещё один способ узнать, не прибегая к взлому HTTPS, на какие ресурсы ходил Степан. Когда в браузере он набирает адрес сайта, то первый запрос идёт не на сервер, гда сайт находится, первый запрос идёт на DNS сервер, чтобы получить IP адрес для данного домена. DNS запросы не шифруются, поэтому только слушая DNS трафик, можно составить историю, какие ресурсы Степан посещал, и по IP адресу DNS сервера можно определить даже, где он приблизительно находился в это время.
Самое время подвести результаты:
- Не взламывая трафик мы всё-таки можем отследить какие ХХХ ресурсы (защищённые либо нет) наш Степан посещает вечерком.
- Можно написать скрипт для фильтрации и ведения полной истории, что Степан посещал, скажем, за последний год (мы не сможем сказать, что он там делал, но с определённостью можно сказать, что он там точно был).
- Если у меня есть непосредственный доступ к трафику (я — админ, который контролирует роутинг, или я — интернет провайдер, через который течёт трафик), то мне даже нет необходимости делать какие-либо действия на клиентской машине, чтобы направить трафик на меня.
- Wi-Fi или спутниковый Интернет может быть слабо защищён, и, зная адрес клиента, можно определить с какими ресурсами он работает.
- И самое главное. Степан так ничего и не заметил, а мы уже потихоньку собираем о нём информацию.
Но нам всё-таки мало знать, что и когда посещал наш Степан. Наша задача узнать, что Степан на этих ресурсах делал (то есть получить доступ к HTTP информации). Продолжение следует во второй части.
Денис Колошко, CISSP
Комментарии (28)
gto
24.05.2018 16:57А разве ssl c 2015-го не tls?
dhound Автор
24.05.2018 17:11нет. TLS это новая версия SSL протоколов. старые версии SSL протокола всё еще поддерживаются, хотя это будет выстрел себе в ногу. некоторые пользователи в первую очередь обращают внимание на то, какие версии SSL и TLS запрещены для использования.
FSA
25.05.2018 11:14Простите, а кто в здравом уме будет включать эти старые версии SSL у себя на сервере?
vesper-bot
25.05.2018 12:48Пораньше вроде, TLS1.0 вышел «первый раз» аж в 1999м. А вот то, что SNI пока ещё ходят открытым текстом — это факт (TLS1.3 это намеревается исправить).
ColdPhoenix
24.05.2018 17:07+11я что-то не припомню чтоб кто-то говорил что HTTPS прячет факт обмена данными...
Alexey2005
24.05.2018 17:14-3Особенно напрягает, что судя по последним тенденциям браузеры скоро простой http вообще поддерживать не будут, что сильно увеличит порог входа для новичков и снизит устойчивость сайтов (если сайт на https, его нельзя один раз настроить и забыть на 10 лет, а нужно постоянно контролировать, что там происходит с сертификатами).
Повторяется ситуация с электронной почтой. Если лет 15 назад почтовый сервер можно было поднять без особых проблем, то сейчас настроить почтовик, который мог бы успешно отправлять почту на тот же gmail, это чрезвычайно сложная задача.AlexFTF
24.05.2018 18:13А что там надо контролировать с сертификатами? Let's Encrypt, certbot… и что там контролировать… тем более уже сейчас хостинги это делают бесплатно и быстро, нужна только заявка от пользователя.
Akdmeh
24.05.2018 22:01Уже сейчас существуют плагины для систем управления сайтами, которые все автоматизируют в несколько кликов. Просто ставите галочку «включить https сайт, переводить трафик с http на https, включить HSTS, сертификат Let's Encrypt» — и все, сайт работает на https.
В чем сложность?
Если нужно Let's Encrypt не используя панель — консольная команда не намного сложнее.
Так что все стало наоборот проще и дешевле.geher
25.05.2018 16:45+1Представьте картину — Let's Encrypt внезапно изменяет порядок получения сертификатов. Или вообще перестает выдавать сертификаты, или вдруг какой-нибудь хром перестанет доверять сертификатам от Let's Encrypt.
В свете некоторых новостей это все не выглядит таким уж и невозможным.hahenty
25.05.2018 17:52Автоскрипт поменяет сам себя и продолжит писать в неизменившуюся конфигурацию сервера? Автоскрипт ещё и сам проследит за доверенностями, и при нарушениях может поменять для себя источник ключей, пусть даже это будет первый ключ от гугла.
FSA
25.05.2018 11:22Добро пожаловать в 2018 год. Я уже года два как пользуюсь Let's Encrypt. Ставил его на FreeBSD, Gentoo, Ubuntu, Debian. Последние версии рекомендуемого клиента certbot на столько развились, что даже если у вас nginx, то он найдёт все твои домены и предложит выбрать для каких из них тебе надо будет получить сертификат. Все необходимые конфиги будут прописаны автоматически. Дальше просто в cron прописываешь задачу на обновление сертификатов и больше о них не вспоминаешь. Ну, или если такой ленивый, то просто заходишь на сервер, когда тебе приходит письмо и руками запускаешь certbot renew и дёргаешь веб-сервер.
nazarpc
24.05.2018 17:19+12А где слабости HTTPS? Не вижу ни одной, всё работает как и задумывалось.
firedragon
24.05.2018 19:16-2Что составляет 99% передаваемой по сети информации и с какой долей вероятности болванку свежего дебиана будут качать миллионы пользователей.
Впрочем вместо болванки можете подставить патч, скрипт, ролик или фильм.VolCh
25.05.2018 07:39Вероятно, 99% составляет сейчас видеоинформация, 99% которой в шифровании с точки зрения пользователя не нуждается, так как не содержит его секретов.
dmitry_dvm
24.05.2018 17:19+9Хм, я думал https для того чтобы зашифровать передаваемые данные, а не сам факт посещения сайта. Кажется автор слегка за уши притянул проблему.
myxo
24.05.2018 21:12+1проблема не в том, что https не скрывает факт посещения сайта, а то, что многие люди это не понимают и думают, что если https, то можно вообще ни о чем не волноваться. Собственно эту проблему автор и пытается решить.
firedragon
24.05.2018 23:04В общем то он и это не делает. Системы DPI вполне себе успешно заглядывают внутрь, а экзабайты мусора передаются по сети и должны хранится на винчестерах провайдеров, причем за наши деньги
Chupaka
24.05.2018 23:47Вот и надо учить людей тому, что https — это способ убедиться, что страница пришла к тебе с оригинального (не подставного) сервера и не была модифицирована по пути. Для этого не обязательно на низком уровне разбирать, как же этот https работает =)
robert_ayrapetyan
24.05.2018 23:07+1Тут вся интрига во второй части, интересно, что нам поведают? Неужели что-то из серии про не зашифрованные заголовки TCP\IP пакетов…
Twost
25.05.2018 00:24+1сразу видно, что CISSP)
жду с нетерпением вторую часть, там видимо будут зиродеи с burpsuite и импортированным сертификатом
ianzag
Это прекрасно когда люди открывают для себя wireshark :)
foxin
Вот вы смеётесь, а когда я говорю коллегам, что игрок может посмотреть весь трафик между игровым клиентом и сервером — на меня смотрят огрооомными глазами.
Nikobraz
Представляю глаза игрока, если там текстовый протокол без шифрования
APXEOLOG
Сейчас модно все пускать по HTTPS, как уже было сказано в статье — считается что это достаточно. Это действительно достаточно от MITM, но совершенно не мешает игроку с Fiddler'ом. Я раньше для развлечения писал ботов для многих таких игрушек (обычно мобильные или браузерные), делалось все элементарно