In nginx error log: "SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback"

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.