Проблемы с использованием tshark сниффинга TLS-шифрованного трафика с ключом .pem

Question

У меня проблемы с расшифровкой зашифрованных TLS-пакетов syslog-ng в honeynet с помощью tshark (командная строка Wireshark). Цель состоит в том, чтобы иметь возможность перехватывать пакеты, идущие от honeypot к honeypot-logserver. У меня есть закрытый ключ в виде файла .pem в следующем формате:

----- НАЧАТЬ RSA ЧАСТНЫЙ КЛЮЧ -----

{ключ здесь}

----- КОНЕЦ RSA ЧАСТНЫЙ КЛЮЧ ------

Команда, используемая для захвата, выглядит так:

tshark -n -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list: 0.0.0.0,0,data,/root/privkey_new.pem" -o "ssl.debug_file: SSL-Decrypt.log" -i eth1 -R "tcp.port==1999" -T fields -e data.data

Это выдает шестнадцатеричный код, но его можно отформатировать как ASCII, отправив его в xxd -r -p

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

Вот файл отладки от tshark:

ssl_load_key: swapping p and q parameters and recomputing u
ssl_init IPv4 addr '0.0.0.0' (0.0.0.0) port '0' filename '/root/privkey_new.pem' password(only for p12 file) ''
ssl_init private key file /root/privkey_new.pem successfully loaded.
association_add TCP port 0 protocol data handle 0x7f2b49775a50

Мне удается расшифровать трафик с помощью TCPdump для регистрации трафика, а затем с помощью SSLDump для его расшифровки. Но цель для меня состояла в том, чтобы иметь возможность расшифровывать трафик в реальном времени, а не по файлам. SSLDump не поддерживает захват в реальном времени на мостовом интерфейсе без IP-адреса.

Я надеюсь, что у кого-то есть знания по этому вопросу.

Answer 1

Хотя предоставленной вами информации недостаточно, чтобы определить, так ли это в вашем случае, многие серверы переключились на схемы, обеспечивающие "идеальную секретность пересылки". Это означает, что эфемерный симметричный ключ шифрования согласовывается с использованием Диффи-Хеллмана вместо традиционного метода генерации одной стороной и отправки асимметрично зашифрованного с использованием пары ключей сертификата.

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

Если вам нужно отслеживать трафик в вашем собственном тестировании, либо пропустите трафик через ретранслятор, который может выводить контент в пути (как тот, что я написал здесь), либо отключите PFS на вашем клиенте / сервере. Это означает отключение любых протоколов, в которых упоминается обмен ключами DH (например, DHE или ECDHE).