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

SSL decryption mystery

0

I'm trying to decrypt SSL packets that are coming from the internet to an application in Windows, and I can't get the decryption to work. Below are the things that I've checked out (thanks again to Sake Blok's presentation for giving me these ideas):

--I may be wrong about this, but I believe that the cipher selected by the server is not Diffie-Hellman based. From the server hello, the cipher is TLS_RSA_WITH_AES_128_CBC_SHA.

--The capture session I'm trying to decrypt does include both the client and the server hello.

--This may be the cause of the problem: When the server sends me the 'Certificate' part of the handshake, it sends me THREE certificates, but I only have ONE private key. I've compared the modulus output of my private key to that of the three certificates, and my private key matches the first certificate listed, but not the other two.

In my debug file, the private key is loaded successfully, but I noticed the following two items which I think may indicate a problem:

dissect_ssl3_hnd_srv_hello trying to generate keys
ssl_generate_keyring_material not enough data to generate key (0x17 required 0x37 or 0x57)
dissect_ssl3_hnd_srv_hello can't generate keyring material

and

ssl_decrypt_pre_master_secret wrong pre_master_secret length (67, expected 48)
dissect_ssl3_handshake can't decrypt pre master secret

Thanks for any ideas you might have.

asked 17 Mar '13, 09:02

sandwiches9's gravatar image

sandwiches9
21●2●2●6
accept rate: 0%

One Answer:

1

This may be the cause of the problem: When the server sends me the 'Certificate' part of the handshake, it sends me THREE certificates, but I only have ONE private key. I've compared the modulus output of my private key to that of the three certificates, and my private key matches the first certificate listed, but not the other two.

That is normal, when the server sends it's certificate, it will send all the Intermediate CA certificates too, so that the client can validate the whole chain up to the root certificate (which it must have in it's trust store).

ssl_decrypt_pre_master_secret wrong pre_master_secret length (67, expected 48) dissect_ssl3_handshake can't decrypt pre master secret

That usually indicates a mismatch between the private key configured in Wireshark and the certificate/private key on the server. However...

I've compared the modulus output of my private key to that of the three certificates, and my private key matches the first certificate listed

Which means you do have the right key.

There have been some issues in the SSL libraries used by Wireshark on Linux systems lately, so that might be the cause of your troubles, cause AFAICT you're right on track in getting decryption to work...

answered 17 Mar '13, 09:23

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

1

Have you tried decrypting the snakeoil file described at http://wiki.wireshark.org/SSL?

If that does not work, then there is something wrong with your decryption libraries. It if does work, then we need to dig deeper in why you can't get it to work with your own capture file...

(17 Mar '13, 09:34) SYN-bit ♦♦

Thanks for bringing that up, I meant to mention that in my question -- I did try to decrypt the snakeoil file, and to my surprise, it did decrypt just fine. Also, one more piece of information, I'm using Wireshark 1.8.6 on Windows 7.

(17 Mar '13, 09:39) sandwiches9
1

OK, now that we know that (in principle) your decryption works fine. Let's look at the tracefile and ssl debug logging. Are you able to share your trace file (on www.cloudshark.org for instance)? And can you share the private key? Or is it a production server? If so, can you post the contents of the whole ssl-debug here?

If you can't share the files with the public, can you share them with me? (My email address is in the notes on my profile)

(17 Mar '13, 09:46) SYN-bit ♦♦

Thanks a ton for helping me with this, e-mail sent.

(17 Mar '13, 12:59) sandwiches9
1

The ssl session is being set up with client certificates. In an RSA key exchange, the public key inside the server certificate is used to encrypt the pre-master secret (from which the session key for encryption is derived). So, you only need the corresponding private key to decrypt the pre-master secret and subsequently decrypt the application data.

As discussed on the mail, you are using the private key of the Client certificate instead of the private key of the server certificate.

(18 Mar '13, 07:36) SYN-bit ♦♦

^^^Right, after some further reading yesterday and today, I have a better understanding of how all that works. Thanks again for going out of your way and pointing me in the right direction.

(19 Mar '13, 21:39) sandwiches9
showing 5 of 6 show 1 more comments