[tor-dev] Proposal 195: TLS certificate normalization for Tor 0.2.4.x
desnacked at riseup.net
Sat Mar 10 01:18:30 UTC 2012
Robert Ransom <rransom.8774 at gmail.com> writes:
> 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
> connection ends.
IIRC stateless TLS session resumption does not quire keeping key
material. The required key material are all stored on the client side.
More information about the tor-dev