SoylentNews is people
SoylentNews
Over the last several months Mozilla has been investigating a large number of breaches of what Mozilla deems to be acceptable CA protocols by the Chinese root CA WoSign and their perhaps better known subsidiary StartCom, whose acquistion by WoSign is one of the issues in question. Mozilla has now published their proposed solution (GoogleDocs link), and it's not looking good for WoSign and Startcom. Mozilla's position is that they have lost trust in WoSign and, by association StartCom, with a proposed action to give WoSign and StartCom a "timeout" by distrusting any certificates issued after a date to be determined in the near future for a period of one year, essentially preventing them issuing any certificates that will be trusted by Mozilla. Attempts to circumvent this by back-dating the valid-from date will result in an immediate and permanent revocation of trust, and there are some major actions required to re-establish that trust at the end of the time out as well.
This seems like a rather elegant, if somewhat draconian, solution to the issue of what to do when a CA steps out of line. Revoking trust for certificates issued after a given date does not invalidate existing certificates and thereby inconvenience their owners, but it does put a severe - and potentially business ending - penalty on the CA in question. Basically, WoSign and StartCom will have a year where they cannot issue any new certificates that Mozilla will trust, and will also have to inform any existing customers that have certificate renewals due within that period they cannot do so and they will need to go else where - hardly good PR!
What do the Soylentils think? Is Mozilla going too far here, or is their proposal justified and reasonable given WoSign's actions, making a good template for potential future breaches of trust by root CAs, particularly in the wake of other CA trust breaches by the likes of CNNIC, DigiNotar, and Symantec?
It appears this situation developed from this discussion at Google Groups.
[Editor's Note: SoylentNews used StartCom certificates in the past but we now use only certificates from Gandi and "Let's Encrypt."]
(Score: 1, Insightful) by Anonymous Coward on Tuesday September 27 2016, @09:31AM
This is prime example of why we need DNSSEC, yet everyone is dragging their feet on it. No DNSSEC, then no DANE-TLS and we reaffirm the broken CA model.
And before you jump on that DNSSEC you still have to "trust", well, is it easier to monitor the trust of one root or the current clusterfuck of root CAs? And while DANE-TLS doesn't kill off the CA model completely, at very least it makes it a secondary verification entity (like that EV certificates?), not as the only verification method.
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @01:32PM
DANE-TLS doesn't really change much, just moves the trust anchor from a certificate authority to another party: the domain registry. I suppose this makes some sense for DV certs but nothing else.
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @09:01PM
I think you need to re-read my comment.
(Score: 2) by NCommander on Tuesday September 27 2016, @06:11PM
DANE-TLS has some inherent problems that make it difficult in real life. While DNSSEC works well for securing zone transfers, it doesn't protect the last mile between the client and the resolver. It's fairly easy to strip DNSSEC traffic in flight, and some DNS servers rewrite records in flight (Google did a test with a TXT record that Chrome would try to access and found only about 70% of users could actually get it unmolested). You can't use an insecure medium for authentication, and validating a DNSSEC chain can require O(N) DNS queries for the TLD, the domain, and sometimes subdomains. The size of DNSSEC records also means you either need to do TCP connections, or pray EDNS0 actually works as advertised.
There was work on adding DANE DNSSEC chain stapling to OpenSSL/NSS, but it never seems to have got formalized into a spec.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @09:13PM
While DNSSEC works well for securing zone transfers, it doesn't protect the last mile between the client and the resolver.
Sure it does, if the client actually wants to verify it. You can either verify the record in the client or have a trusted local DNSSEC authenticating DNS library that does nothing but verify forwarded queries from the DNS server.
But we seem to be stuck with the mentality of "the new stuff is not as perfect as I imagined, so let's keep using totally broken stuff instead". Kind of reminds me of IPv6 adoption rate. The current state is any DNS query can effectively be MITM by anyone with MITM capability, and that list is kind of long. Even if only last hop is vulnerable because of lack of proper library support, MITM scenario becomes much more complicated.
(Score: 0) by Anonymous Coward on Tuesday September 27 2016, @09:21PM
The only thing worse than no sense of security if a false one.
With the major browsers crapping themselves the moment they see a self-signed certificate, I see little point in the work to move to a new-but-also-broken system. Once the criminals at the NSA et al have been dragged from their holes, quickly tried, then presumably executed, we can revisit the subject.
(Score: 2) by NCommander on Tuesday September 27 2016, @11:05PM
The only way for a client to securely verify it is to enumerate the root zone, then the TLD, and downward. While caching helps with the amount of lookups, you're dealing with a serious performance hit, and can still be subject to DNSSEC stripping attacks unless you *know* the target is supposed to be DNSSEC signed.
Still always moving