
Removing Old Versions of TLS - edmorley
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/
======
nindalf
Side note unrelated to TLS.

Using telemetry Mozilla was able to precisely measure how many connections are
actually established with TLS 1.0 and 1.1. Without numbers, they'd have been
flying blind, making decisions with no rational basis. That's why I personally
choose to leave telemetry on in applications that I trust. It helps the dev
makes sensible, data-driven decisions.

~~~
mcny
> Using telemetry Mozilla was able to precisely measure how many connections
> are actually established with TLS 1.0 and 1.1. Without numbers, they'd have
> been flying blind, making decisions with no rational basis. That's why I
> personally choose to leave telemetry on in applications that I trust. It
> helps the dev makes sensible, data-driven decisions.

Some unrelated advice: what would you do if business brings up Google
analytics data showing Google Chrome, IE, and Safari are three main browsers
people use and the usage share of Mozilla Firefox is under 5% for a particular
website? I tried to show my own use case with uBlock Origin which means when I
go to the website it doesn't show up on Google Analytics.

How do we make decisions based on self-reported data?

You'd think institutions funded by public monies would be more sensitive on
issues like this but my pleas fall on deaf ears.

~~~
Operyl
In this specific usecase, if you're having trouble convincing, maybe doing
analysis based on access logs (depending on your size, I guess, maybe you'd
need to sample only a couple of days depending on how much access logs you
store).

EDIT: I'm mostly suggesting this because it sounds like all you need is proof
that your Google Analytics data might be incorrect.

~~~
r3bl
I find it ridiculous that an adblocker blocks access to even first party
analytics. /piwik.php is found on EasyPrivacy list, which is one of the
default uBlock Origin filter lists.

I really didn't expect my adblocker to do that when I installed it.

~~~
Klathmon
I'm always surprised people are willing to give random developers that much
control over their browser when installing extensions like that.

I've had so many things break because someone somewhere didn't think a request
was valid enough and blocked it and it was put into a common blocklist.
WebRTC, several fonts, first party analytics, even whole services like Google
shopping were blocked entirely because "they are ads" or they were "trackers".
We even had to modify an app which was using css modules one time because
class names were compiled down to a hex encoded hash of the css properties,
and any class names beginning with `ad` were blocked by EasyList at one
point...

It is giving an uncomfortable amount of power to a very small amount of
developers. And it ends up ruining efforts to avoid 3rd party analytics
because not only are first party harder to implement and maintain in many
cases, but they get blocked just the same for very innocuous reasons, and give
worse insights in some ways.

Just look at the list of what EasyList considers "unacceptable data to gather"
in first party analytics [0]. Things like the useragent, timezone, IP address,
and language are considered "personal information" and should be blocked even
in first party scripts with EasyList! IP address or useragent alone literally
makes all first party tracking impossible...

[0] [https://easylist.to/2011/08/31/what-is-acceptable-first-
part...](https://easylist.to/2011/08/31/what-is-acceptable-first-party-
tracking.html)

~~~
gorhill
> I'm always surprised people are willing to give random developers that much
> control over their browser

I will say this is why people install content blockers, to avoid giving
control to random developers behind countless websites, which have shown that
there is no limit in the amount of data they will try to gather without a hint
of informed consent.

On the other hand, content blockers are opt-in and people are free to install
or not after reading the description/documentation and further researching
them.

~~~
mcny
This discussion got bigger than I expected. I just want to take a moment to
thank you not just for your hard work but the trust you have brought in uBlock
Origin. From the bottom of my heart, thank you.

------
JoshTriplett
Most of the pushback here isn't going to be on the web. It's going to be in
corporate systems and proxies that haven't upgraded, and reject anything they
don't understand.

For instance, some corporate proxies will parse TLS and drop connections they
don't understand. Theoretically, they do this to combat things like
Heartbleed; in practice, they do it because the same tools will (with the flip
of a switch) do termination and interception.

~~~
amoshi
There are still some essential government, military and corporate websites
relying on these protocols that will not be updated any time soon - it should
always be possible for a user to override this block.

I really dislike this "browser smarter than the user" design.

~~~
dagenix
How many users:

a) Know what TLS is

b) and, have a secure channel to their destination website that allows them to
determine that it intends to serve TLS 1.0

c) and, aren't in a position to just upgrade the darn thing to at least TLS
1.2?

d) and, know that there are no undisclosed weaknesses in the outdated design
of TLS 1.0 or in the outdated cryptography that it mandate

Most users fail a). Basically the only way to pass b) is to be the website
operator or someone that knows that person or group in real life. But, to pass
c), you can't be the operator. Then, finally, no one can really pass d), but,
the closest you could get would be to be a part of a sophisticated government
sponsored security agency, probably working as a cryptographer and definitely
being kept up to date on pretty sensitive intelligence. And for reasons that
aren't clear, you are totally fine with the website in question running on
outdated crypto - so, in addition, you are probably bad at your job.

How many people fit that description? Those are the people that have a right
to consider this a user hostile change. I'm willing to bet its a pretty small
group. Everyone else benefits since they either know they can't make a good
choice as to whether to accept TLS 1.0 from a website, or, mistakenly think
they can.

~~~
jake_the_third
That's why it should be disabled by default but also be overridable. Those
users would have to mess with browser flags to re-enable older versions. And
if a user is willing to mess with advanced browser settings without
understanding them, there are far worse security settings to mess with than
outdated tls protocols.

Users MUST have ultimate control over software and not the other way around;
even if it such control is used to do something very stupid. Software
deliberately designed to go against the wishes of its users is defective,
malicious, or both.

PS: point (d) is a non-point.

~~~
dagenix
> Software deliberately designed to go against the wishes of its users is
> defective, malicious, or both.

I think its quite a stretch to say that Mozilla choosing not to support a
technology makes their product "defective" or "malicious". They get to choose
what they support. They beauty of open source software, is that if someone
disagrees with that decision, they are free to support it themselves. That is
unlikely to happen in this case - and that just validates Mozilla's decision.

Point D) is highly relevant - if it's hard for users to present a rational
reason that a feature should exist, it further justifies Mozilla not wanting
to support it. The IETF, NIST, browser vendors, PCI security standards,
vendors such as Cloudflare, etc have all moved away from TLS 1.0 or
recommended no longer using it as described in
[https://tools.ietf.org/html/draft-ietf-tls-oldversions-
depre...](https://tools.ietf.org/html/draft-ietf-tls-oldversions-
deprecate-00). That document also lays out various technical reasons to no
longer use TLS 1.0. TLS 1.2 has been the recommended version of TLS since 2008
- 10 years ago and it will be 12 years by 2020 when Mozilla stops supporting
it. That is all overwhelming evidence that anyone that thinks that they are
the special exception for whom using TLS 1.0 makes sense, is almost certainly
wrong. People have the right to be wrong, but, it's hardly Mozilla's ethical
obligation to enable them.

~~~
jake_the_third
I understand the point you're making, but I still stand by my opinion.
Software that goes out of its way to subvert the wishes of the user is
defective, malicious, or both.

------
petecooper
If you want Nginx to use TLS v1.2, this is what you need:

    
    
      ssl_protocols TLSv1.2;
    

…and if you compile a recent Nginx from source and bake in OpenSSL 1.1.1 while
you do that, you can have TLS v1.3 with a TLS v1.2 fallback, too:

    
    
      ssl_protocols TLSv1.3 TLSv1.2;
    

See also:

[https://caniuse.com/#feat=tls1-2](https://caniuse.com/#feat=tls1-2)

[https://caniuse.com/#feat=tls1-3](https://caniuse.com/#feat=tls1-3)

~~~
tialaramex
This is a bad design by nginx, how many people configuring a web server are
thinking to themselves "I better check which version of OpenSSL I compiled
with in order to set the appropriate TLS versions?". I'd guess approximately
none.

The correct design would be something like:

    
    
      tls_minimum_version 1.2;
    

If they feel a compulsion to do so they could add a maximum version, but with
a default of (none) and an explicit warning that this probably isn't what you
wanted to change.

~~~
benchaney
tls 1.3 is still very new, so it makes sense that it would have both compile
time and runtime concerns. Unless you are specifically trying to use tls 1.3
(which isn't most people), you don't need to turn it on, even if it is
compiled in. Of course if you are specifically trying to use it, you probably
know how you compiled nginx. So really it isn't bad design at all.

------
kccqzy
Apple is doing the same: [https://webkit.org/blog/8462/deprecation-of-legacy-
tls-1-0-a...](https://webkit.org/blog/8462/deprecation-of-legacy-
tls-1-0-and-1-1-versions/)

~~~
Ajedi32
And Chrome: [https://security.googleblog.com/2018/10/modernizing-
transpor...](https://security.googleblog.com/2018/10/modernizing-transport-
security.html)

And Edge:
[https://blogs.windows.com/msedgedev/2018/10/15/modernizing-t...](https://blogs.windows.com/msedgedev/2018/10/15/modernizing-
tls-edge-ie11/)

Seems like this was coordinated.

~~~
mathw
Chrome's seems to be the only announcement that doesn't mention it's
coordinated with the other major browser vendors.

Dominant position talking :(

------
jandrese
I kind of wish they'd leave the option to re-enable them in extreme
circumstances. It's really annoying to try to bring up the web interface on
some crusty old piece of hardware and discovering that the SSL/TLS negotiation
can't find a workable solution.

~~~
CorpusCalcium
Assuming that device is actually worth accessing, then you could still keep
and use an old version of a browser for that purpose. Newer browser versions
should be pushing the web forward where possible.

~~~
jeroenhd
I agree with you in the case of old encryption methods (plain DES, RC4, NULL
cipher) but not all protocol problems are because of the lack of a recent
encryption algorithm.

There's heaps of old modems that use a weak DH key and will never see a
firmware update. You're left with either accessing the device insecurely over
HTTP, hoping your ISP will send you a new one (good luck with that) or paying
for your own modem which will probably never be allowed on the ISPs network.

Weak DH keys should not be that hard to keep in the code base yet still most
browsers will present an impassable TLS error screen.

~~~
CorpusCalcium
Those modems should no longer be being used, period. If someone cannot afford
a replacement and has an incompetent ISP incapable of providing them with a
subsidized replacement, then that is a separate problem that needs addressing
as soon as possible.

Perpetuating it won't do, and if in doing so we're perpetuating a larger
impending security issue, then we need to resolve it stat, not defer
everything because there is heaps of old hardware lying around.

That may be easy to say and harder to resolve, but there comes a time when
problems need to be resolved. Maybe that won't be 2020, if the desired
timeline proves unrealistic, but two years is plenty of time to move on it. It
generally takes far longer to deprecate and remove protocols from the web than
it does to get a replacement modem.

------
notimetorelax
That’s awesome. Server side software should also be actively removing those
old protocols.

------
jaclaz
Also, probably it will affect accessing a range of hardware devices that
include a web interface (such as routers).

A recent example:

[https://msfn.org/board/topic/177834-modern-browsers-and-
lega...](https://msfn.org/board/topic/177834-modern-browsers-and-legacy-
network-devices/)

------
themew
So if we remove TLS 1.1 from our servers and just offer 1.2, we fail on
fallback when testing through Qualys.

~~~
regecks
There's no reason to remove TLS 1.1 from your server. This change is about the
minimum protocol version supported by the browser.

Your server can advertise SSLv3 support alongside TLS 1.2, and Chrome 70 will
still happily connect to it.

~~~
toast0
> There's no reason to remove TLS 1.1 from your server.

I posit there's no reason to support TLS 1.1 on your server. There are very
few clients that support TLS 1.1, but not TLS 1.2. So, either you are willing
to support clients on TLS 1.0 (or SSLv3), or you aren't.

~~~
1over137
Apple only added TLS 1.2 to their SecureTransport lib in OS X 10.9, which was
released in late 2013. Not so old!

~~~
toast0
Did they actually support tls 1.1 though?

------
fouc
Does anyone think that all this security handling stuff should be kept
separate from the browser and moved into a local proxy that handles this?

So that people with old browsers or other clients can still access the web.

------
mobilemidget
Interesting, including the comments on HN. But personally I wonder more when
we can disable old TLS versions for MTAs

~~~
jeroenhd
A lot of MTAs are improperly configured. There's still a lot of plain text
email sent across the Internet. The secure mail servers often have trouble
connecting to anything with a TLS version higher than 1.0 (if even that). Many
mail servers also don't have a valid server certificate (self-signed, expired
or even from the wrong domain). In my opinion, the email ecosystem is hopeless
with regards to TLS security. Gmail started showing red padlocks for plaintext
or insecurely sent emails a while back and I still see the red pad lock to
this day.

Bexause of this, disabling old TLS versions could make your server unreachable
for large parts of the Internet or have servers fall back to plain text if
they're improperly configured. Nobody wants to be that one company that can't
receive your grandma's emails so everybody just keeps accepting improper
configuration.

Another problem is that a lot of MDA servers share their TLS config with the
MTA side.

I know from experience (worked at a small company that upgraded their email
servers to TLS 1.2, at least on the MDA side) that old Microsoft mail clients
(Office 2007 and lower, Windows Live Mail 2012) have trouble with TLS 1.2,
especially on older Windows versions.

Although these clients have all been deprecated for a long time, a lot of
users with few tech skills still use them because that's what their PC was set
up with years ago when they bought it, or because they don't want to waste
their time learning how to deal with a new UI (you can see this with a lot of
elderly people).

For programs that use the Windows 7 TLS libraries TLS 1.2 is even disabled by
default in Windows 7 because at the time Windows 7 launched, other
implementations had major bugs. It can be enabled using a registry key though.
This includes Office 2010, which still gets security fixes from Microsoft.

So, if a large company would disable TLS 1.0/1.1 on their MTAs it might get a
large amount of customer support calls from their least technical customer
base. You can tell your customers that their program is out of date and that
their program is the reason they're getting errors, but in the end the
customer will still blame you for "breaking their mail program".

Aside from a massive blow to a company's reputation, this would also overload
the customer support desk and cost a lot of man hours.

<edit> Actually, I've seen the built in mail app for Samsung smart phones fail
on TLS 1.2 for Android versions up to Android 8. Other Android vendors
generally have trouble up to Android 5/6\. With the lack of system updates on
the Android ecosystem, this could be an even bigger problem. </edit>

I believe disabling old TLS versions is the right thing, but not until large
parties such as Microsoft and Google decide to take the first step if you
still want your server to receive any email.

------
devit
What needs to be dropped the most are non-TLS non-localhost [http://](http://)
URLs.

