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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Robert Ransom <rransom.8774@xxxxxxxxx> writes:

> 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.
>

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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev