Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Google The Internet

Google Threatens Action Against Symantec After Botched Investigation (itworld.com) 95

itwbennett writes: Through its acquisition of Verisign's authentication business unit in 2010, Symantec became one of the largest certificate authorities (CAs) in the world. In September of this year, Google discovered that Symantec had issued a pre-certificate for google.com without its knowledge. Symantec's initial investigation of the incident determined that 23 test certificates had been issued for domain names belonging to Google, Opera and three other unnamed organizations. But Google quickly found additional unauthorized certificates that Symantec missed. Now, Google wants Symantec to disclose all certificates issued by its SSL business going forward.
This discussion has been archived. No new comments can be posted.

Google Threatens Action Against Symantec After Botched Investigation

Comments Filter:
  • Since the first time I read about this I thought it was an inside job. Symantec should just fess up and admit it. There's no shame in it.
  • by vvaduva ( 859950 ) on Thursday October 29, 2015 @01:38PM (#50826731)

    Symantec has stopped being a "security company" long ago and has become a massive sales organization focused on little more than quarterly results rather than quality products. They've ruined PGP...Verisign is next. Who knows what else they are working on destroying?

    • by Anonymous Coward

      Hello, can you expand on that? How did they ruin PGP? (I am not flaming, I am just really curious and googling "symantec ruin pgp" doesn't yield much)

      • by vvaduva ( 859950 )

        A lot of the senior PGP developers are long gone. The product was split into several smaller pieces to help their bottom line, like e-mail encryption, disk encryption and their file encryption tools. Most people looking to buy the commercial version of PGP don't even know WHAT to buy simply because their marketing and sales lingo is so deliberately confusing.

    • by Burz ( 138833 )

      They sell "legal intercept" services to governments. *Ahem*

  • by Anonymous Coward on Thursday October 29, 2015 @01:42PM (#50826755)

    Seriously, the whole point of a CA is that it's a *trusted* party... who trusts them these days? How can they still claim a piece of this business pie???

    • by Anonymous Coward

      Really, how can you trust any commercial CA? How can you trust any authority that can be purchased?

      If there's anything I've learned about capitalism, its that there is no such thing as trust. Everything is for sale.

      I'm not saying that Symantec set out to defraud Google but when they bought Verisign they were probably thinking about money first, and being a serious trust authority second (or third, or fourth, or not at all). Management shuffles. Hires and fires based on politics rather than merit or need. (M

    • by Anonymous Coward

      The current CA system is broken and overrated. The problem is most browser makers seem to be in league with some of them.

      What would serve better those who actually care about security is to add the option to behave more like SSH. So if a cert changes for no good reason even if its signed by some CA you get a warning. The problem is you need to be able to say OK to multiple different certs per domain due to load/site balancers.

      How it could work - you visit a site for the first time, and the multiple differen

      • The problem is you need to be able to say OK to multiple different certs per domain due to load/site balancers.

        Actually, no you don't. In a situation like that, you should be using a SAN (Subject Alternative Name) certificate with all the names you intend to use, or just the single name (like https://www.google.com/ [google.com] you want the load balancer to answer. You also could use self signed behind the balancer, or no ssl at all, depending on settings.

  • by Anonymous Coward

    Better option is to email companies using verisign and tell them we the users can't trust verisign anymore.

    • Who would you recommend instead? Thawt? GoDaddy? Is there anyone that can be trusted in this industry anymore?

      • Well, I always trust all my security to APKWare. With the IP addresses of every secure site you'd ever want to go to in your HOSTS file, why would you even bother using HTTPS at all? ;-)

  • by Todd Knarr ( 15451 ) on Thursday October 29, 2015 @01:53PM (#50826851) Homepage

    I'd wonder why they needed test certificates at all? For any testing of their systems and software they could use fake domains and organizations located under a domain they own and use just for that purpose (I used the .ttk TLD for that sort of thing for years, back before the gTLD flood). If they were testing issuing of certificates to specific organizations, there wouldn't be any need for them to ever get to servers. I can think of no good reason Symantec would need to have certificates issued to Google, and several bad reasons why an antivirus product would want a certificate that'd be accepted as a genuine certificate for a Web site.

    • by msauve ( 701917 )
      The did that, in addition:

      Symantec re-opened the investigation and uncovered an additional 164 test certificates that it issued for 76 domains it didn't own and 2,458 certificates issued for domains that hadn't been registered.

      But, you're also doing it wrong.

      .test is the only appropriate TLD (see RFC 6761) aside from one you actually own, of course.

      • True, but at the time that RFC didn't exist. And a lot of software had a hard-coded rule about TLDs: ccTLDs were 2 characters, the generic TLDs were 3 characters and only a few were valid. Trying to use a TLD with more than 3 characters would make some software reject it as invalid, but it was easy to pick a 3-character TLD that was guaranteed not to exist in the global DNS.

        Thankfully we've moved past that stage. Though I would like to see a special-use domain "local" defined for names that aren't for testi

        • by dissy ( 172727 )

          True, but at the time that RFC didn't exist. And a lot of software had a hard-coded rule about TLDs: ccTLDs were 2 characters, the generic TLDs were 3 characters and only a few were valid. Trying to use a TLD with more than 3 characters would make some software reject it as invalid, but it was easy to pick a 3-character TLD that was guaranteed not to exist in the global DNS.

          Thankfully we've moved past that stage. Though I would like to see a special-use domain "local" defined for names that aren't for testing but are restricted to the organization's network.

          Even those rules are wrong, and were wrong back in the day.

          The very first TLD for example is 4 characters, and that TLD exists and is in use to this very day.

          (And no matter how wrong it is, it's always fun to stick an A record in your .arpa reverse-zone to an IP pointing back to its own PTR!)

          Thankfully I've never run into any program that rejected .arpa as a valid TLD in my 25 years on the network.
          Much fun on IRC it was.

          But even so, I haven't used anything but .test .invalid and .example since 2000 per the

        • Issuing for .test and .local are strictly prohibited by the CABForum EV requirements. They will soon be outlawed for DV under the basic requirements.

          What seems to have happened is that instead of issuing all test certs for test.verisign.com as the procedure manual required, they had to modify the procedure when Symantec took over and they no longer had verisign.com.

          So instead of doing what they should have done and using test.symantec.com or a test domain bought for the purpose, they typed the first name th

          • Yep, and I agree with .local, .test and bare names and stuff like localhost not being allowed for commercial CAs. If I used them locally it'd be with my own internal CA for certificates (I have one set up, but that hodge-podge of shell scripts would make you cry).

            @sigh Dammit, "The Marching Morons" was supposed to be a satire, not a bloody policy document.

    • by athmanb ( 100367 )
      There are reasons for creating fake certificates, like when you want to sniff your own HTTPS traffic to aid with web debugging. But what Symantec never should've done is use their proper CA for that. They should've used an internal CA that their own computers trust but nobody outside knows about, like any company does that can't just walk across the office and get a "real" certificate from Frank.
      • Damn right they should. The CPS has a long section on the use of test hardware.

        The problem is that all the original team that built VeriSign have been gone for years. A lot of us left before the sale of the PKI business to Symantec. The PKI/DNS merger was not a happy or successful partnership. The original point of the merger was to deploy DNSSEC. that effort was then sabotaged by folk in IETF and ICANN which has delayed the project by at least 10 and possibly 20 years. ATLAS was originally designed to supp

  • by koan ( 80826 )

    "Now, Google wants Symantec to disclose all certificates issued by its SSL business going forward."

    The NSA/GCHQ won't like that.

    • Google Chrome (45-50% desktop+mobile browser market share) can stop trusting all certificates signed Symantec and display security warnings encouraging users to change Certification Authority. Aside of essentially losing the future certificate business, many customers will require refund for already purchased certificates. So yeah, Symantec will just comply with whatever Google says.

  • by ealbers ( 553702 ) on Thursday October 29, 2015 @02:08PM (#50826957)

    The certificates were used for man in the middle attacks, to decrypt google stuff before it got to them by the NSA.

  • Would anyone here like to explain to me, in relation to security on the Internet, how issuing CAs work and how this could lead to a security violation. Please don't use numerical formulas ..
    • Let's start with asymmetric encryption. The cipher has two keys, which appear unrelated to each other, such that what is encrypted by one key is decrypted by the other. We divide these into public and private keys, and let people know about the public key and keep the private key secret. Suppose you do that. To send you something nobody else can read, I encrypt my message with your public key, and you can use your private key to read it. The advantage here is that I can get your public key easily with

  • by LordKronos ( 470910 ) on Thursday October 29, 2015 @03:41PM (#50827651)

    Sorry, but I have no clue what a pre-certificate is. Google search doesn't seem to help me either.

    • Re: (Score:2, Informative)

      by dissy ( 172727 )

      Sorry, but I have no clue what a pre-certificate is. Google search doesn't seem to help me either.

      I assumed they meant a premium certificate, aka a class 3 EV (extended validation) certificate or higher.

      It's just marketing bullshit pretty much, and the only difference is some flags set in the cert when its signed by the CA.

    • by Zeinfeld ( 263942 ) on Thursday October 29, 2015 @11:46PM (#50830341) Homepage

      A pre-certificate is created for use in the Certificate Transparency system. Introducing pre-certificates allows the CT log proof to be included in the certificate presented to an SSL/TLS server.

      The CT system generates a proof that a pre-certificate has been enrolled in it. The proof is then added to the pre-certificate as an extension and the whole thing signed with the production key to make the actual certificate.

      If the CT system logged the actual certificate, the proof of enrollment would only be available after the certificate had been created.

Any program which runs right is obsolete.

Working...