Использование squid ssl_bump для просмотра содержимого https-трафика

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

  1. анализ действий и высокоуровневая отладка приложений, взаимодействующих с другими хостами(серверами) по https
  2. реверс-инжиниринг протоколов, работающих поверх https
  3. фильтрация контента (например, рекламы) на сетевом шлюзе
  4. отслеживание и ограничение действий пользователей в корпоративных сетях (предотвращение утечек конфиденциальных данных)
  5. различная незаконная деятельность (кража конфиденциальная данных и т.п.) в условиях, когда конечному пользователю неизвестно об установке дополнительного корневого сертификата на его устройство

В первых трёх случаях мы сами устанавливаем CA-сертификат на своё устройство и делаем это целенаправленно. В четвёртом случае, это делается администраторами корпоративной сети. В последнем же случае CA-сертификат попадает в устройство либо в результате действий вредоносного ПО или путём обмана пользователя, либо производителем самого устройства предустановлено на заводе.

Схема подключения устройств для этой статьи выполнена следующим образом:
ssl_bump_scheme

Базовая настройка роутера выглядит следующим образом:
– включена маршрутизация (net.ipv4.ip_forward=1)
– на порту eth0 (в сторону LAN-свитча) работает isc-dhcp-server, раздаёт адреса 192.168.1.1-192.168.1.127, ip интерфейса eth0 192.168.1.128, маска сети /24
– через порт eth1 (в сторону Internet) настроено WAN-подключение к интернет-провайдеру, включен iptables SNAT (в случае, если IP-адрес, выдаваемый провайдером динамический, вместо SNAT используется MASQUERADE)

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

Для того, чтобы заняться расшифровкой https и повторным шифрованием нужно установить PROXY-сервер SQUID 3.4 (на текущий момент актуальная версия 3.4.10), который умеет работать в прозрачном режиме (в самом деле, в двух прозрачных режимах, но мы будем использовать более простой – intercept). Прописывать прокси-сервер в настройках сетевого подключения на конечных устройствах не придётся.

Чаще всего, в репозиториях популярных дистрибутивов Linux, Squid поставляется без ssl_bump, поэтому его придётся собирать из исходных кодов:

user@router ~ $ wget http://www.squid-cache.org/Versions/v3/3.4/squid-3.4.10.tar.xz
user@router ~ $ tar -xf squid-3.4.10.tar.xz
user@router ~ $ cd squid-3.4.10/
user@router ~ $ ./configure --prefix=/opt/squid --enable-ssl --enable-ssl-crtd
user@router ~ $ make
user@router ~ $ sudo make install
user@router ~ $ sudo chown nobody /opt/squid/var/logs/
user@router ~ $ sudo mkdir /opt/squid/var/lib
user@router ~ $ sudo /opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db
user@router ~ $ sudo chown -R nobody /opt/squid/var/lib/ssl_db

Генерация CA-сертификата:

user@router ~ $ openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout squidCA.pem  -out squidCA.pem
Generating a 2048 bit RSA private key
...
writing new private key to 'squidCA.pem'
-----
...
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:HOME
Common Name (e.g. server FQDN or YOUR name) []:SQUID
Email Address []:
user@router ~ $ openssl x509 -in squidCA.pem -outform DER -out squidCA.der
user@router ~ $ sudo cp squidCA.pem /opt/squid/etc/squidCA.pem

Файл squidCA.pem содержит CA-сертификат и приватный ключ в BASE64-кодировке, файл squidCA.der содержить только CA-сертификат в DER(бинарной) кодировке, этот файл предназначен для импорта конечными устройствами.

Конфигурация /opt/squid/etc/squid.conf:

cache deny all
http_access allow all
http_reply_access allow all

https_port 192.168.1.128:3166 intercept ssl-bump  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/squidCA.pem
ssl_bump none localhost
ssl_bump server-first all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslproxy_options ALL
sslproxy_cipher ALL

httpd_suppress_version_string on
via off
forwarded_for transparent
reply_header_access X-Cache deny all
reply_header_access X-Cache-Lookup deny all
request_header_access Cache-Control deny all

Запуск Squid осуществляется командой “/opt/squid/sbin/squid”, выключение “killall squid” (3 раза). Проверить, что Squid запущен нужно следующим образом:

user@router ~ $ sudo netstat -ntplu | grep squid
tcp        0      0 192.168.1.128:3166      0.0.0.0:*               LISTEN      7215/(squid-1)  
udp        0      0 0.0.0.0:50048           0.0.0.0:*                           7215/(squid-1)  
udp6       0      0 :::41916                :::*                                7215/(squid-1)

Логи squid хранятся в файлах /opt/squid/var/log/cache.log и /opt/squid/var/log/access.log

На роутере остаётся дело за малым, завернуть https-трафик на локальный SQUID:

user@router ~ $ sudo iptables -t nat -I PREROUTING -p TCP -s 192.168.1.19 --dport 443 -j REDIRECT --to-port 3166
user@router ~ $ sudo iptables -t nat -I PREROUTING -p TCP -s 192.168.1.29 --dport 443 -j REDIRECT --to-port 3166

Для удаления вместо опции -I нужно использовать -D. IP-адреса 192.168.1.19 и .29 принадлежат устройствам PC и Mobile Phone.

Однако, прежде чем перенаправлять трафик на Squid, нужно установить дополнительный корневой сертификат на конечные устройства (файл squidCA.der). Например, для Mac OS X 10.9 это делается с помощью утилиты Keychain Access(File->Import Items, Destination Keychain=login, Always Trust), результат выглядит следующим образом:
Keychain Access-login-CA

Для Android(начиная с 4.0) тоже есть встроенный механизм импорта корневых сертификатов (в версии 4.4 Настройки->Безопасность->Хранилище учётных данных->Установить из памяти(установить сертификаты с носителя)). Результат установки:
Android-user-CA-certificate

В более старых версиях Android возможно добавить свой CA-сертификат в общее хранилище при условии наличия root-привилегий на устройство. Добавление в общее хранилище является более удобным способом, т.к. это не требует установки PIN-кода/пароля на телефон, не появляется предупреждение безопасности при включении устройства.

Теперь запустим браузер(Chrome 39.0.2171.95) на PC и проверим, что осуществляется перехват https-трафика с подменой сертификата:
example.com-ssl-squid

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

Содержимое https-запросов (в зависимости от уровня логирования) можно увидеть в лог-файле access.log Squid-а, но куда более удобный способ анализа – использование Wireshark(запущенный на router). Для того, чтобы расшифровывать трафик, передаваемый в сторону конечных устройств, нужно указать Wireshark-у где находится приватный ключ. Для версии 1.99.2 (development version) настройка осуществляется так: Edit->Preferences->Protocols->SSL->RSA Key List->Edit, далее как на скриншоте:
wireshark-ssl-decrypt-settings

После чего запустим wireshark на интерфейсе eth0 с capture filter “port 443 and host 192.168.1.29” и посмотрим какие https-запросы отправляются с мобильного телефона на Android-е:
wireshark-ssl-decrypt-yamail
На скриншоте изображено взаимодействие приложения Яндекса.Почта с их сервером посредством https. Кроме этого взаимодействия, был обнаружен ещё такой запрос к одному из серверов Яндекс (IP 213.180.204.58, в поле Host analytics.mobile.yandex.net):

POST /report?deviceid=<удалено>&uuid=<удалено>&
analytics_sdk_version=160&client_analytics_sdk_version=160&
app_version_name=2.06&app_build_number=9118&os_version=4.4.2&
locale=ru-RU&

is_rooted=1&

api_key=<удалено>&app_id=ru.yandex.mail&app_platform=android&protocol_version=2&
model=SM-G900FD&manufacturer=Samsung&
screen_width=1920&screen_height=1080&screen_dpi=480&scalefactor=3.0&
device_type=phone&android_id=<удалено>&adv_id=

А в самом теле POST-запроса содержится текущий список видимых Wifi-сетей (хотя в системных настройках геолокации разрешено использование только GPS).
Я понимаю зачем им нужны эти данные и даже передача списка wifi-сетей не удивляет, но интересно, зачем Яндекс хочет знать, что мой телефон рутирован? (is_rooted=1)

Advertisements

One thought on “Использование squid ssl_bump для просмотра содержимого https-трафика

  1. MonaxGT

    Интересный подход, там можно проанализировать данные и гугла, фейсбука, вк и сравнить поля. Возможно это типовой подход или ФБС следит за нами)

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s