What needs to be dropped the most are non-TLS non-localhost http:// URLs.
Removing Old Versions of TLS
61–70 of 94 posts
Re: Removing Old Versions of TLS
#62Most 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.
Why wouldn't they just put a TLS1.2 reverse proxy infront of whatever legacy system is there? or use cloudflare? that'd be way easier than telling people to reconfigure their browsers to be insecure everywhere on the web.
Re: Removing Old Versions of TLS
#63Side 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…
Don't you have logs from your http server?
Re: Removing Old Versions of TLS
#64Earlier quoted context omitted.
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 a…
There is no guarantee that your first party tracker does not relay information to a third party via your web server. Furthermore, at least some of the data you list is considered personal information under GDPR. Block access if you want but do not collect personal data about me.
What I am hating most is that sites where I am willing to send money to (web shops) do these things and send data to ad net works too, no less.
Re: Removing Old Versions of TLS
#65Interesting, including the comments on HN. But personally I wonder more when we can disable old TLS versions for MTAs
Re: Removing Old Versions of TLS
#66Earlier quoted context omitted.
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 a…
There is no guarantee that your first party tracker does not relay information to a third party via your web server. Furthermore, at least some of the data you list is considered personal information under GDPR. Block access if you want but do not collect personal data about me. What I am hating most is that sites where I am willing to send money to (web shops) do these things and send data to ad net works too, no le…
> There is no guarantee that your first party tracker does not relay information to a third party via your web server.
You have no guarantees at all, but that information is always sent across, and in many cases must be sent to even make a request. You literally can't prevent an IP address from being "sent" because it's needed to route the information back to you. Sending an "Accept-Language" header lets a website be translated into multiple languages. And virtually 100% of my users want times and dates in their local time, not UTC.
Just because it's potentially identifying information doesn't mean you can block it and pat yourself on the back as "stopping tracking". When you don't allow an IP address to be sent, you have just created a system where you can arbitrarily choose literally any request and block it under that rule. It's like making a law against breathing oxygen, then arresting anyone that you don't like for any reason because they are breaking at least that law.
Re: Removing Old Versions of TLS
#67Earlier quoted context omitted.
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 a…
If you take all those pieces of information together you're very close to uniquely identifying the user, in a way which could be correlated with similar analytics from other websites if and when your analytics data is leaked or sold.
Sometimes people really mean it when they say they don't want to be tracked: they want to leave no footprint at all. Sometimes people just want the website to load as fast as possible by discarding as much Javascript and as many requests as they can get away with.
But don't forget the good old HTTP access logs, which give you all this information anyway without having to load extra scripts.
Re: Removing Old Versions of TLS
#68Earlier 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…
> Users MUST have ultimate control over software and not the other way around
You can build your own Firefox. You can even download the source and build an old version. What more control do you want?
Re: Removing Old Versions of TLS
#69Interesting, including the comments on HN. But personally I wonder more when we can disable old TLS versions for MTAs
A lot of MTAs are improperly configured. There's still a lot of plain text email sent across the Internet. The secure mail servers often have trouble connecting to anything with a TLS version higher than 1.0 (if even that). Many mail servers also don't have a valid server certificate (self-signed, expired or even from the wrong domain). In my opinion, the email ecosystem is hopeless with regards to TLS security. Gmail started showing red padlocks for plaintext or insecurely sent emails a while back and I still see the red pad lock to this day.
Bexause of this, disabling old TLS versions could make your server unreachable for large parts of the Internet or have servers fall back to plain text if they're improperly configured. Nobody wants to be that one company that can't receive your grandma's emails so everybody just keeps accepting improper configuration.
Another problem is that a lot of MDA servers share their TLS config with the MTA side.
I know from experience (worked at a small company that upgraded their email servers to TLS 1.2, at least on the MDA side) that old Microsoft mail clients (Office 2007 and lower, Windows Live Mail 2012) have trouble with TLS 1.2, especially on older Windows versions.
Although these clients have all been deprecated for a long time, a lot of users with few tech skills still use them because that's what their PC was set up with years ago when they bought it, or because they don't want to waste their time learning how to deal with a new UI (you can see this with a lot of elderly people).
For programs that use the Windows 7 TLS libraries TLS 1.2 is even disabled by default in Windows 7 because at the time Windows 7 launched, other implementations had major bugs. It can be enabled using a registry key though. This includes Office 2010, which still gets security fixes from Microsoft.
So, if a large company would disable TLS 1.0/1.1 on their MTAs it might get a large amount of customer support calls from their least technical customer base. You can tell your customers that their program is out of date and that their program is the reason they're getting errors, but in the end the customer will still blame you for "breaking their mail program".
Aside from a massive blow to a company's reputation, this would also overload the customer support desk and cost a lot of man hours.
Actually, I've seen the built in mail app for Samsung smart phones fail on TLS 1.2 for Android versions up to Android 8. Other Android vendors generally have trouble up to Android 5/6. With the lack of system updates on the Android ecosystem, this could be an even bigger problem.
I believe disabling old TLS versions is the right thing, but not until large parties such as Microsoft and Google decide to take the first step if you still want your server to receive any email.
Re: Removing Old Versions of TLS
#70I 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.
Assuming that device is actually worth accessing, then you could still keep and use an old version of a browser for that purpose. Newer browser versions should be pushing the web forward where possible.
I agree with you in the case of old encryption methods (plain DES, RC4, NULL cipher) but not all protocol problems are because of the lack of a recent encryption algorithm.
There's heaps of old modems that use a weak DH key and will never see a firmware update. You're left with either accessing the device insecurely over HTTP, hoping your ISP will send you a new one (good luck with that) or paying for your own modem which will probably never be allowed on the ISPs network.
Weak DH keys should not be that hard to keep in the code base yet still most browsers will present an impassable TLS error screen.