How to make "modern" TLS and "outdated" browsers friendly?

The topic was prompted by a discussion of the previous post , in which the voice of a caring web server administrator sounded: TLS 1.2 and AEAD are the choice of a healthy person, but who will regret the users of "outdated" browsers? Let's discuss this - the alleged incompatibility between "modern" TLS and "legacy" browsers.



The hypothesis is as follows: if only stable versions of the TLS transport layer security protocol (1.2 and 1.3) and cipher suites (AEAD) are left on the web server, users of "outdated" browsers will not be able to access the site.



Let's take an optional excursion into history ... In 2005 (ie 16 years ago), the US National Security Agency announced a corpus of standards, guidelines, recommendations and other supporting documents on the use of cryptographic algorithms - NSA Suite B Cryptography.



In 2009 IETF published RFC5430Suite B Profile for Transport Layer Security, which established which protocols and cipher suites should be used for HTTPS connections in order to comply with NSA requirements. Even then, to meet these requirements, the web server and web browser had to support TLS version 1.2 and the cipher suites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.



That is, for at least the last 11 years, developers have known what requirements their products must meet in order to be able to qualify for an American government order. Therefore, you will probably perceive the following fact without surprise: all browsers actually used today support the mentioned cipher suite in the version with a 128-bit cipher key, and many (but not all) - and with a 256-bit one.



This could be the end of the article, recommending that all web server administrators leave support only for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and not bother with myths about the incompatibility of TLS 1.2 with "outdated" browsers, if not for a nuance: in TLS versions younger than 1.3, the digital signature algorithm must be in cipher coincide with the algorithm in the TLS certificate, and less than 6% of web servers with a certificate signed using the ECDSA algorithm in the .RU domain zone , the rest are used for RSA signing.



Who is to blame is a question of a separate study; we are interested in what to do? Let us first recall that not only the combination ECDHE + ECDSA + AES recommended by the NSA, but also others are among the strong cipher sets today:





A total of 19 strong cipher suites, but not all of them are suitable for use in real life on a public web server: the CAMELLIA encryption algorithm, like AES in CCM mode, is supported by little more than anyone, with CHACHA20 and its faithful companion POLY1305 are only relatively familiar modern browsers, and to use ECDSA-based cipher suites, as already mentioned, an appropriate TLS certificate is required. Thus, we have only 4 "additional" cipher suites



left : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.



It is tempting to assume that if the browser supports the ECDHE + ECDSA combination, then it will definitely cope with ECDHE + RSA, but this is not always the case - many can only do DHE + RSA, and in order to satisfy the requests of all old browsers, on a site with an RSA certificate you need support two cipher suites:



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



This will give us compatibility with at least the following operating systems and browsers:



Android 4.4.2 + Android Browser (Chrome);

Windows XP + Chrome 49 / Firefox 49 / Opera 12.18;

Windows 7 + Internet Explorer 11 / Chrome 31 / Firefox 31;

OS X + Firefox 29 / Chrome 37;

iOS 9 + Safari 9;

Java 8b.



I will not say about * nix systems - it depends on the assembly, but it is obvious that the problem does not exist as such. The only problem will arise with Windows Phone 8.1 + IE 10, which only support one stable combination - ECDHE + ECDSA.



But what should users of Windows XP + IE 6 or some Android 2.3 do? - the caring admin will ask. Continuesit without access to the modern Internet, - I will answer, - because even the support of the web server protocol SSL 2.0 will not help them. The fact is that even if you roll on Windows XP all the updates released for it (up to May 2019) and update the standard browser to version 8, this will only bring support for TLS 1.2, but not stable cipher suites. In addition, Windows XP neither knew nor would learn what Server Name Indication (SNI), HTML 5 Live HTML, and CSS 3 are.



Are you ready for the sake of stubborn "one and a half diggers" to keep a dedicated IP for the site and not update the layout? Then add support, for example, TLS_RSA_WITH_AES_256_CBC_SHA256, but rather, you should assume that a modern Windows XP user has long been using an alternative browser that even supports TLS 1.3. The same is true for Android 2.3, installing Firefox 27 on which we will get full support for TLS 1.2 and AEAD cipher suites, and without installing - we simply will not be able to use a significant part of modern sites, even over HTTP.



All of the above, of course, is not a call to abandon support for more strong cipher suites, which will be demanded by modern browsers, and which should be proposed for negotiation in the first place.



In order not to get up twice, consider briefly the situation with elliptic curves. NSA Suite B Cryptography recognizes only two of them - NIST P-384 and NIST P-256, support for which on the web server will provide access to the site for both modern and "legacy" browsers. Actually, it is enough to support only NIST P-384 for "oldies" and Curve25519 for modern browsers; well, except perhaps to add NIST P-521, for some "advanced oldies".



To summarize: if we want the site to remain accessible to "outdated" browsers, but at the same time support only robust versions of the transport layer security protocol and cipher suites, we will proceed as follows.



For a site with a TLS certificate signed using the ECDSA algorithm , enable support for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.



For a site with a TLS certificate signed using the RSA algorithm , enable support for the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites.



For both sites, we will enable support for the NIST P-384 or NIST P-256 elliptic curve and set the order of preference for cipher sets and elliptic curves, according to which the above sets and curves are offered to browsers for matching after more stable ones, for example, after TLS_ECDHE_RSA_WITH_AES_ 256 _GCM_SHA 384 and Curve25519, respectively.