Slashdot Mirror


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

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.

9 of 57 comments (clear)

  1. What's the motive for wosign? by interkin3tic · · Score: 2

    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?

    1. Re:What's the motive for wosign? by freeze128 · · Score: 2

      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!

  2. Re:Goodbye by Anonymous Coward · · Score: 2, Insightful

    Your position is actually a very reasonable. You don't know any of the certificate issuers. It is impossible for you to fully trust any of them. At most, you have some "policy" that supposedly tells you what some faceless corporation is doing.

    Fortunately, people implemented solutions to this problem about a quarter century ago. "Moderately trust" your CAs. And if an identity is signed by (say) three moderately-trusted CAs then you consider it fairly trustworthy. You could even work in scoring rules for whether or not the CAs are jurisdictionally diverse enough. (e.g. If a Chinese signer and a US government signer and a French signer all agree, then either it's correct, or you are up against a conspiracy so massive that you'd never beat it anyway.)

    What's the probability that someone is up to something naughty? Some fraction. Now raise that fraction to some more-than-1 power, say the third power. That's how trickable you'd be, if we used modern PK tech, like what PGP has.

  3. Re:Good by dgatwood · · Score: 2

    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-stopper for me, and should be for anyone who is serious about security.
    • The default behavior is fundamentally incompatible with key pinning (a recommended security practice) because it generates a new key every time it generates a new cert.

    The security horrors get deeper and deeper the further you dig, hence the reason I steered clear of it for years. But when the last free TLS cert provider other than LetsEncrypt got the axe (StartSSL), I finally concluded that I'd just have to close my eyes and think of England.

    I ended up creating a cron job that runs a pile of custom code wrapped around their manual updater (which bizarrely doesn't tell you the name of the cert file it just created—ick). It then updates a small crypto config file that gets imported from all the various parts of my main Apache config files. Nine months later, I'm still fixing integration issues, mostly stemming from permissions problems.

    By contrast, I used StartSSL (one of the registrars that is getting the axe here) for half a decade with no real problems. It was easy. Once a year, I requested a new cert. Five minutes later, I was done. It worked much better than LetsEncrypt, from my perspective.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  4. Re:Goodbye by sexconker · · Score: 2

    Why anyone should trust any cert not issued by a cert authority they personally control or vet and trust is beyond me.
    The whole CA game is about a half step more legitimate than the TSA.

  5. Google Guillotine? by drinkypoo · · Score: 4, Funny

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

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  6. Re:Good by cdwiegand · · Score: 2

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

    --
    . Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
  7. Re:Good by darkain · · Score: 2

    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.

  8. WoSign's issues not just political... by Sits · · Score: 2

    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 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 earlier. Outside that though there are a lot of different technical complaints.

    CA's have been dropped in the past for non-political problems (see DigiNotar) so I don't think it's fair to attribute WoSign's woes to purely political motivations as you alleged.