> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Salz, Rich via openssl-users > Sent: Thursday, June 01, 2017 14:44 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] SSL error “inappropriate fallback” and > TLS_FALLBACK_SCSV > > > Would clients actually attempt to send TLS_FALLBACK_SCSV even if the > > previous connection attempt failed for reasons other than TLS? If, say, the > > initial connection attempt failed at the TCP level? That sounds a little > > strange > > to me. > > Yes they do.
And they should, *if* they have actually fallen back to an older protocol version, because an attacker with the appropriate affordance (e.g. a compromised router along the path) could easily trigger a TCP failure by sending a RST. Any time the client falls back, it should include TLS_FALLBACK_SCSV in its cipher-suite list. The question is whether a client that supports fallback (and there's much debate over whether clients should support fallback, particularly in the default configuration) ought to try falling back in response to a TCP failure. On the one hand, it's entirely possible that a broken old server would reject an unrecognized protocol version by simply aborting the connection. On the other, there are a lot of other reasons for a RST, and falling back as the first resort seems rather hasty. Personally, I'd prefer clients not try to fall back at all, except perhaps clients that have a reasonable need to support broken servers, and even then only with some non-default configuration. Browser manufacturers will argue that they have to support fallback in order to support broken web servers, but I think that's dubious. > There are many badly written clients out there. Or poor libraries. Very true. 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. 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. Really there are too many possibilities to make speculation worthwhile. But now that I've written all this I suppose I'll send it. Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
