Proposal 169: Eliminate TLS renegotiation for the Tor connection handshake

[Nick Mathewson]

On Thu, Jan 28, 2010 at 10:21 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> Nick Mathewson wrote:

> [...]
>
>>              * If the CERT cell is a good cert signing the public
>>                key in the x.509 certificate we got during the TLS
>>                handshake, we connected to the server with that
>>                identity key.  Otherwise close the connection.
>
>
> I think this needs to be re-written to be clearer.
>

I've rewritten it to:

   * If the CERT cell contains a valid self-identity cert, and the identity
     key in the cert can be used to check the signature on the x.509
     certificate we got during the TLS handshake, then we know we
     connected to the server with that identity.  If any of these checks
     fail, or the identity key was not what we expected, then we close the
     connection.


>>              * Once the NETINFO cell arrives, continue as before.
>>
>
> [...]
>
>> 6. Open questions:
>>
>>   - Should we use X.509 certificates instead of the certificate-ish
>>     things we describe here?  They are more standard, but more ugly.
>
> Do we get anything out of custom-ish things? It seems kludgy to make
> stuff up on the fly but perhaps it's somehow simpler for our use?

We get the benefit of not importing the whole X.509 mess by reference.
 Right now we already require its use since we're using TLS, but we've
had the good fortune not to need to actually do anything with X.509
inside Tor per se once we've got a secure connection established.

>>
>>   - May we cache which certificates we've already verified?  It
>>     might leak in timing whether we've connected with a given server
>>     before, and how recently.
>
>  It seems like timing information would be leaked. We should avoid that
> if possible.

I wonder if it's ever safe to cache a cert verification result, even
for a little while.  If we can wind up doing less RSA, it would be
worthwhile.


>>
>>   - Is there a better secret than the master secret to use in the
>>     AUTHENTICATE cell?  Say, a portable one?  Can we get at it for
>>     other libraries besides OpenSSL?
>>
>
> I'm not sure. It seems OK. What worries you about it?

First off, if we leak the master_secret somehow, then an observer
might be able to decrypt the TLS stream.  Second, I've only confirmed
that we can grab it out of the guts of the OpenSSL SSL struct; I have
no idea whether people writing Tor clients in Java or Python would be
able to get it without hacking their own SSL libraries.

>>   - Can we give some way for clients to signal "I want to use the
>>     V3 protocol if possible, but I can't renegotiate, so don't give
>>     me the V2"?  Clients currently have a fair idea of server
>>     versions, so they could potentially do the V3+ handshake with
>>     servers that support it, and fall back to V1 otherwise.
>>
>
> Does this open us up to downgrade attacks? Downgrade attacks here seem
> like they might range in seriousness from simply potentially detecting
> Tor users or perhaps doing something actually nasty...

The regular downgrade prevention in TLS should make sure that the
handshake that each party thought they sent matches the handshake the
other one received, and close the connection if a MITM tries any
tomfoolery.

-- 
Nick