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: 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.