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.