Are there any methods to prevent version rollback attack while using TLS 1.2 (apart from disabling lower versions)? I've read about how TLS 1.3 provides a downgrade protection mechanism which is embedded in the server’s random nonce. Is there any such mechanism in TLS 1.2?
1 Answer
Rollback by tampering the ClientHello/ServerHello exchange is detected and blocked by Finished in all versions of TLS. For plain-RSA keyexchange the client version is additionally 'smuggled' in the encrypted premaster secret which allows earlier detection -- but since the early 2010s (teens?) plain-RSA has mostly been deprecated or dropped because it doesn't provide Forward Secrecy. For (all) suites using client authentication in TLS 1.0-1.2 the client signature also covers the transcript including the version, thus detecting rollback, but using client authentication is optional and rare.
Downgrade by causing a higher version handshake to fail so that a client is induced to use (and accept) a lower version varies.
TLS 1.0-1.2 specify a check against downgrade to SSLv2 by setting the low bytes of the premaster secret before encryption in plain-RSA keyexchange (which is the only keyexchange in SSLv2); this is E.2 in RFC 2246 and 4346 and E.3 in RFC 5246. But by the mid-to-late noughties, when 1.1 and 1.2 were adopted, pracically everybody/everything had dropped SSLv2, and it was officially prohibited by RFC6176 in 2011, so this became moot. (Java JSSE until j7 in 2011 used by default the 'transitional' hello format from SSLv2, but JSSE never supported actual SSLv2 protocol.)
For TLS 1.0-1.2 RFC 7507 in 2015 defines a SCSV to detect downgrade (and is referenced in RFC8446, which incorporates the alert code).