Decrypt HTTPS Traffic Using Private Key
|
Applied version
|
Decrypt HTTPS traffic Using Private Key
(1) Examining the decrypted application data using the (asymmetric) private key
To decrypt and display application data, the ssldump utility will need:
- Private key
- Captured SSL traffic in pcap file, this needs to include the SSL handshake packets
Locating a BIG-IP virtual server’s private key
- BIG-IP 9.x – 10.x: /config/ssl/ssl.key/
- Example: /config/ssl/ssl.key/www.site.com.key
- BIG-IP 11.x – recent: /config/filestore/files_d/Common_d/certificate_key_d/
- Example: /config/filestore/files_d/Common_d/certificate_key_d/:Common:www.site.com.key_1
To determine the key used for a particular virtual server, examine the virtual server configuration to determine the name of the SSL profiles applied to the virtual server, then examine the SSL profile configuration to determine the name of the key file.
Decryption Caveats
Not all ciphers provide the ability to decrypt SSL traffic using a utility such as ssldump and wireshark.
- Depending on the cipher negotiated, the ssldump utility may not be able to derive enough information from the SSL handshake and the server’s private key to decrypt the application data.
- Examples of such SSL ciphers would be the DHE (Diffie-Hellman Ephemeral) cipher suites and export-grade RSA cipher suites.
- For troubleshooting purpose, you can temporarily change the cipher suite used in your SSL profile so traffic can be decrypted with ssldump.
- Example of decryptable cipher string: NONE:AES128-SHA.
One of the most common reasons an ssldump may not decrypt application data, is if the data is contained within a resumed TLS session.
- Public key operations are expensive in terms of processing power during the initial setup and key exchange.
- TLS specifications allow a secure shortcut by using the session_id to resume an SSL connection for which the key exchange was already performed.
- In situations where the SSL communication is using a resumed session, ssldump will not be able decrypt the application data unless the capture file contains the initial handshake containing the asymmetric key exchange and session_id.
- The ssldump utility relies on the information that is exchanged during the initial session setup to decrypt the data.
- To avoid this situation, you can use one of the following methods:
- Temporarily disable the SSL session cache in the Client SSL profile by disabling the Renegotiation option.
- Disabling the SSL session cache causes the BIG-IP system to perform a full SSL handshake for each connection.
(1.1) Decryption using Ssldump
[root@ltm101:Active:Standalone] config # tcpdump -vnni 0.0:nnnp -s0 -w /var/tmp/decrypt-ssl-asymmetric-key.pcap host 192.168.201.10 and tcp port 443
[root@ltm101:Active:Standalone] config # ssldump -Aed -nr /var/tmp/decrypt-ssl-asymmetric-key.pcap -k /config/filestore/files_d/Common_d/certificate_key_d/\:Common\:default.key_29915_1 >> /var/tmp/decrypt-ssl-asymmetric-key.pcap.txt
- Client SSL cipher, Tcpdump syntax, Ssldump syntax (Figure 1)
- Decrypted HTTP client request (Figure 2)
- Decrypted HTTP server responses (Figure 3)
(1.2) Decryption using Wireshark
Open the pcap file using Wireshark, decrypt-ssl-asymmetric-key.pcap.
Configure Wireshark to use the private key for specified server
- Wireshark -> Preferences -> Protocols -> TLS -> RSA keys list [Edit]
- 192.168.201.10, 443, http, default.key
- Before decryption (Figure 1)
- Wireshark Preferences (Figure 2)
- Wireshark Protocol: TLS -> Edit RSA keys list (Figure 3)
- Add HTTPS server details and private key (Figure 4)
- After decryption (Figure 5)
0 Comments