Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Reducing Trust In Symantec Certificates Following Numerous Slip-Ups (bleepingcomputer.com)

Posted by BeauHD on from the play-by-the-rules dept.

An anonymous Slashdot reader writes from a report via BleepingComputer: Google Chrome engineers announced plans to gradually remove trust in old Symantec SSL certificates and intent to reduce the accepted validity period of newly issued Symantec certificates, following repeated slip-ups on the part of Symantec. Google's decision comes after the conclusion of an investigation that started on January 19, which unearthed several problems with Symantec's certificate issuance process, such as 30,000 misused certificates. In September 2015, Google also discovered that Symantec issued SSL certificates for Google.com without authorization. Symantec blamed the incident on three rogue employees, whom it later fired. This move from Google will force all owners of older Symantec certificates to request a new one. Google hopes that by that point, Symantec would have revamped its infrastructure and will be following the rules agreed upon by all the other CAs and browser makers.

12 of 78 comments (clear)

  1. Bluecoat by Anonymous Coward · · Score: 5, Informative

    They issued root faking ability to bluecoat. Their certs are untrustable at this point.

    1. Re: Bluecoat by bsDaemon · · Score: 5, Insightful

      Also, they straight bought out BC, meaning a major root CA owns a major SSL/TLS intercept platform as well. But of course, we can trust them...

  2. Re: Objective Case by Zero__Kelvin · · Score: 2

    A low ID indicates the account was created a long time ago. It doesn't say anything about how long he has been actually reading Slashduh articles.

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  3. The Dying Days of the Certificate industry by rahvin112 · · Score: 4, Interesting

    If there is one thing the certificate industry has proven it's that you can't trust any of them. The only solution is the automated solutions like the non-profit Let's encrypt have built. You know it's a good cert because only the person in control of the domain could get it. And I'll tell you what even with it's warts I trust it way more than I trust these damn companies that have 4 year olds signing off on certificate procedures and handing certificates to anyone with the cash.

    Ultimately it's going to be movements like Let's Encrypt that fix this trust issue by taking it out of the hands of people trying to make a buck on "trust" when none of them could be trusted.

    1. Re:The Dying Days of the Certificate industry by Anonymous Coward · · Score: 3, Informative

      And?

      If somebody is capable of getting into the system far enough that they can spoof the authentication methods Let's Encrypt uses to verify ownership/control of the domain, they can also, in all likelihood, gain access to the private key as well.

      If they can gain access to the private key, then that's it: game over. Doesn't matter what you do, TLS is not going to save your customers' hides. The only way to deal with that problem is to lock down the server so they can't get back in, and create a new certificate, revoking the old one.

      TLS is not a panacea for poor server-side security - it's an adjunct to it. If server security has been broken, TLS can't fix it.

    2. Re:The Dying Days of the Certificate industry by AmiMoJo · · Score: 2

      Let's Encrypt doesn't verify identity, which is one of the major functions of the certificate system. The certs that Let's Encrypt offer are enough to enable HTTPS, but not to confirm the identity of the organization running the web site. Such a cert won't give you confidence that randombank.com is actually being run by Random Bank Inc.

      Put another way, if you managed to register gooogle.com you could get a Let's Encrypt cert for it. What certificate authorities are supposed to do is verify that the person requesting the certificate is actually who they say they are, and refuse to offer a cert for "gooogle.com" that says it belongs to "Google Inc."

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  4. Symantec's take on security by Plocmstart · · Score: 2

    I met a marketing exec at the Freescale Technology Forum in Austin last May. Their take on things was the good 'ol way was still the best way. I need to find his business card since he said he'd buy me lunch if Bitcoin was still around a year later.

  5. Re:Why do we need CAs at all? by jonwil · · Score: 3, Interesting

    What you suggest exists. Its called DANE.
    However browser vendors (like Google and Mozilla) have been reluctant to implement it because there are many real-world cases where DNS servers of various sorts simply dont support DNSSEC and DANE and also because DNSSEC and DANE use weaker 1024 bit keys in some places (chosen to keep bandwidth usage lower).

  6. Re:Norton by Z00L00K · · Score: 2

    More important is that this further highlights that the "trust" system as it is designed today is broken.

    The trust system is based on that you get a default trust of a few CAs in the top, and if one is compromised the house of card suffers severely. And what happens if a CA is ordered by a government to provide false certificates? We can't know if that's the case or not because it will look identical to a real certificate unless it's inspected on a very low level and compared with the certificates assigned to the company using them.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  7. Re:Let's Encrypt by campuscodi · · Score: 2

    No it's not. Let's Encrypt is even a bigger offender. Example: Let's Encrypt issued over 15,000 certificates for domains containing PayPal in their name (obvious phishing sites): https://crt.sh/?identity=paypa...

  8. Re:Norton by TheRaven64 · · Score: 2

    The difference now is that many hackers have developed tools for MITM attacks on https.

    Yes and the same tools work with a self-signed cert or with HTTP. To make them work with HTTPS and a signed cert, you need to have a compromised CA signing cert. This is still currently mostly limited to nation-state adversaries.

    --
    I am TheRaven on Soylent News
  9. "Signed all the way". That's just a different CA by raymorris · · Score: 2

    > Can someone explain to me why domains don't just include a public key in their DNS record (signed all the way up to a root authority) ...
    > Why, exactly, are we still fucking around with certificate authorities

    Okay, so the DNS record would have a signed certificate. You'd have "the root authority" sign certificates? You would trust this authority for certificates, and this "certificate signing authority" would be better than having a certificate authority?

    What you've suggested can be said more succinctly as follows:
    Why aren't the people who run DNS also certificate authorities?

    You still have CA, you've just decided that the CA needs to be the same people who run DNS, because ... well no good reason that I can think of. What does that gain you?