Investigate using of TLSv1_method instead of SSLv23_method

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.

changed milestone to %Tor: 0.2.6.x-final

added 024-backport 025-backport component::core tor/tor milestone::Tor: 0.2.6.x-final priority::medium resolution::worksforme status::closed tor-client type::defect labels

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.

Trac:
Milestone: N/A to Tor: 0.2.6.x-final

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.

Trac:
Milestone: Tor: 0.2.6.x-final to Tor: 0.2.???

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.

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.2.6.x-final
Keywords: N/A deleted, tor-client 025-backport 024-backport added

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.

Trac:
Username: moeh

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.

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

Trac:
Resolution: N/A to worksforme
Status: new to closed

closed

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