6

We recently changed our nginx config to support TLSv1.2 as well as a number of more secure ciphers. Since the change, our nginx error logs have been filled with the following errors:

2015/01/28 23:55:57 [crit] 16898#0: *18712916 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: ..., server: 0.0.0.0:443

Our nginx config is as follows:

server {
  root   /var/www/fl/current/public;

  listen              443;
  ssl                 on;
  ssl_certificate     /etc/nginx/ssl/wildcard.pem;
  ssl_certificate_key /etc/nginx/ssl/wildcard.key;
  ssl_session_timeout 5m;
  ssl_session_cache shared:SSL:50m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

We've gotten a few emails about users not being able to access the site. One user said this is the error they get in Firefox:

Secure Connection Failed

An error occurred during a connection to ******.com. The server rejected the handshake because the client downgraded to a lower TLS version than the server supports. (Error code: ssl_error_inappropriate_fallback_alert)

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

If I understand correctly, then the fallback alert is a security precaution when the client is using a lower version of TLS than what it and the server support. This error seems to make a lot of sense given that we now support a higher protocol version. What I don't understand is why this change would cause issues for some users when connecting to our site. Is this a fault in our configuration or their browser?

We now score an 'A' on Qualys SSL Server Test, so I am hesitant to revert back to our old config.

EricR
  • 213
  • 1
  • 3
  • 10
  • OpenSSL [recently](https://www.openssl.org/news/vulnerabilities.html) (look for CVE-2014-3566) got a [TLS_FALLBACK_SCSV](https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03) prevention from downgrade attacks. But I'm not sure why users' browser behaves this way, it is wrong. Maybe they are MitM'ed :) – zakjan Jan 29 '15 at 06:50
  • 2
    Man-in-the-middle attacks would not cause this kind of error, because they do a new TLS connection from attacker to server. – Steffen Ullrich Jan 29 '15 at 08:17

2 Answers2

12

Browsers usually do a SSLv23 handshake. With this handshake they announce the best protocol version they support (mostly TLS1.2 today) but don't restrict the server to this version. Thus a server, which has a properly implemented and configured TLS stack but only supports TLS1.0, will simply reply with TLS1.0 and the connection will succeed on the first try.

But, there are some bad TLS stacks or misconfigurations or some bad middleboxes (load balancer etc) on the servers side, which cause this SSLv23 handshake to fail. In this cases browsers downgrade the protocol used in the handshake, that is they try with an explicit TLS1.0 handshake followed by an explicit SSL3.0 handshake (some browsers have disabled SSL3.0 already and thus don't try this).

Newer browsers will use the TLS_FALLBACK_SCSV pseudo-cipher if they do such a downgraded connection. If the server capable of TLS_FALLBACK_SCSV detects a downgraded connection with a lower protocol version it supports (e.g. downgrade uses TLS1.0 but server supports TLS1.2) than it assumes that a POODLE-like attack happens and will close the connection.

But why might a client downgrade in the first place when contacting your server?

  • You might have a broken load balancer in front, which causes hickups with some requests.
  • Your server or some anti-DOS device in front might simply close connections on high load before the SSL handshake finished. In this case the browser will assume a protocol problem and retry with a downgraded version.
  • Any other kinds of problems like out of memory etc which can cause random close within the SSL handshake.
Steffen Ullrich
  • 13,227
  • 27
  • 39
  • Thank you. It appears we're dealing with some strange connections issues. – EricR Jan 30 '15 at 15:57
  • I get this now with Google Chrome 50 / OS X 10.9.5 and Nginx 1.7.8 / Ubuntu 14.04.4 / libssl 1.0.1f-1ubuntu2.18 and I don't know if it's a server or client ssl bug and how to fix it. – erny Apr 28 '16 at 16:00
  • @erny: this looks like a different issue. Please open a new question and add lots of details if you expect to get help. – Steffen Ullrich Apr 28 '16 at 16:52
0

Change 318904 had a related patch set uploaded (by BBlack): non-crit for client handshake SSL_R_VERSION_TOO_LOW

https://gerrit.wikimedia.org/r/318904

https://phabricator.wikimedia.org/T148893

afly
  • 1