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.
Removing Old Versions of TLS
11–20 of 94 posts
Re: Removing Old Versions of TLS
#12Most 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.
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
#13So if we remove TLS 1.1 from our servers and just offer 1.2, we fail on fallback when testing through Qualys.
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
#14If 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 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
#15Most 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…
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
#16If 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
Re: Removing Old Versions of TLS
#17Using 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
#18Most 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.
Re: Removing Old Versions of TLS
#19Side 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.
> 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
#20Side 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.
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.