27

I'm trying to fully understand the report of the SSL Labs server test.

Can someone explain the term 'TLS version intolerance'? I cannot find any documentation of this term, even not on the forums of SSL labs or their SSL Server Rating Guide.

For example, for the SSL report of mijn.ing.nl (dutch banking site) it states:

TLS version intolerance: TLS 1.3  TLS 1.98  TLS 2.98

Intolerance sounds bad, but is it in this case? I'm also unaware of the TLS versions 1.98 and 2.98.

Update: nowadays the TLS version intolerance is fixed for mijn.ing.nl (stated as "No" in the report)

Julian
  • 516
  • 6
  • 18
  • 3
    The particular entry you show is quite common: http://www.ietf.org/mail-archive/web/tls/current/msg10657.html – user10008 Sep 04 '14 at 20:39
  • Then again, ING is a bank. You would have hoped they would know how to properly implement TLS. – MSalters Sep 05 '14 at 13:38

1 Answers1

45

In TLS, the client announces its maximum supported version. Then the server responds with the protocol version that will actually be used for the connection.

So for instance, if a server knows TLS 1.0 and 1.1, and the client announces "I support up to TLS 1.2", the server, without knowing what TLS 1.2 may be, can still respond: "fine, we'll use 1.1".

Theoretically, if a client says "I support up to TLS 1.38" (which will be encoded in the ClientHello as two bytes of value 0x03 0x27), a server who supports up to TLS 1.2 will not have any clue of what TLS versions 1.3, 1.4... to 1.38 are (and, indeed, such versions don't exist yet, the maximum defined being TLS 1.2 right now); however, that server can still say: "1.38 is higher/later than 1.2, so the client should know about TLS 1.2" and proceed with stating: "we will use 1.2".

In practice, some servers are poorly written, and when a client says "TLS 1.3" they drop the connection. This is a server bug; but a widespread one. That bug is often designated by the expression "version intolerance". Some of these buggy servers accept some kinds of unknown versions, but not all. E.g. some servers would tolerate any "1.x" version for any x in the 0 to 254 range, but would reject a version "2.y".

Because of version intolerance, clients (Web browser) must already include contingency code which tries several times. E.g. it first try to connect with "1.2" in the ClientHello, but if the connection fails, the client tries again with "1.0" as maximum supported version. This is tiresome and kludgy. A server that does not tolerate TLS version 1.3 is a server that will be troublesome when TLS 1.3 is specified and browsers begin to use it.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • thx. Do you any idea why they test 1.98 and not 1.99 and/or 2.0? – Julian Sep 06 '14 at 14:17
  • 3
    The "98" is arbitrary; the encoding is binary, not decimal. Version "x.y" is encoded as two bytes of value 2+x and 1+y, respectively (i.e. TLS 1.0 is encoded as 0x03 0x01), so the cutoff would be at 1.254 -> 2.0 (or even 2.-1 for 0x04 0x00). Point is that some implementation will accept 0x03 0xYY for any YY beyond 03, but reject 0x04 0xZZ. – Thomas Pornin Sep 06 '14 at 17:44
  • 2
    And this "contingency code" BTW is not a good thing as it makes downgrade attacks possible: https://security.stackexchange.com/questions/70988/why-do-browsers-probe-and-fallback-or-why-ssl-mode-send-fallback-scsv – rugk Feb 21 '16 at 09:39