Weird proxy_ssl_protocol ordering
mdounin at mdounin.ru
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.
The same problem can be reproduced using openssl s_client this
$ openssl s_client -no_tls1_1 -connect 127.0.0.1:443
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.
More information about the nginx