Robert Ransom <rransom.8...@gmail.com> writes: > 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. >
IIRC stateless TLS session resumption does not quire keeping key material. The required key material are all stored on the client side. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
