Opened 5 years ago

Closed 5 years ago

#11598 closed defect (worksforme)

Investigate using of TLSv1_method instead of SSLv23_method

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client 025-backport 024-backport
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

tortls.c

#if 0
  /* Tell OpenSSL to only use TLS1.  This may have subtly different results
   * from SSLv23_method() with SSLv2 and SSLv3 disabled, so we need to do some
   * investigation before we consider adjusting it. It should be compatible
   * with existing Tors. */
  if (!(result->ctx = SSL_CTX_new(TLSv1_method())))
    goto error;
#endif

s23_*.c files of OpenSSL code doesn't seems like many eyes will looking at.

Child Tickets

Change History (8)

comment:1 Changed 5 years ago by cypherpunks

Or TLSv1_2_method? And with every next tls version need to update code? It's epic to support everything up to newest with oldest ever code only.

comment:2 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-final

comment:3 Changed 5 years ago by nickm

From the manpage:

       TLSv1_method(void), TLSv1_server_method(void),
       TLSv1_client_method(void)
           A TLS/SSL connection established with these methods will only
           understand the TLSv1 protocol. A client will send out TLSv1 client
           hello messages and will indicate that it only understands TLSv1. A
           server will only understand TLSv1 client hello messages. This
           especially means, that it will not understand SSLv2 client hello
           messages which are widely used for compatibility reasons, see
           SSLv23_*_method(). It will also not understand SSLv3 client hello
           messages.

       SSLv23_method(void), SSLv23_server_method(void),
       SSLv23_client_method(void)
           A TLS/SSL connection established with these methods will understand
           the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
           client hello messages and will indicate that it also understands
           SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1
           client hello messages. This is the best choice when compatibility
           is a concern.

If existing clients are sending out the old ClientHello types, we can't demand TLS 1.0. But does disabling SSL2 and SSL3 make it send a TLS1 clienthello? Somebody needs to look at the openssl code (ick) this to see what clients are actually sending.

comment:4 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:5 Changed 5 years ago by nickm

Keywords: tor-client 025-backport 024-backport added
Milestone: Tor: 0.2.???Tor: 0.2.6.x-final

We should disable support for negotiating SSL v3. Fortunately, Tor doesn't do the downgrade-on-fail dance, and Tor doesn't retransmit the same secrets in multiple TLS sessions (thus severely limiting the usefulness of a padding oracle attack against Tor's SSL), but thanks to POODLE, the time has come to drop SSL v3.

comment:6 Changed 5 years ago by moeh

I am an anonymous coward who has just studied the matter for my own professional needs. I created an account to share my understanding and how to verify what I say by yourself.

Regarding the method parameter to SSL_CTX_new(), I warmly recommend you to experiment with openssl s_client tool (see https://www.openssl.org/docs/apps/s_client.html and the source code ${OPENSSL_SRC_DIR}/apps/s_client.c for details). Of course there is also openssl s_server (https://www.openssl.org/docs/apps/s_server.html) that is also mightily useful. You can see the protocol version in the terminal output or you can use Wireshark. The source code - even per admission of the corresponding manual pages - is potentially slightly hazardous to your mental purity, but the correspondence with the method argument and the parameter to SSL_CTX_new() is easy to find in the source files if you summon the courage to dig in.

Using https://www.google.com as peer for the demonstration, you can observe that openssl s_client -tls1 -connect www.google.com:443 (corresponding to TLSv1_client_method() will give you TLS 1.0 connection). Option -tls1_2 (corresponding to TLSv1_2_client_method()) will give you TLS 1.2 connection. So does the default (no SSL/TLS version option, corresponding to SSLv23_client_method()).

I believe the name of the most interoperable method parameters (SSLv23_method() & friends) are so confusing because of historical reasons. Do not let yourselves mislead by the unfortunately confusing names. If you dislike using SSL3 (or TLSv1.0 or SSLv2 if that can even happen), then you can use SSL_CTX_set_options() (https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html) to disable the undesired protocol versions - there is SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and SSL_OP_NO_TLSv1. I have not tested this or read the OpenSSL source code to comment if the manual page is telling the truth. (Another way could be to somehow check the protocol version after handshake is completed and close the connection if undesired protocol version is negotiated.)

SSLv23_method() and its server/client variants work as follows (you can check this using wireshark):

  1. client: sends client hello using protocol version SSLv3 but indicating support for TLSv1.2 (some perhaps outdated documentation says SSLv2 client hello is sent, but I recall seeing SSLv3).
  2. server: accepts client hellos using SSLv3 (SSLv2 too perhaps) and TLSv1.0 / TLSv1.1 / TLSv1.2 and responds with appropriate way to give you the best protocol version.

Again you can easily test this yourself, using Wireshark and trying different combinations of protocol parameters (which you find all easily enough in the source code) for openssl s_server and openssl s_client. You do not need to blindly believe what I say.

Too long, did not read summary: If you want to absolutely require the most secure TLS protocol version and reject anything else for maximal security, I think you should use TLSv1_2_client_method() / TLSv1_2_server_method() / TLSv1_2_method() and change this when OpenSSL is updated to support newer not yet existing protocol version. Otherwise use SSLv23_method() or its client/server variants for maximal interoperability which gives you the most secure protocol version possible in consideration with what the peer supports and specify the earlier versions of the protocols that you find unacceptable by using SSL_CTX_set_options() so that peers insisting in using obsolete SSL/TLS versions will be rejected.

Last edited 5 years ago by moeh (previous) (diff)

comment:7 Changed 5 years ago by nickm

Yup, you're right. It looks like TLS1_method() is a trap that prevents the use of TLS 1.1 and TLS 1.2. There doesn't seem to be a method that means "Allow TLS 1.0 and later;" instead, I believe we need to use SSLv23_method() and set SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3.

comment:8 Changed 5 years ago by nickm

Resolution: worksforme
Status: newclosed

I've opened a new ticket, #13426, to track the "disable SSLv3" ticket, and closing this ticket as finished. Thanks for the feedback, all.

Note: See TracTickets for help on using tickets.