Browsers refuse to support TLS 1.0 and 1.1
In August 2018, the IETF approved TLS 1.3
TLS 1.0 and TLS 1.1 will soon cease to exist. Already, Firefox telemetry shows that these protocols account for an insignificant proportion of HTTPS traffic: 1.11% and 0.09%, respectively. The vast majority of sites now use TLS 1.2. And in the years 2019-2020, all major browsers intend to completely abandon support for TLS 1.0 and TLS 1.1. On the server side, it is recommended to disable these protocols now.
Why disable TLS 1.0 and 1.1
The TLS 1.0 standard in January of next year marks 20 years. He fulfilled his role: over the years, the protocol has encrypted billions, if not trillions of connections. Over time, it became better to understand how to design encryption protocols. Requirements for cipher reliability have increased. Unfortunately, TLS 1.0 and 1.1 do not meet these requirements.
In TLS 1.0 and 1.1 there are some aspects that arouse concern, writes Mozilla Security Blog. The worst thing is that they do not support the work with modern cryptographic algorithms. For example, when shaking hands, you must use the SHA-1 hashing algorithm. In these versions of TLS, it is not possible to set a stronger hashing algorithm for ServerKeyExchange or CertificateVerify signatures. Therefore, the only solution is to upgrade to the new version of TLS.
On September 14, 2018, the Internet Engineering Task Force (IETF) published a draft of an official document , which does not recommenduse TLS 1.0 and 1.1. Among other things, it is mentioned there that SHA-1 with a cryptographic strength of 2 ^ 77 cannot be considered safe by modern standards: "2 ^ 77 operations [for an attack] are below the permissible security limit."
A fragment of the document IETF refusal of old versions of TLS
The document provides more detailed technical information about the reasons for such a decision. It says BEAST (Browser Exploit Against SSL / TLS) attack on TLS 1.0, namely block ciphers, where the last encryption block of the previous message (n-1) is used as the initialization vector for message n.
TLS 1.1 is taken out of circulation with TLS 1.0 because it is not fundamentally different and has essentially the same drawbacks. In this version, only some of the limitations of TLS 1.0 have been fixed, which can be avoided by other means (again, this is a BEAST attack).
According to the recommendations of NIST, web services were requested to remove support for older versions of TLS until July 2018. Amazon, CloudFlare, GitHub, KeyCDN, PayPal and many other web services have done this.
Timing off
The developers of all leading browsers have agreed to implement the recommendations of the IETF.
Chrome browser is the first to abandon support for older versions of TLS. The developers plan to start the process with version Chrome 72, which will be released in January 2019: from now on, sites with outdated protocols will display a warning in the DevTools console. A complete shutdown will take place in the version of Chrome 81, which is scheduled for release in March 2020 (preliminary versions - from January 2020).
Microsoft promises to disable protocols "in the first half of 2020". Mozilla announced that it will disable TLS 1.0 and 1.1 in Firefox in March 2020. Apple plans to remove support from Safari browsers in March 2020.
Press releases from the developers of all leading browsers came out very coordinated:
Modern TLS 1.2 profile
According to the IETF recommendation, TLS 1.2 should be the minimum cryptographic base for HTTPS connections. According to the Firefox telemetry, it now accounts for 93.12% of HTTPS traffic ( 94% according to Qualys ), so the de facto recommendations are being implemented today.
Using TLS versions for all HTTPS connections in Firefox Beta 62, telemetry data for August-September 2018
TLS 1.2 is a prerequisite for HTTP / 2 operation, which improves the performance of sites . Mozilla recommends using a modern TLS 1.2 profile on the server sideif there are no specialized needs. Modern profile provides a high level of security and includes the following options:
- Cipher suites: ECDHE-ECDSA-AES256-GCM-SHA384,: ECDHE-the RSA-AES256-GCM-SHA384,: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-the RSA-CHACHA20-POLY1305: ECDHE-ECDSA-AES128-GCM-the SHA256: ECDHE -RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA256
- Elliptic curves for TLS: prime256v1, secp384r1, secp521r1
- Certificate Type: ECDSA
- Elliptic curves for certificate: prime256v1, secp384r1, secp521r1
- Certificate Signature: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512
- RSA key size: 2048 (if not ECDSA)
- DH Parameter size: None (completely disabled)
- ECDH Parameter Size: 256
- HSTS: max-age = 15768000
- Switching Certificates: No
Experts note that now few certification centers support ECDSA-signatures, so the recommendations allow RSA-signatures for ECDSA-certificates.
The DHE key exchange protocol is completely removed from the cipher suite because it is slower than ECDHE, and all modern clients support elliptic curves.
The SHA1 signature algorithm is also completely removed from the set: SHA384 for AES256 and SHA256 for AES128 are used instead.
This configuration is supported from Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0 and Java 8. If older browsers are needed, then the requirements for the cipher suite will have to be reduced to the “average” level It is also set as the default level. Only in the most extreme case it is advised to stoop tobackward compatible cipher suite supporting Windows XP / IE6.
Unfortunately, today not all vendors comply with the recommendations for the safe configuration of TLS 1.2.
On September 24, 2018, an academic study of this problem was published at arXiv.org by researchers from Concordia University in Montreal (Canada). The authors analyzed the behavior of 17 versions of 13 network TLS-tools of different classes (free, open source, low-level and high-level).
The conclusions are disappointing: almost all the products considered were vulnerable:
For example, it turned out that WebTitan, UserGate and Comodo do not perform TLS validation. Comodo and Endian by default consider all certificates verified, and Cacheguard accepts self-signed TLS certificates.
Trend Micro, McAfee and Cacheguard use pre-generated key pairs (although the McAfee documentation claims otherwise). Four devices — from UserGate, WebTitan, Microsoft, and Comodo — accept their own certificates for externally delivered content. Private keys are stored on the device and can be easily extracted using other vulnerabilities.
The BEAST attack allows you to get authentication cookies from TLS users from Microsoft, Cisco, and TrendMicro, while Sophos, Cacheguard, OpenSense, Comodo, and Endian clients accept RSA-512 certificates, which private keys are easily forged for four hours.
Future for TLS 1.3
In August 2018, the IETF approved the TLS 1.3 standard , which was described in detail in Habré . The main innovations in the new version:
- new handshake protocol: the process is twice as fast by combining several steps, the handshake mechanism has become more secure, as the developers have removed all algorithms that do not use block encryption AEAD modes;
- A new key generation process using the Extract-and-Expand Key Derivation Function (HKDF);
- removing cipher dials using RSA or DH key exchange, CBC mode and SHA-1 mode.
Now version 1.3 in the preliminary version is supported by Chrome and Firefox. According to telemetry, the Firefox browser now establishes more connections over TLS 1.3 than over TLS 1.0 and 1.1.
It is clear that updating one of the most important protocols will affect many sites and take a long time, but in the end the Internet will become safer.
