Using tools like Wireshark, it's possible to decrypt SSL traffic as the client by logging the (pre)master secret, without using a mitm attack or the server's private key. But I found that for some websites, the ssl session id is being stored by the server (evidence: the ServerHello message contains the re-used session id), and (I believe) this prevents a full ssl handshake from occurring, which prevents wireshark from successfully decrypting. Admittedly I am not totally sure that this is the problem, but the evidence is quite convincing. Is there any way for the client to prevent re-use of ssl session ids?


In SSL, the client and server may engage in an abbreviated handshake only if both client and server remember the "handshake parameters" (in particular the negotiated pre-master secret). The "session ID" is how the client and server advertise their remembrance: the client sends in its ClientHello a copy of the previous session ID, and the server sends it back to acknowledge that this session is going to be reused.

You cannot remove the session ID from the client message without breaking the subsequent cryptographic operations, because the Finished messages at the end of the handshake are computed as hash values over all previously exchanged handshake messages, which includes the ClientHello. Thus, the client and the server MUST "see" the same ClientHello. (However, see below.)

Therefore, to prevent an abbreviated handshake, you have to enforce forgetfulness. SSL servers can be configured not to remember sessions beyond some inactivity timeout; for instance, see Apache mod_ssl directives SSLSessionCache and SSLSessionCacheTimeout. Shutting down and restarting the server may also flush the cache, as long as the cache is kept in RAM (with multi-frontend servers, the cache may be shared with a common database or something similar, in which case cache purging can be more complex).

On the client side, SSL sessions are normally kept in RAM. Internet Explorer, for instance, internally consists of several process that talk to each other, and you have to kill them all to make it forget a SSL session (in practice, this happens only when you have closed all the IE windows).

Your quote, however, is weird:

Using tools like Wireshark, it's possible to decrypt SSL traffic as the client by logging the (pre)master secret, without using a mitm attack or the server's private key.

Wireshark cannot do that. Wireshark inspects data packets in transit, and from these packets, you cannot infer the pre-master secret without having a copy of the server's private key. That's the whole point of SSL: to prevent eavesdroppers from being able to make sense of the exchanged data. To be able to break into the SSL session from a "network interceptor" point of view, you have to do a Man-in-the-Middle attack, with double impersonation; and this may happen only if you bypass the certificate security model: you have to convince the human user (SSL client) to install a fake rogue root CA key, or to "click through" the red and scary warning that the browser displays when it notices that the alleged server certificate is funky.

If you can "log the pre-master secret" then this means that you have privilege access to the RAM contents of either the client or the server; that access would not use Wireshark, but a debugger. What Wireshark offers is the possibility to use some captured pre-master secret (e.g. see this page); with this information, Wireshark will be able to decrypt the data. However, it does not (and cannot) do the capture itself: this requires direct access to the client or server RAM, or a modified client or server to leak the information. To make an analogy, you cannot do brain surgery over the phone.

If you indeed have a debugger-like access to the client (or the server), then you should be able to manipulate the client (respectively server) to make it "forget" a previous SSL session, thus forcing a new full handshake.

  • About my "weird" comment - I was sloppy with my description, I of course didn't mean to imply that Wireshark can do it on its own, I mean with the aid of NSS ssl key logging (in Firefox - also Chrome, I believe). I appreciate your detailed description, though of some of the issues surrounding this. I have moved on from the question given here specifically but am still very interested in finding a way to clear the ssl cache, especially from within the browser, so as to force a new session. I'm not sure if the 'ClearSSLCache' ff addon is quite what I want. – AdamZSI Oct 2 '13 at 13:26

If you are using a browser like IE for instance you can clear the cache and the SSL cache which will force it to go through the entire process once again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.