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

[Robert Ransom]

On 2012-03-26, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Mon, Mar 26, 2012 at 3:17 AM, Robert Ransom <rransom.8774 at gmail.com>
> wrote:
>  [...]
>>>    (OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL
>>>    before 1.0.0e or so had some security issues with them.)
>>
>> Can Tor detect that it is running with a version of OpenSSL with those
>> security issues and refuse to support the broken ciphersuites?
>
> We can detect if the version number is for a broken version, but I
> don't know a good way to detect if the version number is old but the
> issues are fixed (for example, if it's one of those Fedora versions
> that lock the openssl version to something older so that they don't
> run into spurious ABI incompatibility).
>
> I need to find out more about what the security issues actually were:
> when I took a quick look, the only one I was a problem with doing
> multithreaded access to SSL data structures when using ECC.  That
> wouldn't be a problem for us, but if there are other issues, we should
> know about them.

The only security issue that I knew affected ECDHE in old versions of
OpenSSL was http://eprint.iacr.org/2011/633 .  The paper indicates
that that bug was never in any OpenSSL 1.0.0 release.


>>>   Otherwise, the ClientHello has these semantics: The inclusion of any
>>>   cipher supported by OpenSSL 1.0.0 means that the client supports it,
>>>   with the exception of
>>>       SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
>>>   which is never supported. Clients MUST advertise support for at least
>>> one
>>> of
>>>   TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
>>
>> I'm no longer comfortable with 128-bit symmetric keys.  An attacker
>> with many messages encrypted with a 128-bit symmetric cipher can
>> attempt a brute-force search on many messages at once, and is likely
>> to succeed in finding keys for some messages.  (See
>> http://cr.yp.to/papers.html#bruteforce .)
>
> Hm. We'd need to check whether all the servers today support an AES256
> ciphersuite.  Also, wasn't there some dodgy issue in the AES256 key
> schedule?  Or is that basically irrelevant?

I am not aware of any additional bugs in AES-256 that are as severe as
the small keyspace of AES-128.

I am not aware of any bugs (other than very serious side-channel leaks
in most implementations) in AES-256 when used with keys generated by
an acceptable key-derivation function or random number generator.


>>>   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 (!).
>>
>> Would that FIPS ciphersuite provide forward secrecy?  If not, then
>> there is no point in having clients or servers implement it.
>
> The idea would be that, so long as we advertise ciphers we can't
> support, an MITM adversary could make a Tor detector by forging
> ServerHello responses to choose the FIPS suite, and then seeing
> whether the client can finish the handshake to the point where they
> realize that the ServerHello was forged.
>
> This is probably not the best MITM Tor-detection attack, but it might
> be nice to stomp them as we find them.

Does OpenSSL validate the certificate chain at all before Tor allows
it to complete the TLS handshake?  If not, They can MITM a user's
connection by sending a ServerHello with an invalid certificate chain
(e.g. one in which a certificate is not signed correctly), and see
whether the client completes the TLS handshake like Tor or closes the
connection like a normal client.


>>>   [**] Actually, I think it's the Windows SChannel cipher list we
>>>   should be looking at here.
>>>   [***] 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.
>>
>> A relay whose link protocol implementations can't provide forward
>> secrecy to its clients cannot be used as an entry guard -- it would be
>> overloaded with CREATE cells very quickly.
>
> Why is that?  It shouldn't be facing more than 2x the number of create
> cells that a relay faces, and with the ntor handshake, create cell
> processing ought to get much faster.

Clients often produce rapid bursts of circuit creation.  If bursts of
CREATE cells from two or three clients hit an entry guard at the same
time, the guard could be overloaded.

I expect that this link-protocol change will be deployed before a new
circuit-extension protocol is deployed.  I expect that the ntor
handshake will not be deployed.


Robert Ransom