Hello! 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 way: $ 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 configuration. 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 http://nginx.org/ _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
