Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#6033 closed defect (fixed)

Tor v2 handshake does not work with openssl 1.0.1

Reported by: murble Owned by:
Priority: Very High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version: Tor:
Severity: Keywords: tor-bridge
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Bridge configuration:

PublishServerDescriptor 0
BridgeRelay 1
ORPort 8443
ContactInfo IRC://murble@oftc
ExitPolicy reject *:*

on Linux 3.2.0-0.bpo.2-amd64 with wheezy userland
and tor
openssl 1.0.1c-1
libevent-2.0-5 2.0.19-stable-2

I'm using the standard tor browser bundle I've
tested with both Win32 and Linux binaries. based tor browser bundles can connect
as can tor

Child Tickets

Attachments (2)

tor-log.txt (18.9 KB) - added by murble 8 years ago.
Tor Browse bundle log file
tor-ticket-6033.pcap (2.8 KB) - added by marshray 8 years ago.
Pcap of repro with openssl 1.0.1 s_client and s_server

Download all attachments as: .zip

Change History (22)

Changed 8 years ago by murble

Attachment: tor-log.txt added

Tor Browse bundle log file

comment:1 Changed 8 years ago by nickm_mobile

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 work for you here as a bridge?

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

comment:2 Changed 8 years ago by murble

no 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 bridge.


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 (

comment:3 Changed 8 years ago by murble (client)(Current TBB) -> (bridge)( on openssl (1.0.1c)

Also fails. (alpha TBB) -> works.

comment:4 Changed 8 years ago by nickm

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.

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.2.x-final
Priority: normalmajor

comment:6 Changed 8 years ago by nickm

Priority: majorcritical
Summary: can't connect to bridgesTor v2 handshake does not work with openssl 1.0.1

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.

comment:7 Changed 8 years ago by nickm

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.

Changed 8 years ago by marshray

Attachment: tor-ticket-6033.pcap added

Pcap of repro with openssl 1.0.1 s_client and s_server

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by nickm

Status: newneeds_review

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

comment:10 Changed 8 years ago by arma

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?)

comment:11 Changed 8 years ago by nickm

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.

comment:12 Changed 8 years ago by nickm

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.

comment:13 Changed 8 years ago by marshray

OpenSSL has been notified and a patch has been sent via 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.

comment:14 Changed 8 years ago by arma

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.

comment:15 Changed 8 years ago by murble

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

Source List:

comment:16 Changed 8 years ago by marshray

OpenSSL is referring to this as ticket [ #2828]

They already have a patch, but perhaps they haven't cut a release for it yet.

comment:17 Changed 8 years ago by nickm

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.

comment:18 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

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

comment:19 Changed 8 years ago by nickm

Keywords: tor-bridge added

comment:20 Changed 8 years ago by nickm

Component: Tor BridgeTor
Note: See TracTickets for help on using tickets.