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

21–30 of 94 posts

Re: Removing Old Versions of TLS

#21

Post by esrauch »

flukus wrote: post #19
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.

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.

Re: Removing Old Versions of TLS

#22

Post by notatcomputer68 »

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.

> military

But uh isn't it better that it breaks in peacetime* than in wartime?

Re: Removing Old Versions of TLS

#23

Post by gerdesj »

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…

Corporates be damned! (and they will be if they don't adapt). There are many issues here and you touch on one: MItM web proxies. To be honest it is pretty trivial to get Squid to do Bump and Splice so MiTM is a thing for anyone and not just corporates with expensive proxy toys.

In the Windows world, you have a weird collection of SSL/TLS settings available out of the box. Unfortunately you have at least three sets of these to worry about: SChannel, WinHTTP and .NET (this one has several sub versions). Updates enable extra features but some need reg keys to switch them on.

Then, once you get things tuned correctly so that TLS <1.2 is unavailable, something will need an older version and you have to switch it back on ... unless your IT security officer is also the Managing Director, which means I get to tell the whiner to piss off and fix their application. I do accept that I have a luxury unavailable to most people!

Re: Removing Old Versions of TLS

#24

Post by notatcomputer68 »

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.

1. Downgrade attacks.

2. Preventing people from shooting themselves in the foot.

Re: Removing Old Versions of TLS

#25

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

Re: Removing Old Versions of TLS

#26

Post by [deleted] »

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.

[deleted]

Re: Removing Old Versions of TLS

#27

Post by dagenix »

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.

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.

Re: Removing Old Versions of TLS

#28

Post by jsjohnst »

petecooper wrote: post #13
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.

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

Your link shows all the clients you’re blocking. Expand the “unsupported clients” section. You’re currently blocking a lot of clients some folks care about (I say good riddance to them, but not everyone can).

Re: Removing Old Versions of TLS

#29

Post by jsjohnst »

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.

You don’t “fail” due to lack of 1.1, you can still get an A+ as evidenced by Pete’s link. That said, you’ll notice that his server is blocking a bunch of clients that maybe you care about.

Re: Removing Old Versions of TLS

#30

Post by benchaney »

tialaramex wrote: post #14
petecooper wrote: post #8

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

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.
Post reply on HN