0

I am having problems decrypting TLS encrypted syslog-ng packets in a honeynet using tshark (command line Wireshark). The goal is to be able to intercept the packets going from the honeypots to a honeypot-logserver. I have the private key as a .pem file with this format:

-----BEGIN RSA PRIVATE KEY-----

{the key is here}

-----END RSA PRIVATE KEY------

The command used for capturing is this:

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

This outputs hex, but it can be formatted as ASCII by piping it to xxd -r -p

The problem lies in that it seems that the encrypted traffic is not being decrypted, despite the debug log file from tshark loading the key successfully.

Here is the debug file from 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

I manage to decrypt the traffic by using TCPdump to log the traffic, and then using SSLDump to decrypt it. But the goal for me was to be able to decrypt traffic live, and not by files. SSLDump does not support live capture on a bridged interface without an IP address.

I hope someone has some knowledge on this issue.

1 Answer 1

2

While the information you've provided isn't enough to tell if this is the case in your instance, many servers have switched to schemes that provide "perfect forward secrecy". Which is to say that the ephemeral symmetric encryption key is negotiated using Diffie-Hellman instead of the traditional technique of being generated by one side and sent asymmetrically encrypted using the certificate keypair.

Of course, this means that without obtaining the ephemeral key directly from either the client or the server (unlikely), decryption is impossible. Since, in this case, the key isn't sent encrypted using the certificate keypair, having the private key doesn't help you. This is the whole point to Perfect Forward Secrecy. Even if you have possession of the private key, you still can't decrypt captured traffic.

If you need to do traffic snooping in your own testing, either run the traffic through a relay that can output the content in transit (like the one I wrote here), or turn off PFS on your client/server. That means disabling any protocols that mention DH key exchange (e.g. DHE or ECDHE).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy