[openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV

[Florin Andrei]

On 2017-06-01 12:23, Michael Wojcik wrote:
> 
> On the other hand, this doesn't really answer Florin's question of why
> the server sees so many clients falling back. If the load is bursty,
> it might be listen-queue dumping. I don't know if Nginx lets you
> configure the listen queue depth, but at some point the stack will
> start dropping connections (either silently, in the BSD or "correct"
> manner; or with a RST, in the Winsock or "patently wrong" manner) if
> the sustained load is too high. But unless this is a pretty busy
> server or has a really high variance in its load distribution, it's
> probably an intermediary node that's to blame.

Aggregate traffic has a smooth profile, with daily increase towards the 
middle of the day, and decrease towards midnight. Client sessions are 
typically short (way under 1 minute, perhaps most of them under 15 
seconds).

I don't see any errors related to what you're saying.

> Or the clients have a really short timeout, or the connection's being
> aborted by the user and the client is incorrectly falling back when
> that happens. Though then I'd assume Florin would see that in the
> Nginx logs, assuming it logs ECONNRESET.

Well, I'm digging through the logs. The one thing I see often is:

     client X.Y.Z.K closed keepalive connection

Not much other than that, and these are really "severity:info" events, I 
see them even with TLS termination at the ALB.

I see some amount of...

     peer closed connection in SSL handshake while SSL handshaking

...also a "severity:info" event, at a rate about 4x less than the 
“inappropriate fallback” stuff.

(shrug) Seems normal.

As a more informal argument: We're using whatever Amazon deemed 
appropriate for their TLS policy for load balancers, in terms of 
protocol versions and ciphers. Surely if there was a problem with 
versions or ciphers, we'd hear about it, or they would change it 
quickly, just based on the amount of traffic they receive every day. 
That was the main reason why I've found hard to accept that this rate of 
TLS errors is somehow normal; but now I think I start to understand this 
aspect of the protocol thanks to the excellent explanations I've seen 
early in this discussion.

-- 
Florin Andrei
http://florin.myip.org/