I tried to figure out if there is a way to decrypt resumed SSL session in Wireshark if first session with full SSL handshake (including pre-master key exchange) is not captured.
Seems that it's not possible even when pre-master secret was captured via ssldump. But maybe I am doing something wrong?
Is above correct? I assumed that when original pre-master secret is know to Wireshark it can generate master key and use it for resumed sessions even without seeing original full SSL Handshake.
Am I missing something here? Is that just limitation of Wireshark or it is not technically possible at all to decrypt resumed session knowing original pre-master key.
Sure I am talking about RSA non ephemeral cipher suites, in this case Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Very good question. I've always been under the impression the pre-master secret is the 'key' to deriving the master as well. However, in looking at the way the master is generated, it seems the randoms from original client and server hellos are required as well:
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
Would be interesting to hear some additional thoughts.
I was under impression that if RSA key exchange is used - so no Forward Secrecy or Perfect Forward Secrecy involved then master secret is always the same, generated by both sides using shared pre-master secret. That is reason to use FS or PFS.
That is as well info in all great videos about PFS posted on your site (John, thanks again).
So knowing pre-master should be enough to decrypt resumed session - of course if pre-master was captured when full SSL handshake was performed for that session.
All the logic for session resumption (at least my understanding) is to not go through new master secret generation and use master secret that is still in both client and server memory (identified by Session ID).
So it seems some limitation of Wireshark, which refuses to use pre-master configured if it can't see full SSL handshake, maybe because it can't connect configured pre-master with resumed session because of not being aware that Session ID send by client to use resume is the one for which configured pre-master should be used?
If above is true then it's quite a problem, but probably one that can be overcome - but not using Wireshark?
Based on what I'm seeing in RFC5246, this would be a more complete statement:
generated by both sides using shared pre-master secret and the client_random and server_random headers exchanged during the initial SSL handshake.
Still when session is resumed I doubt there is any pre-master exchange (will have to verify using packet capture), sure for generating pre-master in full SSL handshake random number is used - I can clearly recall it.
But if for resumed session again random number is exchanged then it will force recalculation of master secret, so for me denying benefits of resume - which if I am not wrong is to avoid costly master secret calculation, but maybe I am wrong?
Anyway, from tests when pre-master is configured and trace contains full SSL handshake session all resumed sessions are ddecrypted.
If new trace is started, so not SSL full handshake in the trace then nothing can be decrypted.
If new random number would be used for resumed session then pre-master from full handshake should not change anything in decrypting trace - even containing full handshake - or I am wrong here?
Below stating "session's master_secret" seem to indicate new randoms are associated with an existing master_secret:
When a connection is established by resuming a session, new
ClientHello.random and ServerHello.random values are hashed with the
But the question remains (for me); does Wireshark need the randoms from the initial, full handshake?
Well, so in short, it's only possible to decrypt resumed session when:
If trace does not contain full handshake session, resumed session are not possible to be decrypted even having private key or pre-master from original full handshake session.
Is above true?
Answering my own question :-)
Based on test:
Capture with resumed sessions only, pre-master from full handshake attached in Wireshark - no decryption
Capture with resumed sessions only, merged with full handshake session stored before, pre-master from full handshake attached in Wireshark - resumed session decrypted
Indeed even when resumed session handshake is performed, random bytes are exchanged between client and server.
Still, there is no new pre-master exchanged so I am not sure what operations both server and client performs in relation to master secret - is that somehow recalculated but using some simpler method than in full handshake - I am still looking for performance savings in using resumed session vs full handshake.
Conclusion: To be able to decrypt resumed sessions using stored pre-master secret it's necessary to have full handshake session stored and then merge it with capture containing resumed sessions.
Same is true when using private key.
Comparing pre-master secret file generated by ssldump with content of full SSL handshake record I can see that file contains:
I assume that Wireshark is matching content of pre-master secret file to ssl record by comparing those 8 bytes. Then based on that it can find Session ID and identify resumed session as using specified pre-master secret file.
I did test by changing one byte of 8 byte value and after using such file traffic is no longer decrypted.
When there is no full handshake included in capture Wireshark is unable to match and do not attempt to decrypt.
At least it is my wild guess.
Considering my test with merging full handshake trace with resumed session captured later on only additional piece of info (not contained in pre-master secret file) are random numbers exchange during full handshake between client and server.
Are those somehow crucial when decrypting resumed sessions? All resumed sessions are exchanging new random numbers - to be used for something - recalculating master secret?
During resume there is only:
So not a lot public info exchange that could be important for decrypting resumed session.