Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing Old Versions of TLS

blog.mozilla.org

Post reply on HN
Print view View original

51–60 of 94 posts

Re: Removing Old Versions of TLS

#51

Post by mrweasel »

amoshi wrote: post #7
JoshTriplett wrote: post #4

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.

Honestly if you still need something that clearly deprecated, and you're given a two year warning (if not more) then you can just fork Firefox and put the old TLS versions back.

With open source software you have every opportunity to customize it to your needs. The question that remains of cause is: Which is more expensive, upgrading the outdated software or maintaining your own Firefox branch.

Re: Removing Old Versions of TLS

#52

Post by jwilk »

regecks wrote: post #10
themew wrote: 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.

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.

People also thought that there's no reason to remove SSLv2 from your server, and then the DROWN attack happened:

https://drownattack.com/

DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.

Re: Removing Old Versions of TLS

#53

Post by dnbgfher »

cpeterso wrote: post #47
smichel17 wrote: post #46

Earlier quoted context omitted.

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.

It is opt-in, but typically both opt-in and out-out in these sorts of contexts refer to what happens in the absence of user input.

In that context opt-in has a bit of an issue with people even knowing it exists, not to mention caring enough to go find the option to opt-in, and then doing so. This route will, for better or worse, produce a very self-selected group. The proposal above is a way to maintain the benefits of opt-in (namely, consent) while trying to improve the quality of the group.

Re: Removing Old Versions of TLS

#54

Post by a_imho »

nindalf wrote: 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.

As a Firefox user, Moz://a has plenty on their tab and does not deserve special treatment.

Re: Removing Old Versions of TLS

#55

Post by r3bl »

Operyl wrote: post #43
mcny wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Removing Old Versions of TLS

#56

Post by joosters »

r3bl wrote: post #55
Operyl wrote: post #43

Earlier quoted context omitted.

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.

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.

I find it ridiculous that first party analytics requires extra requests at all - there's enough log information from my actual page requests, you don't need to make extra ones. If your logging is so inefficient, it should be blocked.

Re: Removing Old Versions of TLS

#57

Post by gsich »

JoshTriplett wrote: post #4

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…

Where is the problem?

Re: Removing Old Versions of TLS

#58

Post by Klathmon »

r3bl wrote: post #55
Operyl wrote: post #43

Earlier quoted context omitted.

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.

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.

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

Re: Removing Old Versions of TLS

#59

Post by Klathmon »

jandrese wrote: post #25

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.

At some point that code has to be removed. They can't keep every old option and code path around forever, it's just not sustainable.

There's a cost to using outdated systems, and this is it. If you need it, you can proxy requests to upgrade their protocol to something newer browsers speak, upgrade the device in question, keep old versions of browsers around for those single purposes (and probably gap that device as much as possible as it's now a much easier target for attackers).

Calling for all software to support all outdated options and code paths forever or even to always keep the code and flags or settings to enable it is absurd, and leads to unsustainable software that becomes impossible to change and improve.

Re: Removing Old Versions of TLS

#60

Post by [deleted] »

notatcomputer68 wrote: post #24
regecks wrote: post #10

Earlier quoted context omitted.

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.

1. Downgrade attacks. 2. Preventing people from shooting themselves in the foot.

[deleted]
Post reply on HN