GFW probes based on Tor's SSL cipher list

Tim's tests show that GFW is probing v2/v3 bridges based on the Tor cipher list. Tor is using 28 static ciphers (src/common/ciphers.inc) for the SSL ClientHello of the v2/v3 link handshakes, and GFW seems to get agitated by them.

The question mark in the ticket title reflects the fact that this is not 100% verified, even though Tim dodged probing by simply removing two ciphersuites from ciphers.inc [0], when the same ClientHello, but with full ciphers.inc, was always getting probed (IIRC).

Tim said he is gonna look into this soon-ish, so that the question mark can be removed from the title.

In any case, this ticket is to find a good tactic to remove this static fingerprint from Tor's SSL handshake. My patch in [0] might do it, but it doesn't seem very future-proof.

We should probably see what Firefox does, and hope that it doesn't interfere with v2 signalling.

[0]:

diff --git a/src/common/ciphers.inc b/src/common/ciphers.inc
index c84620d..99ec494 100644
--- a/src/common/ciphers.inc
+++ b/src/common/ciphers.inc
@@ -111,16 +111,6 @@
 #else
    XCIPHER(0xc012, TLS1_TXT_ECDHE_RSA_WITH_DES_192_CBC3_SHA)
 #endif
-#ifdef SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
-    CIPHER(0x0016, SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA)
-#else
-   XCIPHER(0x0016, SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA)
-#endif
-#ifdef SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA
-    CIPHER(0x0013, SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA)
-#else
-   XCIPHER(0x0013, SSL3_TXT_EDH_DSS_DES_192_CBC3_SHA)
-#endif
 #ifdef TLS1_TXT_ECDH_RSA_WITH_DES_192_CBC3_SHA
     CIPHER(0xc00d, TLS1_TXT_ECDH_RSA_WITH_DES_192_CBC3_SHA)
 #else

changed milestone to %Tor: 0.2.3.x-final

added block censorship cn component::core tor/tor fingerprinting milestone::Tor: 0.2.3.x-final owner::nickm parent::4185 priority::high resolution::implemented severity::normal status::closed tls tor-bridge type::defect labels

ISTR that we took that list of ciphers from watching a version of firefox handshaking with a version of apache using mod_ssl. I wonder whether there's a better list to use now.

Firefox 8.0, in my environment, seems to send the following cipher suites in ClientHello:

TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
TLS_RSA_WITH_RC4_128_MD5 (0x0004)
TLS_RSA_WITH_RC4_128_SHA (0x0005)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

which seem to be the ciphers enabled by default in about:config (in the security.ssl3 area), plus the RI ciphersuite (0x00ff).

The current Firefox defaults can be found in: https://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/security-prefs.js (and https://hg.mozilla.org/mozilla-central/filelog/c5b90ea7e475/netwerk/base/public/security-prefs.js)

and some relevant code is: https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSComponent.cpp#1790 and https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#4008

The problem with copy-pasting Firefox's cipher list is that we might run into problems when Firefox changes its cipher list, like it happened with SSL DH modulus. Still, I'm not sure if randomization is a better solution either. It will complicate the implementation (since we will still need to always have a strong PFS ciphersuite in the "randomized" cipher list), and I'm not sure if it will help in the long run (China might whitelist cipher lists, or it might start detecting clients connecting to SSL services that always have a different cipher list.).

I would go with copy-pasting Firefox's cipher list and monitoring the security-prefs.js file for changes.

Thoughts?

I think that editing ciphers.inc to match this might be sensible.

Some questions:

• How did you you make this list?
• What exactly is your environment here? Does the same thing happen with the latest mainstream firefox? How about Chrome?
• Does openssl send the TLS_EMPTY_RENEGOTIATION_INFO_SCSV value? I worry adding it on our own could lead to trouble and incompatibility.

Trac:
Owner: N/A to nickm
Status: new to accepted
Milestone: N/A to Tor: 0.2.3.x-final
Priority: blocker to major

(Marking this for 0.2.3.x, but I think it's backportable if it turns out to be clean)

and hope that it doesn't interfere with v2 signalling

and fwiw, it is almost impossible to interfere with v2 signalling. The way to signal that a tor connection is v2/v3 is by including at least one ciphersuite not in the list TLS1_TXT_DHE_RSA_WITH_AES_128_SHA, TLS1_TXT_DHE_RSA_WITH_AES_256_SHA, SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA.

Replying to nickm:

I think that editing ciphers.inc to match this might be sensible.

Some questions:

• How did you you make this list?

I connected to a Tor relay's ORPort using Firefox 8.0 and HTTPS. I had 'Use SSL 3.0' and 'Use TLS 1.0' ticked, in my Preferences -> Advanced -> Encryption tab. Then I checked the ClientHello packet in Wireshark.

Afterwards, I double-checked my findings with the security-prefs.js file I mentioned in comment:2, and they seemed to match.

You should try it too to make sure I got it right.

• What exactly is your environment here? Does the same thing happen with the latest mainstream firefox? How about Chrome?

A Debian testing machine, using http://packages.debian.org/wheezy/iceweasel . I haven't tried with the 9.0 branch of Firefox. I should do this. I haven't tried with Chrome. I should do this.

• Does openssl send the TLS_EMPTY_RENEGOTIATION_INFO_SCSV value? I worry adding it on our own could lead to trouble and incompatibility.

I think modern OpenSSL automatically adds the TLS_EMPTY_RENEGOTIATION_INFO_SCSV in the first ClientHello of an SSL session. Take a look at ssl_lib.c:ssl_cipher_list_to_bytes().

I'm not sure what libnss does. I noticed that it sends the SCSV when both 'Use SSL 3.0' and 'Use TLS 1.0' are ticked, but it doesn't send the SCSV when only 'Use TLS 1.0' is ticked.

I think that explicitly adding the SCSV ourselves is a bad idea (especially, since I suspect that OpenSSL will happily add a second SCSV on its own), but we should look into it.

Trac:
Keywords: N/A deleted, tls fingerprinting added

Replying to nickm:

I think that editing ciphers.inc to match this might be sensible.

I agree. I look forward to seeing a commit to 0.2.3 that changes its ciphers to be more like what Firefox does these days.

I also agree that we should think about ways to future-proof the idea some more -- but there's no need to do that for 0.2.3, and ultimately "sometimes play the losing arms race that's time consuming and no fun to play, while preparing transports like obfsproxy" may turn out to be a fine strategy.

I can confirm that it is the cipher list, the chinese DPI boxes are looking for. I did some testing and was able to consistently trigger scanning by setting all fields in the TLS Client Hello to 0-bytes except the cipher list.

Also, since the goal of the cipher list change is to render Tor recognition in China useless, I would suggest to adapt the cipher list to something which is very common in China (and, if possible, in the rest of the world too). According to some quick Google search, IE is much more used than Chrome and Firefox in China.

Trac:
Summary: GFW probes based on Tor's SSL cipher list (?) to GFW probes based on Tor's SSL cipher list

Do we have a cipher list from recent IE? http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx purports to have one, but it doesn't look authoritative.

If that list is accurate, then unfortunately,it doesn't include the one we actually want, TLS_DHE_RSA_WITH_AES_128_SHA. (It doesn't have any DHE+RSA ciphers, as near as I can tell.) It'd be nice to support something properly fast, like TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256, but that'd require server upgrading.

Replying to nickm:

Do we have a cipher list from recent IE? http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx purports to have one, but it doesn't look authoritative.

If that list is accurate, then unfortunately,it doesn't include the one we actually want, TLS_DHE_RSA_WITH_AES_128_SHA. (It doesn't have any DHE+RSA ciphers, as near as I can tell.) It'd be nice to support something properly fast, like TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256, but that'd require server upgrading.

I just looked at the cipher list used by IE 9. Maybe somebody can reproduce the results. http://pastebin.com/Hr1YFppk Unfortunately, it also lacks DHE+RSA ciphers.

This, on the other hand, is the cipher list used by the current Google chrome (on Windows 7): http://pastebin.com/7i2MD5Bm It contains TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

According to statcounter, Chrome is still far behind in China but at least it seems to be catching up: http://gs.statcounter.com/#browser-CN-monthly-201101-201201

Trac:
Username: .phw

Copying and pasting here, so it doesn't get lost in the pastebin hole. .phw says the IE9 list is:

IE 9.0.4 TLS cipherlist on Windows 7 Prof. SP1
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

and this is the Chrome list:

Chrome 17.0.963.46 TLS cipherlist on Windows 7 Prof. SP1

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
                Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
                Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
                Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
                Cipher Suite: TLS_DHE_DSS_WITH_RC4_128_SHA (0x0066)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
                Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
                Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
                Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
                Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
                Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
                Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
                Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
                Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
                Cipher Suite: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

I have implemented the features that are suggested inside of this ticket.

Basically there are now two advertised cipher lists sets, cipher_chrome and cipher_firefox. The one that should be used can be configured from a define inside of tortls.c.

Here is the patch: https://gitweb.torproject.org/user/art/tor.git/tree/bug4744

Trac:
Status: accepted to needs_review

Looks like the only commit we'd want from this is 863442ff2edaed726590eb2a9e2aa58aa64f6247 ; the rest is all old tor2web junk.

Hellais, please reset your master to point at origin/master if you haven't done so already.

Other stuff:

• Were these files made, like the existing ciphers.inc, using the perl script and the firefox/chrome source? Or did you make them by hand? If the latter, have you checked them for accuracy via sniffing or something?
• Makefile.am will need to mention the new files, so they get distributed.
• The patch should probably remove ciphers.inc as unused.

Trac:
Status: needs_review to needs_revision

Replying to nickm:

Looks like the only commit we'd want from this is 863442ff2edaed726590eb2a9e2aa58aa64f6247 ; the rest is all old tor2web junk.

Hellais, please reset your master to point at origin/master if you haven't done so already.

Ok will do.

Other stuff:

• Were these files made, like the existing ciphers.inc, using the perl script and the firefox/chrome source? Or did you make them by hand? If the latter, have you checked them for accuracy via sniffing or something?

It was generated with a python script by sniffing the accepted cipher list of Google Chrome 17.0.963.56 and Firefox 8.

• Makefile.am will need to mention the new files, so they get distributed.

Ok.

• The patch should probably remove ciphers.inc as unused.

I was thinking that probably there isn't a lot of benefit of being able to compile your Tor with a different set of ciphers to use and maybe it could be best to simply replace ciphers.inc with the FF ciphers. The goal of this is to avoid Tor being distiguishable based on the ciphers it advertises, maybe we should just keep our cipher set up to date with what is the current mainstream browser.

This process of "updating" the cipher suite should be automatized and read it from the FF or Chrome source code.

What do you think?

Replying to hellais:

• The patch should probably remove ciphers.inc as unused.

I was thinking that probably there isn't a lot of benefit of being able to compile your Tor with a different set of ciphers to use and maybe it could be best to simply replace ciphers.inc with the FF ciphers.

That's fine by me.

The goal of this is to avoid Tor being distiguishable based on the ciphers it advertises, maybe we should just keep our cipher set up to date with what is the current mainstream browser.

This process of "updating" the cipher suite should be automatized and read it from the FF or Chrome source code.

Sounds good. We should document (in the code) the process and script we use to do that? Can you do that easily, or should I look into it?

Replying to nickm:

Sounds good. We should document (in the code) the process and script we use to do that? Can you do that easily, or should I look into it?

I have a script ready that does it for Firefox. You need to the source code of the current version of firefox, the OpenSSL libraries. You will find it attached.

Trac:
get_mozilla_ciphers.py

Get the default ciphers of Mozilla Firefox

--- tortls.c.orig	2011-12-15
+++ tortls.c	2012-03-13
@@ -907,6 +907,24 @@
   return 1;
 }
 
+static void
+tor_tls_client_hack_callback(const SSL *ssl, int type, int val)
+{
+  (void) val;
+  if (type == SSL_CB_HANDSHAKE_START &&
+      !ssl->new_session) {
+    SSL *_ssl = (SSL *)ssl;
+    _ssl->new_session = 3; /* XxXXxX Hack. Do not repeat if alone at home */
+    return;
+  }
+  if (type == SSL_CB_ACCEPT_LOOP && 
+      ssl->new_session == 3) {
+    SSL *_ssl = (SSL *)ssl;
+    _ssl->new_session = 0; /* XxXXxX Hack. Do not repeat if alone at home */
+    return;
+  }
+}
+
 /** Invoked when we're accepting a connection on <b>ssl</b>, and the connection
  * changes state. We use this:
  * <ul><li>To alter the state of the handshake partway through, so we
@@ -1092,6 +1110,12 @@
   }
 #endif
 
+#ifdef V2_HANDSHAKE_CLIENT
+  if (!isServer) {
+    SSL_set_info_callback(result->ssl, tor_tls_client_hack_callback);
+  }
+#endif
+
   /* Not expected to get called. */
   tls_log_errors(NULL, LOG_WARN, LD_NET, "creating tor_tls_t object");
   return result;
@@ -1324,6 +1348,7 @@
 #endif
     } else {
 #ifdef V2_HANDSHAKE_CLIENT
+      SSL_set_info_callback(tls->ssl, NULL);
       /* If we got no ID cert, we're a v2 handshake. */
       X509 *cert = SSL_get_peer_certificate(tls->ssl);
       STACK_OF(X509) *chain = SSL_get_peer_cert_chain(tls->ssl);

<wanoskarnet> We could create new SSL_METHOD if used SSLv3 or TLSv1 then use
self made ssl_put_cipher_by_char(). With SSLv23 it has no sense because there
are ssl3_put_cipher_by_char() used without chance to change.
> wanoskarnet: fun hack. what does it do?
<wanoskarnet> it prevents auto append of 0x00ff to the cipher list of client
hello.
> ah ha. because of the ciphers. is that what kz is doing to block tor? last i
checked it was only china. but i've been busy with performance research
stuff.
<wanoskarnet> And censir can't ban it easly as it now.
<wanoskarnet> I did test yestarday from kz net.
> with cipher change it works, without cipher change it fails?
> and i guess 0x00ff fix is not needed quite yet, but you expect it will be
the next thing needed?
<wanoskarnet> They detect tor client by unique cipher list. after chnge tor
cleint can't be detect current rules.
<wanoskarnet> yes no need. but it's very nice target
<wanoskarnet> even if you chane cipers list. it's still unique. no one modern
browser append it to end.
> why does openssl append it? because openssl has never thought somebody might
use it to lie about cipher suites?
<wanoskarnet> yes

Wanoskarnet recommends this version instead.

--- tortls.c.orig	2011-12-15
+++ tortls.c	2012-03-13
@@ -907,6 +907,24 @@
   return 1;
 }
 
+static void
+tor_tls_client_hack_callback(const SSL *ssl, int type, int val)
+{
+  (void) val;
+  if (type == SSL_CB_HANDSHAKE_START &&
+      !ssl->new_session) {
+    SSL *_ssl = (SSL *)ssl;
+    _ssl->new_session = 3; /* XxXXxX Hack. Do not repeat if alone at home */
+    return;
+  }
+  if (type == SSL_CB_CONNECT_LOOP && 
+      ssl->new_session == 3) {
+    SSL *_ssl = (SSL *)ssl;
+    _ssl->new_session = 0; /* XxXXxX Hack. Do not repeat if alone at home */
+    return;
+  }
+}
+
 /** Invoked when we're accepting a connection on <b>ssl</b>, and the connection
  * changes state. We use this:
  * <ul><li>To alter the state of the handshake partway through, so we
@@ -1092,6 +1110,12 @@
   }
 #endif
 
+#ifdef V2_HANDSHAKE_CLIENT
+  if (!isServer) {
+    SSL_set_info_callback(result->ssl, tor_tls_client_hack_callback);
+  }
+#endif
+
   /* Not expected to get called. */
   tls_log_errors(NULL, LOG_WARN, LD_NET, "creating tor_tls_t object");
   return result;
@@ -1324,6 +1348,7 @@
 #endif
     } else {
 #ifdef V2_HANDSHAKE_CLIENT
+      SSL_set_info_callback(tls->ssl, NULL);
       /* If we got no ID cert, we're a v2 handshake. */
       X509 *cert = SSL_get_peer_certificate(tls->ssl);
       STACK_OF(X509) *chain = SSL_get_peer_cert_chain(tls->ssl);

I've split the "how to remove the SSL3_CK_SCSV indicator" discussion into a new ticket: #5390 (moved).

Doing the changes here should be a good start, and they're orthogonal from the patches above.

Hang on. Before we make this change I want to figure out what it means for eventually letting servers choose better ciphers. Since clients can (and do) advertise ciphers that they don't really support, we need to figure out whether servers can ever support a better ciphersuite than the ones they currently provide.

Interestingly, with OpenSSL 1.0 with no options turned off, I believe the only cipher that we need to "fake" on the list is 0xfeff, "SSL3_TXT_RSA_FIPS_WITH_3DES_EDE_CBC_SHA", which appears pretty low on the list.

What if we do the following:

• Say, "If the client ciphersuite list is exactly (current contents of ciphers.inc), then the server can only use the following N ciphers. Otherwise, the server may assume that any cipher advertised by the client, except 0xfeff, is present."
• Stop pretending to have ciphersuites that we don't, with the exception of 0xfeff. This means that OpenSSL 0.9.x users and users of OpenSSL on distributions that have disabled ECC or other ciphers will stand out some.
• Strongly recommend use of OpenSSL 1.0.x or later, with nothing turned off.
• Switch servers to select something good in 0.2.4, like ECDHE_RSA_WITH_AES_256_CBC_SHA or something.

Thoughts? Otherwise, I don't know how we can tell whether we can ever allow ECDHE ciphersuites.

Replying to nickm:

Interestingly, with OpenSSL 1.0 with no options turned off, I believe the only cipher that we need to "fake" on the list is 0xfeff, "SSL3_TXT_RSA_FIPS_WITH_3DES_EDE_CBC_SHA", which appears pretty low on the list.

What if we do the following:

• Say, "If the client ciphersuite list is exactly (current contents of ciphers.inc), then the server can only use the following N ciphers. Otherwise, the server may assume that any cipher advertised by the client, except 0xfeff, is present."
• Stop pretending to have ciphersuites that we don't, with the exception of 0xfeff. This means that OpenSSL 0.9.x users and users of OpenSSL on distributions that have disabled ECC or other ciphers will stand out some.
• Strongly recommend use of OpenSSL 1.0.x or later, with nothing turned off.
• Switch servers to select something good in 0.2.4, like ECDHE_RSA_WITH_AES_256_CBC_SHA or something.

Thoughts? Otherwise, I don't know how we can tell whether we can ever allow ECDHE ciphersuites.

Sounds like a sane plan.

We should make sure that the alpha version of Tor Browser Bundle produces the cipher list we want, since most .cn users should be using TBB. AFAIK Tor Browser Bundle uses OpenSSL 1.0.0g (https://www.torproject.org/projects/torbrowser-details.html.en#contents), and it shouldn't have features turned off.

The small amount of OpenSSL 0.9.x users in .cn, should still be able to circumvent the GFW, since their cipher list won't be identical to the current one.

Talked about the above on irc for a while with arma and asn. Consensus was that I will write a proposal summarizing and explaining why, some time on Friday. Then we'll aim to implement it and merge this by next week. I'm sad not to be doing it right now, but glad we thought about the above issues before we went and implemented something regrettable.

The proposal was 198. I implemented the client side of it, and the final bits of the ciphersuite switcheroo, in branch "bug4744" in my public repo.

Trac:
Status: needs_revision to needs_review

< tjr:#tor-dev> nickm: I reviewed 4744 and proposal 198 like you suggested.  I didn't find anything terribly wrong with
                them.... but
< tjr:#tor-dev> nickm: I haven't held all of this commit and its supporting code
                https://gitweb.torproject.org/nickm/tor.git/commitdiff/d7e455018f6f2ea402c17412fbf4f1185857939f in my head, so
                I'm kind of just presuming it works: i and j don't get out of sync in the loop; the ">> 24) & 0xff) != 3" stuff
                is referencing some code I don't know about,...
< tjr:#tor-dev> nickm: I do wonder what would happen if OpenSSL added ciphers to 1.0.0... Would line 112:
                https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt#l112 get
                the spec out of sync with the code, would that mess up the loop and keeping i/j in sync...?
< tjr:#tor-dev> nickm: Also, complete nitpicking, but since you log "Skipping v2 ciphers" at notice, maybe you'd also want to
                log the unsupported ciphers at notice too? /shrug

On the server side, if the client's ciphersuites indicate 198-awareness, maybe passing EDH+AES:EDH+3DES:!LOW:!MEDIUM:!NULL:!EDH-RSA-DES-CBC3-SHA to SSL_set_cipher_list() will do the filtering specified by proposal 198?

  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.

I've tried to make the code more straightforward; still in branch bug4744. I have also rebased and squashed it as "bug4744_rebased."

s/let let i/let i/

s/To correct this use/To correct this, use/

nickm/bug4744 looks cursorily fine other than these.

I also just reread proposal 198 and the discussion on tor-dev, and it looks like a plausible way forward. I look forward to having it work fine for a few years, and then we'll learn what we should have thought of. :)

I created a new component called "Censorship analysis" for the stuff we're doing wrt Ethiopia and Kazakhstan. Should I change the component of this ticket as well?

Replying to runa:

I created a new component called "Censorship analysis" for the stuff we're doing wrt Ethiopia and Kazakhstan. Should I change the component of this ticket as well?

I'd rather you didn't. Let's reserve "censorship analysis" for "figure out how the censorship is working", and have tickets (like this one) that are about changing tor remain in one of the tor components.

arma: made those changes in bug4744; made a new bug4744_squashed; merging bug4744_squashed into master. I'm going to make new tickets for merging the prop198 changes into tor-spec and for doing the server side of prop 198.

Trac:
Status: needs_review to closed
Resolution: N/A to implemented

These are #6143 (moved) and #6144 (moved)

Trac:
Keywords: tls fingerprinting deleted, tls fingerprinting tor-bridge added

Trac:
Component: Tor Bridge to Tor

Trac:
Reviewer: N/A to N/A
Keywords: tls fingerprinting tor-bridge deleted, tls fingerprinting tor-bridge censorship block cn added
Sponsor: N/A to N/A
Severity: N/A to Normal

closed

mentioned in issue #5390 (moved)

mentioned in issue #6045 (moved)

mentioned in issue #6144 (moved)

mentioned in issue #6246 (moved)

moved to tpo/core/tor#4744 (closed)

mentioned in issue tpo/core/tor#6144 (closed)

mentioned in issue tpo/anti-censorship/censorship-analysis#6045 (closed)