Is there a list of old browsers that only support TLS 1.0?

Question

I am looking to Block all old browsers that support only TLS 1.0. Since TLS 1.0 is out of PCI Compliance, it is a safety measure that I want to take. But I am having trouble finding a list of these old browsers. Can anyone help?

You want to block them? By userAgent string? Why not simply disable TLS1.0 server side? — StackzOfZtuff, Jan 09 '18 at 19:28
Can you clarify whether you mean that you control the servers and want to prevent them from accepting connections to these old browsers? Or do you control workstations, and you want to make sure you've removed all old browsers? — Mike Ounsworth, Jan 09 '18 at 19:34
@StackzOfZtuff: Common sense would say he probably wants to find out how many browsers (=> users) would be impacted by such a change before actually making the change... — user541686, Jan 10 '18 at 07:12
@Mehrdad: Yes. But common sense would also say OP should mention that in the question... — sleske, Jan 11 '18 at 09:55
@sleske: That's literally the opposite of what you do when something is common sense. — user541686, Jan 11 '18 at 10:48

RedGrittyBrick · Answer 1 · 2018-01-11T15:23:12.647

53

I am having trouble finding a list [of old browsers that only support TLS 1.0]

Lists of browsers with specific features

Trouble finding a suitable list might be partly because such a list might be large, incomplete, frequently changing and might need to take account very large numbers of plugins and addons.

As Tripehound mentioned in a comment. A browser might not be on such a list because it has support for TLS 1.2 even if support for 1.1 and 1.2 is disabled by default. This makes relying on a list more risky.

Depending on what you are doing, you may not need a list of browsers (user agents?).

Predicting Impact of barring browsers that use TLS 1.0

If you need to work out how many of a server's customers rely on TLS 1.0 you can enable TLS version logging in Apache and probably in other webservers etc. After a suitable period (e.g. a week) you would have some good statistics about the number of customers affected.

Preventing use of insecure protocols by browsers

It is often possible to configure web-servers and other services to not support TLS 1.0 - thus blocking browsers that don't support more recent versions.

edited Jan 11 '18 at 15:23

answered Jan 09 '18 at 17:22

RedGrittyBrick

1,355
8
14

28

This is the most complete and most efficient way to handle this problem. Disable 1.0 on the *server* – schroeder Jan 09 '18 at 17:44
14

I would assume that the OP is trying to determine how large the impact would be of disabling 1.0 before throwing the switch. – Peter Green Jan 09 '18 at 19:47
3

@PeterGreen but then impact analysis should be done on the server, too. Look at the logs to see when TLS 1.0 is used and measure from that, not from a generic list. – schroeder Jan 10 '18 at 10:08
6

When TLS 1.0 is used isn't _necessarily_ the same as when it's the only option available. While, I suspect, most browsers that _can_ do better than 1.0 will be configured to do so, there may be some that could do better but aren't (currently) configured to do so. IIRC when IE first added the ability to do TLS 1.1/1.2, the options to use them were disabled by default (although later updates enabled them by default). – TripeHound Jan 10 '18 at 10:24
2

@TripeHound Since the client-initiated TLS handshake is the same for TLSv1/TLSv1.1/TLSv1.2 and allows the server to choose among the cipher suites supported by the client, the server should always be able to determine whether the client can support TLS > v1 unless the client is being intentionally evasive about it. For example, forcing cipher suite `AES256-GCM-SHA384` (defined in TLSv1.2) to be preferred over `AES256-SHA` (defined in SSLv3/TLSv1) on the server side will always end up choosing `AES256-GCM-SHA384`, proving the client supports TLSv1.2. – Christopher Schultz Jan 10 '18 at 21:18
Your point about "support" versus "being enabled" is, however, well taken because there are many TLSv1.2-capable MSIE installs out there where TLSv1.1 and TLSv1.2 are simply disabled in configuration – which is a crying shame. – Christopher Schultz Jan 10 '18 at 21:19

jcaron · Answer 2 · 2018-01-10T10:24:27.980

34

You can use our good friend Can I Use, which tells us that TLS v1.1 is supported since:

Chrome 22
Firefox 24
IE 11
Safari 7
Opera 12.1
iOS Safari 5.1

Global support is 95.61%. It may vary a bit based on your target markets.

So disabling TLS v1.0 would mean rejecting HTTPS from a bit over 4% of browsers out there.

You probably want to compare against your own Analytics for the business impact on your own site.

Note that there are lots of other parameters that affect security, including ciphers and various other settings.

Mozilla published several TLS profiles with varied compatibility/security tradeoffs. There's also a tool that will provide the TLS server configuration for each of these profiles (for Apache, Nginx, HAProxy).

The highest security ("modern"), but lowest compatibility, has its cut-off point at Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8.

The intermediate level has its cut-off point at Firefox 1, Chrome 1, IE 7, Opera 5 and Safari 1 (but doesn't support Windows XP).

Of course, the latest and greatest also needs support server-side!

edited Jan 10 '18 at 10:24

answered Jan 10 '18 at 10:18

jcaron

3,365
2
15
22

Actually if you not the flags, some of them can be enabled, so to say IE 11 doesn't support it seems disingenuous. – AncientSwordRage Jan 11 '18 at 09:43
2

@Pureferret, I'm not saying IE11 doesn't support it, I'm saying it is supported since IE11. It can indeed be enabled on older versions of IE, but one usually cares about the impact on the general public who won't go change flags and settings, using it as it is configured "out of the box". The 3 versions of IE on which this could be done represent about 0.54%, so I'm not sure they matter anyway. – jcaron Jan 11 '18 at 09:55
1

@Pureferret we still don't know what the OP actually wanted though... Know the browsers which will be affected before stopping TLS 1.0 or know how to block those browsers, so we're just speculating... – jcaron Jan 11 '18 at 10:01
+1 for the very useful "Can I Use" list, but for the metrics, I would emphasise that "It may vary a **lot** based on your target markets.". We don't know if OP is talking about a worldwide or region-specific service (Asia metrics differ greatly from Western Europe as instance), if he's targeting specific audiences, etc. – zakinster Jan 11 '18 at 11:42
In most cases the metrics are quite similar, though there seems to be a big exception for China. But as stated, the ideal thing is to use one's own site analytics based on the list of browsers. A site targeted to US security aficionados will of course not have the same results as a site targeted to Chinese grandmothers :-) – jcaron Jan 11 '18 at 11:49
Ironically, the CanIUse website itself [does not support TLS v.1.1](https://github.com/Fyrd/caniuse/issues/4198). – Nic Oct 15 '18 at 18:28

score 12 · Answer 3 · edited Jun 16 '20 at 09:49

Try the SSL Labs list

SSL labs has an HTML list.

They also offer a nice JSON list. TLS 1.0 seems to be encoded as highestprotocol being 769.

Using PowerShell you can parse it like so:

PS C:\> Invoke-WebRequest -Uri https://api.ssllabs.com/api/v3/getClients -OutFile getClients.json
PS C:\> Get-Content .\getClients.json | Out-String | ConvertFrom-Json | foreach {$_ | select *} | where {$_.highestprotocol -like "769"
} | select name, version, useragent, highestprotocol | sort name, version, useragent

name        version     userAgent
----        -------     ---------
Android     2.3.7       Mozilla/5.0 (Linux; U; Android 2.3.7; en-us; Genymotion ('Phone' version) Build/GWK74) AppleWebKit/533.1 (KHTML, like Gecko) Ver...
Android     4.0.4       Mozilla/5.0 (Linux; U; Android 4.0.4; en-us; Android SDK built for x86 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Vers...
Android     4.1.1       Mozilla/5.0 (Linux; U; Android 4.1.1; en-us; Nexus S - 4.1.1 - API 16 - 480x800 Build/JRO03S) AppleWebKit/534.30 (KHTML, like Ge...
Android     4.2.2       Mozilla/5.0 (Linux; U; Android 4.2.2; en-us; Nexus 4 - 4.2.2 - API 17 - 768x1280 Build/JDQ39E) AppleWebKit/534.30 (KHTML, like G...
Android     4.3         Mozilla/5.0 (Linux; U; Android 4.3; en-us; Nexus 4 - 4.3 - API 18 - 768x1280 Build/JLS36G) AppleWebKit/534.30 (KHTML, like Gecko...
Baidu       Jan 2015    Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
BingBot     Dec 2013
BingPreview Dec 2013
BingPreview Jun 2014    Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b
Firefox     10.0.12 ESR
Firefox     17.0.7 ESR
Firefox     21
Firefox     21
Firefox     22
Firefox     24
Firefox     24.2.0 ESR
Firefox     26
Googlebot   Jun 2014    Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Googlebot   Oct 2013
IE          10          Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 925)
IE          7
IE          8
IE          8
IE          8
IE          8-10
IE          8-10        Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
IE          9
Java        6u45
Java        7u25
OpenSSL     0.9.8y
Opera       12.15
Safari      5.1.9
Safari      6.0.4
Tor         17.0.9
Yahoo Slurp Oct 2013
YandexBot   May 2014

(No idea about the double entries for e.g. IE 8.)

Update: Cipher redirect

Not sure if this is what you’re after, but if this is about providing a nice error message to non compliant clients you may be interested in this old answer of mine: https://serverfault.com/a/644167/253701

That list is inaccurate/incorrect because the TLS version used isn't solely dependent on the browser. More specifically, IE 10 and lower will use the maximum TLS version supported/enabled by the operating system and *can* have TLS 1.2 enabled but will not do so by default. Likewise, older versions of Java (OpenJDK 7?) supported TLS 1.1 and 1.2 but did not have it enabled by default - presumably specific applications and configurations would have it enabled. — Bob, Jan 10 '18 at 00:42
@Bob Perfect answers are unlikely to be necessary here. As someone pointed out, to achieve PCI compliance you just disable TLS 1.0. More likely the question is about the impact of disabling TLS 1.0, which only requires a good answer, not a perfect one. — Steve Sether, Jan 10 '18 at 15:11
Try `invoke-restmethod` some day. Could save you some typing for json parsing. — n0rd, Jan 10 '18 at 20:08

score 5 · Answer 4 · edited Jan 11 '18 at 07:20

As others already wrote, why do you want that list? If it is for testing that your site correctly blocks TLS 1.0, you can e.g. use FireFox and in about:config set both security.tls.version.min and security.tls.version.max to 1.
Now Firefox will only accept TLS 1.0 and should be blocked if you use it to access your site.

I assume other browsers have similar settings.

Reference

score 4 · Answer 5 · answered Jan 09 '18 at 17:11

4

This Knowledge Article from SalesForce lists out the major browsers' TLS support well.

answered Jan 09 '18 at 17:11

waltonob

399
2
9

1

To be fair, the question asks for a list, and posting that list here is not very useful. Although the answer is to not use a list, this reasonably answers the question. – schroeder Jan 10 '18 at 10:10

score 3 · Answer 6 · answered Jan 10 '18 at 11:25

To improve cipher security, you shouldn't just block certain user agent strings, since the client (or maybe even a middleman) can force a ciphersuite downgrade in newer browsers as well, and browsers can send bogus user agents. Don't trust the client.

The secure way is to block TLS 1.0 traffic completely. But it would not be very user-friendly to do that and let the browser handle the error message.

What you want to do is allow establishing a connection, but check the agreed ciphersuite before delivering any content over it, and if TLS 1.0 is used, display a descriptive error page. ("The connection is insecure, most probably your browser is too old.") Whether reading the ciphersuite of a https connection is possible in the webserver software you use, I cannot say.

Timlukas B. · Answer 7 · 2018-01-11T09:30:42.760

Although I agree with the other answers that disabling TLS 1.0 server-side is the best way to shut it off and that the server logs are best suited to measure the impact, knowing what your excluding from your webservice is important, as you may have special use-cases.

Can I Use and SSL Labs have already been mentioned, but I'd like to add Wikipedia to the list. In my experience it's one of the most complete lists when it comes to SSL/TLS browser compatibility.

Also don't forget to disable unnecessary cipher suites. This might already fulfill security needs, without disabling a complete protocol version. When turning off TLS 1.0 you should also disable cipher suites that only work with it.

Before disabling (or enabling) anything be sure to know what you're doing. Always read recommendations before changing things and make sure to test your configuration.

score 0 · Answer 8 · answered Oct 09 '19 at 22:03

The university of Warwick in the UK made a great help page on this, it has lists of what devices will and will not work after removing TLS 1.0 and 1.1. Have a look:

https://warwick.ac.uk/services/its/servicessupport/web/sign-on/help/tls1-eol/

They have sub pages at the top for each OS and what's supported.

In most cases, running Firefox or Chrome will get you new SSL, even on old devices/OS's. Otherwise, the TL;DR is that Windows 7 and XP remain unsupported, Windows 8 works with IE11 installed. Mac OS Sierra (10.12) and later works with safari. iOS 9+ works, older ones do not. Android 5.0 Lollipop and later works, Kitkat and older do not.