Re: [tor-dev] Proposal 195: TLS certificate normalization for Tor 0.2.4.x

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2012-03-10, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> Nick Mathewson <nickm@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev