[tor-dev] Proposal 195: TLS certificate normalization for Tor 0.2.4.x
rransom.8774 at gmail.com
Sat Mar 10 01:06:25 UTC 2012
On 2012-03-10, George Kadianakis <desnacked at riseup.net> wrote:
> Nick Mathewson <nickm at 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
>> 2. TLS handshake issues
>> 2.1. Session ID.
>> Currently we do not send an SSL session ID, as we do not support
>> resumption. However, Apache (and likely other major SSL servers) do
>> this support, and do send a 32 byte SSLv3/TLSv1 session ID in their
>> 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
>> 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
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.
More information about the tor-dev