This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Struggling to decrypt SSL

1

I've spent most of the day ripping my hair out trying to get SSL traffic to decrypt...

Here is the capture i've taken which should just be a simple hit to IIS splash screen. https://dl.dropboxusercontent.com/u/8208314/Wireshark/Capture.pcapng

The private key to the certificate is here: https://dl.dropboxusercontent.com/u/8208314/Wireshark/privatekey.pem

I've checked the private key matches the certificate. The modulus has been compared. I can decrypt snake oil example.

My debug log is here: https://dl.dropboxusercontent.com/u/8208314/Wireshark/debug.txt

I've removed from IIS all the cipher suites for Diffie-Hellman and ECDH so am at a loss why this won't decrypt.

The debug log is just saying there is no enough material to generate the key... what else does it need?

asked 01 Jul '15, 08:39

ingybing's gravatar image

ingybing
21114
accept rate: 0%


One Answer:

0

Your SSL capture uses SSL session resumption and skips the ServerKeyExchange. Therefore the encrypted key is not transmitted over the wire and you cannot decrypt the traffic even if you have the private key.

See the client request:

Frame 5: 204 bytes on wire (1632 bits), 204 bytes captured (1632 bits) on interface 0
...
Secure Sockets Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 145
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 141
            Version: TLS 1.0 (0x0301)
            Random
                GMT Unix Time: Jul  1, 2015 17:04:25.000000000 CEST
                Random Bytes: ea0ea305800f28c796df322c46728872f74e6464fe1fbc96...
            Session ID Length: 32
            Session ID: ed1100003c6c96e97979417c6bacf88ae7b637abcb5df1c1...
            ...

and the server response:

Frame 6: 199 bytes on wire (1592 bits), 199 bytes captured (1592 bits) on interface 0
...
Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 81
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 77
            Version: TLS 1.0 (0x0301)
            Random
                GMT Unix Time: Jul  1, 2015 17:04:25.000000000 CEST
                Random Bytes: b20d047492d020cb99ba0d233760e46ddc1dca41478a6732...
            Session ID Length: 32
            Session ID: ed1100003c6c96e97979417c6bacf88ae7b637abcb5df1c1...
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            ...

and the full communication (note: missing ClientKeyExchange):

  5  11.039305  10.64.99.12 -> 10.64.104.135 SSL 204 Client Hello
  6  11.039592 10.64.104.135 -> 10.64.99.12  TLSv1 199 Server Hello, Change Cipher Spec, Encrypted Handshake Message
  7  11.041144  10.64.99.12 -> 10.64.104.135 TLSv1 438 Change Cipher Spec, Encrypted Handshake Message, Application Data
  8  11.042308 10.64.104.135 -> 10.64.99.12  TLSv1 1072 Application Data, Application Data
 10  11.338115  10.64.99.12 -> 10.64.104.135 SSL 60 Continuation Data

See this figure from RFC 5246 for a flow diagram for the abbreviated handshake due to the use of session resumption (be sure to read the preceding text as well for a background).

answered 01 Jul '15, 08:46

Lekensteyn's gravatar image

Lekensteyn
2.2k3724
accept rate: 30%

edited 01 Jul '15, 08:52

Ok i think i understand... so i reset iis, closed my client ran another trace: https://dl.dropboxusercontent.com/u/8208314/Wireshark/capture2.pcapng and it's still not sending the serverkeyexchange during the server hello even through the client hello had no session id... so that ones no resuming an existing session is it? Shouldn't that be sending the server key exchange now? Is it due to the cypher why its not?

(01 Jul '15, 09:27) ingybing

Also the snakeoil example doesn't have a server key exchange... i'm confused.....

(01 Jul '15, 13:45) ingybing

@ingybing FYI, I have been working on this issue for the past days. The problem is within the parameters from your RSA private key. It upsets the crypto library (libgcrypt). I am now trying to find out the cause and a solution.

(05 Jul '15, 08:36) Lekensteyn

@ingybing It took some time to understand the cryptography behind it, but the fix such that your traffic is recognized can be found at: https://code.wireshark.org/review/9573

(09 Jul '15, 07:38) Lekensteyn