Weird proxy_ssl_protocol ordering

Maxim Dounin mdounin at
Fri Jan 13 19:32:27 UTC 2017


On Fri, Jan 13, 2017 at 12:33:16PM -0500, bclod wrote:

> Hello All,
> I found some strange behavior while troubleshooting a connectivity issue
> today.  Below was the scenario.
> * Upstream Backend configured to allow TLSv1.1 and TLSv1.2
> * Client (nginx) configured with proxy_ssl_protocols TLSv1 TLSv1.2
> No matter the ordering of nginx proxy_ssl_protocols TLSv1 was always
> attempted first and the handshake would fail. Once I added TLSv1.1 it caused
> TLSv1.2 to be attempted first which would be successful to the Server.
> Is this a bug?  I always assumed that nginx would default to highest
> supported protocol outbound; but it seems that "TLSv1 TLSv1.2" might
> introduce some sort of strange ordering issue.

Sort of.

The same problem can be reproduced using openssl s_client this 

$ openssl s_client -no_tls1_1 -connect

The problem is that only _one_ protocol version can be sent in 
CLientHello during a handshake, and expected to be the maximum 
version supported by the client.

Depending on the OpenSSL version you use, TLS 1.0 and TLS 1.2 (but 
no TLS 1.1) in your configuration means either:

- TLS 1.2 in ClientHello (OpenSSL before 1.0.2); or
- TLS 1.0 in ClientHello (OpenSSL 1.0.2+);

Both options have their drawbacks.

In the first case a backend which supports TLS 1.1 but not TLS 1.2 
will see highest supported version TLS 1.2, and will respond with 
TLS 1.1.  And this will fail, as TLS 1.1 is not allowed by your 

In the latter case a backend which supports TLS 1.2 but not TLS 
1.0 will immediately fail as the version request is too low (this 
is what happens in your case).

I personally think that the previous behaviour was much more 
logical and allowed users to configure whatever they want to.  But 
the change was clearly intentional.  Please complain to the 
OpenSSL team if you too think it was wrong.

Note though, that making "holes" in the protocol versions 
supported by a client isn't generally a good idea, and is likely 
to cause troubles.

Maxim Dounin

More information about the nginx mailing list