Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV
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/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV
On 2017-06-01 11:43, Salz, Rich via openssl-users wrote: 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. There are many badly written clients out there. Or poor libraries. What I find surprising is the rate of these errors. For every 100 legitimate HTTP requests that make it to Nginx, I get 2.5 “inappropriate fallback” SSL errors. That's a lot of noise. I guess I'll have to adjust my expectations. Related question: assuming the lists of TLS protocol versions and ciphers I've enabled in Nginx are indeed exactly the same as the default TLS policy in an AWS ALB, the errors I see now logged by Nginx should be, more or less, the same population of errors I saw reflected in the ALB metrics before, right? The whole point of this exercise is to temporarily work around the lack of a TLS error log in an ALB. The error rate does seem quite similar between ALB and Nginx. I'm just wondering if the ALB is doing something that my standard Ubuntu openssl libraries are not. -- Florin Andrei http://florin.myip.org/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV
On 2017-06-01 02:13, Matt Caswell wrote: The presence of this error doesn't actually mean that you are under attack. It just means that the client made an earlier connection attempt with a higher version number and it failed. There could be many reasons for the failure. For example, plausibly, if you have a lot of mobile clients then you could imagine that a network glitch could cause an earlier attempt to fail. It's interesting how I see a constant stream of “inappropriate fallback” errors in the logs, but this is pretty much the only error from a TLS perspective. Sure, there's the occasional certificate failure, like once every few minutes or so, and then, rarely, there's some ancient app trying SSLv3 (which is not enabled). But looking at the Nginx error.log the “inappropriate fallback” is basically the only error I get a perpetual flow of. If the TLS_FALLBACK_SCSV attempt is caused by a previously failed connection, that must have been something different from a TLS error, because “inappropriate fallback” is probably over 99% of the lines in error.log - it's the only thing I see as logs are scrolling up in my viewer. 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. Again, our clients are a mix of the average mobile devices in general use these days. -- Florin Andrei http://florin.myip.org/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SSL error “inappropriate fallback” and TLS_FALLBACK_SCSV
: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_FALLBACK_SCSV (0x5600) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 92 Extension: renegotiation_info Type: renegotiation_info (0xff01) Length: 1 Renegotiation Info extension Renegotiation info extension length: 0 Extension: server_name Type: server_name (0x) Length: 27 Server Name Indication extension Server Name list length: 25 Server Name Type: host_name (0) Server Name length: 22 Server Name: [REDACTED] Extension: Extended Master Secret Type: Extended Master Secret (0x0017) Length: 0 Extension: SessionTicket TLS Type: SessionTicket TLS (0x0023) Length: 0 Data (0 bytes) Extension: Application Layer Protocol Negotiation Type: Application Layer Protocol Negotiation (0x0010) Length: 26 ALPN Extension Length: 24 ALPN Protocol ALPN string length: 5 ALPN Next Protocol: h2-16 ALPN string length: 8 ALPN Next Protocol: spdy/3.1 ALPN string length: 8 ALPN Next Protocol: http/1.1 Extension: ec_point_formats Type: ec_point_formats (0x000b) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: elliptic_curves Type: elliptic_curves (0x000a) Length: 8 Elliptic Curves Length: 6 Elliptic curves (3 curves) Elliptic curve: secp256r1 (0x0017) Elliptic curve: secp384r1 (0x0018) Elliptic curve: secp521r1 (0x0019) It's a little puzzling because the exchange of crypto messages uses TLS 1.0 which the server definitely supports, and the client should be very likely to support too. I've seen discussions online saying that the presence of the TLS_FALLBACK_SCSV cipher suite is an indication that this failed connection is related to anti-POODLE security measures, and the communication is likely to be retried again. Is that correct? For the most part, what I'm trying to do is find the answers to these questions: 1. Is this bad? If yes, why? (what are the things that the clients need that the endpoint is not providing) 2. If it's not bad, then why do we get this constant stream of SSL errors? It's a little difficult to search the capture file and try to correlate the failed SSL handshake with other, successful connections, because the source IPs are masked by the ELB. There might be a way to rely on the PROXY protocol header to identify IPs, but I'll have to figure out how to do that. -- Florin Andrei http://florin.myip.org/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
