Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open
Overview:
Currently, all supported Tor versions try to imitate an older version of Firefox when advertising ciphers in their TLS ClientHello. This feature is intended to make it harder for a censor to distinguish a Tor client from other TLS traffic. Unfortunately, it makes the contents of the ClientHello unreliable: a server cannot conclude that a cipher is really supported by a Tor client simply because it is advertised in the ClientHello.
This proposal suggests an approach for restoring sanity to our use of ClientHello, so that we still avoid ciphersuite-based fingerprinting, but allow nodes to negotiate better ciphersuites than they are allowed to negotiate today.
Background reading:
Section 2 of tor-spec.txt 2 describes our current baroque link negotiation scheme. Proposals 176 and 184 describe more information about how it got that way.
Bug 4744 is a big part of the motivation for this proposal: we want to allow Tors to advertise even more ciphers, some of which we would actually prefer to the ones we are using now.
What you need to know about the TLS handshake is that the client sends a list of all the ciphersuites that it supports in its ClientHello message, and then the server chooses one and tells the client which one it picked.
Motivation and constraints:
We'd like to use some of the ECDHE TLS ciphersuites, since they allow us to get better forward-secrecy at lower cost than our current DH-1024 usage. But right now, we can't ever use them, since Tor will advertise them whether or not it has a version of OpenSSL that supports them.
(OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL before 1.0.0e or so had some security issues with them.)
We cannot have the rule be "Tors must only advertise ciphersuites that they can use", since current Tors will advertise such ciphersuites anyway.
We cannot have the rule be "Tors must support every ECDHE ciphersuite on the following list", since current Tors don't do all that, and since one prominent Linux distribution builds OpenSSL without ECC support because of patent/freedom fears.
Fortunately, nearly every ciphersuite that we would like to advertise to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0 and later. This enables the following proposal to work:
Proposed spec changes:
I propose that the rules for handling ciphersuites at the server side become the following:
If the ciphersuites in the ClientHello contains no ciphers other than the following[*], they indicate that the Tor v1 link protocol is in use.
TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
If the advertised ciphersuites in the ClientHello are _exactly_[*] the following, they indicate that the Tor v2+ link protocol is in use, AND that the ClientHello may have unsupported ciphers. In this case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA or DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher.
TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1_DHE_RSA_WITH_AES_256_SHA TLS1_DHE_DSS_WITH_AES_256_SHA TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS1_RSA_WITH_AES_256_SHA TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS1_ECDHE_RSA_WITH_RC4_128_SHA TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS1_DHE_RSA_WITH_AES_128_SHA TLS1_DHE_DSS_WITH_AES_128_SHA TLS1_ECDH_RSA_WITH_RC4_128_SHA TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA TLS1_ECDH_ECDSA_WITH_RC4_128_SHA TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA SSL3_RSA_RC4_128_MD5 SSL3_RSA_RC4_128_SHA TLS1_RSA_WITH_AES_128_SHA TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA SSL3_EDH_RSA_DES_192_CBC3_SHA SSL3_EDH_DSS_DES_192_CBC3_SHA TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA SSL3_RSA_DES_192_CBC3_SHA
[*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is not counted when checking the list of ciphersuites.
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.
The server MUST choose a ciphersuite with ephemeral keys for forward secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT choose any cipher other than AES or 3DES.
Discussion and consequences:
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.
The proposed spec change above tries to future-proof ourselves by not declaring that we support every declared cipher, in case we someday need to handle a new Firefox version. If a new Firefox version comes out that uses ciphers not supported by OpenSSL 1.0.0, we will need to define whether clients may advertise its ciphers without supporting them; but existing servers will continue working whether we decide yes or no.
The restriction to "servers SHOULD only pick AES or 3DES" is meant to reflect our current behavior, not to represent a permanent refusal to support other ciphers. We can revisit it later as appropriate, if for some bizarre reason Camellia or Seed or Aria becomes a better bet than AES.
Open questions:
Should the client drop connections if the server chooses a bad cipher, or a suite without 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 (!).
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?
[**] 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.
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
On 20 March 2012 11:33, Nick Mathewson nickm@freehaven.net wrote:
Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open
I've not worked with TLS renegotiations before, but could Tor perform a renegotiation after the initial handshake, and the renegotiation ciphersuites are taken at face value? Less performant, but also less complicated?
-tom
On Tue, Mar 20, 2012 at 10:48 PM, Tom Ritter tom@ritter.vg wrote:
On 20 March 2012 11:33, Nick Mathewson nickm@freehaven.net wrote:
Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open
I've not worked with TLS renegotiations before, but could Tor perform a renegotiation after the initial handshake, and the renegotiation ciphersuites are taken at face value? Less performant, but also less complicated?
We used to do that; see proposal 176 and surrounding discussion for an explanation of why we stopped.
Briefly: TLS renegotiation is detectable as renegotiation on the wire by anybody who cares to watch. Renegotiating immediately after connection makes us stand out more than we'd like to.
On 2012-03-21, Tom Ritter tom@ritter.vg wrote:
On 20 March 2012 11:33, Nick Mathewson nickm@freehaven.net wrote:
Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open
I've not worked with TLS renegotiations before, but could Tor perform a renegotiation after the initial handshake, and the renegotiation ciphersuites are taken at face value? Less performant, but also less complicated?
Tor just got rid of TLS renegotiation with the v3 link protocol.
Robert Ransom
On 2012-03-20, Nick Mathewson nickm@freehaven.net wrote:
Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open
Overview:
Currently, all supported Tor versions try to imitate an older version of Firefox when advertising ciphers in their TLS ClientHello. This feature is intended to make it harder for a censor to distinguish a Tor client from other TLS traffic. Unfortunately, it makes the contents of the ClientHello unreliable: a server cannot conclude that a cipher is really supported by a Tor client simply because it is advertised in the ClientHello.
This proposal suggests an approach for restoring sanity to our use of ClientHello, so that we still avoid ciphersuite-based fingerprinting, but allow nodes to negotiate better ciphersuites than they are allowed to negotiate today.
Background reading:
Section 2 of tor-spec.txt 2 describes our current baroque link negotiation scheme. Proposals 176 and 184 describe more information about how it got that way.
Bug 4744 is a big part of the motivation for this proposal: we want to allow Tors to advertise even more ciphers, some of which we would actually prefer to the ones we are using now.
What you need to know about the TLS handshake is that the client sends a list of all the ciphersuites that it supports in its ClientHello message, and then the server chooses one and tells the client which one it picked.
Motivation and constraints:
We'd like to use some of the ECDHE TLS ciphersuites, since they allow us to get better forward-secrecy at lower cost than our current DH-1024 usage. But right now, we can't ever use them, since Tor will advertise them whether or not it has a version of OpenSSL that supports them.
(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 cannot have the rule be "Tors must only advertise ciphersuites that they can use", since current Tors will advertise such ciphersuites anyway.
We cannot have the rule be "Tors must support every ECDHE ciphersuite on the following list", since current Tors don't do all that, and since one prominent Linux distribution builds OpenSSL without ECC support because of patent/freedom fears.
Fortunately, nearly every ciphersuite that we would like to advertise to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0 and later. This enables the following proposal to work:
Proposed spec changes:
I propose that the rules for handling ciphersuites at the server side become the following:
If the ciphersuites in the ClientHello contains no ciphers other than the following[*], they indicate that the Tor v1 link protocol is in use.
TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHAIf the advertised ciphersuites in the ClientHello are _exactly_[*] the following, they indicate that the Tor v2+ link protocol is in use, AND that the ClientHello may have unsupported ciphers. In this case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA or DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher.
TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1_DHE_RSA_WITH_AES_256_SHA TLS1_DHE_DSS_WITH_AES_256_SHA TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS1_RSA_WITH_AES_256_SHA TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS1_ECDHE_RSA_WITH_RC4_128_SHA TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS1_DHE_RSA_WITH_AES_128_SHA TLS1_DHE_DSS_WITH_AES_128_SHA TLS1_ECDH_RSA_WITH_RC4_128_SHA TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA TLS1_ECDH_ECDSA_WITH_RC4_128_SHA TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA SSL3_RSA_RC4_128_MD5 SSL3_RSA_RC4_128_SHA TLS1_RSA_WITH_AES_128_SHA TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA SSL3_EDH_RSA_DES_192_CBC3_SHA SSL3_EDH_DSS_DES_192_CBC3_SHA TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA SSL3_RSA_DES_192_CBC3_SHA[*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is not counted when checking the list of ciphersuites.
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 .)
The server MUST choose a ciphersuite with ephemeral keys for forward secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT choose any cipher other than AES or 3DES.
Discussion and consequences:
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.
s/(non-system)/non-system/
The proposed spec change above tries to future-proof ourselves by not declaring that we support every declared cipher, in case we someday need to handle a new Firefox version. If a new Firefox version comes out that uses ciphers not supported by OpenSSL 1.0.0, we will need to define whether clients may advertise its ciphers without supporting them; but existing servers will continue working whether we decide yes or no.
Why standardize on OpenSSL 1.0.0, rather than OpenSSL 1.0.1?
The restriction to "servers SHOULD only pick AES or 3DES" is meant to reflect our current behavior, not to represent a permanent refusal to support other ciphers. We can revisit it later as appropriate, if for some bizarre reason Camellia or Seed or Aria becomes a better bet than AES.
Open questions:
Should the client drop connections if the server chooses a bad cipher, or a suite without 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 (!).
Would that FIPS ciphersuite provide forward secrecy? If not, then there is no point in having clients or servers implement it.
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?
The certificate-chain validation code and the v3 handshake protocol would be a bigger issue with DSS or ECDSA ciphersuites.
[**] 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.
Robert Ransom
On Mon, Mar 26, 2012 at 3:17 AM, Robert Ransom rransom.8774@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.
[...]
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?
[...]
The proposed spec change above tries to future-proof ourselves by not declaring that we support every declared cipher, in case we someday need to handle a new Firefox version. If a new Firefox version comes out that uses ciphers not supported by OpenSSL 1.0.0, we will need to define whether clients may advertise its ciphers without supporting them; but existing servers will continue working whether we decide yes or no.
Why standardize on OpenSSL 1.0.0, rather than OpenSSL 1.0.1?
1.0.0 is good enough to get everything we need for ff8+. Also, when I wrote the document, 1.0.0 was pretty ubiquitous but 1.0.1 had only been out for a few days. We could do 1.0.1, I guess.
[...]
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.
[...]
[**] 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.
On 2012-03-26, Nick Mathewson nickm@alum.mit.edu wrote:
On Mon, Mar 26, 2012 at 3:17 AM, Robert Ransom rransom.8774@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
-
Jacob Appelbaum -
Nick Mathewson -
Nick Mathewson -
Robert Ransom -
Tom Ritter