[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