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