Robert Ransom rransom.8774@gmail.com writes:
On 2012-03-10, George Kadianakis desnacked@riseup.net wrote:
Nick Mathewson nickm@freehaven.net writes:
Filename: 195-TLS-normalization-for-024.txt Title: TLS certificate normalization for Tor 0.2.4.x Author: Jacob Appelbaum, Gladys Shufflebottom, Nick Mathewson, Tim Wilde Created: 6-Mar-2012 Status: Draft Target: 0.2.4.x
<snip>
- TLS handshake issues
2.1. Session ID.
Currently we do not send an SSL session ID, as we do not support session resumption. However, Apache (and likely other major SSL servers) do have this support, and do send a 32 byte SSLv3/TLSv1 session ID in their Server Hello cleartext. We should do the same to avoid an easy fingerprinting opportunity. It may be necessary to lie to OpenSSL to claim that we are tracking session IDs to cause it to generate them for us.
(We should not actually support session resumption.)
This is a nice idea, but it opens us to the obvious active attack of Them checking if a host *actually* supports session resumption or if it's faking it.
What is the reason we don't like session resumption? Does it still makes sense to keep it disabled even after #4436 is implemented?
Session resumption requires keeping some key material around after a TLS connection is closed, thereby possibly denting Tor's link-protocol forward secrecy if a bridge/relay is compromised soon after a connection ends.
IIRC stateless TLS session resumption does not quire keeping key material. The required key material are all stored on the client side.