SSL: установка и примеры использования утилиты ssldump

By | 01/23/2014
 

ssl_logoДля анализа пакетов SSL есть отличный инструмент – SSLDUMP.

Страница разработчика – http://www.rtfm.com/ssldump/.

Установка и примеры выполняются на:

# uname -ro
FreeBSD 9.0-RELEASE-p3

Установка ssldump

Не забываем обновить порты:

# portsnap fetch update


Находим порт:

# cd /usr/ports/ && make search key="ssldump"
Port:   ssldump-0.9b3_4
Path:   /usr/ports/net/ssldump
Info:   SSLv3/TLS network protocol analyzer
Maint:  arved@FreeBSD.org
B-deps:
R-deps:
WWW:    http://www.rtfm.com/ssldump/

Устанавливаем, конфигурацию можно оставить по-умолчанию – всё необходимое в ней есть:

# cd /usr/ports/net/ssldump && make BATCH=yes install clean

Проверяем установку:

# ssldump -v
ssldump 0.9b3
Copyright (C) 1998-2001 RTFM, Inc.
All rights reserved.
Compiled with OpenSSL: decryption enabled

Для работы ssldump необходима библиотека lipcap. В стандартной конфигурации FreeBSD её нет, поэтому лучше проверить:

# whereis libpcap
libpcap: /usr/src/contrib/libpcap

Расшифровка значений ssldump

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

New TCP connection #1: mail5.domain1.net.ua(34690) <-> mail.domain2.org.ua(25)

Тут – запрос на новое SSL-соединение с хоста mail5.domain1.net.ua к сервереу mail.domain2.org.ua, номер соединения #1 – он же будет использоваться в дальнейшем выводе для упрощения идентификации полученных данных (прим.: в примерах номера сессий не везде совпадают, т.к. выполнялись по несколько раз);

Далее:

2 1  0.0355 (0.0355)  C>S  Handshake

2 – номер соединения, которому принадлежит этот пакет, 1– номер самого пакета, 0.0355 – время получения с момента инициализации сессии (первого SYN-пакета, время может быть разное, см. ключи ниже),  (0.0355) – время с получения предыдущего пакета. C>S – направление пакета (тут – от Client к Server), дальше идёт тип передаваемых данных, может быть: Handshake, Alert, ChangeCipherSpec или application_data.

Информация далее зависит от типа данных. Например, для Handshake это может быть:

5 2  0.1037 (0.0675)  S>C  Handshake
ServerHello
Version 3.1
session_id[32]=
52 e1 2b d1 56 82 9c fd be 35 e8 5f 72 e8 c4 f9
37 5f 8e bc ce a5 40 4e 1e 79 f6 35 e7 31 59 44
cipherSuite         TLS_RSA_WITH_RC4_128_SHA
compressionMethod                   NULL
Certificate
ServerHelloDone

ServerHello – тип сообщения, которое включает в себя:

  • Version 3.1 – поддерживаемая версия SSL;
  • session_id[32]=id сессии, необходима для поддержания/восстановления сессии;
  • cipherSuite – поддерживаемый тип ширования;
  • compressionMethod – метод сжатия;
  • Certificate – передача клиенту паблик-ключа сервера (?);

Дальнейшие данные зависят от заданных ключей.

Примеры использования

Синтаксис во многом схож с обычным tcpdump.

Прослушивать только определённый интерфейс – ключ -i:

# ssldump -i em0 | tee ssldump1.log
# head ssldump1.log
New TCP connection #2: 85.***.***.15(12351) <-> mail.domain2.org.ua(8443)
2 1  0.0355 (0.0355)  C>S  Handshake
ClientHello
Version 3.1
resume [32]=
52 e1 0e 11 77 b0 5e 89 66 0a e0 40 f1 8e ce ae
85 de 83 40 52 fe 25 f0 32 68 b2 0c c2 ce bf e6
cipher suites
Unknown value 0xc02b

И определённый порт:

# ssldump -i em0 port 8443 | tee ssldump1.log
# head ssldump1.log
New TCP connection #1: 85.***.***.15(27258) <-> mail.domain2.org.ua(8443)
1 1  0.0419 (0.0419)  C>S  Handshake
ClientHello
Version 3.1
resume [32]=
52 e1 0e 11 77 b0 5e 89 66 0a e0 40 f1 8e ce ae
85 de 83 40 52 fe 25 f0 32 68 b2 0c c2 ce bf e6
cipher suites
Unknown value 0xc02b
Unknown value 0xc02f

Важно – дополнительные опции должны быть заданы до опций, к которым указываются аргументы.

Например:

# ssldump -i em0 port 8443 -a
PCAP: syntax error

Ошибка “PCAP: syntax error” в данном случае не связана с системой, а вызвана именно неверной очередью опций.

Правильный вариант:

# ssldump -a -i em0 port 8443

Ещё полезной может быть опция -e – выводить текущее время, а не время “от начала эпохи” (Unix time):

# ssldump -e -i em0 port 8443 | tee ssldump1.log
# head ssldump1.log
New TCP connection #1: 85.***.***.15(52984) <-> mail.domain2.org.ua(8443)
1 1  1390481670.9259 (0.0386)  C>S  Handshake

Так время будет выводится в виде 1390481670.9259, что в привычном виде является Thu, 23 Jan 2014 14:54:30 +02:00.

Удобный конвертер времени есть тут>>>.

Ещё один ключ -n, по аналогии с tcpdump указывает не переводить IP в FQDN имена хостов и наоборот:

# ssldump -n -i em0 port 8443 | tee ssldump2.log
# head ssldump2.log
New TCP connection #1: 85.***.***.15(25108) <-> 77.***.***.40(8443)
1 1  3.0325 (3.0325)  C>S  Handshake
ClientHello
Version 3.1
resume [32]=
52 e1 0e 11 77 b0 5e 89 66 0a e0 40 f1 8e ce ae
85 de 83 40 52 fe 25 f0 32 68 b2 0c c2 ce bf e6
cipher suites
Unknown value 0xc02b
Unknown value 0xc02f

Ключ -H – выводить полный заголовок SSL-пактов:

# ssldump -H -i em0 port 8443 | tee ssldump2.log

В принципе бесполезно, если не выполнять декодирование этих самых пакетов, об этом – ниже.

Ключ -T – выводить полные заголовки TCP пакетов:

# ssldump -T -i em0 port 8443 | tee ssldump2.log
# head ssldump2.log
TCP: mail.domain2.org.ua(8443) -> 85.***.***.15(31673) Seq 2769725607.(37) ACK 637251301 FIN PUSH
TCP: 85.***.***.15(31673) -> mail.domain2.org.ua(8443) Seq 637251301.(0) ACK 2769725645
TCP: 85.***.***.15(31673) -> mail.domain2.org.ua(8443) Seq 637251301.(0) ACK 2769725645 FIN
TCP: mail.domain2.org.ua(8443) -> 85.***.***.15(31673) Seq 2769725645.(0) ACK 637251302
TCP: 85.***.***.15(36445) -> mail.domain2.org.ua(8443) Seq 2977162043.(0) SYN
TCP: mail.domain2.org.ua(8443) -> 85.***.***.15(36445) Seq 1852430927.(0) ACK 2977162044 SYN
TCP: 85.***.***.15(36445) -> mail.domain2.org.ua(8443) Seq 2977162044.(0) ACK 1852430928
New TCP connection #1: 85.***.***.15(36445) <-> mail.domain2.org.ua(8443)
TCP: 85.***.***.15(36445) -> mail.domain2.org.ua(8443) Seq 2977162044.(219) ACK 1852430928 PUSH
1 1  0.0343 (0.0343)  C>S  Handshake

Перейдём к ещё более интересным возможностям.

Чтение из файла

Можно записать все данные, полученные tcpdump в файл – и использовать его как input для ssldump.

Пример:

# tcpdump -nnvvXSs 0  -w /home/setevoy/Temp/tcpdump.log -i em0 port 8443
  • -vvv  самый подробный режим;
  • -s      длина пакетов для записи (0 – полностью);
  • -nn    >не преобразовывать IP в имена хостов и имена сервисов по используемым портам;
  • -i       интерфейс;
  • -w     запись вывод в файл.

Теперь запускаем ssldump  с ключём -r (read):

# ssldump -r tcpdump.log | tee ssldump3.log
# head ssldump3.log
New TCP connection #1: 85.***.***.15(53522) <-> mail.domain2.org.ua(8443)
1 1  0.0372 (0.0372)  C>S  Handshake
ClientHello
Version 3.1
resume [32]=
52 e1 0e 11 77 b0 5e 89 66 0a e0 40 f1 8e ce ae
85 de 83 40 52 fe 25 f0 32 68 b2 0c c2 ce bf e6
cipher suites
Unknown value 0xc02b
Unknown value 0xc02f

Расшифровка SSL-пакетов

И, наконец, самая полезная возможность – расшифровка содержимое полученных SSL-пакетов.

Для этого, само собой, потребуется ключ сервера. Если ключ хранится в формате .JKS – его необходимо конвертировать в формат .PEM (хотя, возможно, подойдёт и .DER – не проверял) – SSL: конвертировать файл .JKS в .PEM. Иначе – будет сообщение об ошибке:

# ssldump -d -k ../.ssh/akira.jks
Problem loading private key

Теперь – запускаем ssldump с новыми ключами: -d (decode), -k (key) и -p (password). Ключ -p и пароль можно не указывать – тогда ssldump запросит его при старте:

# ssldump -d -k ../.ssh/akira.pem | tee ssldump4.log
Enter PEM pass phrase:
# head ssldump4.log
New TCP connection #1: cs104.domain3.ru(32839) <-> mail.domain2.org.ua(80)
0.0392 (0.0392)  C>S
---------------------------------------------------------------
GET /feed/ HTTP/1.1
Range: bytes=0-524288
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; BOIE9;RURU)
Host: rtfm.co.ua
Accept: */*
Accept-Encoding: deflate, gzip

Тут есть один немаловажный момент – ssldump “из коробки” не понимает многие типы шифрования, что можно увидеть на примере таких строк:

cipher suites
Unknown value 0xff
Unknown value 0xc00a
...
Unknown value 0x2f
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
Unknown value 0xc008
...

Для устранения этой проблемы – можно установить пропатченный ssldump (например – отсюда>>>).

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

Из примера выше видно, что ssldump “понимает” TLS_RSA_WITH_RC4_128_SHA.

Открываем about:config браузера (Mozilla в данном случае), и отключаем все типы, кроме security.ssl3.rsa_rc4_128_sha и security.ssl3.ecdh_rsa_rc4_128_sha:

ssldump_1

Но после настройки соединения – лучше вернуть используемые значения в прежнее состояние.

Ссылки по теме:

http://www.rtfm.com
http://manpages.ubuntu.com
http://support.f5.com
http://khanna111.com
http://lost-and-found-narihiro.blogspot.com
https://devcentral.f5.com
https://blogs.oracle.com
http://www.frank4dd.com