[tor-bugs] #11598 [Tor]: Investigate using of TLSv1_method instead of SSLv23_method

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Oct 15 07:09:12 UTC 2014


#11598: Investigate using of TLSv1_method instead of SSLv23_method
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:
  cypherpunks            |     Status:  new
         Type:  defect   |  Milestone:  Tor: 0.2.6.x-final
     Priority:  normal   |    Version:
    Component:  Tor      |   Keywords:  tor-client 025-backport
   Resolution:           |  024-backport
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by moeh):

 I am an anonymous coward who has just studied the matter for my
 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 misleading because of historical
 reasons, do not get stuck with the confusing name. If you dislike using
 SSL3 (or TLSv1.0 or SSLv2 if that can even happen), then maybe there is
 way to 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''.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11598#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list