Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Google Chrome Privacy Security

Google Guillotine Falls on Certificate Authorities WoSign, StartCom (zdnet.com) 57

Posted by msmash from the tightening-bolts dept.
Google has warned that all certificates issued by Chinese company WoSign and subsidiary StartCom will be distrusted with the release of Chrome 61. From a report: According to a Google Groups post published by Chrome security engineer Devon O'Brien, due to "several incidents" involving the certificate authority which has "not [been] in keeping with the high standards expected of CAs," Google Chrome has already begun phasing out WoSign and StartCom by only trusting certificates issued prior to October 21, 2016. The tech giant is soon to go further and will completely distrust any certificate issued by the companies within a matter of months. The Chrome development team have restricted trust through a whitelist of hostnames which are based on the Alexa Top one million sites, and this list has been pruned down over the course of Chrome releases. Once version 61 is ready for public release, this will fully distrust any existing WoSign and StartCom root certificates and all certificates they have issued.
This discussion has been archived. No new comments can be posted.

Google Guillotine Falls on Certificate Authorities WoSign, StartCom More

Google Guillotine Falls on Certificate Authorities WoSign, StartCom

Comments Filter:

  • I'm glad there are people willing to stand up to corporate misbehavior. Now if only we could get some better way of doing revocation checks.

    • It's called Let's Encrypt. Use it, love it. 90 Day certs, full automatic signing and updating. Built-in support in most distributions (even pfsense has a package now).

      If you are paying for anything other than an EV certificate you're an idiot.

      • Just a thumbs-up for Let's Encrypt. Fantastic service and super easy to set up and have it fully automated, so the short-lived certs are not an issue. It automatically takes care of itself if configured properly.

      • Re: (Score:3)

        by dgatwood ( 11270 )

        I use Let's Encrypt, too. HATE it.

        • It has to automatically update your web server configuration files because the maximum certificate validity period is too d**n short to manually update your server. (That was a show-stopper for me. I don't trust anybody modifying my insanely complex Apache config files, after several tools barfed horribly over the years.)
        • As a result of that flawed design decision, they also made the design decision to cut corners and run it as root by default. That was also a show-st

        • Re: (Score:2)

          by guruevi ( 827432 )

          Sorry, but you are an idiot. There are plenty of alternative clients for the ACME protocol, plenty of them run without root access. I have never needed to run as root and the LE client also doesn't modify my web server configs. All the client does is update the certificate every so often and then tests the configuration before deploying it. It took me all of ~10 lines to get it to work the way I want it.

          Your Apache scripts shouldn't be so complex that they become un-editable, do you even know what they do?

          • The lesson of biology is that if you make your scripts complex enough; they'll start maintaining themselves. Upgrading, even. Exact behavior of upgrades not guaranteed.

        • Re: (Score:3)

          by cdwiegand ( 2267 )

          You're kidding, right? The certificate location doesn't change. Once you setup the certificate, you just run letsencrypt-auto renew once a week and when it's done do an apachectl reload. I run over a hundred websites across 10 servers and haven't had any issues integrating LE into my flow. I will admit I use nginx and not apache, but given that the path to the certificate, chain and key don't change and are all symlinks, I fail to see how it's "complicated".

          • Re: (Score:2)

            by DeadSea ( 69598 )

            It gets much more complicated once there is a load balancer involved. I end up redirecting the acme-challenge directory to a subdomain that gets hosted without a load balancer, generating the certificate there, and then having scripts push it to the load balancer.

            The other problem I have is that certbot is not idempotent. Certbot doesn't check if the deploy scripts actually succeed or not, it just assumes they did. If they didn't, they will never get called again. Just running certbot auto-renew is

        • Re: (Score:3)

          by darkain ( 749283 )

          The default client has command line options to simply output the cert to a file and NOT touch Apache or any other HTTPD at all. In fact, in my setup, I have a 100% dedicated VM for generating certs. It does nothing else. That's it. From there, the cert files are moved via SSH to their respective web servers. But in no way shape or form does the LetsEncrypt VM have any sort of access to any infrastructure to modify it at all.

        • I was put off Let's Encrypt too, also purely because the letsencrypt program makes a severe mess of the system. However, there are many other ACME clients, and even letsencrypt.org itself no longer recommends letsencrypt (it recommends certbot at the moment, and also has around 73 other suggested clients if certbot isn't what you want).

          • Re: (Score:2)

            by dgatwood ( 11270 )

            Actually, certbot is the nightmare I was referring to.

            • Thanks, good to know. I haven't actually tried that one myself. I was planning to give Let's Encrypt another shot with some of the other clients, and happened to be looking through the list just before this story hit.

  • What's the motive for wosign? (Score:3)

    by interkin3tic ( 1469267 ) on Monday July 10, 2017 @05:04PM (#54781513)
    I don't know much about CAs. TFA says wosign issued bad certificates for github, and there were other issues. Is this incompetence or malice? Were they just overeager to sell certificates, are they catering to criminals, or is this likely to be some type of state-sponsored conspiracy to spy on secure websites?
    • Wosign was guilty of issuing certs for google.com. "It was only used in a test environment" was their excuse. Maybe it was, but it could have easily been used in public instead. It's shady practice, and for that, they will pay with their lives!

      • Re: (Score:2)

        by _merlin ( 160982 )

        That was Symantec issuing google.com certificates for their test environment, not WoSign. The thing everyone jumped on WoSign for was doing a customer a favour. Some significant Australian customer wasn't ready for SHA1 certificates being phased out and asked if WoSign could help them out. WoSign issued back-dated SHA1 certificates for the customer.

        IMO, Symantec was worse yet they haven't been punished anywhere near as hard, and the timing seemed rather "convenient" in that it coincided with the launch o

        • Re: (Score:2)

          by CRC'99 ( 96526 )

          The thing everyone jumped on WoSign for was doing a customer a favour. Some significant Australian customer wasn't ready for SHA1 certificates being phased out and asked if WoSign could help them out. WoSign issued back-dated SHA1 certificates for the customer.

          Yep - and I'm pretty sure we know who that customer was. There are still major institutions still using SHA1 certs internally - and if they get moved to newer ones by the end of the year then I'd be shocked. The reality is, this stinks of a scapegoat - the industry in question would face *MASSIVE* disruption for the everyday Australian because of the relatively quick move to higher level certs. A lot of these are still contained within embedded devices that cannot upgrade so easily.

          Instead, let's execute th

          • The thing everyone jumped on WoSign for was doing a customer a favour. Some significant Australian customer wasn't ready for SHA1 certificates being phased out and asked if WoSign could help them out. WoSign issued back-dated SHA1 certificates for the customer.

            Yep - and I'm pretty sure we know who that customer was. There are still major institutions still using SHA1 certs internally - and if they get moved to newer ones by the end of the year then I'd be shocked. The reality is, this stinks of a scapegoat - the industry in question would face *MASSIVE* disruption for the everyday Australian because of the relatively quick move to higher level certs. A lot of these are still contained within embedded devices that cannot upgrade so easily.

            Instead, let's execute the CA for political reasons. Don't pretend its anything else.

            Looking through the list on Mozilla's list of WoSign Issues [mozilla.org] it looks like WoSign not just issued

            • long lived SHA1 certs
            • identical certs other than the notbefore date
            • certs with identical serials
            • certs that violate the "Baseline Requirements"
            • certs using unapproved cryptographic settings

            but their setup also violated a number of other best practices and security measures too (such as unpatched servers). However I'll note that on the political front folks were unhappy that the Startcom acquisition wasn't made public

            • Re: (Score:2)

              by CRC'99 ( 96526 )

              But did you notice that most listings there are "its not against the rules - but we don't like it anyway".

              Yes, there have been some screwups, bugs and other problems that they seem to have fixed - but show me one CA that hasn't had a number of issues in their history...

    • Unfortunately, one of the disadvantages of deviating from strictly correct behavior as a CA is that it makes it harder for people trying to figure out who the threat is to answer that question; and 'all of the above' benefit from those bad practices.

      If your approach to 'customer service' involves a willingness to forge certs for them; it may start with a few extra sales to admins trying to dodge deadlines; but criminals will have an obvious interest in someone willing to issue dodgy certs for a few extra

  • Anyone else find it odd that the whitelist depends on the version? Like they hardcoded it?

  • Google Guillotine? (Score:5, Funny)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Monday July 10, 2017 @06:18PM (#54782007) Homepage Journal

    Oh great, another Google service that will probably be cancelled within a year

  • It wasn't just a few bad certs, there was a whole set of issues. Here is Mozilla's list: https://wiki.mozilla.org/CA:Wo... [mozilla.org]

    Check out issue N, it is particularly bad.

  • This really sucks for customers of StartCom (StartSSL):

    • Your website suddenly stops working with no warning.
    • There is no equivalent alternative to StartSSL

    Basically Google (and to a lesser extent Firefox) have handled this really badly. I found out about this issue when I got a new certificate and it wouldn't work: StartSSL certificate gives SEC_ERROR_REVOKED_CERTIFICATE in Firefox and ERR_CERT_AUTHORITY_INVALID in Chrome [stackexchange.com]

    • The browser error messages are cryptic and inconsistent. None of them say what th

Slashdot Top Deals

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Close