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: 5, Insightful) by driverless on Wednesday June 20 2018, @09:04AM (17 children)
In that case the first nail would be to drop the ridiculous hyperbole. TLS 1.0 and 1.1 aren't "hopelessy insecure". They have some mostly theoretical weaknesses that apply in special situations, but don't affect most users. And before someone jumps in with "but everyone knows they fail in manner XYZ", if they're hopelessy insecure then show me an actual attack on, say, eBay or Paypal using TLS 1.0 or 1.1.
An actual, real attack on eBay or Paypal, not some theorising based on a research paper at a conference.
(Score: 1, Interesting) by Anonymous Coward on Wednesday June 20 2018, @10:32AM (6 children)
TLS 1.0 has been in use for years. Was anyone actually pwned in the wild because of those weaknesses?
People are far more likely to be pwned by governments/corporations using their CA certs to MITM people. There have been actual real cases of this happening:
https://www.theregister.co.uk/2013/12/10/french_gov_dodgy_ssl_cert_reprimand/ [theregister.co.uk]
https://www.fastcompany.com/3042030/the-huge-web-security-loophole-that-most-people-dont-know-about-and-how-its-be [fastcompany.com]
https://techcrunch.com/2015/04/01/google-cnnic/ [techcrunch.com]
And upgrading to TLS 1.3 isn't going to help vs that.
So if anything is hopelessly insecure it's the way browsers implement the CA https system that puts their users at risk.
Something like what SSH does would be safer - e.g. if a cert changes unexpectedly the user is warned (there's stuff like certificate patrol but it doesn't handle cases where a site has multiple certs due to load balancing or other reasons).
(Score: 2) by Pino P on Wednesday June 20 2018, @01:19PM (5 children)
In TLS, self-signed certificates do exactly this. But how does this protect a user visiting a particular site for the first time? The client might be behind the same sort of government or corporate MITM that you mention.
I guess part of the perception that the SSH model is safer than the TLS model comes from the fact that a user will typically connect to far fewer SSH servers than TLS servers in his lifetime and can therefore afford to spend more time (which is money) on double-checking each server's key fingerprint.
(Score: 2) by tomtomtom on Wednesday June 20 2018, @08:51PM (2 children)
There are ways we can improve on this. The "ssh model" (trust on first use), for servers you connect to frequently, is better in many ways than trusting the very large number of CAs out there *every* time you connect. That's why things like HPKP certificate pinning exist - to try to combine the two. So you can then trust on first use based on a CA, and then either have future cert rollovers required to be signed by another key within the site owner's control or by a specific CA otherwise they trigger a browser alert.
The big problem though is convenience and in particular convenience to site admins, who are mostly imperfectly competent, at least some of the time. HPKP is unpopular because the cost of failure for a site admin (in terms of losing their certificates) is too high.
So the approach which everyone seems to be converging on is to add side channels to verify multiple ways to make a man in the middle attack harder. eg DANE/DNSSEC, Certificate Logs, etc
(Score: 0) by Anonymous Coward on Thursday June 21 2018, @06:55AM (1 child)
No. Things like certificate pinning exist to serve the corporations more than the users.
Browsers can warn users of unusual/unexpected changes without requiring stuff like certificate pinning. This would help the user in so many more attack scenarios. e.g. in cases where certificate pinning is not practical for certain sites, or for self-signed certificates.
Certificate pinning adds complexity just to protect narrower more specific cases (only for organizations that pin their certificates).
See also:
So guess whose interests were the real priority for those creating the standard?
(Score: 2) by Pino P on Saturday June 23 2018, @03:41PM
I assume the -Report-Only mode of HPKP is like that of Content Security Policy (CSP): a transition mechanism to help sites that did not support the feature debug their preliminary support before committing to support.
(Score: 0) by Anonymous Coward on Thursday June 21 2018, @04:22AM (1 child)
Do they really? Say you have a self-signed cert for yourdomain.com and your browser has been told to accept that. Say a CA signs a cert for yourdomain.com and it's used to MITM your browser and yourdomain.com. Which browser will warn you when that happens?
(Score: 2) by Pino P on Saturday June 23 2018, @05:39PM
Does the browser trust a newly seen certificate just because it's for the same hostname for which the user has added an exception for a different certificate?
A browser behaving "correctly" would reject the certificate. Unfortunately, I have not had a chance to test this behavior in all browsers on all platforms.
(Score: 3, Insightful) by driverless on Wednesday June 20 2018, @10:42AM (3 children)
As a followup based on a PM, since I never set any benchmark for what resources it would take, let's say you can call something "hopelessy insecure" if you can achieve either full plaintext recovery or full message forgery in close to real time, say 5 seconds or less. That figure is chosen so it won't be noticed by the victim if there's too much delay, maybe 30s for a web site but for something like SIP it'd have to be close to real time, 5s seems a good compromise.
So I'll modify my previous challenge to say that "you can call it hopelessy insecure if you can demonstrate full plaintext recovery or message forgery in five seconds or less against TLS 1.0 or 1.1 for a typical target site like eBay or Paypal".
(Score: 2) by FakeBeldin on Wednesday June 20 2018, @11:10AM (2 children)
I would still not consider that "hopelessly insecure".
For me, hopelessly insecure is when a non-expert with access to Google can break the security in 5 minutes or less.
If someone is able to break Paypal or eBay, it might just mean that that person is good at this (or: spend enough effort to defeat them).
(Score: 2) by darkfeline on Thursday June 21 2018, @03:25AM (1 child)
By that definition, being vulnerable to SQL injection attacks or storing passwords hashed using MD5 and unsalted is not "hopelessly insecure". Hell, ROT13 might barely escape being "hopelessly insecure", given the average person's comprehension skills.
Join the SDF Public Access UNIX System today!
(Score: 2) by FakeBeldin on Thursday June 21 2018, @07:31AM
...which underscores that I feel that "hopelessly insecure" is a very strong statement.
If the average person that understands the security purpose of a device/security control cannot trivially break it, then I believe "hopelessly" is an overstatement.
Note that not all SQL injection may not fall under this: I'd be surprised if you couldn't learn within 5 minutes to type "test; DROP DATABASE" into a form field.
(Score: 2) by ledow on Wednesday June 20 2018, @11:52AM (4 children)
Oh come on.
The first was written in 1998, you really expect it to still be secure:
https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/ [gracefulsecurity.com]
DROWN: "It allows an attacker who has an effective man-in-the-middle to break the encryption of a TLS connection in under eight hours with a variant being achievable in one minute"
CRIME: "The attacker requires a man-in-the-middle connection and the ability to repeatedly inject predictable data whilst monitoring the resulting encrypted traffic. This could be achievable through Cross-site scripting attacks; JavaScript is not required and an attack could be possible with HTML Injection alone however it would be less efficient. For CRIME to be possible the client and server must support compression of the request before encryption. TLS supports DEFLATE which is vulnerable, as is SPDY."
BEAST: Mitigated, but can only be fixed by moving to TLS 1.2
BREACH: See CRIME but without the same compression.
FREAK:"allows an positioned attacker with a man-in-the-middle attack to reduce the security offered by SSL/TLS by forcing a connection to use “Export-grade” grade encryption – which reduces the RSA strength to 512 bits, which is breakable by attackers with a modest budget (In 2015 researchers showed this to be about $104 on Amazon EC2 instances)"
Logjam: "allows a man-in-the-middle attacker to downgrade the encryption to 512-bit export grade cryptography"
NOMORE: "allows a HTTP Cookie to be retreived within 52 hours"
Bar Mitzvah: allows for small amounts of plaintext data to be recovered from an SSL/TLS session. It requires a positioned attacker with a man-in-the-middle attack capable of capturing “many millions” of requests."
SWEET32: "It requires a positioned attacker with a man-in-the-middle attack capable of capturing a long-lived HTTPS connection. The original proof of concept showed that it was possible to recover secure HTTP cookies by capturing around 785 GB of traffic, by generating traffic through malicious JavaScript."
SSL POODLE: "It requires a man-in-the-middle attack and the ability for the attacker to cause the application to send the same data over newly created SSL3.0 connections but allows an attacker to decipher a chosen byte of cipher text in as few as 256 attempts."
TLS POODLE: "is a vulnerability affecting certain implementations of TLS" (Yep, I'll give you that one!)
Heartbleed: "It does not require a Man-in-the-Middle to exploit and can be exploited against both the server and the client. The issue allows an attacker to extract up to 64kb of memory from the vulnerable system, which can lead to the theft of credentials, session tokens and server private keys."
Most of the original cipher suites are deprecated too. Though you can mitigate some of those, and some of those are poor implementations, by far they are the most dangerous classes of code to have problems inside, and redesign to combat those problems is critical. Not just papering over the cracks.
SSL/TLS below 1.3 are dead for a reason. PCI DSS wouldn't FORCE them out of action unless they needed to, they barely keep up with most things as it is. If the finance sector has deprecated a protocol, you can be sure it's dead in the water. These are some of the people still insisting on Internet Explorer and ActiveX controls to do basic business banking in some instances!
(Score: 3, Insightful) by driverless on Wednesday June 20 2018, @12:20PM
The only ones in there that are a real threat, fallback to insecure ciphers and implementation bugs, aren't helped by going to TLS 1.2 or 1.3. In addition several of the attacks you've cited there as if they were attacks on the main protocol are simply fallback attacks, e.g. DROWN, which is an attack via SSLv2, not TLS 1.0 or 1.1. In any case if you still support SSLv2 and 512-bit RSA then I'd say that's an implementation bug, so the problem is mostly buggy code which you'll find in any version of TLS, not just 1.0 and 1.1. The rest are... well, as I said, demonstrate a real attack on a major site like eBay or Paypal that takes 5s or less to qualify as "hopelessly insecure". "Allows a HTTP Cookie to be retreived within 52 hours" and the like isn't an attack, it's a conference paper proof-of-concept.
(Score: 2, Interesting) by Anonymous Coward on Wednesday June 20 2018, @12:44PM (2 children)
So you are just posting a huge list without actually reading it and pretending it actually supports your claim? The only one on that list i saw that had anything to do with TLS 1.0 or 1.1 was beast, only TLS 1.0 was vulnerable not 1.1 like you claimed. There are several about cypher suites, those can be disabled separate from TLS version.
(Score: 2) by ledow on Wednesday June 20 2018, @01:27PM (1 child)
You mean apart form the ones that say TLS, even TLS 1.2 (Logjam), TLS 1.0 (BEAST) etc. and yet we were actually TALKING specifically about TLS 1.0 and 1.1... And several of them mention the fix is to upgrade to TLS 1.2 (or else they'd say 1.1, wouldn't they?), talk about TLS (not SSL, e.g. BREACH, CRIME) or that the TLS session can be downgraded to the point that they are vulnerable (if you have to have TLS 1.0 but turn off most of the cipher suites, why is that any different to needing to upgrade to TLS 1.2 in terms of old-client-usage?).
The protocols are broken. They are crackable NOW. Using commodity hardware and a MITM. That's a death sentence for any encryption security standard. Pretending it isn't is a nonsense. And that's just a brief page of summary CVE issues.
This is like fecking about with WEP (1997) and WPA (2003) when WPA2 (2004) and WPA3 (2018) is just sitting there... and that had actual hardware upgrades required.
TLS 1.0 (1999), TLS 1.1 (2006) are broken. Replace them with TLS 1.2 (2008) and soon TLS 1.3 (2018) where possible.
Worse case with WEP, someone got on your wireless. Worst case with TLS, every secure financial or private byte of data anyone sends over the net can be read by anyone and EC2 instance or some clever side-channels.
Banks don't up and change their software and encryption standards for a laugh. If anything, they are TEN YEARS behind.
(Score: 3, Insightful) by driverless on Wednesday June 20 2018, @03:50PM
You keep repeating this. Prove it by performing a full plaintext recovery attack on eBay or Paypal as I described earlier. Simply bleating "they're broken, they're totally insecure, they're totally broken" over and over doesn't make it so. If they're so incredibly easy to break, go ahead and do it, on a site where it actually matters like eBay or Paypal. I'll wait here.
(Score: -1, Troll) by Anonymous Coward on Wednesday June 20 2018, @03:42PM
Translation: I work for NSA and would really like if you wouldn't fix potential vulnerabilities before we use them against you.