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.

Comments

Inside job?

[campuscodi]

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.

Re:Inside job?

[Anonymous Coward]

There's no shame in it.

Depends on who made the sales.

Symantec is a sales organization

[vvaduva]

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:Symantec is a sales organization

[Anonymous Coward]

>They've ruined PGP

Did they? GPG works so well that I haven't looked at PGP in years.

Re:Symantec is a sales organization

[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)

Re:Symantec is a sales organization

[Anonymous Coward]

This is what happens when you cut costs by getting rid of your senior staff who are actually competent. Also, it happens if you don't invest enough in internal documentation and on boarding to train new people when the senior people retire.

So, many tech businesses will be feeling pain like this in the coming years.

Re:Symantec is a sales organization

[Gr8Apes]

GPG started life as PGPs lesser cousin. And PGP has at least one OSS version available as well. So you're actually using PGP.

Re:Symantec is a sales organization

[vvaduva]

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:Symantec is a sales organization

[Anonymous Coward]

That's funny. I find confusing marketing and sale lingo a good reason NOT to buy a particular product. If it doesn't make sense, I don't buy it.

Re:Symantec is a sales organization

[Burz]

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

Re:Symantec is a sales organization

[Anonymous Coward]

What do you expect from an incompetent end user such as Anonymous Coward?

Self Signed

[Anonymous Coward]

I can't believe people would trust anything other than self signed certificates.

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

Then get rid of trusted (obviously no such word) certificate authorities and do it like SSH has been for decades.

If people are that concerned about the first visit to a site, just call your friend in some other location and have that person confirm that the certificate is the same that they are using.

It's a huge waste of time how it works now, but I suppose it keeps a lot of people in business.

Re:Self Signed

[known_coward_69]

who trusts google?

Re:Self Signed

[Knuckles]

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:Self Signed

[Anonymous Coward]

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.

Re:Self Signed

[Anonymous Coward]

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

Re:Self Signed

[Anonymous Coward]

who trusts google?

The issue isn't whether you trust Google, the issue is whether, when you go to a Google website, you can actually trust that that is a Google website.

If you don't trust Google, don't go to Google websites, and this specific case won't affect you. BUT, given who Google is, this brings into question *all* website certs issued by this company.

Re:Self Signed

[Anonymous Coward]

I can't believe people would trust anything other than self signed certificates.

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.

Re:Self Signed

[TechyImmigrant]

>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:Self Signed

[Anonymous Coward]

Which sucks because some of us paid a premium for SSL for good CA's like Thawte so that we wouldn't have to worry. Then along comes Symantec and now we can't have nice things.

Re:Self Signed

[swb]

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.

Re:Self Signed

[squiggleslash]

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.

Re:Self Signed

[Anonymous Coward]

You assume everyone is as sophisticated as you. If browsers are modified to not choke every time they see a cert signed by someone they don't yet trust, then it will open up the barn doors for MITM attacks and the vast majority of web users would never have a clue they were doing anything dangerous. You present a page with the message as above, 95% of the population will just click whatever button they have to so they can get to the site. If instead you make them jump through a few hoops before they can accept a cert that isn't yet trusted and they think twice and generally just move along.

Re:Self Signed

[heypete]

I can't believe people would trust anything other than self signed certificates.

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:Self Signed

[Anonymous Coward]

How about when you go to google and get that message. I got a certificate for google.com from attlocal.net I accepted it temporarily.

Re:Self Signed

[Anonymous Coward]

So calling up a buddy to compare digital signatures is not a waste of time?

I hope your bank DNS gets hacked and you are presented with website that looks like your bank but they have a self-signed cert for you to accept.

You will deserve all the pain coming to you.

Re:Self Signed

[Anonymous Coward]

SSH is different.

If I SSH into my server and the certs don't match, I know there is a serious problem.

When you don't control the server, you just don't know.

Self-signed certs don't scale.

Re:Self Signed

[cheater512]

DANE (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) would make self signed certificates seamless and virtually flawless.

Re:Self Signed

[AK Marc]

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.

Re:Self Signed

[AK Marc]

And when everyone self signs, we'll have many millions of bad CAs.

Re:Self Signed

[ttucker]

To be fair, even Symantec SSL certificates are more secure than just blindly trusting self signed certs.

Re:Self Signed

[TechyImmigrant]

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:Self Signed

[TechyImmigrant]

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:Self Signed

[ttucker]

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:Self Signed

[AK Marc]

Well, the discussion was between central CAs and self-signing.

What do you see the choices as?

Re:Self Signed

[Zeinfeld]

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:Self Signed

[TechyImmigrant]

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.

Re:Self Signed

[TechyImmigrant]

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:Self Signed

[AK Marc]

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?

Re:Self Signed

[TechyImmigrant]

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:Self Signed

[cheater512]

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:Self Signed

[AK Marc]

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.

Re:Self Signed

[TechyImmigrant]

I'm doing fine on the big org side of things.

How did Google discover this?

[Anonymous Coward]

"Google discovered the incident because, as part of its Chrome browser policies, it requires all CAs to disclose the EV certificates they issue in a public audit log as part of a new protocol called Certificate Transparency (CT)."

What exactly does this mean? Google Chrome is spying on all certificates and sending data back to google servers?

Re:How did Google discover this?

[Todd Knarr]

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.

Re:How did Google discover this?

[Anonymous Coward]

Why wasn't Todd issued a tinfoil hat at the door like most others at this conspiracy blog?

Re:How did Google discover this?

[Anonymous Coward]

This is exactly what I asked and you confirmed what I said. This so called "log" *is* the google servers. Basically even if you are doing internal testing (like I'm sure Symantec was doing) with Chrome browser, it will leak data to Google servers by default.
Is it good? Maybe for someone, but not for me, disabling all BS features in browser that leak your browsing habits is already a pain.

Re:How did Google discover this?

[Anonymous Coward]

... Google only sees information about certificates that're lying about their EV status.

Ha.

How much would you bet on that?

I bet I could get you to pay quite a bit for a ride on my pegacorn.

Re:How did Google discover this?

[Anonymous Coward]

FWIW, the EFF's HTTPS Everywhere can be configured to send all the certificates your Firefox browser sees to their SSL Observatory and has the option to make the submission over Tor if you choose.

Re:How did Google discover this?

[Anonymous Coward]

No.

The CT logs are run by anybody who wants to step up (Google run three but there are several others) and they log the _creation_ of the certificate, not the fact that a web browser saw it in use. The log isn't just a huge list, but instead uses some clever mathematics to do with how signatures can sign other signatures to be able to prove that the history recorded doesn't change. If you try to pull a Rebecca Brooks and delete evidence from the logs, now your log is exposed as bogus and nobody will trust you.

These logs can be monitored, to see if bad guys are issuing certs they're not entitled to, even if they never use those certs where the general public would see them. AND they can be verified by web browsers (currently only Chrome) to reject certificates that "somehow" weren't logged, because those are obviously bogus.

Re:How did Google discover this?

[Anonymous Coward]

so the CA gets a log of all your browsing to EV sites for which they've issued certificates? I'm guessing not, but a less pollyannaish description of what EV means would be helpful.

So the trusted middleman is no longer trusted?

[Anonymous Coward]

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:So the trusted middleman is no longer trusted?

[Anonymous Coward]

YA!, F*CK California!

Re:So the trusted middleman is no longer trusted?

[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. (Most of you likely are aware of what happens during a "merger") In such an environment it's much easier for bad actor to sneak in and issue fraudulent certs un-noticed.

The very notion of a publicly traded company as a trust authority, subject to the whims of a volitle market, is flawed.

Re:So the trusted middleman is no longer trusted?

[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 different valid certs are signed by a valid CA or two (you get a warning for the 2nd CA which you say "should be OK" based on your out-of-band verification with the site or verification by trying via different connections or you just take the chance- what are the odds you get MITM by a rogue cert signed by a valid CA the first time you visit the site?), the browser remembers the different certs for that session. Weeks later you visit the site again and you get a new different cert you get a warning, especially if it's signed by a different CA.

Re:So the trusted middleman is no longer trusted?

[Anonymous Coward]

I sure as hell don't trust any of them. That's why I have every god damn CA and certificate disabled in my browsers and only add exceptions for those that I absolutely know are needed. Sorry NSA I don't trust any of them because you have the fucking keys - Diginotar anyone?

Captcha was appropriate : Senators

Re:So the trusted middleman is no longer trusted?

[Coren22]

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/ 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

[Anonymous Coward]

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

Re:better option...forget Symantec

[Coren22]

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

Re:better option...forget Symantec

[squiggleslash]

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? ;-)

Re:better option...forget Symantec

[Anonymous Coward]

Thawte was bought up by Verisign before Symantec bought up Verisign. Choices are limited if you're looking for CAs trusted by the browsers, Microsoft, and Oracle (for Java). I actually don't know who to suggest for US residents. And by some amazing coincidence, the price of trusted certificates has risen considerably in recent years.

Wny did they need the certificates?

[Todd Knarr]

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:Wny did they need the certificates?

[msauve]

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.

Re:Wny did they need the certificates?

[athmanb]

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.

Re:Wny did they need the certificates?

[Todd Knarr]

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.

Re:Wny did they need the certificates?

[dissy]

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 RFC.
Somewhat ironically though, your .ttk test-tld still seems to not exist, where as the .xxx test-tld I used does.

Even more ironic (or just sad) it was right around the time that RFC was published that none other than Microsoft started using .local as a defacto standard for a LAN TLD on Windows networks, a practice that continued right up until CAs begun to refuse signing .local domain names for Exchange servers (In 2012 or so? I can't quite remember)

Of course instead of pushing to make .local a true global standard in the root zones, Microsoft just threw up their hands and said "Fuck it, we don't know, just go get some insanely long .com domain to type in front of all your usernames from now on or something."

Re:Wny did they need the certificates?

[Zeinfeld]

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 support DNSSEC.

Unfortunately, in PKI terms what VeriSign was to IBM, Symantec is to Lenovo.

They apparently remember the ceremonies we designed but not the purpose. So they are going through the motions but not the substance.

One of the main criticisms I have heard is that we built the system too well. From 1995 up to 2010 it worked almost without any issues. So people decided that they didn't need things like proper revocation infrastructure. The only recent issue the 1995 design could not have coped with was DigiNotar which was a complete CA breach.

There are some developments on the horizon in the PKI world that will help add controls to mitigate some of the issues arising since. But those depend on cryptographic techniques that won't be practical for mass adoption till we get our next generation ECC crypto fully specified.

Re:Wny did they need the certificates?

[Zeinfeld]

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 that entered their head.

Re:Wny did they need the certificates?

[Todd Knarr]

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.

Laugh

[koan]

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

The NSA/GCHQ won't like that.

Certs for NSA to spy on google

[ealbers]

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

Re:Certs for NSA to spy on google

[Anonymous Coward]

Also, the NSA kills and drinks the blood of newborns to give their analysts ESP powers to read the minds of unsuspecting Freedom Fighters.

Fact because that would be evil and therefore the NSA must be behind it.

Re:Certs for NSA to spy on google

[Anonymous Coward]

Why bother when multiple government agencies in multiple countries have CAs that are included in the default trusted root lists for every major browser?

Re:Certs for NSA to spy on google

[Anonymous Coward]

Yes, because they've never been caught doing crazy things like tapping an internet carriers network with a secret room.............. oh never mind that one, ah they've never been caught hijacking shipments of ISP hardware being shipped to other countries to spy...... oops, well they've definately never been caught supplying illegally obtained evidence to the DEA/IRS and then telling them to lie to courts about......... oh you've got to be kidding.

http://www.wired.com/threatlevel/2009/07/jewel/
http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant
http://www.reuters.com/article/2013/08/05/us-dea-sod-idUSBRE97409R20130805

Re:Certs for NSA to spy on google

[Anonymous Coward]

Because you want to authenticate google.com, not some randomly generated other .com THATS why, getting a CA which matches the google.com domain is priceless for MITM attack.
Yes governments can get the info, but they will be SEEN doing it, with a CA you can be invisible.

Re:Certs for NSA to spy on google

[Anonymous Coward]

I don't think you understand how certificate verification works...

Any trusted root CA can sign any certificate for which its purpose is trusted.

Some countries have trusted CAs that are loosely tied to the government and there is plausible deniability... such as those owned by ISPs with government oversight.

The user will probably not notice the cert was signed with Verisign vs Webtrust.

And it's happened before .. https://www.eff.org/deeplinks/2010/08/open-letter-verizon

Google can do that

[mimino]

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.

Re:Google can do that

[Anonymous Coward]

That may very well be illegal

Re:Google can do that

[Anonymous Coward]

Depends on what Symantec agreed to in its contract with Google.

Re:Google can do that

[Anonymous Coward]

"many customers will require refund for already purchased certificates."
Why? Are you saying that if the knife set I bought from Walmart goes blunt, I'm entitled to a refund on the steak I purchased from another company?
That's essentially what you're talking about.

Company A's product uses Company B's product.
Company A's product stops using Company B's product.
I can now get a refund on Company B's product due to Company A's post-purchase decision, despite the fact Companies C through Q still use Company B's product.

Blockchain

[Anonymous Coward]

Why can't we use a blockchain for things like this?

Re:Blockchain

[Anonymous Coward]

Because I don't want to have to have a 50GB file on my computer just so I can use my company's webmail.

How do certificate authorities work ..

[nickweller]

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

Re:How do certificate authorities work ..

[Anonymous Coward]

The YouTube channel Computerphile has some good explanations. Just recently they covered some info on MITM attacks and Superfish

Re:How do certificate authorities work ..

[david_thornley]

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 without establishing contact first. Also, you can encrypt something with your private key, and when I decrypt it with your public key I know it was from you. (Or you might encrypt a checksum of your message. These actions are sometimes called signing.) This is often used for authentication: you send my server a message saying "This is me" encrypted with your private key, and the server decrypts it with your public key and lets you in.

Assuming the cipher is secure (the first such scheme depends on it being prohibitively had to factor the product of two large primes), there are two weak points here. First, you need to keep your private key private, since anyone who gets it can act as you on the net. Second, I have to make sure that the public key I'm using is actually yours, since if someone else can fool me and give me his public key instead the bad guy can act as you. In this sense, an identity on the Internet is a key pair.

If I try to send you a message, and get a public key that belongs to an eavesdropper, the eavesdropper can read my message and pass it on to you. If the eavesdropper is efficient about it, I have no clue that this is happening. The eavesdropper can monitor our communications, and can send me a message while pretending to be you. This is the traditional man-in-the-middle attack.

Suppose I have two public keys listed for you, and I don't know which is you and which is someone else. Ideally, someone I trust sends me a message, encrypted with his or her private key, telling me what your private key is. The two problems here are that (a) I have to trust my friend to know, and (b) I have to know that the public key I'm using is my friend. To simplify things, I put my friend's public key in a list of trusted people, and I can automatically check public keys and trust what he or she tells me. Since my friend doesn't want to get emailed every time I make a connection, he or she gives you a note saying "I am nickweller and this is my public key: ..." encrypted (signed) with his or her private key. Therefore, when I want to connect with you, you've configured your site to present that note to me, so I have a process read it and verify your public key, so I know I'm communicating with you.

In this example, my friend is a certificate authority. Your browser has the public keys of lots of CAs (I counted well over a hundred on Firefox once) and the note my friend gave you is a certificate. (It's much more complicated, of course, but this is the general idea.) Now, suppose one of the CAs is Symantec, and they've issued a certificate that says "Hi! I'm Google." to Snidely Whiplash. Then, if my browser gets pointed to Snidely's page, his webserver gives me that certificate, and my browser says "Yup, Symantec issued that certificate, and Symantec is in my long list of reliable CAs", and I think I'm dealing with Google rather than Snidely. Snidely is in a position to do a man-in-the-middle attack and monitor my session, or just collect what I type in and think is private between me and Google, or tell me things I think are coming from Google. Naturally, Google isn't going to like this.

An unsigned certificate is pretty much a public key you publish, without giving people any verification information. It's vulnerable to man-in-the-middle attacks, since I don't actually know it's yours. A certificate authority is someone who gives you a certificate, signed by them, that identifies you. You can show me the certificate.

The two ways for a CA to fail are to let someone get their private key (and that's happened), or issue certificates saying "I'm nickweller" to other people. It's been said that a CA will protect you against anyone whose money they won't take.

What is a pre-certificate?

[LordKronos]

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

Re:What is a pre-certificate?

[dissy]

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?

[Zeinfeld]

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:What is a pre-certificate?

[Anonymous Coward]

In principle EV is supposed to mean the issuing CA conducted due diligence of the recipient's identity. For example if you control the-mcdonalds.burger-chain.example then you could easily get a DV ("domain verified") cert which says you control that. But only a moron would believe your web site is actually the web site of the famous McDonalds.

Under EV McDonalds can prove to a CA that they're the actual McDonalds corporation, and browsers respect that by showing the verified name of the entity in green in the URL bar, this typically involves sending a letter on headed paper, and verifying that the recipient's address matches the company address. A fraudster could doubtless subvert this system, but at least they'd have to try and they might leave a trail that could be followed back to them.

Re:What is a pre-certificate?

[Anonymous Coward]

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.

Care to translate to English please?

Re:What is a pre-certificate?

[IamTheRealMike]

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 has a lot of downsides and a couple of upsides. The downsides are that it scales horrible, that an outage of the Bigass Database would mean an outage of the entire secure internet, that nobody is really incentivised to pay the huge costs of running it, whoever ran it would be a monopoly, and that the owners of the database would get a record of everyone's browsing sessions. The big upside is that all public keys are transparent: nobody can insert a fake mapping without being spotted, assuming there are people paying attention. And additionally, if someone lost control over a private key, the key can be revoked by just deleting it from the database.

So there are tradeoffs, but in practice the PKI (largely designed in the 1990's) doesn't use a Bigass Database. It uses certificate chains instead. Browsers and other SSL clients choose to trust a number of certificate authorities which issue certificates to servers, and those servers present their certificate chain during connection setup. Then the client can check that the public key/identity binding is valid by checking the chain of digital signatures. This scales, is robust, avoids monopolies (adding a new trusted CA is easy) and has great privacy.

That leaves the two upsides of the Bigass Database approach: revocation and transparency. Revocation is easy, you use something called OCSP stapling. CA's run a server that issues a short, signed, time limited statement of the form "certificate ABC is not revoked". Traditionally it was supposed to be the clients that did the server call, but that brought back the privacy and outage problems, so in modern setups it's the server that requests this statement and caches it for a while, then hands it to the client along with all the rest of the data.

Finally, there's the issue of transparency. CT fixes transparency. The plan is to require CAs to publish every certificate they sign in a global audit log. The log is structured somewhat like a block chain. To enforce that CAs can't sign certificates in secret, and to avoid the CT logs being hammered with privacy-sensitive traffic, a stapling approach is used again: the certificates themselves contain a mathematical proof that they exist in the global logs. Thus clients (like Chrome) can check that a certificate was published and eventually stop accepting any cert that lacks the proof.

So we end up with a PKI design that is very complicated, but lets us have our cake and eat it - we've been able to get all the major features we'd like (scalability, privacy, reliability, provider competition, agility, revocability) without compromises.

Internet (SSL) Death Penalty (for CA's)

[Anonymous Coward]

Seriously folks, like the USENET death penalty of olde, Google (and other browser makers who maintian their own SSL cert security) needs to bring down the hammer HARD. Currently, Google are somewhat bitchslapping Verisign for this by forcing a third party audit and adding certificate transparency to regular certs, but a real pain-of-death monitoring clause where Verisign is on parole for a year or two will scare them straight (at least for the parole period).

Hell, the ONLY reason we even know about this is the CT logs having to be published for EV certs. We`re lucky we even have that to hold CA's accountable. The LEtsEncrypt guys are supposed to go full CT, so at least they have the right idea...

Re: Certs to spy on google

[Anonymous Coward]

Everybody wants them. Chinese, Russians, and probably some three-letter agencies too.

Re:Certs

[Anonymous Coward]

Check to see if Symantec has any Chinese employees that go home for vacation. Lol.