Tor v2 handshake does not work with openssl 1.0.1

changed milestone to %Tor: 0.2.2.x-final

added component::core tor/tor milestone::Tor: 0.2.2.x-final priority::very high reporter::murble resolution::fixed status::closed tor-bridge type::defect version::tor 0.2.3.15-alpha labels

Trac:
Username: murble

tor-log.txt

Tor Browse bundle log file

Trac:
Username: murble

Jun 02 13:58:11.051 [Info] TLS error while renegotiating handshake with [scrubbed]: wrong version number (in SSL routines:SSL3_GET_RECORD:SSL3_ST_CR_SRVR_HELLO_A)

That looks like the culprit.

Did 0.2.3.14-alpha work for you here as a bridge?

Does this problem also affect 0.2.2.35 clients connecting to regular relays? How about 0.2.2.36 connecting to this bridge?

no 0.2.3.14-alpha doesn't work either.

It seems to be a openssl 1.0.1 supporting newer TLS problem. The TBB I've tested with are linked with openssl 1.0.1c During the renegotiation the client claims to support v1.2 and dies with the above message when we try and speak TLSv1.2

As a quick work around I set SSL_OP_NO_TLSv1_2 and SSL_OP_NO_TLSv1_1 on the 0.2.3.15 bridge.

z.B

diff --git a/src/common/tortls.c b/src/common/tortls.c
index cffba2e..bf29ae2 100644
--- a/src/common/tortls.c
+++ b/src/common/tortls.c
@@ -1174,6 +1174,9 @@ tor_tls_context_new(crypto_pk_t *identity, unsigned int ke
   if (!(result->ctx = SSL_CTX_new(SSLv23_method())))
     goto error;
   SSL_CTX_set_options(result->ctx, SSL_OP_NO_SSLv2);
+  /* Disable TLSv1.x handshakes so we work with 0.2.2.x clients */
+  SSL_CTX_set_options(result->ctx, SSL_OP_NO_TLSv1_2);
+  SSL_CTX_set_options(result->ctx, SSL_OP_NO_TLSv1_1);
 
   if (
 #ifdef DISABLE_SSL3_HANDSHAKE

Trac:
Username: murble

0.2.2.36 (client)(Current TBB) -> 0.2.2.36 (bridge)(0.2.2.36-1~wheezy+1) on openssl (1.0.1c)

Also fails.

0.2.3.12-alpha (alpha TBB) -> 0.2.2.36 works.

Trac:
Username: murble

Hm. That should work; those two version should be able to renegotiate with each other just fine. I wonder why they don't like renegotiating with 1.0.1c and recent TLS versions? I wonder if it's possible that the weird renegotiation flags we set to work with older TLS versions are breaking this, or if there's a genuine openssl bug happening.

Trac:
Priority: normal to major
Milestone: N/A to Tor: 0.2.2.x-final

Further testing shows that when both sides are using a released version of openssl 1.0.1 (in other words, not openssl 1.0.1-beta1), the v2 handshake does not complete.

Please correct me if we get any data to contradict the above.

This issue is probably either:

A bug in OpenSSL 1.0.1, or
A problem with how Tor is using OpenSSL 1.0.1.

To confirm 1.0.1, we could write a trivial SSL client and SSL server using openssl 1.0.1, and show that they cannot renegotiate. I think this might be worth looking into, since Libevent's unit tests are seeing some issues with OpenSSL 1.0.1 and renegotiation as well, and Libevent doesn't do half of the crazy stuff that Tor tries.

Trac:
Summary: 0.2.2.35 can't connect to 0.2.3.15-alpha bridges to Tor v2 handshake does not work with openssl 1.0.1
Priority: major to critical

It appears that renegotiation in openssl 1.0.1 is broken when you use TLS 1.1 or TLS 1.2. To reproduce: Run openssl s_server. Run openssl s_client. Type "R" into the s_client, and hit enter.

To prevent this from messing up the Tor network, we should disable TLS 1.1 and TLS 1.2 when they are present, until some version of OpenSSL implements them correctly. To fix this, we should report it to appropriate OpenSSL devs.

Trac:
Username: marshray

tor-ticket-6033.pcap

Pcap of repro with openssl 1.0.1 s_client and s_server

Trac:
Username: marshray

I have reproed the problem and attached a packet capture.

Packets 4 and 6 show TLS 1.1 being negotiated successfully.

Packet 11 is an encrypted handshake message that is the client initiated renegotiation. However, note that the record layer version has jumped backwards from 1.1 to 1.0. It's expected that the initial Client Hello will have a record layer version of TLS 1.0 because the client doesn't know if the server supports anything higher. But once encryption has started, it's not OK for the client to change the record layer version because that would change the encryption format and the server wouldn't be able to decode it. I believe this behavior is against RFC 5246.

Trac:
Username: marshray

Likely workaround in branch "bug6033" in my public repository.

Trac:
Status: new to needs_review

bug6033 looks plausible. (Who are the people who don't have SSL_OP_NO_TLSv1_2 defined, and why should they not disable it too?)

They are people running OpenSSL 1.0.0 and earlier, and should not disable it, because they can't disable it, because it wasn't implemented in versions OpenSSL before 1.0.1.

I have confirmed that my workaround indeeds allows a tor-0.2.2 openssl-1.0.1 network to bootstrap again.

There may be much better workarounds available -- ones that don't require us to disable TLS 1.1 and TLS 1.2 -- and we ought to consider them, but we should not delay acting on this too much. We can move to a better workaround, in 0.2.2 or in 0.2.3, once we know what one looks like.

OpenSSL has been notified and a patch has been sent via http://rt.openssl.org/ and personal communication. I'll update this ticket once I get an OpenSSL ticket number.

It seems that neither client- nor server-initiated renegotiation worked with TLS 1.1 and 1.2.

Trac:
Username: marshray

One of the yuckier side effects here doesn't actually have to do with Tor clients, but with two Tor relays trying to reach each other. If both relays have upgraded their openssl, they won't be able to reach each other. So much for our clique topology assumption.

I was curious about the number of Tor relays with this bug, so i did a quick test using:

echo -en "R\nQ\n"| openssl s_client  -connect relay:port

Of the 2716 relays connect to, 470 failed with SSL3_GET_RECORD:wrong version number:s3_pkt.c:340

V2Failed: https://www.yuri.org.uk/~murble/tor/bug6033/negfail.csv Source List: https://www.yuri.org.uk/~murble/tor/bug6033/Tor_query_EXPORT.csv

Trac:
Username: murble

OpenSSL is referring to this as ticket [openssl.org #2828 (closed)]

They already have a patch, but perhaps they haven't cut a release for it yet. http://cvs.openssl.org/chngview?cn=22567

Trac:
Username: marshray

Merged into 0.2.2 and 0.2.3. I will leave this ticket open until we have a "make a better fix" ticket open.

Ticket #6055 (moved) is now the ticket to re-enable TLS 1.1 and TLS 1.2. Calling this one fixed.

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

Trac:
Keywords: N/A deleted, tor-bridge added

Trac:
Component: Tor Bridge to Tor

closed

mentioned in issue #6055 (moved)

mentioned in issue #11149 (moved)

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

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

Tor v2 handshake does not work with openssl 1.0.1

Child items ...

Activity