On 2012-03-10, George Kadianakis <desnac...@riseup.net> wrote: > Nick Mathewson <ni...@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> >> >> 2. 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. OpenSSL provides an implementation of session resumption, with the code quality you should expect to find in a rarely-used piece of OpenSSL. There have been several OpenSSL security-fix releases due to code-exec bugs in the session-resumption code. Robert Ransom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
