[tor-dev] Proposal 198: Restore semantics of TLS ClientHello

[Jacob Appelbaum]

On 03/20/2012 08:33 AM, Nick Mathewson wrote:
> Filename: 198-restore-clienthello-semantics.txt
> Title: Restore semantics of TLS ClientHello
> Author: Nick Mathewson
> Created: 19-Mar-2012
> Status: Open
> 

[ ... ]


>   Currently, OpenSSL 1.0.0 (in its default configuration) supports every
>   cipher that we would need in order to give the same list as Firefox
>   versions 8 through 11 give in their default configuration, with the
>   exception of the FIPS ciphersuite above.  Therefore, we will be able
>   to fake the new ciphersuite list correctly in all of our bundles that
>   include OpenSSL, and on every version of Unix that keeps up-to-date.
> 
>   However, versions of Tor compiled to use older versions of OpenSSL, or
>   versions of OpenSSL with some ciphersuites disabled, will no
>   longer give the same ciphersuite lists as other versions of Tor.  On
>   these platforms, Tor clients will no longer impersonate Firefox.
>   Users who need to do so will have to download one of our bundles, or
>   use a (non-system) OpenSSL.
> 

What platforms have this issue? It seems that our integration with
platforms is really heading in a bad direction. I'd like to figure out
how to not diverge entirely and if possible to fix or document the issues.

> 
> Open questions:
> 
>   Should the client drop connections if the server chooses a bad
>   cipher, or a suite without forward secrecy?
> 

I think so. Do we have any relays that do not currently support forward
secrecy?

>   Can we get OpenSSL to support the dubious FIPS suite excluded above,
>   in order to remove a distinguishing opportunity?  It is not so simple
>   as just editing the SSL_CIPHER list in s3_lib.c, since the nonstandard
>   SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher is (IIUC) defined to use the
>   TLS1 KDF, while declaring itself to be an SSL cipher (!).
> 

Huh.

>   Can we do anything to eventually allow the IE7+[**] cipher list as
>   well?  IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or
>   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current
>   Tor servers, which _only_ support those.  It looks like the only
>   forward-secure ciphersuites that IE7+ *does* support are ECDHE ones,
>   and DHE+DSS ones.  So if we want this flexibility, we could mandate
>   server-side ECDHE, or somehow get DHE+DSS support (which would play
>   havoc with our current certificate generation code IIUC), or say that
>   it is sometimes acceptable to have a non-forward-secure link
>   protocol[***].  None of these answers seems like a great one.  Is one
>   best?  Are there other options?
> 

This sounds like a job for pluggable transports!

I think as long as the servers support as many ciphers as possible, we
can make simple pluggable transports that setup the cipher suites we
want to use - no?

>   [**] Actually, I think it's the Windows SChannel cipher list we
>   should be looking at here.

I think we need to come up with a list of fingerprints for a bunch of
clients, a bunch of servers and then try to match them.

>   [***] If we did _that_, we'd want to specify that CREATE_FAST could
>   never be used on a non-forward-secure link.  Even so, I don't like the
>   implications of leaking cell types and circuit IDs to a future
>   compromise.

Indeed.

All the best,
Jake