SoylentNews is people
SoylentNews
As TLS 1.3 inches towards publication into the Internet Engineering Task Force's RFC series, it's a surprise to realise that there are still lingering instances of TLS 1.0 and TLS 1.1.
The now-ancient versions of Transport Layer Security (dating from 1999 and 2006 respectively) are nearly gone, but stubborn enough that Dell EMC's Kathleen Moriarty and Trinity College Dublin's Stephen Farrell want it formally deprecated.
This Internet-Draft (complete with “die die die” in the URL) argues that deprecation time isn't in the future, it's now, partly because developers in recalcitrant organisations or lagging projects probably need something to convince The Boss™ it's time to move.
The last nail in the coffin would be, formally and finally, to ban application fallback to the hopelessly insecure TLS 1.0 and 1.1 standards.
Deprecation also removes any excuse for a project to demand support for all four TLS variants (up to TLS 1.3), simplifying developers' lives and reducing the risk of implementation errors.
[...] The publication of TLS 1.3 into the RFC stream is imminent – it's reached the last stage of the pre-publication process, author's final review. When it's published, it will carry the designation RFC 8446.
(Score: 3, Disagree) by shortscreen on Wednesday June 20 2018, @07:42AM (6 children)
one of these days I'll figure out how to set up my own local MITM proxy so I can browse plain old http again without all of the pointless errors about certificates and "unable to complete secure transaction"
allowing webtards to decide what software I can run (by deliberately breaking everything else) is much worse than some hypothetical threat of ISPs injecting ads (which I could avoid anyway via other means)
(Score: 3, Disagree) by ledow on Wednesday June 20 2018, @11:38AM (5 children)
Really?
I've seen certificate errors about... what... once a year or less. Considering the sheer number of websites I visit, and that most of those errors are literally insecure websites, that's nowhere near a hassle.
The threat isn't from ISPs. It's from ANY malware on your network or anywhere in the path to the Internet. Without TLS, everything you see and type is visible and modifiable across your network and is actively used as propagation techniques for viruses out in the wild, and has been for decades. That's how those "router infections" work too. Something gets into your network, pops up a window which it pulls from your internal router, you click it because it's "not secure" or because you can't verify its security and blamm, it's in your router firmware.
Plus, there's no excuse for even internal services not to have a valid TLS nowadays. They are literally free (LetsEncrypt). That error you "just click through" to get to your private webserver / router admin page / whatever could have a full certificate no problem.
And it's not the case that just putting in a MITM proxy would solve the problem - if the destination site literally doesn't support TLS 1.0, then your proxy can't use it to talk to it either. So either way you have to keep a machine up-to-date to talk to the latest websites securely, or do without talking to them at all. And if you're going to do that, you may as well just keep your own machines up to date.
(Score: 2) by Pino P on Wednesday June 20 2018, @01:14PM (3 children)
Let's Encrypt requires a fully-qualified domain name, as do all other CAs that meet the CAB Forum's Baseline Requirements. Domain name registration isn't free.
Or to put it another way: What is the fully-qualified domain name of your Internet router? Or your aunt's Internet router?
(Score: 3, Touché) by ledow on Wednesday June 20 2018, @01:29PM (2 children)
username.dyndns.org
Or any of a dozen supported rivals, many of them free.
Next question?
(Score: 2) by Pino P on Saturday June 23 2018, @05:44PM
If a dynamic DNS provider's domain isn't on the Public Suffix List [publicsuffix.org], then the first 20 users who request a certificate under that domain get a certificate, and the rest for the week get an error message that the request exceeds the rate limit of Let's Encrypt [letsencrypt.org].
Only the provider can request that a domain be added to the PSL, not its users. This means a provider can hold its users hostage by requesting that only "premium" domains be added to the PSL, especially if the provider also resells some commercial TLS CA's DV certificates. And last I checked, there was a months-log backlog in processing requests by providers to be added to the PSL.
(Score: 3, Informative) by Pino P on Saturday June 23 2018, @05:47PM
That went away years ago. When I type dyndns.org into my browser, I get redirected to dyn.com whose pricing page [dyn.com] doesn't show a free option. Wikipedia confirms [wikipedia.org]: "In April 2014, Dyn announced the discontinuation of its free hostname services effective May 7."
(Score: 3, Insightful) by jdccdevel on Wednesday June 20 2018, @06:09PM
I have to work with equipment that has this sort of problem ALL THE TIME.
There is a LOT of equipment out there, on Enterprise LANs and WANs, and in peoples homes, that use old versions of TLS and even SSL to encrypt web browser access. That equipment (most of it) absolutely CAN NOT be upgraded as you describe. It will be in place until it breaks and is replaced. HTTP access is out of the question, since sending passwords in plaintext even on a LAN or WAN is irresponsible, but worrying about someone spoofing a certificate, or MITM attack on SSL? If we have a malicious actor with access and smarts like that, we have bigger problems than a less than perfectly secure web browser.
We really, really need the tools to access this equipment.
I absolutely understand removing default support for older encryption, self signed certs, and whatnot from the Internet as a whole. That's a public space, and websites need to keep up to date, and web users need to protect themselves (even if the attack is theoretical). But web browsers are tools for accessing more than just the Internet, and I wish they would give me the option to disable some of the hoops I need to jump through every time I need to configure something more than a couple years old on my LAN.
I already have a older version of Palemoon installed just to access older Java Applet based stuff, and older SSL encrypted config pages. It gives me warnings, but at least it works. Firefox stopped compiling in SSL support a while back, and it was a absolute requirement, so I couldn't use that anymore. The problem is that the older web browser still works on the Internet, so it gets used to access it too (by habit, or because it's more convenient, or by accident, or some UI changes make the older web browser more comfortable to use...), and suddenly you're vulnerable. You're browsing the net with a web browser isn't up to date anymore, and can't be upgraded because that will break access to things you need access to.
Seriously, if it's a RFC1918 IP address, it's on the LAN, and I should be able to configure an up-to-date web browser so everything legacy works. I should be able to let it know that I know it might be less than secure, (to use TLS1.0 on the LAN, for example) but I need to access it anyway.
Legacy equipment on the LAN should just keep working, and it shouldn't be that hard to whitelist legacy support for it.