Talk:TLS/SSL support history of web browsers

sectioning the table

I spent quite a bit of time fixing up and updating the table to actually fit on screen and be readable. Please don't revert and change things drastically without discussion. With regard to specific changes:

• drop strikeout in non-mixed cells -> good idea
• reverting 2003 / Vista merge -> No, they were not different. They are different now, because an intermediate color has been added.

 -> before merge/remove cells make sure they are not needed again in near future due to upcoming known changed like in this case EOS of 2003. Also notes @SHA-2 do not fit to Vista

• addition of peach color for still supported but nearly EOL stuff -> good idea, but need to be careful here as the timeframe specified would consider all more iterative release schedules to have this coloring -> I'm going to change this to explicitly say "long-term support", as that's what we're actually talking about here. -> good idea
• dropping of vendor names -> No. I'm going to add those back, and they have to stay in some form, for the following reasons:

 1) Consistency. Listing "Mozilla Firefox" but just "Internet Explorer" is not consistent and potentially confusing. Dropping the "Mozilla", as was the latest change, resolves this issue, however I do not believe it is the best solution.
 2) Google Chrome can never be safely referred to as just "Chrome". The word "chrome" is a pre-existing technical term used in all browsers' internals. It's roughly equivalent to if Ford named their next car the "Ford Vehicle". The full name needs to be there.
 3) Built in browsers, namely Safari, Internet Explorer, and whatever Android has, need to name their vendors as they tend to hide them. Likewise, both IE & Spartan should be prefixed with "Microsoft" for those who have never heard of Spartan.
 4) There is lots of space available. Listing the full names makes things more clear and does not impact table size.
 Now, formatting the vendor+name cells differently is entirely reasonable, but both need to be in there for everyone. (with Opera obviously being the oddity without a separate vendor & name)

• Why on Earth is the Spartan entry such a mess now?

 1) There are still plenty of unknowns; you can't assume things yet.
 2) Double-listing Spartan is a very messy solution to the possibility of having different configuration options on mobile. Additionally, Microsoft is attempting to blur the line between mobile and desktop versions, so attempting to draw a hard line, especially at this early stage, is not a good idea.

96.245.254.195 (talk) 20:04, 27 April 2015 (UTC)

Spartan

Microsoft Spartan has cells it needs to have as "unknown" until there's something to cite otherwise. Technically, the "Yes" cells all need "citation needed", but assumption of TLS 1.x with vuln fixes is reasonable, as IE11 has the same. SSL & RC4 are both prohibited by the IETF (SSL3 RFC is still in queue; just yet to be released), so I think Microsoft should be given the benefit of doubt with "unknown" listings until known for sure otherwise. It's safe to assume that SSL2 and SSL3 are unknown, but deserving of green, but that's still unknown. (either "No" or "Disabled by default", but we don't know which yet) Specifics from a cited source are desired to update these fields. 96.245.254.195 (talk) 20:51, 27 April 2015 (UTC)

Suggestions to sort the Spartan mess:

1) obey SChannel. IE11 @W10 is not same like IE11 @W8.1 (refer to RC4@ IE11 @W7 vs W8.1) / Vice versa, IE11 @W10 and Spartan @W10 use same SChannel.

2a) Proposal 1, one row for Spartan @W10 and one for IE11, no rowspan. And copy Windows 10 also to mobile section

Browser	Version	Platforms
Microsoft Internet Explorer	11	Windows 10
Microsoft Spartan	"Spartan"	Windows 10

2b) Proposal 2, merge 1st column (Browser) IE+Spartan and add "IE" to all Versions if not Spartan (or vice versa Spartan's final name once known) and copy Windows 10 also to mobile section

Browser	Version	Platforms
Microsoft Internet Explorer and Microsoft Spartan	IE 11	Windows 8.1
		Server 2012 R2
	IE 11	Windows 10
	"Spartan"

2c) Proposal 3, to solve issue that Windows 10 might will be identical on desktop and mobile merge 1st column (Browser) IE+IE mobile+Spartan, add "IE" to all Versions if not Spartan (or vice versa Spartan's final name once known) and move/sort IE mobile above to normal IE Versions. Than only one row for Windows 10 needed.

Browser	Version	Platforms
Microsoft Internet Explorer Microsoft Internet Explorer Mobile Microsoft Spartan	IE (mobile) 11	Windows Phone 8.1
	IE 11	Windows 8.1
		Server 2012 R2
	IE 11	Windows 10
	"Spartan"

Prop 2b feels like it may turn out to be the best idea eventually, if Spartan is mostly just a new UI with rebranding. That said, until it's much further along in the dev process, keeping it completely separate as in 2a is probably the best route. What I'm most concerned with is mixing it in such that it's hard to draw a line and say which has what capability. (yeah, I know, the way MS does browsers, this is by design) For now, moving Spartan up in the middle of desktop/mobile is good. If it turns out that Spartan has a significant difference on mobile, in spite of MS trying to blur the two, then we should call it Spartan Mobile just like we do for IE. (main culprit is lack of config option) The 2c option feels likely to be confusing.

I think we should probably both resist the urge to prettify the tables and merge together too much with Spartan, if just because the wiki table markup is a damned pain in the ass. ;)

WRT SChannel, yeah, handling that is needed. Adding some references for SChannel versions might be a good idea, if available, so they are explicitly cited to be different where needed. This problem pops up all over the table; we're listing browsers when the libs are what mostly matters. If NSS were listed separately, Firefox, Google Chrome, and pos-Presto Opera would make a lot more sense than just the "except Windows" notes. That's not really fixable in this table, though, so I guess just being more verbose (vertically) is what's needed to qualify things.

96.245.254.195 (talk) 18:29, 29 April 2015 (UTC)

Firefox 37 and TLSv1.0

Firefox 37 disabled TLS fallback by default with bug fix 1084025. In order to reduce the impact with "TLSv1.2-intolerant" servers, the record protocol is specified as TLSv1.0 even though the handshake protocol remains TLSv1.2. Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1084025

Testing various browsers with servers that can gracefully downgrade to TLSv1.0 shows that by default Firefox version 37 will not downgrade the handshake protocol to support TLSv1.0. In fact, Firefox version 37 by default cannot connect to a WebLogic 9.2 server, which supports TLSv1.0 but no higher. Further testing shows that when Firefox 37 is connected to servers that handle TLSv1.2, the browser will show that connection is using TLSv1.0 because the record protocol is set to TLSv1.0 even though the handshake protocol used is TLSv1.2 when observed via wireshark. Chris qwertysdfgjassdfassl (talk) 22:54, 28 April 2015 (UTC)

Firefox 37+ can connect servers which only support TLS 1.0.

• e.g. [1]: login page of UC Card (Japanese credit card company), which supports TLS 1.0/SSL 3.0
• e.g. [2]: login page of Mizuho Bank, which supports TLS 1.0/SSL 3.0

In addition, Bug 1084025 disabled "insecure" fallback to TLS 1.1/1.0, not fallback itself to TLS 1.0 (change the default value of security.tls.version.fallback-limit from 1 to 3). If you want to change status of TLS 1.0 on Firefox 37 from "Yes" to "Disabled by default" or something like that, you should also change the status of TLS 1.1 as same as TLS 1.0. --Claw of Slime (talk) 02:29, 29 April 2015 (UTC)

Realistically, we should add a new column for insecure version fallback. This has nothing to do with using TLS versions. It's merely about completely broken server implementations that can't follow the spec to negotiate versions properly. Mozilla used to do the downgrade dance to hack around it, as others do, but this process is woefully insecure and needs to die. Firefox is currently using a whitelist for certain sites that need insecure fallback or RC4, but that will be phased out eventually.

This will sadly end the short reign of the actually-fitting-on-the-screen table, but do what must be done. :'(

96.245.254.195 (talk) 18:24, 29 April 2015 (UTC)

That said, researching all browsers' insecure fallback history and properly filling in that column sounds like a PITA that may not be worth it. I'm fine with just leaving it off of the table entirely, possibly sticking it in a footnote that does not otherwise alter the status of any of the cells in the table. Again, specification compliant TLS version fallback works fine; it's just hack-around insecure version fallback that's going away. 96.245.254.195 (talk) 18:36, 29 April 2015 (UTC)

Can you describe the difference between "insecure" fallback versus "secure" fallback? I understand how secure renegotiation works, which takes place after the Finished message, but I don't see any methods of "secure" fallback from TLSv1.2 to TLSv1.0. In the first example you provided, it appears that the server is simply ignoring the handshake protocol version in the client hello message. Chris qwertysdfgjassdfassl (talk) 22:35, 30 April 2015 (UTC)

Insecure fallback isn't in the TLS spec. Secure version negotiation is done via the version proposed in the ClientHello message. The server picks the lower of ClientHello.client_version or the server's maximum supported version. This has been in there since SSL3, however entirely too many servers didn't implement this properly. When receiving an offer for TLS 1.0, instead of falling back to SSL3 it would reject the connection entirely. This is likely the primary reason IE6 had TLS 1.0 off by default forever. The TLS 1.0 situation is now largely fixed, but we have the same problem with TLS 1.2. If a client proposes TLS 1.2, and the server doesn't know what that is, instead of simply falling back to the highest version it supports (usually TLS 1.0), it chokes and aborts the connection. This is a direct violation of the spec, but it happens with astonishing frequency. Most sites have fixed this issue, but then there is a pending equivalent problem with TLS 1.3 (which is likely to be hacked around at the protocol level). Some server implementers are sloppy. This type of brokenness is called TLS version intolerance.

Insecure version fallback is sometimes called "the downgrade dance". Every browser was sadly forced to implement a version of this. In the event that a server returns any error instead of a working connection, the client then lowers its proposed version by one and offers again. Fail with TLS 1.2, then ask with TLS 1.1; fail with that, then try again with TLS 1.0. Firefox recently added a step in the middle to fall back to adding RC4 on one of them to cope with badly configured servers. Sometimes you may also need a step at the end to deal with servers that break when any TLS extensions are proposed. Again, that shouldn't happen, but it does. This (air quotes) "fixes" (air quotes) the problem, but is of course vulnerable to a downgrade attack. All an attacker needs to do to force a connection to use the worst security possible is to break the early connection attempt(s). The browser interprets this brokenness as a reason to try again with junk, and it does so. A hack around this is SCSV, but that's not exactly ideal either. With SSL3 and RC4 being taken out back and shot, insecure fallback, which should never have existed is too being phased out. It's horrible, and everyone always knew that. Killing it involves horribly broken servers actually breaking, though. Mozilla is going with a whitelist at first for this one too. Servers are actually getting fixed, which might surprise you, but the rate is nowhere near enough to expect no end-user breakage. Unfortunately, users end up blaming the browser instead of the server that doesn't support any security protocols from the current century, or even properly implements the one from 1999.

96.245.254.195 (talk) 23:24, 30 April 2015 (UTC)

Thank you for the explanation, it is very helpful. It does beg a few more questions:

1. If the client continues to handle a server initiated fallback anyway (as we see in the first example you provided), how does disabling the client initiated downgrade dance make it any less vulnerable to a MITM attack? Can't an attacker simply change the version in the client hello message?
2. Won't a MITM attacker be able to remove the SCSV from the client hello message cipher suites? (I don't see SCSV in Firefox 37's client hello message cipher suites anyway, but I'm curious to know how much it would really help.)

Chris qwertysdfgjassdfassl (talk) 01:47, 1 May 2015 (UTC)

Good question, as it's not really explained in the spec up front, but it is very much covered. (I think everyone reading it takes a bit to see it at first) The initial messages are of course in the clear, not authenticated, and could be tampered with via MitM. The handshake is not considered safely complete until the Finished message is verified. This verification is based on a hash of all handshake messages for this connection. As a result, if any message was tampered with mid-flight, the endpoints will have different hashes and the verification will fail. (e.g. change a bit in the ClientHello, and what the server sees will differ from what the client knows it sent; the hashes each compute will not be the same) This retroactively verifies the integrity of the connection. It is entirely possible to MitM to break things to prevent it from finishing successfully, but that's already possible if the attacker can MitM the connection like that. (e.g. the attacker could just null-out or outright drop packets if it just wants to cut the connection) The result of this is that either the connection succeeds with assurance that it was not tampered with, or it fails and the endpoints report a security error.

96.245.254.195 (talk) 17:22, 1 May 2015 (UTC)

Right, the hashes make the difference. Makes perfect sense, thanks.

Chris qwertysdfgjassdfassl (talk) 18:02, 1 May 2015 (UTC)

ECDSA

How about to add a column which show what browser supports ECDSA and which not ? (like SHA-2 Support)

2003:4C:6E26:9A00:409:EB8B:AC88:CA1F (talk) — Preceding undated comment added 16:46, 9 June 2015 (UTC)

ECDSA Column need some more evidence since when which browser / OS supports it. Cloudflare FAQ is not a good source cause merge ECDSA+SNI

Needed evidence:
Chrome up to 42
Android up to OS v4.04
Firefox up 31.2
IE Mobile 7,9 (WP 7-7.8)
Opera: any
Safari Windows
Safari up to 6 (OS X 10.5)
Safari up to 6 (iOS 5)

I suggest to keep cells, that currently contain (mixed) browser/OS versions, which have currently no evidence for ALL versions in this cell, marked as unknown.
So if more evidence found for all versions in this cell or for version above, such cell do not need to split for different ECDSA info.

--84.131.226.36 (talk) 19:23, 12 June 2015 (UTC)

Chrome and Opera(Chrome based) as well as Safari the ECDSA Certificate supports also depend on OS Version.

some sources https://support.globalsign.com/customer/portal/articles/1995283-ecc-compatibility https://www.tbs-certificates.co.uk/FAQ/en/limitations_techniques_certificats_ssl_ecc.html

--2003:4C:6E04:A900:894C:7FF7:4D70:6093 (talk) 19:47, 12 June 2015 (UTC)

SNI

I think there there should also be a SNI compatibility column,right ? Cause SNI, SHA-2 and ECC will affect if a browser can connect a server or not, while EV is only an add-on info.

--2003:4C:6E0C:D700:8443:B87C:4107:B1B0 (talk) 19:47, 15 June 2015 (UTC)

This template already have many columns and new column for TLS 1.3 will be added in near future. I cannot agree to add column for SNI. Yes, EV is an add-on of TLS, however, whether supporting EV or not is a big issue for web browsers (In past, Paypal would block web browsers which do not support EV, including Safari). Support of SHA-2 and ECC is also essential for web browsers (there are many news about these), but SNI is not mentioned not so many times. --Claw of Slime (talk) 12:16, 16 June 2015 (UTC)

I agree that there is a space issue but maybe we could decrease the space used by SSL 2 - TLS 1.2 columns cause they mostly do not have additional infos. SNI might grow due to ipv4 shortage and servers cannot use ipv6 only cause not all clients can support this (by software/hardware or ISP) And if browser do not support SNI it is a show-stopper like e.g. missing TLS 1.1/1.2 support of browser if server disabled old SSL and TLS 1.0 e.g

(color depends on if it is save or not like currently already used)
green/red "N" (or X) for "no"
green/red "Y" for "yes"
green/yellow "D" for "disabled by default"
red "E" for "enabled by default"
grey "?"

That would save a lot of space. Of course there should be a legend below the table

TLS/SSL support history of web browsers

Browser	Version		Platforms	Protocols						Certificate Support			SNI	Vulnerabilities fixed						Protocol selection by user
				SSL		TLS
				2.0	3.0	1.0	1.1	1.2	1.3	EV	SHA-2	ECDSA		BEAST	CRIME	POODLE (SSLv3)	RC4	FREAK	Logjam
TEST	TEST		TEST	N	E	Y	D	D	?

--2003:4C:6E0B:E00:8828:F417:D530:72ED (talk) 17:34, 17 June 2015 (UTC)

Firefox 39 vs RC4

Firefox 39 seems not to close RC4 except whitelisted
You still can open https://rc4.serverhello.com/ with FF 39
It only warn about broken encryption like written in
https://bugzilla.mozilla.org/show_bug.cgi?id=999544
So https://www.mozilla.org/en-US/firefox/39.0/releasenotes/ might be wrong
— Preceding unsigned comment added by 79.197.123.188 (talk) 18:14, 3 July 2015 (UTC)

--2003:4C:6E12:9A00:51F7:90D1:C990:8DBF (talk) 18:13, 3 July 2015 (UTC)

rc4.serverhello.com is NOT listed on
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc but is accessable by Firefox 39

--2003:4C:6E57:1C00:B094:9766:66C8:C3DA (talk) 08:16, 4 July 2015 (UTC)

Firefox 43 RC4 whitelist has been reverted

Update: This change has been reverted because the UI that allows temporarily using RC4 is not ready yet.

— https://www.fxsitecompat.com/en-US/docs/2015/rc4-is-now-allowed-only-on-whitelisted-sites/

--emk (talk) 10:52, 30 October 2015 (UTC)

Thank you for providing information. I have added this article as the an reference. --Claw of Slime (talk) 23:25, 1 November 2015 (UTC)

SHA-1 deprecation

should there be a SHA-1 collumn (red if supported without warning/green yellow if warn/green when block ?)
https://googleonlinesecurity.blogspot.de/2015/12/an-update-on-sha-1-certificates-in.html
https://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
--80.129.6.102 (talk) 17:17, 20 December 2015 (UTC)

To save columns, how about to merge SHA-1 and SHA-2 and do something something like e.g:

Brower	SHA-1/2
BrowserVersion A	SHA-1 only
BrowserVersion B	SHA-1+SHA-2
BrowserVersion C	SHA-2 only

80.129.4.130 (talk) 15:07, 28 June 2016 (UTC)

TLS 1.3

TLS 1.3 release will happen soon. Time to add a TLS 1.3 column to browser history table ? What do you think ? 80.129.14.67 (talk) 17:21, 22 June 2016 (UTC)

Good idea. I have added TLS 1.3 column.[3] --Claw of Slime (talk) 23:55, 22 June 2016 (UTC)

SWEET 32

How about to add a new column for "Sweet 32" behind Logjam ? https://sweet32.info/ https://www.openssl.org/blog/blog/2016/08/24/sweet32/ --84.131.227.217 (talk) 18:06, 24 August 2016 (UTC)