Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday September 27 2016, @07:23AM   Printer-friendly
from the who-CAN-you-trust? dept.

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."]


Original Submission

Related Stories

Mozilla Joins Google Shunning China's Root Certificate Authority 30 comments

El Reg has published a story which discusses the steps Google and Mozilla are taking, in response to the apparent misuse of a China Internet Network Information Center (CNNIC) intermediate Cetificate Authority (CA) administered by MCS Holdings, who claim it was all just a big mistake.

Firefox-maker Mozilla has joined Google in refusing to recognize SSL certificates issued by the China Internet Network Information Centre (CNNIC).

This should not be a surprise since:

This comes after a security biz in Egypt used a CNNIC-issued intermediate certificate to create unauthorized SSL certs that could be used to trick people into connecting to bogus, password-stealing Gmail.com or Google.com websites.

As a result:

[A]ll Mozilla products – including the Firefox web browser and the Thunderbird email client, among others – will be updated so that all CNNIC-based certificates issued on or after April 1, 2015 are considered untrusted.

Mozilla said it also plans to ask CNNIC for a comprehensive list of all of its current valid certificates. Any certificates issued before April 1 that are not included on this whitelist will also be subject to potential "further action."

Microsoft has also revoked the suspect CNNIC intermediate CA:

Microsoft is updating the Certificate Trust list (CTL) to remove the trust of the subordinate CA certificate. The trusted root Certificate Authority, the China Internet Network Information Center (CNNIC), has also revoked the certificate of the subordinate CA.

Google Drops the Boom on WoSign, StartCom Certs for Good 8 comments

Last August, after being alerted by GitHub's security team that the certificate authority WoSign had errantly issued a certificate for a GitHub domain to someone other than GitHub, Google began an investigation in collaboration with the Mozilla Foundation and a group of security professionals into the company's certificate issuance practices. The investigation uncovered a pattern of bad practices at WoSign and its subsidiary StartCom dating back to the spring of 2015. As a result, Google moved last October to begin distrusting new certificates issued by the two companies, stating "Google has determined that two CAs, WoSign and StartCom, have not maintained the high standards expected of CAs and will no longer be trusted by Google Chrome."

WoSign (based in Shenzen, China) and StartCom (based in Eliat, Israel) are among the few low-cost certificate providers who've offered wildcard certificates. StartCom's StartSSL offers free Class 1 certificates, and $60-per-year wildcard certificates—allowing the use of a single certificate on multiple subdomains with a single confirmation. This made the service wildly popular. But bugs in WoSign's software allowed a number of misregistrations of certificates. One bug allowed someone with control of a subdomain to claim control of the whole root domain for certificates. The investigation also found that WoSign was backdating the SSL certificates it issued to get around the deadline set for certificate authorities to stop issuing SHA-1 SSL certificates by January 1, 2016. WoSign continued to issue the less secure SHA-1 SSL certificates well into 2016.

Source: Google drops the boom on WoSign, StartCom certs for good

Previously:
Heads Roll as Qihoo 360 Moves to End Wosign, Startcom Certificate Row
Game Over for WoSign and StartCom Certificate Authorities?


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Flamebait) by TheRaven on Tuesday September 27 2016, @08:22AM

    by TheRaven (270) on Tuesday September 27 2016, @08:22AM (#406877) Journal

    StartCom was the company that made SSL possible for a lot of people. Their free SSL certs were around before Let's Encrypt was even an idea and are still a lot easier to use than Let's Encrypt (can you even get an S/MIME cert that mail readers trust with Let's Encrypt?). Looking at the incident report, the issues are far more minor than Commodo a couple of years ago (and all of the ones I read had a timely response from WoSign that resolved the issue). I removed Commodo from the list of roots that I trust as a result, but Mozilla still quite happily trusts them even though they've shown that they are totally untrustworthy.

    If StartCom certs start being rejected by Mozilla, then my suggestion will be to get a different web browser. The annoying thing here is the number of third-party things that use the Mozilla trusted root cert list...

    --
    sudo mod me up
    • (Score: 5, Informative) by zocalo on Tuesday September 27 2016, @09:15AM

      by zocalo (302) on Tuesday September 27 2016, @09:15AM (#406883)
      Look again. They're not going to breaking any existing certs - by Startcom or WoSign - they're proposing to start rejecting certs with a NotBefore date that is yet to be determined and lies at some point in the future specifically to avoid end user disruption; there won't be any existing certs that stop working until they expire anyway, apart from the few documented special cases of the "Macau certificates". They've also identified some major flaws and policy violations in WoSign's setup that now appear to have been adopted by StartCom, either by a copy of the WoSign proceedures and infrastructure or by moving StartCom's operations to China - the time of certificate issuance suggests the latter, and use of infratructure software that is five *years* behind on its patches. Hardly a ringing endorsement for a business that is, by definition, based on trust and accountability. You do have a point on Comodo though; they only managed to get away with it by being the first one to get caught out so the policies and procedures in place were not as robust, but everyone in the CA business should be well aware that things have been getting much more strict since then with the other CA issues I linked at the end.

      Anyway, good luck with your new browser. Ryan Sleevi, one of the authors of the proposal, works for Google on Chromium's CA, so it seems very likely Google will be following suit, and since all the major players have generally acted in unison when it comes to matters like this I'd say the writing is on the wall unless there are some compelling objections raised in response to Mozilla's proposal.
      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 2) by TheRaven on Wednesday September 28 2016, @08:46AM

        by TheRaven (270) on Wednesday September 28 2016, @08:46AM (#407287) Journal

        They're not going to breaking any existing certs - by Startcom or WoSign - they're proposing to start rejecting certs with a NotBefore date that is yet to be determined and lies at some point in the future specifically to avoid end user disruption

        And they're going to continue to do so for a year. StartSSL's free certs are only valid for one year, which means that this is guaranteeing to break free certs for at least a few months and force everyone to move to something else. Purely by coincidence, the backers of this proposal are also the backers of Let's Encrypt, for whom StartCom is the major competitor.

        --
        sudo mod me up
    • (Score: 0) by Anonymous Coward on Wednesday September 28 2016, @03:26PM

      by Anonymous Coward on Wednesday September 28 2016, @03:26PM (#407435)

      still a lot easier to use than Let's Encrypt

      lets encrypt is very easy once you figure it out. you just run a command and you have a cert in a couple seconds. how could it be any easier? maybe you just need to stick with your windows pc and quit trying to admin a server.

  • (Score: 2) by MostCynical on Tuesday September 27 2016, @08:26AM

    by MostCynical (2589) on Tuesday September 27 2016, @08:26AM (#406878)

    If you decide you can't trust a Root CA, what other options do browser suppliers have?

    Can self-signed certificates be replaced with "signed by other" (with no signing authority allowed to certify the one that certified them)?

    --
    (Score: tau, Irrational)
    • (Score: 0) by Anonymous Coward on Thursday September 29 2016, @06:47AM

      by Anonymous Coward on Thursday September 29 2016, @06:47AM (#407762)

      For Mozilla there you may encounter some problems when you decide to not trust a Root CA for all sites, but you still trust particular sites that that CA has issued certs to: https://soylentnews.org/comments.pl?sid=15716&cid=406960#commentwrap [soylentnews.org]

      As for other browsers, on Windows at least - IE and Chrome (and other browsers and apps that use Windows CA stuff) are worse in my opinion: https://www.proper.com/root-cert-problem/ [proper.com]
      With IE and Chrome on Windows, the NSA could create a new cert and have Microsoft or some other CA that you "have to trust" sign it and your computer will automagically add it and trust it.

  • (Score: 5, Insightful) by bradley13 on Tuesday September 27 2016, @08:28AM

    by bradley13 (3053) Subscriber Badge on Tuesday September 27 2016, @08:28AM (#406879) Homepage Journal

    Not far enough, really. The way the Internet is currently set up, trust in CAs is essential. This is no place for "three strikes" or even "two strikes". As far as I'm concerned, if a CA violates trust guidelines, their business is done, they should be permanently eliminated from the list of trusted CAs.

    On the other hand, there is the problem of catching abuses. Recently, Google discovered that Symantec had issues unauthorized certificates for various domains [engadget.com]. They discovered this by happenstance - how many times does it go unnoticed? For example, I am certain that governments have pressured CAs into issuing fake certificates, to enable MITM surveillance of HTTPS connections for specific victims. You average surveillance target will never look past the green padlock, and will never notice these unauthorized certificates.

    So for me the larger question is: How can we alter the Internet, so that unauthorized certificates are noticed and reported? That is a prerequisite to bringing down the ban-hammer on the guilty CAs.

    --
    Everyone is somebody else's weirdo.
  • (Score: 1, Insightful) by Anonymous Coward on Tuesday September 27 2016, @09:31AM

    by Anonymous Coward on Tuesday September 27 2016, @09:31AM (#406887)

    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

      by Anonymous Coward on Tuesday September 27 2016, @01:32PM (#406935)

      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

        by Anonymous Coward on Tuesday September 27 2016, @09:01PM (#407095)

        I think you need to re-read my comment.

    • (Score: 2) by NCommander on Tuesday September 27 2016, @06:11PM

      by NCommander (2) Subscriber Badge <mcasadevall@soylentnews.org> on Tuesday September 27 2016, @06:11PM (#407056) Homepage Journal

      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

        by Anonymous Coward on Tuesday September 27 2016, @09:13PM (#407100)

        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

          by Anonymous Coward on Tuesday September 27 2016, @09:21PM (#407104)

          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

          by NCommander (2) Subscriber Badge <mcasadevall@soylentnews.org> on Tuesday September 27 2016, @11:05PM (#407121) Homepage Journal

          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
  • (Score: 1, Insightful) by Anonymous Coward on Tuesday September 27 2016, @10:09AM

    by Anonymous Coward on Tuesday September 27 2016, @10:09AM (#406899)

    Maybe it would be better for many online security system to start setting up a global Web of Trust. This way you can determine yourself who to trust and who not, and if you don't know what to do, let friends/relatives have a saying for you (in times of social media and following that should be not too hard).

    • (Score: 2, Informative) by Anonymous Coward on Tuesday September 27 2016, @02:30PM

      by Anonymous Coward on Tuesday September 27 2016, @02:30PM (#406960)

      You used to be able to do that with Mozilla - disable all CAs you don't or can't trust then only accept CAs or server certs on a case by case basis.

      Unfortunately Mozilla's implementation of HSTS now makes that more difficult than it should be. For example if you stop trusting UserTrust or Gandi for whatever reason (say one day they screw up badly or decide to sign WoSign's cert) then you can't connect to soylentnews at all even if you still trust soylentnews. Mozilla won't allow you to add an exception (there is a workaround that involves invalidating the HSTS lists timestamp but a more appropriate configurable would be appreciated :) ).

      • (Score: 1) by Scruffy Beard 2 on Tuesday September 27 2016, @06:25PM

        by Scruffy Beard 2 (6030) on Tuesday September 27 2016, @06:25PM (#407066)

        For a while I was using "Certificate Patrol". Not sure if it still works.

        I think I gave up on it because I had no good way to know how suspicious a cert change really is.\

        • (Score: 0) by Anonymous Coward on Wednesday September 28 2016, @08:58AM

          by Anonymous Coward on Wednesday September 28 2016, @08:58AM (#407291)

          I gave up on it because it can't handle more than one CA for a site. Many popular sites nowadays have more than one CA (load balancing or whatever).

          So Certificate Patrol would keep showing warnings when you get one or the other.