Live data from Hacker News

Removing Old Versions of TLS

blog.mozilla.org

41–50 of 94 posts

Re: Removing Old Versions of TLS

#41
post #36

Apple is doing the same: https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-a...

And Chrome: https://security.googleblog.com/2018/10/modernizing-transpor...

And Edge: https://blogs.windows.com/msedgedev/2018/10/15/modernizing-t...

Seems like this was coordinated.

Re: Removing Old Versions of TLS

#42
post #27
post #7

Earlier quoted context omitted.

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.

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…

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.

Re: Removing Old Versions of TLS

#43
post #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 Googl…

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.

Re: Removing Old Versions of TLS

#44
post #27

Earlier quoted context omitted.

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…

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…

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

Re: Removing Old Versions of TLS

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

Re: Removing Old Versions of TLS

#46
post #21
post #19

Earlier quoted context omitted.

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.

The opt-in information would be skewed to the point of uselessness though right, thanks to extreme correlation? In fact, the non-opt out is probably pretty skewed itself so some wrong data driven decisions are inevitable.

There's a third, seldom-discussed alternative to opt-in and opt-out: no default.

On first launch or after a set period, show a non-dismissable dialog asking users to choose between the two, with no default option selected, so you can't just click through.

This strikes me as the best compromise between respect for user privacy and acknowledging that data collection can be useful, with the trade-off that some users will choose not to use the software/website rather than decide on an option (thus, 'no default' must be used sparingly).

Re: Removing Old Versions of TLS

#47
post #21

Earlier quoted context omitted.

The opt-in information would be skewed to the point of uselessness though right, thanks to extreme correlation? In fact, the non-opt out is probably pretty skewed itself so some wrong data driven decisions are inevitable.

There's a third, seldom-discussed alternative to opt-in and opt-out: no default. On first launch or after a set period, show a non-dismissable dialog asking users to choose between the two, with no default option selected, so you can't just click through. This strikes me as the best compromise between respect for user privacy and acknowledging that data collection can be useful, with the trade-off that some users wil…

That's still opt-in because the user elects to submit their telemetry data, even though they didn't seek out the setting.

Re: Removing Old Versions of TLS

#48
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 almost certainly have an `about:config` option (it has one right now)

Re: Removing Old Versions of TLS

#49
post #27

Earlier quoted context omitted.

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…

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…

Spoken like someone who never had to support some old feature because "maybe there is one user who still uses it". Features have a cost. Disabling features and removing them if they are no longer useful for the majority is a valid response to limited resources. I'd rather see Mozilla work on features that are useful and secure than garbage from yesteryear.

Re: Removing Old Versions of TLS

#50

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

These links work with JS disabled:

https://caniuse.com/tls1-2

https://caniuse.com/tls1-3

Post reply on HN