Re: Revised TSL handshake proposal question

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Nov 21, 2007 at 07:30:22AM +0100, Lucky Green wrote:
> SSLv3 and TLS permit either the client or the server to request an SSL 
> renegotiation. The content of the renegotiation and any certificates 
> exchanged during the renegotiation are encrypted using the SSL connection 
> that was previously established.

Very interesting.

> This means that an SSL renegotiation permits the client to present an SSL 
> client cert to the server inside the initial SSL encrypted connection. Not 
> revealing the client cert to an observer was very much one of the use 
> cases considered during the initial SSLv3 and later TLS specification 
> efforts. The idea at the time was that clients may store a great many 
> certificates, one for each services they wish to access. For example, a 
> website portal containing health education information may offer a number 
> of forums, one for those suffering from cancer, another for those 
> suffering from AIDS. Each using a client cert rather than UID/PW to access 
> the forum. You wouldn't want the observer to be able to determine which 
> particular forum a visitor is logging into or that they are logging into a 
> forum at all.

Does the SSL connection prevent an observer from learning the fact that a
renegotiation is taking place? (that is, an observer who does filtering
on payloads -- an observer who does timing attacks is probably in fine
shape against Tor, as you note)

I would hope that it does, but your summary above doesn't include that.

> While client certificates have not yet become as ubiquitous as was 
> considered possible during the SSLv3 specification days with individual 
> users potentially holding hundreds of certificates, the ability to request 
> a renegotiation of an SSL session to step up from a server authenticated 
> to a client authenticated connection is built into every major SSL/TLS 
> implementation, including OpenSSL.

That's very useful -- we've been wondering how much compatibility we
would break in other crypto libs by proposal 124.

Of course, we still need to fake some Firefox ciphers in the initial
handshake, and that appears to be not supported well by OpenSSL, and is
probably not supported well by other crypto libs too. So be it.

> With this in mind, it is not clear to me which security properties the 
> proposal will give you that you cannot natively obtain from TLS.

Right. Steven pointed out that we waste bandwidth by sending a duplicate
server-side cert during the renegotiation. But I think that's a small
price to pay for the simplified design.

> I of course recognize that an observer may be able to determine from 
> watching the number of encrypted bits exchanged that the encrypted SSL 
> connection likely contains an SSL renegotiation payload. Alas, there are 
> many aspects of Tor that would permit for protocol identification based on 
> traffic analysis.
> 
> You may wish to consider using TLS-native capabilities to obscure the 
> client certificate exchange by using SSL renegotiation instead.

Agreed. Thanks for helping us catch this before we'd gone too far.

--Roger