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.
Inside job? (Score:2)
Symantec is a sales organization (Score:5, Insightful)
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?
Re: (Score:1)
Re: (Score:1)
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)
Re: (Score:3)
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.
Re: (Score:2)
They sell "legal intercept" services to governments. *Ahem*
Re: (Score:1)
Re: (Score:1)
I do not understand what is so scary about a message saying, "hey, you've never been to this SSL domain before and it has a self signed certificate. A self signed certificate means that the owner of the domain created a certificate which is used to encrypt communications between your browser and the domain. In order to browse this site you must accept this certificate however you must be sure that this is the domain which you intended. Click here to read more about Self Signed Certificates..."
Who is the audience supposed to be understanding this?
Re: (Score:3, Insightful)
If you are running a utiliy like Convergence [convergence.io] or Perspectives [mozilla.org] to monitor certificates, I'll buy your solution. Otherwise, you're just setting yourself up for a MITM attack.
Re: (Score:1)
Because you can't know if it's really self-signed, even if you "call you friend in some other location". It reduces the likelihood of a successful attack but you can't know for sure without comparing the fingerprints securely.
If you can compare the fingerprints physically with the site operator (after verifying that the party you're comparing fingerprints with is indeed the operator), there's no problem with self-signed certs. With SSH, the remote host usually either belongs to you yourself, or to your or
Re: (Score:2)
>Because you can't know if it's really self-signed
Yes you can. You can check the signature and see that it was created using the public key associated with the private key in the cert.
I assume you mean you can't know if the cert was issued by the entity it claims to be issued by. This is true of all certs when you have CAs issuing certs to anybody. This is why X.509 PKI is brittle. It only takes one bad CA to break everything and we have several bad CAs. We can add Symantec/Verisign to the list.
Re: (Score:2)
Re: (Score:2)
And when everyone self signs, we'll have many millions of bad CAs.
And who is proposing that at a solution to anything? It's the first I've heard of it.
Re: (Score:3)
What do you see the choices as?
Re: (Score:2)
Well, the discussion was between central CAs and self-signing.
What do you see the choices as?
Fair enough.
My basic principle is the domain of interest of the CA signer should be synchronous with the domain of interest of the signee. Like a company CA, or a govt CA or a household CA. The situation where root CAs, trusted by OSs and browsers are just floating out there on the internet, separate from the certs they sign is a source of the problems. PKI fails because of the way CAs work and it doesn't fail safe. It's broken now but your browser doesn't bring up a warning saying "At least on the CAs is c
Re: (Score:2)
Re: (Score:2)
That's not far off. Destroying X.509 and TLS is also on my agenda, so it's probably going to keep me busy until retirement.
Re: (Score:2)
Re: (Score:2)
I'm doing fine on the big org side of things.
Re: (Score:2)
To be fair, even Symantec SSL certificates are more secure than just blindly trusting self signed certs.
Re: (Score:2)
To be fair, even Symantec SSL certificates are more secure than just blindly trusting self signed certs.
Who's blindly trusting them? I trust my own self signed cert that I use for my own purposes.
On the other hand, my browsers however trust on my behalf, a large number of root certs that I've never heard of. That's where the blind trust is.
Re: (Score:2)
Who's blindly trusting them? I trust my own self signed cert that I use for my own purposes.
This deliberately ignores the real use case of digital certificates... communicating with other entities while preventing man in the middle attacks. The trusted CAs in browsers might not be perfect, but again, they are almost infinitely better than no infrastructure at all, which is the only real alternative at this time.
Re: (Score:2)
Yes. It does. That's the hard problem. There are solutions, but none of them involve CAs and PKI in the way browsers and email use them today.
Re: (Score:2)
That's ridiculous. Anything you do with a self-signed certificate can also be done with a CA cert, including certificate/public key pinning. What you really mean is that you can't believe users trust browsers that don't do public key pinning.
Exactly. On my not-particularly-interesting sites, the CA-issued cert is used merely to (a) not show warnings in browsers and (b) offer an independent check on the legitimacy of my domain.
To prevent spoofing, I use DNSSEC+DANE to identify which certificates should be presented, as well as using HSTS to ensure future visits use TLS. I also use HPKP public key pinning.
All basic stuff that should be used by pretty much every secure site. Alas, it's not widely used. Too bad, really.
Re: (Score:2)
Self-signed works fine if you can actually verify the certificates by some other method, which is generally OK for smaller, more tightly integrated groups but is hard to scale to the general public or complete strangers.
It would also help if product makers would make it somewhat easier to manage them. Most people reasonably intelligent and competent in the world of IT don't know how to manage self-signed certs, even down to what they would need to do to make the browser errors go away.
Of course, if OS vend
Re: (Score:3)
Re: (Score:3)
DANE (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) would make self signed certificates seamless and virtually flawless.
Re: (Score:2)
Actually it doesn't. DANE certificates are not self-signed for a start, they are signed by the DNSSEC key for the zone.
The problem with DANE is that you swap the choice of multiple CAs for a monopoly run by ICANN, a shadowy corporation that charges a quarter million bucks for a TLD because that is what the market will bear. What do you think the price of DANE certification will rise to if it takes off?
ICANN is the Internet version of the NFL only with greater opportunities for peculation and enrichment.
Re: (Score:2)
No DNSSEC does not rely on trusting ICANN. ICANN's public key is fixed and known - if it changed alarm bells would go off.
You do trust the TLD your domain uses, but nothing further. There is no single point of failure.
And just trusting your TLD is a) easily verifiable (a simple DNS query can tell if they inject unauthorised public keys) and b) a hell of a lot better than hundreds of CA's that can all issue certificates for your domain.
Re: (Score:2)
Re:How did Google discover this? (Score:5, Informative)
No. It means every CA has to have a log of every EV certificate it's issued, and Chrome is checking any purported-EV certificate it sees against the issuing CA's list. If the certificate really is a valid EV certificate, it'll be in the list. I presume that if the certificate isn't a valid EV certificate (ie. it's not found in the list) and you've got the "Automatically report details of possible security incidents to Google" setting turned on (the default) it sends the error report back to Google for analysis. All of that's perfectly reasonable, and Google only sees information about certificates that're lying about their EV status.
So the trusted middleman is no longer trusted? (Score:5, Insightful)
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???
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:3)
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.
better option...forget Symantec (Score:1)
Better option is to email companies using verisign and tell them we the users can't trust verisign anymore.
Re: (Score:3)
Who would you recommend instead? Thawt? GoDaddy? Is there anyone that can be trusted in this industry anymore?
Re: (Score:2)
Wny did they need the certificates? (Score:5, Insightful)
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.
Re: (Score:2)
But, you're also doing it wrong.
.test is the only appropriate TLD (see RFC 6761) aside from one you actually own, of course.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
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
Laugh (Score:1)
"Now, Google wants Symantec to disclose all certificates issued by its SSL business going forward."
The NSA/GCHQ won't like that.
Google can do that (Score:1)
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.
Certs for NSA to spy on google (Score:3, Insightful)
The certificates were used for man in the middle attacks, to decrypt google stuff before it got to them by the NSA.
How do certificate authorities work .. (Score:2)
Re: (Score:2)
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
What is a pre-certificate? (Score:4, Insightful)
Sorry, but I have no clue what a pre-certificate is. Google search doesn't seem to help me either.
Re: (Score:2, Informative)
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.
Re:What is a pre-certificate? (Score:4, Informative)
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.
Re: (Score:2)
Certificate Transparency is a Google-driven initiative taking place at the IETF to design a system to increase trust in the public key infrastructure (PKI).
The basic issue is this. The simplest way to design a public key infrastructure is to have a bigass central database that maps names to public keys. If you navigated to foobar.com, your browser would go consult the Bigass Database and look up the public key there in some secure way, then check it matched what the foobar.com server was using.
This design h