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