Check Server security protocol using openssl

Question

I have an framework application which connects to different servers depending on how it is used. For https connections openssl is used. My problem is, that I need to know if the server I am connecting to is using SSL or TLS, so I can create the right SSL context. Currently if I use the wrong context trying to establish a connection times out.

For TLS I use:

SSL_CTX *sslContext = SSL_CTX_new(TLSv1_client_method());

For SSL I use:

SSL_CTX *sslContext = SSL_CTX_new(SSLv23_client_method());

So is there a way to know which protocol a server is running before establishing a connection?

Edit: So as I understand it now it should work either way, since the SSLv23_client_method() also contains the TLS protocol. So the question is why does it not? What could be the reason for a timeout with one client method but not the other?

Answer 1

For SSL I use:
SSL_CTX *sslContext = SSL_CTX_new(SSLv23_client_method());

TLS is just the current name for the former SSL protocol, i.e. TLS1.0 is actually SSL3.1 etc. SSLv23_client_method is actually the most compatible way to establish SSL/TLS connections and will use the best protocol available. That means it will also create TLS1.2 connections if the server supports that. See also in the documentation of SSL_CTX_new:

SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)

A TLS/SSL connection established with these methods may understand the SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.

... a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. This is the best choice when compatibility is a concern.

Any protocols you don't want (like SSL3.0) you can disable with SSL_OP_NO_SSLv3 etc and using SSL_CTX_set_options.

Currently if I use the wrong context trying to establish a connection times out.

Then either the server or your code is broken. If a server gets a connection with a protocol it does not understand it should return "unknown protocol" alert. Other servers simply close the connection. Timeout will usually only happen with a broken server or middlebox like an old F5 Big IP load balancer.

Answer 2

So is there a way to know which protocol a server is running before establishing a connection?

No. But you should now presume its "TLS 1.0 and above".

As Steffen pointed out, you use SSLv23_method and context options to realize "TLS 1.0 and above". Here's the full code. You can use it in a client or a server:

const SSL_METHOD* method = SSLv23_method();
if(method == NULL) handleFailure();

SSL_CTX* ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();

const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);

Now, there's an implicit assumption here that's not readily apparent; and that assumption is wrong. That assumption is there is a "TLS min" and "TLS max" version.

What happens is there's a underlying SSL/TLS record layer that carries the protocol payloads. The TLS record layer is independent from the protocol layer, and it has its own version. People interpret TLS record layer version as "TLS min" version; and the protocol version as the "TLS max" version. Most clients servers, sites and services use it that way.

However, the IETF does not specify it that way, and browser's don't use it that way. Because of that, we recently got TLS Fallback Signaling Cipher Suite Value (SCSV).

The browser are correct. Here's how its supposed to be done:

• try TLS 1.2, use Fallback Signalling to detect downgrade attacks
• if TLS 1.2 fails, then try TLS 1.1, use Fallback Signalling to detect downgrade attacks
• if TLS 1.1 fails, then try TLS 1.0, use Fallback Signalling to detect downgrade attacks

Many give up after TLS 1.0 fails. Some user agents may continue with SSLv3.

---

Why has the IETF not moved to give us "TLS min" and "TLS max"? That's still a mystery. I think the effective argument given is "suppose a client want to use TLS 1.0, 1.2 and 1.3, but not 1.1". I don't know anyone who drops a protocol version like that, so its just a strawman to me. (This is one of those times when I wonder if law enforcement or a national interest, like the NSA, is tampering with standards).

The issue was recently brought up again on the TLS Working Group. From TLS: prohibit <1.2 support on 1.3+ servers (but allow clients) (May 21, 2015):

Now might be a good time to add a (3) for TLS 1.3: have a client specify both the least TLS version they are willing to use, and the greatest TLS they desire to use. And MAC or derive from it it so it can't be tampered or downgraded.

You can still provide the the TLS record layer version, and you can keep it un-MAC'd so it can be tampered with to cause a disclosure or crash :)

Effectively, that's how the versions in the record layer and client protocol are being used. It stops those silly dances the browsers and other user agents perform without the need for TLS Fallback SCSV.

If part of the IETF's mission is to document existing practices, then the IETF is not fulfilling its mission.