Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
May 19, 2017

Resumed SSL session and decryption

Hi,

 

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?

 

Scenario:

 

  • tcpdump used to capture first session with full SSL Handshake
  • ssldump used to extract pre-maset secret to the file
  • Wireshark is capturing traffic including first session - everything is encrypted
  • pre-master secret file configured in Wireshark - traffic decrypted, including following resumed sessions (same is true when private key is configured in Wireshark)
  • New capture in Wireshark performed
  • Client and server are still resuming SSL session (same SessionID reported in ClientHello) - no traffic decrypted.

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)

 

Piotr

 

decryption
devops
LTM
pre-master secret
resumed ssl
security
ssl handshake
wireshark
  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    May 20, 2017

    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.

     

    Piotr

     

  • Kevin_K_51432's avatar
    Kevin_K_51432
    Historic F5 Account
    May 19, 2017

    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 20, 2017

      Well, so in short, it's only possible to decrypt resumed session when:

       

      • There is full handshake session in the trace along with resumed sessions
      • There is either private key or pre-master from full handshake configured in Wireshark

      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?

       

      Piotr

       

    • Kevin_K_51432's avatar
      Kevin_K_51432
      Historic F5 Account
      May 19, 2017

      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 session's master_secret.

       

      https://tools.ietf.org/html/rfc5246appendix-F.1.4

       

      But the question remains (for me); does Wireshark need the randoms from the initial, full handshake?

       

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

      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?

       

      Piotr