Vulerabilities

Into

There are two types of vulnerabilities:

  • SSL Certificate Vulnerabilities
  • SSL Endpoint Vulnerabilities

SSL Certificate Vulnerabilities

Certificate Name Mismatch

If the exact domain name (FQDN) in the SSL Certificate does not match the domain name displayed in the address bar of the browser

Internal names

After November 1, 2015, CAs will no longer issue certificates to internal names. Internal names cannot be implicitly validated because they cannot be externally verified.

Missing or Misconfigured Fields and Values in Certificates

Certificates that do not contain the necessary fields and values may cause browsers to display warnings.

SHA-1 Hashing Algorithm

The current acceptable key strength for an RSA (Rivest-Shamir-Adleman) key is 2048 bits. Certificates must be generated with an RSA key of 2048 bits or higher.

Weak Hashing Algorithm

Algorithms once thought of as secure and unbreakable have become either weak or breakable. For example, MD5, RC4, etc

Weak Keys

Exhaustive key searches/brute force attacks are a danger to any secure network. As computational power increases, so does the need for stronger keys.

SSL Endpoint Vulnerabilities

How to do SSL protocol check

For general SSL checking of a website protocols in use: https://www.ssllabs.com/ssltest/analyze.html or: https://paranoidsecurity.nl/
The easiest way to amend (enable/disable) protocols in use is achieved by a tool called ”IISCripto” at https://www.nartac.com/Products/IISCrypto/

These are the IISCripto tool Features supported:

  • Single click to secure your site using best practices
  • Stop FREAK, BEAST and POODLE attacks
  • Easily disable SSL 2.0 and SSL 3.0
  • Enable TLS 1.1 and 1.2
  • Disable other weak protocols and ciphers
  • Enable forward secrecy
  • Reorder cipher suites
  • Templates for compliance with government and industry regulations – FIPS 140-2 and PCI

POODLE and TLS_FALLBACK_SCSV

We’ve been seeing a lot of requests to implement TLS_FALLBACK_SCSV. Unfortunately, it only works if you already have clients that understand it. This article will give some background, discuss TLS downgrades and finally have some suggestions for what you can do now.

Background
Over the years, cryptographers have worked with Internet engineers to improve the Transport Layer Security (TLS) protocol. Each revision of the protocol provides improvements to defend against the latest attacks devised by the cryptographers.
In 2011, Thai Duong and Juliano Rizzo demonstrated a proof-of-concept for attacks against the way SSL/TLS use the Cipher Block Chaining (CBC) mode of encryption. Their paper introduced the Browser Exploit Against SSL/TLS (BEAST) and used it to demonstrate how a “man-in-the-middle” (MITM) with the ability to run Javascript on the victim client could generate many thousands of TLS sessions and eventually recover a session cookie.
The defense against the BEAST attack was included in TLS 1.1, but few web servers or clients migrated right away.

POODLE is a similar attack to BEAST, but works against SSLv3 due to the special structure of the padding in SSLv3. Part of the POODLE attack is a downgrade to SSLv3.

TLS Downgrades
TLS agents should negotiate the highest version of the protocol supported by client and server. Clients advertise the highest version of the protocol they support. The server selects the highest version it supports, and sends the negotiated version number in the ServerHello message.

Many broken TLS implementations in widespread use were unable to cope with versions they did not understand. This caused large numbers of TLS sessions to break during the TLS 1.1 rollout.

The browser vendors implemented a downgrade mechanism. Immediately after a session fails during the initial handshake, the browser will retry, but attempt a max version one lower than before. After attempting to connect to a server with the max version set to TLS1.1, the client would retry with the max version set to TLS1.0.

Security researchers love automatic downgrades because they get to attack older protocols instead of newer, more secure protocols. A MITM attacker can break client connections during the initial TLS handshake, triggering a downgrade all the way to SSLv3.

Bodo Möller and Adam Langley devised Signaling Cipher Suite Value (SCSV) ,TLS_FALLBACK_SCSV, so the client can inform the server of a downgraded connection. It indicates to the server that the client had previously attempted to connect using a higher max protocol version, but the session was broken off before the initial handshake could be completed.

If the server sees the SCSV, and if it could have negotiated a protocol version higher than what the client is currently announcing as its maximum, the server must break the connection.

On October 21, Möller and Langley presented to members of the IETF TLS Working Group to lay out their rationale and argue for inclusion of the TLS_FALLBACK_SCSV draft in the upcoming revision to TLS.

The key points to their argument are presented on page 3:

Ideally, stop doing downgrade retries
If that’s not practical, clients should add TLS_FALLBACK_SCSV to ClientHello.cipher_suites in fallback retries
Servers that detect TLS_FALLBACK_SCSV will reject the connection if ClientHello.client_version is a downgrade

Möller and Langley implemented TLS_FALLBACK_SCSV in Chrome, Firefox, and Google servers earlier in 2014. During the past several months, they’ve had an opportunity to confirm that it allows SSLv3 connections only in cases where that is truly the highest common protocol version.

On October 15, OpenSSL for the first time integrated TLS_FALLBACK_SCSV code.

Upgrade your clients
The best protection against POODLE is to disable SSLv3. That is not always possible because of legacy clients. Unfortunately, TLS_FALLBACK_SCSV requires both clients and servers to implement it. Legacy clients will not send TLS_FALLBACK_SCSV. You must update the clients to newer code to get all the advantages of TLS_FALLBACK_SCSV.
If you can update all your clients to code that supports TLS1.x, then you can successfully disable SSLv3 from your BIG-IPs using either method described earlier.
If you can’t upgrade your clients, you can avoid POODLE by using SSL3’s RC4 stream cipher instead of a block cipher with CBC. Be aware that there are known weaknesses in RC4.

RC4 usage

Protocols:

  • SSLv2: Released in 1995. Most modern clients do not support SSLv2, but the DROWN attack demonstrated that merely serving SSLv2 enables the inspection of traffic encrypted with more modern TLS versions.
  • SSLv3: Released in 1996. Considered to be insecure after the POODLE attack was published in 2014. Turning off SSLv3 effectively removes support for Internet Explorer 6.

Ciphers:

SSLv3 POODLE mitigation recommendations

In our previous post, we discussed POODLE and legacy SSLv3 clients.
The best solution to POODLE is to disable SSLv3.
However, SSLv3 often can’t be disabled because legacy clients only speak SSLv3.
F5’s security teams have done some investigation, and we believe that using the RC4 can be used as POODLE mitigation for those legacy clients. RC4 is a stream cipher and is not vulnerable to the POODLE attack.
RC4 does have a known weakness. After hundreds of millions of messages, an attacker could recover the plaintext.
POODLE can recover information after only tens of thousands of attacks.
So even though RC4 is not recommended as a cipher, it remains more secure to use in SSLv3 sessions than AES-CBC.
If you cannot disable SSLv3, you may enable RC4-SHA only for use in SSLv3 sessions until you are able to replace all the legacy clients.
To configure your virtual server to only allow SSLv3 RC4-SHA, use a cipher string like the following:
“default:-RC4:-SSLv3:SSLv3+RC4-SHA”
“Default” sets the default ciphers, “-RC4″ removes any ciphers that contain RC4 (this is optional). “-SSLv3” removes any SSLv3 ciphers, but “SSLv3+RC4-SHA” re-enables only the RC4-SHA cipher from SSLv3. Any client connecting via SSL3 will be forced to use RC4 rather than a CBC cipher that is vulnerable to POODLE.
See SOL 13171 for information on setting your cipher string.
There are known attacks against RC4 that are better than brute-force. But given POODLE, RC4 is the most secure SSLv3 cipher.
It is still recommended to disable SSLv3 and RC4 once you are able to remove all legacy clients.

Who still needs RC4

At the time we had an internal debate about turning off RC4 altogether, but statistics showed that we couldn’t. Although only a tiny percentage of web browsers hitting CloudFlare’s network needed RC4 that’s still thousands of people contacting web sites that use our service.
To understand who needs RC4 I delved into our live logging system and extracted the User-Agent and country the visitor was coming from. In total, roughly 0.000002% of requests to CloudFlare use the RC4 protocol. It’s a small number, but it’s significant enough we believe we need to continue to support it for our customers.
Requests to CloudFlare sites that are still using RC4 fall into four main categories: people passing through proxies, older phones (often candy bar), other (more on that below) and a bucket of miscellaneous (like software checking for updates, old email programs and ancient operating systems).

Ciphers

Examining data for a 59 hour period last week showed that 34.4% of RC4-based requests used RC4-SHA and 63.6% used ECDHE-RSA-RC4-SHA. RC4-SHA is the oldest of those; ECDHE-RSA-RC4-SHA uses a newer elliptic curve based method of establishing an SSL connection. Either way, they both use the RC4 encryption algorithm to secure data sent across the SSL connection. We’d like to stop supporting RC4 altogether, because it is no longer believed to be secure, but continue to offer it for the small number of clients who can’t connect more securely.

If you ever need to know the details of an SSL cipher you can use the openssl ciphers command:

$ openssl ciphers -tls1 -v RC4-SHA
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1

which shows that RC4-SHA uses RSA for key exchange, RSA for authentication, RC4 (128-bit) for encryption and SHA1 for message authentication.

Similarly,

$ openssl ciphers -tls1 -v ECDHE-RSA-RC4-SHA
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1

shows that the same encryption, authentication and message authenitication are used as RC4-SHA but the key exchange is made using Elliptic Curve Diffie Hellman.

Inside RC4

One of the reasons RC4 is used for encryption is its speed. RC4 is a very fast encryption algorithm and it can be easily implemented on a wide variety of hardware (including phones with slow processors and even on 8-bit systems like the Arduino). After all, RC4 dates back to 1987.

The core of RC4 is the following algorithm:

i := 0
j := 0 
while GeneratingOutput:
    i := (i + 1) mod 256
    j := (j + S[i]) mod 256
    swap values of S[i] and S[j]
    K := S[(S[i] + S[j]) mod 256]
    output K
endwhile

It generates a pseudo-random stream of numbers (all 8-bit numbers in the range 0 to 255) by doing simple lookups in a table, swapping of values and addition modulo 256 (which is very, very fast). The output of that algorithm is usually combined with the message to be encrypted byte-by-byte using some fast scheme like an XOR.

The following short video shows the RC4 algorithm in action. It’s been restricted to 32 values rather than 256 to fit it nicely on the screen but the algorithm is identical. The red stream of numbers at the bottom shows the pseudo-random stream output by the algorithm. (The code for this animation is available here; thanks to @AntoineGrondin for making the animated GIF).

So, RC4 is fast, but who’s still using it? To answer that I looked at the HTTP User-Agent reported by the device connecting to CloudFlare. There were 292 unique User-Agents.

Who still uses RC4?

Firstly, lots of people using older “candy bar” style phones. Phones like the Nokia 6120 classic which was released in 2007 (and is the phone with the greatest number of RC4 requests to CloudFlare sites: 4% of the RC4-based requests in the measurement period), the Lemon T109 or the Sony Ericcson K310 which was released in 2006.

And, of course, it’s not all older telephones being used to visit CloudFlare-powered web sites. There are old browsers too. For example, we’ve seen the now ancient iCab 2.9.9 web browser (it was released in 2006) and we’ve seen it being used running on a 68k based Macintosh (last sold by Apple in 1996).

Another source of RC4-only connections is older versions of Adobe AIR. AIR is often used for games and if users don’t update the AIR runtime they can end up using the older RC4 cipher.

Yet another source is stand-alone software that makes its own SSL connection. We’ve seen some software checking update servers using RC4-secured connections. The software makes a connection to its own update server using HTTPS but the available ciphers are limited and RC4 is chosen. The command-line program curl was used to generate 1.9% of RC4-based requests to CloudFlare sites (all done with versions dating to 2009).

There’s also quite a bit of older Microsoft Internet Explorer around including Internet Explorer 5.01 (which dates back to 1999!). Here’s a breakdown of Internet Explorer versions connecting using RC4:

Looking at Windows tells a similar story of older version of the operating system (except for the presence of Windows 7 which is explained below) with lots of Windows XP out there:

I sampled connections using RC4 to see which countries they came from. The following mapping shows the distribution of RC4-based connections across the world (the darker the more RC4 was used).

From the map you can see that in Brazil, India, and across central Africa RC4 is still being used quite widely. But you’ll also notice that the coloring of the US indicates that a lot of RC4 is in use there. That seems like a surprise, and there’s an extra surprise.

Transparent SSL Proxies

Digging into the User-Agent data for the US we see the following web browser being used to access CloudFlare-powered sites using RC4:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/34.0.1847.137 Safari/537.36

That’s the most recent version of Google Chrome running on Windows 7 (you can see the presence in Windows 7 in the chart above). That should not be using RC4. In fact, most of the connections from Windows machines that we see using RC4 should not be (since we prioritize 3DES over RC4 for older machines).

It was initially unclear why this was happening until we looked at where the connections were coming from. They were concentrated in the US and Brazil and most seemed to be coming from IP addresses used by schools, hospitals and other large institutions.

Although the desktop machines in these locations have recent Windows and up to date browsers (which will not use RC4) the networks they are on are using SSL-based VPNs or firewalls that are performing man-in-the-middle monitoring of SSL connections.

This enables them to filter out undesirable sites, even those that are accessed using HTTPS, but it appears that the VPN/firewall software is using older cipher suites. That software likely needs updating to stop it using RC4 for secure connections.

What you can do

You can check the strength of your browser’s SSL configuration by visiting How’s My SSL. If you get a rating of “Probably Okay” then you’re good. If not make sure you have the latest browser version.

BEAST – (Browser Exploit Against SSL/TLS)

Block-based cipher suites are vulnerable to the BEAST attack. Older versions of the TLS protocol (1.0) and the SSL protocol (2.0 and 3.0) are vulnerable to the BEAST attack. To fix it you need to:
– Enable TLS 1.1 and/or TLS 1.2 on servers that support TLS 1.1 and 1.2.
– Enable TLS 1.1 and/or TLS 1.2 in Web browsers that support TLS 1.1 and 1.2.

BREACH (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext)

BREACH attacks are similar to the CRIME attack. Known as CVE-2013-3587, or Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) is an instance of CRIME against HTTP Compression. That is to say that CRIME attacked TLS SPDY whereas BREACH targets HTTP gzip/DEFLATE. Therefore turning off the TLS compression has no affect on BREACH as it exploits the underlying HTTP compression. The attack follows the basic steps of the CRIME attack and there are several methods to remediate the issue, such as disabling HTTP compression, protecting the application from CSRF attacks, randomising CSRF tokens per request to prevent them being captured, obfuscating the length of page responses by adding random amounts of arbitrary bytes to the response.
Web Server: Turn off compression for pages that include PII (Personally Identifiable Information).
Web Browser: Force browser not to invite HTTP compression use.
Web Applications:
– Consider moving to Cipher AES128.
– Remove compression support on dynamic content.
– Reduce secrets in response buddies.
– Use rate-limiting requests.

CRIME (Compression Ratio Info-leak Made Easy)

The Transport Layer Security (TLS) protocol contains a feature that allows you to compress the data passed between the server and the Web browser. TLS data compression is susceptible to the CRIME exploit. CRIME targets cookies over connections that use HTTPS protocol (Hyper Text Transfer Protocol with Secure Sockets Layer) and SPDY protocol (Web protocol from Google), which employ TLS data compression.
In a CRIME attack, the attacker recovers the content of secret authentication cookies and uses this information to hijack an authenticated web session. The attacker uses a combination of plaintext injection and TLS compression data leakage to exploit the vulnerability. The attacker lures the Web browser to make several connections to the website. The attacker than compares the size of the ciphertexts sent by the browser during each exchange to determine parts of the encrypted communication and hijack the session.
If you are vulnerable to the CRIME attack, the highest grade you can receive is a C. To resolve it:
– Disable server (website) TLS data compression and Web browser TLS data compression.
– Modify gzip to allow for explicit separation of compression contexts in SPDY.

FREAK (Factoring Attack on RSA-EXPORT Keys)

A team of researchers revealed that the old export-grade cryptographic suites are still being used today. Servers that support RSA export cipher suites could allow a man-in-the-middle (MITM) to trick clients, who support the weak cipher suites, into using these weak 40- and/or 56-bit export cipher suites to downgrade their connection. The MITM can then use today’s computing power to crack those keys in just a few hours.

To fall into this attack:
Server: The server must support RSA export cipher suites.
AND
Client: The client must do one of the following: (1) must offer an RSA export suite, or (2) must be using Apple SecureTransport, or (3) must be using a vulnerable version of OpenSSL, or (4) must be using Secure Channel (Schannel).

To fix it:
Server-Side: Disable support for all export-grade cipher suites on your servers. We also recommend that you disable support for all known insecure ciphers (not just RSA export ciphers), disable support for ciphers with 40- and 56-bit encryption, and enable forward secrecy.
Client-Side: Vulnerable clients include software that rely on OpenSSL or Apple’s Secure Transport (i.e., Chrome, Safari, Opera, the Android and the BlackBerry stock browsers), or Windows Secure Channel/Schannel (i.e. Internet Explorer). FREAK vulnerability patched in latest OpenSSL Release.

Heartbleed Bug

The cryptographic libraries in OpenSSL versions 1.0.1 through 1.0.1f and 1.0.2-beta1 are vulnerable to the Heartbleed Bug attack.
Solution is to Patch your software. Upgrade to the latest version of OpenSSL (version 1.0.1g or later).

Insecure TLS Renegotiation

The Secure Socket Layer (SSL)/Transport Layer Security (TLS) protocol contains a session renegotiation feature that permits a server and client to use their connection to establish new parameters and generate new keys during the session.
To fix it: Make sure your servers support secure negotiations by running current versions of the SSL/TLS protocol. Servers should not be running SSL 2.0, an outdated version of SSL that has known vulnerabilities.

Logjam Attack

Researchers found that old DHE export-grade cryptographic suites are still being used. They also discovered that servers with support for these DHE_EXPORT cipher suites enabled could allow a man-in-the-middle (MITM) to trick clients that support the weak DHE_EXPORT cipher suites into downgrading their connection to a 512-bit key exchange.

To fix it:
– Disable support for all DHE_EXPORT cipher suites on your servers.
– Generate a strong Diffie-Hellman Parameter, minimum 2048-bits.

BlueKeep (then BlueKeep II, III, IV, V aka DejaBlue)

BlueKeep (CVE-2019-0708) is a security vulnerability that was discovered in Microsoft’s Remote Desktop Protocol, which allows for the possibility of remote code execution. Identified May2019
Then few weeks later further flaws in RDP were found – (CVE-2019-1181 and CVE-2019-1182)
The RDP protocol uses “virtual channels”, configured pre-authentication, as a data path between the client and server for providing extensions. RDP 5.1 defines 32 “static” virtual channels, and “dynamic” virtual channels are contained within one of these static channels. If a server binds the virtual channel “MS_T120” (a channel for which there is no legitimate reason for a client to connect to) with a static channel other than 31, heap corruption occurs that allows for arbitrary code execution at the system level

How to Prevent and Fix BlueKeep

  • First and foremost action is to patch all of your Windows machines (user workstations, servers etc) with the patches released by Microsoft. Even non-supported versions (XP, Vista, 2003) have patches available here.
  • Block RDP port 3389 if not needed (using a network firewall or even the Windows firewall). Especially if port 3389 is accessible from the Internet, this is a huge mistake and you must either block it immediately or patch the system. Currently there are around 1 million unpatched windows machines on the Internet with exposed RDP port.
  • Enable Network Level Authentication (NLA) for RDP connections. NLA requires authentication therefore a possible worm will not be able to propagate to machines having NLA.
  • Similar to point 2 above, disabling Remote Desktop service (if it’s not required) will help to mitigate the issue.

To fix it: KEEP CALM AND START PATCHING – DO NOT RUSH but plan for it!
Permit me to remind you that BlueKeep itself hasn’t been reliably exploited. The threat is real, but it’s not viral or immediate.
Microsoft released patches for the vulnerability on 14 May 2019m valid up to WS2012
First, focus on patching externally facing RDP servers, then move on to critical servers such as domain controllers and management servers. Finally patch non-critical servers that have RDP enabled, along with the rest of the desktop estate. You can find more information on applying the patch from Microsoft’s support pages

RC4 Cipher Enabled

The BEAST attack was discovered in 2011. The solution to mitigating the attack is to enable TLS 1.1 and TLS 1.2 on servers and in browsers. Because RC4 is easy to implement and because of the BEAST attack workaround, the RC4 stream cipher’s use is widespread. One estimate says that RC4 may account for up to 50% of all TLS traffic. (back in 2014)
To fix it:
– Enable TLS 1.2 on servers that support TLS 1.2 and switch to AEAD cipher suites (i.e. AES-GCM).
– Enable TLS 1.2 in browsers that support TLS 1.2.

SSL 2.0 Protocol Enabled

“SSL 2.0 is an outdated protocol version with known vulnerabilities.”
SSL 2.0 protocol was disavowed in 1996 due to known security flaws, some servers are still using it. Servers still using the SSL 2.0 protocol should disable it.

SSL 3.0 Protocol Enabled

While the SSL 3.0 protocol is enabled, a MITM (man-in-middle-attack) can intercept encrypted connections and calculate the plaintext of the intercepted connections.
The most effective way to counter the POODLE attack is to disable the SSL 3.0 protocol.
Disable the SSL 3.0 protocol on the server and enable TLS1.1, and TLS1.2.

TLS 1.0 and TLS 1.1 Protocol Enabled

It’s Time to Disable TLS 1.0 (2019 onwards). Unless you need to support legacy browsers, you should also disable TLS 1.0 and TLS 1.1
Microsoft recommends customers get ahead of this issue by removing TLS 1.0 dependencies in their environments and disabling TLS 1.0 at the operating system level where possible (More details at https://docs.microsoft.com/en-us/security/solving-tls1-problem)
If you disable TLS 1.0 and TLS 1.1, the following user agents and their older versions will likely be affected (specific user agent versions on different operating systems may vary).

  • Android 4.3
  • Chrome 29
  • Firefox 26
  • Internet Explorer 10
  • Java 6u45, 7u25
  • OpenSSL 0.9.8y
  • Safari 6.0

SSL/TLS Best Practices (2019+)

Use Secure Protocols – TLS 1.1/1.2/1.3
Use at least 2048-Bit Private Keys
Protect Private Keys
Ensure Sufficient Hostname Coverage
Obtain Certificates from a Reliable CA
Use Strong Certificate Signature Algorithms – SHA256
Use Complete Certificate Chains
Use Secure Cipher Suites:

  • Anonymous Diffie-Hellman (ADH) suites do not provide authentication.
  • Cipher suites with a “NULL” only offer integrity check. They do not offer data encryption and are not secure for most usages.
  • Export cipher suites are insecure when negotiated in a connection, but they can also be used against a server that prefers stronger suites (the FREAK attack).
  • Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken.
  • RC4 is insecure.
  • 3DES is slow and weak.

Select Best Cipher Suites
Use Forward Secrecy
Use Strong Key Exchange
Mitigate Known Problems
Use Session Resumption – a performance-optimization technique
Avoid Too Much Security
Use WAN Optimization and HTTP/2
Cache Public Content
Use OCSP Stapling
Use Fast Cryptographic Primitives
HTTP and Application Security
Encrypt Everything
Eliminate Mixed Content
Understand and Acknowledge Third-Party Trust
Use Secure Cookies – Secure Cookie responce header
Secure HTTP Compression
Deploy HTTP Strict Transport Security – HSTS responce header
Deploy Content Security Policy – CSP header
Do Not Cache Sensitive Content
Consider Other Threats
Public Key Pinning (advanced)
DNSSEC and DANE (advanced)

Security Protocol Support by OS Version

Browsers

BROWSERSTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Mobile IE version 10 and below✓✗✗✗
Desktop IE versions 7 and below✓✗✗✗
Desktop IE versions: 8, 9, and 10✓PartialPartial✗
Desktop and mobile IE version 11✓✓✓✗
Microsoft Edge✓✓✓✗
Mozilla Firefox 22 and below✓✗✗✗
Mozilla Firefox 23 to 26✓PartialPartial✗
Mozilla Firefox 27 and higher✓✓✓✗
Google Chrome 21 and below✓✗✗✗
Google Chrome 22 to 37✓PartialPartial✗
Google Chrome 38 and higher✓✓✓✗
Android 4.3 (Jelly Bean) and below✓✗✗✗
Android 4.4 (Kitkat) to 4.4.4✓PartialPartial✗
Android 5.0 (Lollipop) and higher✓✓✓✗
Mobile Safari for iOS 4 and below✓✗✗✗
Mobile Safari versions 5 and higher for iOS 5 and higher✓✓✓✗
Desktop Safari versions 6 for OS X 10.8 (Mountain Lion)✓✗✗✗
Desktop Safari versions 7+ for OS X 10.9 (Mavericks)+✓✓✓✗

Desktop clients

Desktop ClientsTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Windows XP✓✗✗✗
Windows XP SP3✓✓✗✗
Windows Vista✓✗✗✗
Windows 7 SP1✓✓✓✗
Windows 8✓PartialPartial✗
Windows 8.1✓✓✓✗
Windows 10✓✓✓✗
MAC OS X 10.2 and 10.3✓✗✗✗
MAC OS X 10.4 and 10.5✓✗✗✗
MAC OS X 10.6 and 10.7✓✗✗✗
MAC OS X 10.8✓✗✗✗
MAC OS X 10.9✓✓✓✗
MAC OS X 10.10✓✓✓✗
MAC OS X 10.11✓✓✓✗
MAC OS X 10.12✓✓✓✗
MAC OS X 10.13✓✓✓✗
Linux✓✗✗✗

Mobile Clients

Mobile ClientsTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Airwatch✓✓Partial✗
Android versions: 1.0 to 4.4.4✓✗✗✗
Android versions: 5.0 to 8.1 and Android P✓✓✓✗
iPhone OS versions: 1, 2, 3, and 4✓✗✗✗
iPhone OS versions: 5, 6, 7, 8, 9, 10, and 11✓✓✓✗
MobileIron Core versions 9.4 and below✓✗✗✗
MobileIron Core versions 9.5 and higher✓✓✓✗
MobileIron Cloud✓✓✓✗
Windows Phone versions: 7, 7.5, 7.8 and 8✓✗✗✗
Windows Phone version 8.1✓✓✓✗
Windows 10 Mobile versions: v1511, v1607, v1703, and v1709✓✓✓✗

Servers

ServersTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Windows Server 2003✓✗✗✗
Windows Server 2008✓✗✗✗
Windows Server 2008 R2✓✓✓✗
Windows Server 2012✓PartialPartial✗
Windows Server 2012 R2✓✓✓✗
Windows Server 2016✓✓✓✗

Libraries

LibrariesTLS 1.0TLS 1.1TLS 1.2TLS 1.3
.NET 4.6 and higher✓✓✓✗
.NET 4.5 to 4.5.2✓PartialPartial✗
.NET 4.0✓✓Partial✗
.NET 3.5 and below✓✗✗✗
OpenSSL versions: 1.0.0 and below✓✗✗✗
OpenSSL versions: 1.0.1 and higher✓✓✓✗
Mozilla – NSS versions: 3.13.6 and below✓✗✗✗
Mozilla – NSS versions: 3.14 to 3.15✓✓✗✗
Mozilla – NSS versions: 3.15.1 and higher✓✓✓✗

Even more links

Links:
https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
https://www.acunetix.com/blog/articles/tls-ssl-cipher-hardening/
https://support.globalsign.com/customer/portal/articles/2934392-tls-protocol-compatibility
https://www.ssl.com/article/tls-1-3-is-here-to-stay/