Forum Discussion

Kevin_K_51432's avatar
Kevin_K_51432
Historic F5 Account

Hi Piotr,

 

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)

 

 

https://tools.ietf.org/html/rfc5246section-8.1

 

 

Would be interesting to hear some additional thoughts.

 

Kevin

 

dragonflymr's avatar
dragonflymr
Icon for Cirrostratus rankCirrostratus
May 19, 2017

Hi,

 

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?

 

Piotr