Just wait for the next Reg articles about this 'hole'.
And thanks NSA, we know it was you and Google!
An overhaul of a critical internet security protocol has been completed, with TLS 1.3 becoming an official standard late last week. Describing it as "a major revision designed for the modern Internet," the Internet Engineering Task Force (IETF) noted that the update contains "major improvements in the areas of security, …
Except for crusty old appliances that the vendors will never release updated firmware for
Except for crusty old systems that are running on decades old OS/application stacks that the business has no budget for but are business critical.
Except for crusty old load balancers, firewalls etc that will need to upgraded/replaced that there is no budget for but are business critical.
I agree that it's a no-brainer for sysadmins, but manglement have no brains!
You have a valid point for things like load balancers and other high-throughput devices, but for other appliances, servers, etc.I don't see why you can't just park a reverse proxy in front that speaks TLS1.3 (or better, as time passes) on the user side, and whatever outdated version of SSL/TLS on the server side.
I don't see why you can't just park a reverse proxy in front that speaks TLS1.3 (or better, as time passes) on the user side, and whatever outdated version of SSL/TLS on the server side
That's what I'll probably have to end up doing; But not all middle-ware etc type systems play nice with proxies. Hell... I'm *still* trying to convince some particularly broken ugly nasty server side stuff to play nice with TLS1.2.
It's nice that TLS1.3 looks like a drop in replacement (probably via openSSL) but to think that solves all problems everywhere is not reflected in reality. Hopefully the libs get backported to CentOS/EL 6 & 7
Unfortunately the drop in with OpenSSL is not perfect - the only version of OpenSSL that will have TLS 1.3 support is 1.1.1, which is ABI compatible to 1.1.0, but 1.1.0 and 1.0.2 are ABI incompatible.
there is a bit of API incompatibility also between 1.1.0 and 1.0.2, but if an application didn't peek to much under the skirt of OpenSSL, it will require "only" a recompilation to start running on 1.1.0 ABI (and thus get TLS 1.3 with 1.1.1 release)
>.I don't see why you can't just park a reverse proxy in front that speaks TLS1.3
Client side Java app that only speaks SSLv2.
"It has been obsolete since 1997."
"But we had a vendor develop the app in 2001!"
"I can't help it you hired some developers whose skill level was copying from past projects and ignoring deprecation warnings."
We accept the risk. I keep obsolete load balancers running for a single application.
Tell management that all the kit will stop working at the end of 2018. In terms of working securely, that's not so far wrong. Y2K18 Bug: This Time It's Spurious. You could probably even persuade them that "spurious" means "very, very bad." Serious and worse. So when they ask the consultants, "Our guy says this threat is spurious, do you agree?" "Oh yes, it's the most spurious that I've ever seen."
I suppose this is a Man In The Budget Freeze Attack:
TLS is tightening security at the same time as the Australian Government is mandating "not backdoors" (as seen on The Reg). What could possibly go wrong? Will this mean that Australian sites will need to implement weaker security and leave us exposed or do we run the risk of invoking the ire of the Australian security agencies?
From the article:
The way TLS 1.3 works also sparked some last-minute pleading from the banking industry to make a change and effectively introduce a backdoor into the system
To be more exact, it was just some people from the banking industry that were complaining about it, it wasn't a long list or a majority. Few people from the same industry said that they don't need that ability at all. And no, no significant changes were made to accommodate pervasive monitoring.
There is a, non zero, possibility that the CIA, NSA or some other criminal organisation will have slipped in a "not a backdoor" that they can share with their corporate owners and their chums in other spook groups across the world.
Mind you, with that much paranoia, there probably already are innapropriate weaknesses in the previous versions
The mass surveillance of internet communications by the US National Security Agency (NSA) revealed in 2013 by Edward Snowden,
In 2005-2007, major media groups like the New York Times, Reuters, BBC, and numerous others described the NSA's warrantless mass surveillance of the internet, phones, email, office gossip, and pillow talk. This incredible violation of privacy filled the evening TV news, internet websites, and newspapers.
After a few years of quiet, in 2013 Edward Snowden reminded the world that the NSA's surveillance was still happening.
However, most discussions I see today about the NSA's internet monitoring hail Snowden as the hero who FIRST told the world about it. It's like all the news coverage, ACLU lawsuits, and outrage of the late 2000s didn't happen and Snowden revealed something new. Maybe the NSA asked the CIA to use their mind control satellites to blank everyone's brains for a few years.
Non-rhetorical question: Is there some key difference between 2006 NSA internet surveillance and 2013 NSA internet surveillance that makes Snowden's revelation particularly novel? I feel like I'm missing something that makes Snowden different than all the earlier revelations.
The protocol is different, but the cipher suites and certs are still the same.
The suites for TLSv1.3 are all different. There's no overlap in cipher suites between 1.2 and 1.3.
Now, many of the same algorithms are present in suites on both sides. But the suites themselves, including what algorithms and modes they specify, have changed. 1.3 also standardizes some algorithms that are not available in standard 1.2 suites, and removes a great many deprecated ones.
As for certificates, the bit Kieren quoted from Eric Rescorla isn't accurate. DSA keys are no longer supported, and so neither are DSA certificates. That affects pretty much only some US Federal users - few or no other people were using DSA. (ECDSA is still supported.) SHA1 is allowed as a certificate hash in TLSv1.2 (though of course many applications now reject such certificates, at least under some conditions); it's not in TLSv1.3.
It's impossible to break into. We haven't found a way in so we gave up.
No one is claiming that, least of all the NSA. Security researchers of all imaginable hat colors are trying, and will continue to try, to break TLSv1.3 and the protocols, algorithms, and primitives it uses. I have no idea why anyone would think otherwise.
There is a built-in downgrade protection mechanism, but as the RFC says, it doesn't work for RSA ciphersuites. Additionally, if you can break SHA-1 in real-time, then you can downgrade to TLS 1.1 and earlier. (If you can break SHA-256 is real time you don't have to downgrade to TLS 1.2 as that means you can break TLS 1.3).
RSA ciphersuites you shouldn't be using (see ROBOT), and TLS 1.1 and earlier is useful only for deprecated software (Win XP) or short-sighted software combined with lazy developers (default .NET and, IIRC, PowerShell settings for HTTPS connections).
So it does require a bit of work to plug possible holes, but nothing insurmountable (and really, it's still just hardening at this point, there are no known successful attacks like this).
Biting the hand that feeds IT © 1998–2019