So far we have learned how the SSL/TLS protocol encrypts traffic and maintains confidentiality. In the next section, we will cover how Wireshark helps to decrypt SSL/TLS traffic.
Decryption of TLS traffic depends upon which cipher suite was chosen by the server in the Server Hello message. Open the file decrypt-ssl-01.pcap and look for the cipher selected by the server. In this case the TLS_RSA_WITH_AES_256_CBC_SHA cipher suite was used; since this is RSA, we can decrypt the packet using our private key.
Now go to Edit | Preferences | Protocol | SSL, add the new RSA key, and configure the following properties of the RSA key dialog box:
After applying these settings, the SSL traffic will be decoded into HTTP traffic for that IP, as shown in the following screenshot:
Once the packet is decrypted, the SSL session can be exported by clicking on File | Export SSL Session Keys. A dialog box will open; save this session key in the file (exported-session-keys). The content of the file looks like this:
RSA Session-ID:af458c9c61675238b74f40b2a9547a0a2a394ada458a1b648e0495ed279d5e2e Master-Key:6c970211a77548811267646a759d0d03bbc532d9b6336f2b656cb0c6bbef8f3a262d845b9abed87d26583a9c4bb9b230
Once the exported-session-keys file is created, use this file to decrypt the SSL/TLS traffic. To do so, go to Edit | Preferences | Protocol | SSL and configure the (Pre)-master-secret log file with the path of the SSL Session Keys. This approach is helpful when the user wants to share the packet without sharing the private keys and still needs to provide the decryption step:
DHE/ECDHE can't be decrypted using this approach even if we have private keys as they are designed to support forward secrecy.
Forward secrecy is supported in the Diffie-Hellman (DHE) and Elliptic curve cryptography Diffie-Hellman (ECDHE) key exchange algorithms. Take the previous scenario; the SSL/TLS communication can be decrypted by knowing the server's private key. If the private key is compromised by poor system hardening or (an internal threat agent), the SSL/TLS communication can be broken. In forward secrecy, the SSL/TLS communication is secure even if we have access to the server's private key.
If the cipher suite's name contains "ECDHE" or "DHE", it means it supports forward secrecy. For example, note this cipher suite name: TLS_ECDHE_RSA_WITH_RC4_128_SHA.