1126620 - (TLS-Intolerance) [META] TLS 1.1/1.2 version intolerant sites

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Dave Garrett]

Bug 1084025 disables insecure TLS version fallback and bug 1114816 adds a whitelist to compensate for broken sites which still need it due to TLS version intolerance. This meta-bug is to organize the various bugs filed for individual servers on the topic.

Starting with dependencies of the bugs noted in the current whitelist patch. Filing new TE bugs for every broken site on the Internet would probably not be productive, but bugs for high-visibility sites might be useful.

Comment 1

[Dave Garrett]

A quick way to test if an individual site connectivity issue is the result of TLS version intolerance is to run it through: https://www.ssllabs.com/ssltest

Once complete, scroll down to the "Protocol Details" section of the test results. Both TLS version and extension intolerance are tested for. If the domain is intolerant to TLS 1.1 or 1.2, then this meta-bug is applicable.

Comment 2

[Kohei Yoshino [:kohei]]

Tweeted: https://twitter.com/FxSiteCompat/status/560257529813692416

Comment 3

[Yuhong Bao]

Due to TLS 1.1/1.2?

Comment 4

[Takanori MATSUURA]

What is the deadline for whitelisting for released version?

I found one airline website has this issue and contacted to the customer support.
This issue is under consideration in the company. So I would like to report the site only when they miss the deadline.

Comment 5

[Dave Garrett]

(In reply to Takanori MATSUURA from comment #4)
> What is the deadline for whitelisting for released version?

There is no official timetable yet. In fact, the current nightly only has a small list and the full list has yet to land. (see bug 1128227) After that lands it'll be uplifted to Aurora, and around February 24th it'll probably go to beta. Beta gets fewer updates, but major sites could still be added (assuming the maintainer permits it). The week of April 7th would be final release unless it gets held back. I would guess the last realistic time to amend the list prior to release would be in late March.

> I found one airline website has this issue and contacted to the customer
> support.
> This issue is under consideration in the company. So I would like to report
> the site only when they miss the deadline.

I would recommend filing a TE bug (same product as this bug) and set it to block this bug. It gives the company a place to be pointed to and reply. It has been known to help get things done more easily in the past, though all too often they just track the fact that the company never followed up on the report. Just put in your description the fact that you already attempted contact and are waiting on a resolution prior to requesting whitelisting. That's always preferred if possible.

Comment 6

[Takanori MATSUURA]

Thanks Dave.
Filed as bug 1129773.

Comment 7

[Takanori MATSUURA]

One more question.

When is the hard-coded whitelist (by bug 1129773) removed?
Announce of the date removing whitelist may be required especially for maintainer for the listed websites.

Comment 8

[Dave Garrett]

The patch in bug 1128227 also has a script to auto-prune the list which will be run periodically by the maintainer. Domains which are updated to no longer need the list (or start to break with the list) will be removed and the list will shrink over time. I don't think anyone knows how long it will be until it is small enough to warrant removal. I would expect they would also want telemetry to know how commonly it is used.

I think the idea of requiring a warning page and user confirmation before doing an insecure fallback is still under consideration, and might be done at some point in the future when the list gets smaller. (or possibly in direct response to a new exploit)

My best guess is that the whitelist has a good chance of staying in use for at least the rest of this year, but that is only a wild guess. I would recommend acting like it could go away at any time. It's not a fix; it's a workaround for horribly broken servers that need to be upgraded.

Comment 9

[Karl Dubost💡 :karlcow]

Probably another one. 
https://webcompat.com/issues/706

Comment 10

[Masatoshi Kimura [:emk]]

(In reply to Karl Dubost :karlcow from comment #9)
> Probably another one. 
> https://webcompat.com/issues/706

Actually it is a fallout from bug 1124039. The site is TLS tolerant but RC4 or Camellia only. Could you file a evangelism bug and block bug 1124039 to track this?

Comment 11

[:Cykesiopka]

(In reply to Masatoshi Kimura [:emk] from comment #10)
> (In reply to Karl Dubost :karlcow from comment #9)
> > Probably another one. 
> > https://webcompat.com/issues/706
> 
> Actually it is a fallout from bug 1124039. The site is TLS tolerant but RC4
> or Camellia only. Could you file a evangelism bug and block bug 1124039 to
> track this?

I filed Bug 1137444.

Comment 12

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: fx37b2_tls_intolerant_sites.txt

I ran a compatibility test of Fx37b2 against Fx36.0.1 to look for any potential site breakage. I used the Pulse top SSL site list of around 200k domains. 

This attached list contains an additional 88 sites that are all most likely TLS intolerant and will break in Fx37b2. This is in addition to the site lists that I posted as attachments to bug 1084025. I have not checked all of them - just a handful - but they seem to fail for related reasons. Obviously some of these sites are not being maintained at all and may not respond to requests to upgrade their SSL stack, but I am providing this list anyway.

Comment 13

[Masatoshi Kimura [:emk]]

All dependent bugs are closed.