This is our old Q&A Site. Please post any new questions and answers at

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.

dissect_ssl enter frame #19 (first time)
packet_from_server: is from server - FALSE
  conversation = 00000000057C13E8, ssl_session = 00000000036F38B0
  record: offset = 0, reported_length_remaining = 198
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 134, ssl state 0x17
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 16 offset 5 length 130 bytes, remaining 139 
ssl_generate_pre_master_secret: found SSL_HND_CLIENT_KEY_EXCHG, state 17
pre master encrypted[128]:
| 9a 23 93 d6 e3 40 cf 8f 1f cb a9 c3 9c 03 ca 27 |.#[email protected]'|
| ba 7f 8d 86 f4 0d 46 ef 01 95 65 e9 0d 6d 9c de |......F...e..m..|
| 1f 7a cb 5b 8b a8 5e 10 a4 01 7b c5 00 8d b6 ec |.z.[..^...{.....|
| e2 a5 c9 97 31 45 81 60 71 0c c3 b1 76 68 0c 9e |....1E.`q...vh..|
| b5 78 d7 f9 52 c9 fe a9 26 a9 83 94 39 62 bf cd |.x..R...&...9b..|
| de 2c 9e 96 f9 5a d4 f7 b3 89 eb 34 de 65 1c cf |.,...Z.....4.e..|
| ef de ae 0a dd aa 82 08 53 71 5a b3 67 05 45 c7 |........SqZ.g.E.|
| 46 9f 6c f7 ec 49 70 b5 70 28 60 ea 6e 66 2d 4d |F.l..Ip.p(`.nf-M|
| 63 0c 93 bf a1 64 5b 2b ab 06 46 6a 71 64 16 42 |c....d[+..Fjqd.B|
| ab 36 d2 83 71 a9 32 43 e5 03 6d 8e 05 6d 06 e1 |.6..q.2C..m..m..|
| e1 89 43 f7 51 7b 64 f1 23 e1 6b 4d 50 2f d6 d8 |..C.Q{d.#.kMP/..|
| ec 0b 16 b3 6e e6 4c 97 b9 87 b7 a6 8e cd 88 60 |....n.L........`|
| cc 8c 67 01 52 8f 3a 0e b3 53 fb dd cd 2a f3 06 |..g.R.:..S...*..|
| 83 81 aa 55 99 f5 50 43 ad b5 12 7b 63 1f b4 0a |...U..PC...{c...|
| 4b 52 1d 56 4e 79 77 d1 50 e9 36 03 a5 a1 fd 20 |KR.VNyw.P.6.... |
| b4 a8 4c db 8d dd ec 67 3c 89 d8 17 ac 7c 94 36 |..L....g<....|.6|
pcry_private_decrypt: stripping 0 bytes, decr_len 128
ssl_decrypt_pre_master_secret wrong pre_master_secret length (128, expected 48)
ssl_generate_pre_master_secret: can't decrypt pre master secret

Could there be any other reason apart from an incorrect key?

Wireshark 1.12.8 on Windows.


asked 22 Oct '15, 07:30

ronslow's gravatar image

accept rate: 0%

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).

(23 Oct '15, 01:59) Lekensteyn

Following Lekensteyn's suggestion, upgrade to Wireshark 2.0.0rc1 solved the problem for me.

(27 Oct '15, 03:14) ronslow

Yup. Worked. See answer below. Thanks Lekensteyn.

(27 Oct '15, 03:15) ronslow

O.K. and what was the problem? Wrong key, as I assumed first in my answer?

(27 Oct '15, 04:03) Kurt Knochner ♦

No, correct key. Works in Wireshark 2.0.0rc1 therefore must be a bug in Wireshark 1.12.8

(27 Oct '15, 04:14) ronslow

O.K. good to know. Thanks.

(27 Oct '15, 04:28) Kurt Knochner ♦

@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.

(29 Oct '15, 02:57) Lekensteyn
showing 5 of 7 show 2 more comments

ssl_decrypt_pre_master_secret wrong pre_master_secret length (128, expected 48) ssl_generate_pre_master_secret: can't decrypt pre master secret

Most certainly, the private key does not match the public key!

See my answer to a similar question.


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.

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:

  • close Wireshark
  • empty the ssl debug file
  • start Wireshark and load the pcap
  • close Wirshark
  • upload the ssl debug file


permanent link

answered 22 Oct '15, 08:16

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

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 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

ssl_restore_session Cannot restore using an empty SessionID
trying to use SSL keylog in C:\Users\ronslow\Documents\xbundle\pms.log
failed to open SSL keylog
cannot find master secret in keylog file either

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.

dissect_ssl enter frame #16 (first time)
ssl_session_init: initializing ptr 0000000003CF58B0 size 712
association_find: TCP port 57452 found 0000000000000000
packet_from_server: is from server - FALSE
  conversation = 0000000005F013E8, ssl_session = 0000000003CF58B0 <==== HERE

Same problem, as described here:

To test my assumption, you can do this:

  • completely restart the client and/or the server (kill the process)
  • then capture the very first TLS connection between them.

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 ssl_restore_session did not (re)use a previous session key. You have configured a RSA private key and Wireshark is trying to use that key for decrypting the RSA-encrypted premaster secret from the ClientKeyExchange message. Apparently the RSA key is not correct (or read incorrectly). Can you try a newer Wireshark version as mentioned in the comment to your question?

(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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 22 Oct '15, 07:30

question was seen: 3,875 times

last updated: 29 Oct '15, 02:57

p​o​w​e​r​e​d by O​S​Q​A