Slashdot Mirror
Google Threatens Action Against Symantec After Botched Investigation (itworld.com)
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.
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.
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?
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???
Better option is to email companies using verisign and tell them we the users can't trust verisign anymore.
who trusts google?
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.
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?
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
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.
If you are running a utiliy like Convergence or Perspectives to monitor certificates, I'll buy your solution. Otherwise, you're just setting yourself up for a MITM attack.
"Now, Google wants Symantec to disclose all certificates issued by its SSL business going forward."
The NSA/GCHQ won't like that.
"If any question why we died, Tell them because our fathers lied."
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 organization. It's easy, if not trivial, to compare the fingerprints when you have physical access to YOUR machine.
I'm not saying CAs are more secure than self-signing. Actually they're less so, and the CA business model is completely broken. But self-signing alone doesn't help. GnuPG-like web of trust, maybe, but that would require far more effort than simply "calling your friend".
The certificates were used for man in the middle attacks, to decrypt google stuff before it got to them by the NSA.
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.
>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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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 ..
Sorry, but I have no clue what a pre-certificate is. Google search doesn't seem to help me either.
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 vendors or application vendors made it easier, we'd probably just end up with a giant mess of untrustworthy self-signed certificates floating around, with every home PC bloated with bogus certificates designed to rip them off.
What I don't understand is what does it take to become a public CA? Who approves them? Who audits their procedures? Sometimes it just feels like you can be one as long as your sales pitch is good enough to get your root CAs installed by default in browsers and operating systems.
Because a so-called "self signed" certificate (that is, one that is lacking a signature from a CA) is one nobody you've programmed your browser to trust stands behind.
That's the only difference between certificates that give you warnings, and certificates that don't. If I go to www.bankofsquiggleslash.com, I'd kinda like to know that the certificate is likely to be genuine without having to phone them up and ask for a MD5Sum. And, not surprisingly, the bank would also like me to know that, as they wouldn't be able to field all the calls otherwise.
You are not alone. This is not normal. None of this is normal.
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.
DANE (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) would make self signed certificates seamless and virtually flawless.
But if someone MITM your first trip to that site, you'll have no independent way to verify Google is Google. If you have a root certificate loaded, then you trust the root when it says it knows Google is Google, so you have multiple independent points of agreement that you are at the right spot.
Learn to love Alaska
And when everyone self signs, we'll have many millions of bad CAs.
Learn to love Alaska
To be fair, even Symantec SSL certificates are more secure than just blindly trusting self signed certs.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
Well, the discussion was between central CAs and self-signing.
What do you see the choices as?
Learn to love Alaska
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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 compromised!".
My day job, amongst other things, involves working to solve these certification problems. I have a much more complete proposal but it's being worked for submission right now. It would involve everything signing it's own cert (automagically) and separate attestation certs. So I guess I'm proposing it, but not in the way discussed here.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
A hybrid system, with a self-signed everything, but with 3rd party verification. Preferably by an organization that's not financially dependent on the issuance of certificates. An ICANN/IANA like group, one per country, to certify the certificates come from the self-signer they come from. If the root DNS servers held certificates as well, like a DNSSEC setup for certs per domain, we could distribute, yet mostly trust the whole thing, right?
Learn to love Alaska
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
Such things are easier if you copy an existing standard. DCS (Domain Certificate Service), modeled after DNSSEC with certs handed out, rather then DNS resolution. Then all you need is to get BIND or Infoblox or someone to buy in, and you'll get a large organization pushing it for you. A for-profit company like Infoblox or Men and Mice may jump at the opportunity to be the "first and only" at a new security feature. And once you have them pushing for you, it's easier.
Learn to love Alaska
I'm doing fine on the big org side of things.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.