On 01/06/17 02:58, Florin Andrei wrote: > 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?
"Normal" TLS version negotiation works like this (ignoring TLSv1.3 which isn't relevant for this discussion): the client sends the maximum TLS version that it supports in its ClientHello message (this should not be confused with the version number in the record header). The server responds with a ServerHello containing the maximum version that it supports and which is less than or equal to the client's maximum version number. For example, if the client supports TLSv1.2 but the server only supports TLSv1.0, then the ClientHello version will be TLSv1.2 and the server will respond with TLSv1.0. On the other hand if the client only supports TLSv1.0 but the server supports TLSv1.2, then the ClientHello version will be TLSv1.0 and the ServerHello version will also be TLSv1.0. This is all fine but there are some servers out there which are buggy and abort the connection if the ClientHello version is bigger than the maximum version that the server supports. To work around this some clients will do "fallback". So, they start with a ClientHello version of TLSv1.2. If the connection aborts then they might send another one with a version of TLSv1.1. If that aborts then TLSv1.0. The problem with that approach is that it can be exploited by an attacker. An attacker may be able to exploit some weakness in an earlier TLS version which is fixed in a later version. The attacker may then be able to modify the traffic to ensure that a TLSv1.2 ClientHello fails in order to force the client to fallback to the earlier exploitable version. The TLS_FALLBACK_SCSV ciphersuite is used as a counter measure to that type of attack. A client will include it if it is sending a ClientHello with a max version that is lower than the maximum that the client actually supports (because an earlier attempt with the higher version number failed). If a server receives a TLS_FALLBACK_SCSV ciphersuite in a ClientHello and it supports a higher version than the one in the ClientHello then there should have been no reason for the client to fallback and you get the "inappropriate fallback" error. 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. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
