I have an SSL session. I have checked that the private key attached to the session is correct for the certificate which is shown as being received from the server using openssl pkcs8 -modulus. Yet the decrypt of the pre master secret is not correct.
Could there be any other reason apart from an incorrect key? Wireshark 1.12.8 on Windows. Robert asked 22 Oct '15, 07:30 ronslow showing 5 of 7 show 2 more comments |
One Answer:
Most certainly, the private key does not match the public key! See my answer to a similar question. UPDATE:
O.K. I did not see that in the first place. So, if you are 100% sure that the private key matches the public key in the cert (please double check that), it could be a bug in Wireshark, or something else. Is it possible to upload the whole ssl debug file somewhere and post the link here? If yes, the please do the following:
Regards answered 22 Oct '15, 08:16 Kurt Knochner ♦ edited 22 Oct '15, 09:10 Wireshark 1.12.8 on Windows 10. Snakeoil decrypts fine. I have previously decrypted other sessions using a different key/cert. Debug log shows that Wireshark is loading the key correctly for the ip address. 100% sure the private key matches the certificate coming from the server There's no issue with the certificate needing to be in the trust store, is there? (22 Oct '15, 09:25) ronslow Wireshark debug at http://pastebin.com/TtiTsDWb There is a TCP retransmissions at packets 18 and 19 but I don't think that this makes a difference. The same public key/cert combination failed in previous sessions without a TCP retransmission (22 Oct '15, 09:40) ronslow
looks like SSL session reuse/resumption was used and the initial handshake was not included in the pcap file, thus Wireshark can't generate the session key. (22 Oct '15, 12:54) Kurt Knochner ♦ Don't think so Kurt. Packet 16 has got the handshake and Wireshark is correctly selecting the private key. I always find this attempt to find a SessionID. (22 Oct '15, 14:13) ronslow I'm pretty sure it's as I said. In the ssl debug output, you can see, that your client is sending an SSL session ID in the CLIENT HELO. If there was no other (full) SSL handshake in Frame #0 - Frame #15, Wireshark won't be able to generate the session key.
Same problem, as described here:
To test my assumption, you can do this:
Are you then able to decrypt the pcap file? If so, I'm right. If you are still unable to decrypt the pcap, it's something else that just looks very similar to SSL session resumption. (22 Oct '15, 15:38) Kurt Knochner ♦ The SessionID length at packet 16 in the raw PCAP is 0. Looks like a bug in Wireshark. It's using a cached SessionID from some other session? (23 Oct '15, 02:44) ronslow In the debug log you can find that (23 Oct '15, 02:50) Lekensteyn Thanks Kurt for looking into this. (27 Oct '15, 03:16) ronslow showing 5 of 8 show 3 more comments |
Can you try your capture with the current 2.0.0rc? It has a fix for an edge case for the RSA private key parameters and has a new method to match private keys against public keys (it uses the modulus+exponent instead of a user-entered address+port).
Following Lekensteyn's suggestion, upgrade to Wireshark 2.0.0rc1 solved the problem for me.
Yup. Worked. See answer below. Thanks Lekensteyn.
O.K. and what was the problem? Wrong key, as I assumed first in my answer?
No, correct key. Works in Wireshark 2.0.0rc1 therefore must be a bug in Wireshark 1.12.8
O.K. good to know. Thanks.
@ronslow Can you link to logs from the 1.12 and 2.0 releases? If it is confidential, you can mail it to me using my PGP key 0xE9B345052419DC1097A9FC9473C4D7C13DB3073A.