Live data from Hacker News

Removing Old Versions of TLS

blog.mozilla.org

11–20 of 94 posts

Re: Removing Old Versions of TLS

#11
post #7

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 termina…

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.

Older versions of the browser aren't going anywhere. Users are free to keep them as long as they want.

Re: Removing Old Versions of TLS

#12
post #7

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 termina…

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.

This will give the techies a reason to give to their bosses to pay off that technical debt that has accrued with these systems. Every system that uses outdated websites will need to upgrade. And they will have two years to do it. It makes the argument go from the nebulous "it will make us safer" to the concrete "things will not work".

And yes, it's a heavy handed way, but the fact there are "There are still some essential government, military and corporate websites relying on these protocols that will not be updated any time soon" shows the soft touch isn't working.

Re: Removing Old Versions of TLS

#13
post #3

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

What web server are you using? I'm running numerous servers with just TLS v1.2 and get A+ at Qualys [1].

Not bragging, just curious where you fall down.

[1] https://www.ssllabs.com/ssltest/analyze.html?d=tractor.textp...

Re: Removing Old Versions of TLS

#14

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-3

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.

Re: Removing Old Versions of TLS

#15

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 termina…

In my experience this kind of thing is becoming less common as time goes on, but granted it's a long-tail of behavioral change.

A lot of organisations (at least, ones I've talked with) are starting to look realistically at how they handle things like proxying and traffic monitoring in a world where they can't reasonably MITM HTTPS sessions any longer.

Reality for most is, they're starting to realize they can no longer paper over a people problem with technology, and are starting to look realistically at how the issues they were addressing via MITM can be solved in softer ways.

Genuine high-security environments are a different matter. If you absolutely have to safeguard against data-loss events and such, there are a wide variety of other techniques available such as full air gapping, or maintaining full end-client control at the tail of the tunnel so you never need to peek halfway along the pipe. The other common need for MITM is to police time-wasting behavior and perceived risks of staff web activity, and those are better solved via good old fashioned people management.

Re: Removing Old Versions of TLS

#16

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-3

The default includes TLSv1.2 (along with TLSv1.1 and TLSv1). So the default does and will continue to use TLSv1.2 with browsers that support it, and will still work when browsers disable TLSv1 and TLSv1.1

Re: Removing Old Versions of TLS

#17
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.

Re: Removing Old Versions of TLS

#18
post #7

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 termina…

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.

Essential has nothing to do with it. Upgrading to a ten year old standard as a minimum is not burdensome. If these services are so critical, they have far bigger problems due to these gaping security holes.

Re: Removing Old Versions of TLS

#19
post #17

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.

The information from people that explicitly opt-in would have given them the same insight.

> That's why I personally choose to leave telemetry on in applications that I trust

The problem is that when I have to "leave it on" rather than explicitly enable it then it's no longer an application I trust.

Re: Removing Old Versions of TLS

#20
post #17

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.

> 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.

Post reply on HN