Как расшифровать https трафик
Как легко расшифровать TLS-трафик от браузера в Wireshark
Многим из вас знаком Wireshark — анализатор трафика, который помогает понять работу сети, диагностировать проблемы, и вообще умеет кучу вещей.
Одна из проблем с тем, как работает Wireshark, заключается в невозможности легко проанализировать зашифрованный трафик, вроде TLS. Раньше вы могли указать Wireshark приватные ключи, если они у вас были, и расшифровывать трафик на лету, но это работало только в том случае, если использовался исключительно RSA. Эта функциональность сломалась из-за того, что люди начали продвигать совершенную прямую секретность (Perfect Forward Secrecy), и приватного ключа стало недостаточно, чтобы получить сессионный ключ, который используется для расшифровки данных. Вторая проблема заключается в том, что приватный ключ не должен или не может быть выгружен с клиента, сервера или HSM (Hardware Security Module), в котором находится. Из-за этого, мне приходилось прибегать к сомнительным ухищрениям с расшифровкой трафика через man-in-the-middle (например, через sslstrip).
Логгирование сессионных ключей спешит на помощь!
Настраиваем браузеры
Нам необходимо установить переменную окружения.
Windows
Откройте свойства компьютера, затем «Дополнительные параметры системы», затем «Переменные среды…»
Добавляем новую пользовательскую переменную «SSLKEYLOGFILE», и указываем путь до файла, куда мы хотим его сохранять.
Linux и Mac OS X
/.bashrc на Linux или в
/.MacOSX/environment на OS X, чтобы вам не пришлось ее устанавливать каждый раз после перелогина.
В следующий раз, когда вы запустите Firefox или Chrome из Dev channel, они будут логгировать TLS-ключи в этот файл.
UPD: Если у вас ничего не работает на OS X, загляните в комментарии (оригинальной статьи). Похоже, Apple изменила работу переменных окружения в новой версии OS X. Попробуйте запускать Firefox и Wireshark из этого же терминального окна:
Спасибо Tomi за это замечание.
Настраиваем Wireshark
Вам понадобится Wireshark версии 1.6 и новее. Открываем настройки Wireshark: 
Разворачиваем секцию «Protocols»:
Указываем путь к файлу:
Результат
Вот что мы обычно видим, когда инспектируем TLS-пакет:
А вот что происходит, когда мы переключаемся на вкладку «Decrypted SSL Data». Теперь мы можем видеть текст запроса. Победа!
Заключение
Надеюсь, теперь вам будет гораздо проще перехватывать TLS. Одна примечательная особенность этого метода заключается в том, что устанавливать Wireshark на компьютер, который генерирует TLS-трафик, не требуется, поэтому вам не придется устанавливать ненужные клиентам программы, вы можете сохранить дамп в файл на сетевой диск или просто скопировать его с машины, и использовать с дампом трафика.
Wireshark для всех. Лайфхаки на каждый день
Пакет с сертификатами от Хабра
Практические варианты использования
В Wireshark миллион функций, но буквально каждый человек с минимальными знаниями может использовать его с пользой. Ниже примеры основных сетевых задач.
Расшифровка трафика SSL/TLS
Chrome и Firefox могут записывать логи сессионных ключей, которые используются для шифрования трафика SSL/TLS. Наша задача — включить запись этих логов, а потом загрузить их в Wireshark для анализа. Предполагается, что у нас есть физический доступ к компьютеру пользователя, трафик которого мы хотим расшифровать. Или к серверу, который устанавливает зашифрованное соединение с пользователем.
Сначала включаем запись ключей.
Старые билды Windows 10
В старых билдах Windows 10 работает старый метод. Заходим в Панель управления → Система и безопасность → Система. На вкладке «Дополнительные параметры системы» нажимаем кнопку «Переменные среды».
Добавляем для пользователя новую переменную SSLKEYLOGFILE и указываем путь до файла.
В результате получаем логи с ключами, начало файла:
Новые билды Windows 10
В более новых версиях после установки Windows 10 старый способ добавления переменных окружения может больше не работать. Тогда есть альтернативный вариант с помощью команды в оболочке PowerShell.
[Environment]::SetEnvironmentVariable(«PATH», «C:\TestPath», «User»)
Первый параметр — это имя переменной, второй — значение, третий — для какого уровня переменная (пользовательский или системный).
[Environment]::SetEnvironmentVariable(«SSLKEYLOGFILE», «D:\wireshark», «User»)
Linux и Mac OS X
Под Linux и Mac OS X можно использовать такую команду для изменения переменной окружения и ведения логов — с запуском браузера из того же терминального окна, поскольку переменные окружения всегда работают в пределах одной сессии.
После накопления лога запускаем Wireshark.
Заходим в «Параметры», там на вкладке «Протоколы» (Protocols) находим раздел TLS (раньше он назывался SSL) — и указываем путь к файлу с логами и ключом, который использовался в сессии симметричного шифрования: (Pre)-Master-Secret log filename.
Например, при заходе пользователя на сервер Gmail в окне инспектирования пакетов QUIC мы видим обычные пакеты QUIC, зашифрованные ключом TLS.
Но в нижней части экрана появляется новая вкладка Decrypted QUIC, которая показывает расшифрованное содержимое этих пакетов.
Такой метод расшифровки трафика клиента не требует установки Wireshark на его компьютер, достаточно только скачать дамп с ключами, а потом использовать его вместе с дампом трафика.
Примечание. Этот способ не ограничен только HTTP. Точно так же можно перехватывать и расшифровывать трафик SSL/TLS в других потоках. Например, зашифрованный трафик от сервера MySQL.
Анализируем трафик с другого компьютера
Если нужно разобраться с сервером в продакшне, то удобно скопировать оттуда файлы pcap — и проанализировать трафик на личном компьютере.
Записываем пакеты на сервере с помощью сниффера пакетов tcpdump, который входит в стандартный комплект *nix:
Затем копируем файлы к себе на компьютер:
Здесь уже запускаем Wireshark и открываем полученный файл.
Есть вариант отслеживать серверный трафик в реальном времени со своего домашнего/рабочего компьютера. Например, весь трафик, кроме портов 22 и 53:
Примерно то же самое с компьютера под Windows:
Ищем проблемы
Чтобы выделить конкретное TCP-соединение, находим любой интересующий пакет, щёлкаем по нему правой кнопкой мыши — и применяем фильтр диалога.
Теперь из всего записанного трафика остались только пакеты, принадлежащие конкретно этому соединению.
На скриншоте мы видим пакеты с начала установки соединения TLS: пакет с приветствием клиента, ответный пакет с приветствием сервера, предъявленный сертификат, список шифров и так далее. Содержимое каждого пакета можно изучить отдельно. Очень удобно.
Типичный паттерн — использовать Wireshark для диагностики конкретных проблем. Например, в случае разрыва TLS-соединения мы можем зайти и посмотреть, кто его разорвал (клиент или сервер), на каком этапе это произошло и по какой причине.
Содержимое пакетов
Побайтовое содержимое каждого пакета — это настоящая магия. Конкретно эта функциональность Wireshark позволяет выявить самые серьёзные баги. Например, несколько лет назад выяснилось, что гигабитные Ethernet-контроллеры Intel 82574L отключаются, если отправить на них специально сконструированный пакет с определённой последовательностью байтов — так называемый «пакет смерти». Именно благодаря Wireshark выяснилось, какие конкретно байты в пакете приводят к гарантированному отключению сетевой карты.
Вот запись конкретных пакетов: pod-http-post.pcap и pod-icmp-ping.pcap. Можем их скачать, открыть в Wireshark и посмотреть своими глазами.
Отключение сетевого интерфейса Intel происходит, если по адресу 0x47f находится значение 2 или 3, то есть 32 HEX или 33 HEX. Если там 4, то всё нормально.
Для атаки подходил любой пакет: HTTP POST, ICMP echo-request и проч. Например, на веб-сервере можно сконфигурировать ответ 200 таким образом, что «убивает» сетевые интерфейсы на клиентских машинах. Довольно любопытная ситуация.
Поиск пакетов по содержанию
Выше мы применили фильтр диалога, чтобы выдать все пакеты для конкретного TCP-соединения. Однако фильтры можно писать и вручную. Вот некоторые примеры запросов:
Трафик с мобильного телефона
Аналогичным образом можно проанализировать трафик с фитнес-часов по Bluetooth или трафик любого мобильного приложения под Android. Для этого нужно записать пакеты PCAP на мобильном устройстве — и передать их для анализа в Wireshark на рабочем ПК.
Есть несколько мобильных программ для записи PCAP. Например, приложение
PCAPdroid для Android:
PCAPdroid
В принципе, можно не передавать записанные файлы PCAP, а анализировать их прямо на мобильном устройстве. В некоторых мобильных снифферах есть и зачаточные функции анализатора пакетов, см. Packet Capture и Termux (о нём ниже).
Packet Capture
Wireshark имеет и прямой интерфейс Androiddump, чтобы снимать данные с телефона напрямую через Android SDK.
Трафик с телевизора и других бытовых приборов
Чтобы изучить трафик с телевизора, смартфона жены или других бытовых приборов, которые подключены в домашнюю сеть по Ethernet и WiFi, придётся записывать PCAP на маршрутизаторе. Иногда достаточно встроенных инструментов. Если у вас маршрутизатор с прошивкой DD-WRT, то можно прямо на устройстве запустить tcpdump :
Для прошивки OpenWrt есть вариант зеркалировать трафик с помощью iptables-mod-tee.
Можно зеркалировать и записывать трафик с помощью дополнительного физического хаба или врезки в сеть. Подробнее см. в документации.
Другой способ — перехватить беспроводной трафик WiFi с помощью утилиты Airodump-ng без подключения к маршрутизатору. Но это больше подходит для анализа трафика на чужих хотспотах.
Далее всё по накатанной — загружаем файлы в Wireshark, запускаем фильтры.
Кстати, Wireshark поддерживает также анализ трафика USB: встроенный сниффер USBPcap и импорт пакетов из сторонних снифферов, таких как Npcap и RawCap.
Termshark
Если вы анализируете объёмные логи на удалённом сервере, но не хотите копировать всё на свою машину, может пригодиться Termshark — удобный пользовательский интерфейс в консоли для анализатора TShark, по внешнему виду напоминающий Wireshark.
Функции
Вот как выглядит версия под Android:
Wireshark как веб-приложение
Если по каким-то причинам вы не можете запустить Wireshark на локальной машине, можно воспользоваться облачным сервисом CloudShark, который сделан на удивление качественно.
Основная функция — совместная работа и публикация разборов пакетов по URL. Например, cloudshark.org/captures/05aae7c1b941. Файлы загружаются в облако и анализируются в браузере. Это нужно, если вы хотите спросить совета на форуме, поделиться информацией с коллегами или опубликовать разбор пакетов для широкой аудитории. Кстати, удобно использовать с мобильного телефона, ведь под Android есть приложения для захвата пакетов, а вот хорошего анализатора нет.
Сервис платный, есть 30-дневный пробный период.
В общем, Wireshark — просто фантастическая программа на все случаи жизни.
Кроме реальной практической пользы, анализатор даёт примерное представление о том, как работает фильтрация DPI у российских провайдеров. Там всё устроено примерно так же. Система в реальном времени сканирует трафик, фильтрует конкретно пакеты от Twitter — и замедляет их доставку пользователям на территории России. В частности, этим непотребством занимается Роскомнадзор с 10 марта 2021 года.
На правах рекламы
Если для работы необходим сервер в аренду на Linux или Windows, то вам однозначно к нам — активация услуги через минуту после оплаты!
[ВОЗМОЖНО] СОРМ расшифровывает HTTPS трафик к Mail.ru и ICQ
На конференции Chaos Constructions 2019 Леонид darkk Евдокимов показал любопытный доклад про случайно обнаруженные в открытом доступе панели управления СОРМ. Доклад можно посмотреть здесь: darkk.net.ru/2019/cc В двух словах: панели со статистикой работы программно-аппаратных комплексов СОРМ от МФИ Софт торчали наружу в интернет и всем было пофиг.
В какой-то момент времени наружу торчали сырые дампы перехваченного трафика, которые успел проиндексировать поисковик shodan.io. Вот один из таких дампов: archive.li/RG9Lj
Там есть MAC-адреса, IMEI телефонов и разная другая личная информация. Но самое интересное в этих дампах, что туда каким-то образом попал трафик к некоторым хостам на 443 порт (HTTPS) в открытом виде! То есть видны полностью GET запросы, а это может значить, что СОРМ умеет расшифровывать HTTPS. Попробуем подумать как такое возможно.
Вот как выглядят перехваченные куски трафика. Видно, что соединение происходит на порт 443, но при этом GET-запрос виден целиком:
Совершенно очевидно, что система каким-то образом получает доступ к трафику, который должен быть зашифрован. Как именно это происходит точно неизвестно и возможности это проверить нет. Поэтому остается только строить гипотезы.
Вариант 1: HTTP-трафик на 443 порт
Обычно, при отправке HTTP-трафика на HTTPS-порт (443) веб-сервер возвращает ошибку:
Ошибка при HTTP-запросе на порт 443
Автор доклада выдвигает предположение, что некоторые хосты могли принимать нешифрованный HTTP-трафик на порт 443. И действительно такие хосты нашлись, например mra1.mail.ru.
Это можно проверить так:
Видно, что запрос отрабатывает без ошибки. При этом другие хосты из дампа отвечают ошибкой на такой запрос.
Некоторые хосты принимают HTTP-трафик на HTTPS-порт
Из этой гипотезы следует, что программы Мейлу.ру и ICQ умеет по команде СОРМ отключать шифрование и переключаться с HTTPS на HTTP. Лично мне это кажется маловероятным, так как предполагает активные действия со стороны СОРМ и такую закладку легко обнаружить в программе локально. К тому же другие провайдеры, находящиеся по пути следования трафика, смогут перехватывать конфиденциальную информацию пользователей.
Вариант 2: у них есть ключи
Для пассивной расшифровки современного TLS недостаточно иметь приватный ключ сервера, так как для шифрования используются временные ключи (Perfect Forward Secrecy).
Тут возможны два варианта:
Вывод
Пока нет однозначных доказательств, что СОРМ действительно что-то расшифровывает. Все описанное здесь только предположение, основанное на словах автора доклада. В приведенных ссылках нет конкретных дампов с расшифрованным HTTPS трафиком.
Позиция Mail.ru Group
В очень старых версиях ICQ клиент действительно передает нешифрованный HTTP-трафик с аватарами и прочими элементами интерфейса по 443 порту. Такое решение применялось для обхода прокси-серверов в локальных сетях, т.к. трафик на 443 порт не проксируется.
Конспирологическую теорию о расшифровке трафика ICQ кем-либо мы не подтверждаем.
Анализ SSL/TLS трафика в Wireshark
Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).
Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.
Разобраться с расшифровкой будет гораздо проще, если есть общие представления о принципах работы протокола SSL/TLS. Рассмотрим упрощённый вариант функционирования SSL/TLS, выделив в нем только самые важные для нас моменты.
Обычно началу обмена шифрованными данными, в SSL/TLS предшествует процесс установки соединения, рукопожатие (SSL handshake).
На этом этапе помимо аутентификации и других действий две стороны (приложения) согласуют общий сеансовый ключ (симметричный). После согласования ключ используется приложениями для шифрации и расшифровки передаваемых между ними данных.
Однако как стороны согласуют одинаковый сеансовый ключ, общаясь по незащищенным каналам связи?
Для этого существуют различные алгоритмы. Наиболее часто используемые в Интернет – это RSA (самый популярный) и эфемерный Диффи-Хеллмана (DHE/ECDHE).
В момент установки SSL/TLS соединения алгоритм согласования сеансовых ключей выбирает сервер.
Выбор происходит из списка алгоритмов, поддерживаемых клиентом, которые он передает на сервер.
Ниже на диаграмме показан процесс согласования сеансовых ключей в случаях RSA и DHE/ECDHE, а также информация, которую видит сниффер (Wireshark) в перехваченном SSL/TLS трафике.
В первом случае (согласование ключей RSA) в момент установки соединения клиент генерирует случайное число, предварительный секрет (pre-master secret). Шифрует его открытым ключом, полученным в сертификате от сервера.
Отправляет в зашифрованном виде на сервер. Сервер расшифровывает предварительный секрет своим секретным ключом. Далее обе стороны, обладая одинаковым предварительным секретом, конвертируют его в главный и уже из него создают общий сеансовый ключ.
В ассиметричных алгоритмах шифрования (RSA) данные, зашифрованные открытым ключом, могут быть расшифрованы только секретным. При этом, открытый и секретный ключи должны быть связаны между собой определенным математическим образом, являются ключевой парой.
Во втором случае (согласование ключей DHE/ECDHE) все работает немного по-другому.
В момент установки нового соединения клиент и сервер генерируют пару случайных эфемерных (временных) ключей Диффи-Хеллмана.
Пара состоит из открытого и секретного ключей. Стороны обмениваются открытыми ключами.
Далее клиент и сервер, используя свой закрытый и полученный открытый ключи, создают предварительный секрет, главный секрет и общий сеансовый ключ.
В данном алгоритме постоянный секретный ключ сервера (RSA/DSA/ECDSA) в шифрации не участвует и используется только для подписи открытых DH-ключей. Описание очень общее, есть подробная информация в статье на хабре (Как HTTPS обеспечивает безопасность соединения: что должен знать каждый Web-разработчик) zavg.
Теперь возможно стало немного понятней.
Если клиент и сервер при согласовании сеансовых ключей используют алгоритм RSA, то перехваченный между ними трафик всегда можно расшифровать, имея секретный ключ сервера.
Дело в том, что в момент установки SSL/TLS-соединения клиент пересылает серверу зашифрованное значение предварительного секрета.
Предварительный секрет дешифруется секретным ключом сервера, далее вычисляется сеансовый ключ.
Данные расшифровываются полученным сеансовым ключом.
В случае использования алгоритма DHE/ECDHE и обладая секретным ключом сервера, расшифровать данные SSL/TLS трафика уже не получится.
В момент установки соединения передаются только открытые значения DH-ключей.
Секретные DH-ключи, необходимые для вычисления сеансовых, находятся в оперативной памяти клиента и сервера и после завершения соединения уничтожаются.
Эфемерные алгоритмы согласования ключей Диффи-Хеллмана (DHE/ECDHE) поддерживают Perfect Forward Secrecy (PFS).
Есть конечно другой, альтернативный вариант.
Подходит для расшифровки SSL/TLS-трафика без секретного ключа сервера, а также если используются алгоритмы DHE/ECDHE, RSA и другие.
В момент установки SSL/TLS-соединения в оперативной памяти клиента и сервера присутствуют открытые значения секретов, предварительного и главного.
Если успеть вытащить секреты из памяти и сохранить на диск, то в дальнейшем их также можно использовать для расшифровки данных.
Конечно, это не всегда просто сделать и не позволяет расшифровать трафик, перехваченный когда-либо ранее.
А теперь посмотрим, как на практике, обладая секретным ключом сервера или значениями секретов сессий, можно расшифровать SSL/TLS-трафик в Wireshark.
Wireshark + cекретный ключ сервера
Собственно, тут все относительно просто.
Загружаем в Wireshark дамп SSL/TLS-трафика обмена клиента с сервером, подключаем секретный ключ сервера и расшифровываем.
Конечно, предварительно стоит проверить, что клиент и сервер для согласования сеансовых ключей использовали алгоритм RSA.
Для этого находим инициализацию SSL/TLS-соединения (фильтр «ssl.handshake»).
Проверяем, что сервер в сообщении Server Hello в Cipher Suite указывает алгоритм RSA.
В ответном сообщении клиента (Client Key Exchange) присутствует зашифрованное значение предварительного секрета сессии (Encrypted PreMaster).
В появившемся окне жмем кнопку New и заполняем поля:
• IP Address – IP-адрес SSL-сервера в IPv4 или IPv6-формате
• Port – номер порта SSL-сервера (для https обычно 443)
• Protocol – название протокола, использующего шифрацию SSL (например, http). Если не известен, указываем data
• Key File – путь к файлу секретного ключа сервера (файл формата PEM или PKCS#12)
• Password – заполняется, только если секретный ключ PKCS#12 и защищен паролем
Подтверждаем выполненные настройки и наслаждаемся просмотром расшифрованного трафика.
Для удобства через фильтр выводим только трафик прикладного уровня, например, http.
Также открытая информация доступна на закладке «Decrypted SSL Data», в нижней части окна.
Или выбираем любой пакет из SSL/TLS-сессии, нажимаем правую клавишу мыши, затем в списке – «Follow SSL Stream».
Получаем поток расшифрованных данных из выбранного соединения.
Wireshark + cекреты сессий
Кроме секретного ключа сервера, для расшифровки данных в Wireshark могут использоваться известные значения секретов сессий.
Хорошая возможность для тех, у кого нет секретного ключа сервера или если сервер выбирает алгоритм согласования сеансовых ключей с поддержкой PFS (DHE/ECDHE).
Где и как можно достать секреты сессий?
Конечно, перед этим трафик должен быть расшифрован секретным ключом сервера.
Яркий пример таких приложений – это браузеры Chrome и FireFox.
Оба в своей работе используют криптографический модуль NSS, разрешающий логирование секретов в файл.
Формат лога приведён ниже и соответствует первым двум вариантам.
Более подробное описание функциональности есть в статье на хабре (Как легко расшифровать TLS-трафик от браузера в Wireshark) ValdikSS.
Используя сторонние утилиты, перехватывать секреты сессий в оперативной памяти клиента или сервера.
А теперь – о том, как и в каком виде секреты загружаются в Wireshark.
Значения секретов сессий указываются построчно в обычном текстовом файле в определенном формате.
Существует три возможных формата строк:
— зашифрованное значение предварительного секрета сессии (поле Encrypted Premaster в сообщение ClientKeyExchange)
— расшифрованное значение предварительного секрета
— случайное число клиента (Random в сообщение Client Hello)
— значение главного секрета сессии
RSA Session-ID: Master-Key:
— идентификатор сессии (поле Session ID из Server Hello или Session Ticket из Client Hello)
— значение главного секрета сессии
И теперь подключаем файл с секретами в Wireshark и дешифруем SSL/TLS-трафик.
Настройки Wireshark аналогичны указанным в предыдущем разделе.
За исключением того, что в настройках протокола SSL в «RSA keys list» не нужно ничего указывать (параметры SSL-сервера и его секретный ключ). Только в поле «(Pre)-Master-Secret log filename» путь к файлу с секретами.
Подтверждаем настройки и смотрим расшифрованный трафик.
Заключение
Надеюсь, представленная информация окажется интересной всем,
кто планирует или уже занимается анализом SSL/TLS-трафика в Wireshark.