Google Bans Symantec Root Certificates 84
An anonymous reader writes: After in September Google discovered SSL certificates issued in its name by Symantec, and after in October the company discovered over 2,500 more certificates issued for non-existent domains, also by Symantec, Google has now decided to ban Symantec's dodgy certificates from Android and Chrome. "Symantec has decided that this root will no longer comply with the CA/Browser Forum's Baseline Requirements," said Ryan Sleevi, Google Software Engineer. "As these requirements reflect industry best practice and are the foundation for publicly trusted certificates, the failure to comply with these represents an unacceptable risk to users of Google products." Apparently Symantec hasn't been very careful of where and to whom it issues SSL certificates from a particular root branch.
lemme guess (Score:1)
not ALL symmantec certificates...
Re: (Score:2)
I bet something that broad would generate a lawsuit, possibly some kind of antitrust litigation.
egregious misrepresentation (Score:5, Interesting)
I would say that Symantec issuing Certs with Google's name on them would qualify as egregious misrepresentation, on the behalf of Symantec, and be grounds to suing symmantec into oblivion by Google.
Really, perhaps that's a better response for Google.
It could even fall under the context of identity theft and grounds for criminal charges to be filed; another good response and not exclusive of a civil lawsuit based from Google.
Re: (Score:3)
That doesn't mean that didn't happen. What it means is that the mechanism for that is not an NSL. People seem, for some odd reason, to misunderstand the scope of an NSL. They are not some Swiss Army Knife approach where you get to do all sorts of things under one heading. They're quite specific and quite limited.
This, of course, doesn't mean that there aren't other issues. This doesn't mean that they're not doing some of the things that they're accused of. This doesn't mean that they're not engaging in unco
Re: (Score:1)
Yes, that why FBI agents also carry guns.
Re: egregious misrepresentation (Score:1)
Law school students are by far the most irritating people on the planet. Perhaps that's what you meant.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I wish Google would just buy them and then shut them down. Its a much better outcome.
Symantec's shareholders and all of Symantec's competitors wholeheartedly agree.
It's less clear that it would do the world any good, and very clear that it would do Google none.
Re: (Score:2)
I bet something that broad would generate a lawsuit, possibly some kind of antitrust litigation.
RT*A: Google claims they are doing it at Symantec's request.
As Symantec is unwilling to specify the new purposes for these certificates, and as they are aware of the risk to Google’s users, they have requested that Google take preventative action by removing and distrusting this root certificate.
Re: lemme guess (Score:2)
RTFPC
Totally over-stated summary (Score:5, Informative)
From TFA:
As Symantec is unwilling to specify the new purposes for these certificates, and as they are aware of the risk to Google’s users, they have requested that Google take preventative action by removing and distrusting this root certificate.
Later in TFA:
Symantec has indicated that they do not believe their customers, who are the operators of secure websites, will be affected by this removal.
Symantec is retiring the certificate, and has asked for it to be removed from Google (and probably other) products. End of story. Nobody should be affected.
Re:We need SSL/TLS infrastructure written in Rust. (Score:5, Funny)
Yep, we really need to rewrite our entire infrastructure in your favorite language platform flavor of the month.
Just to be secure. Think of the children.
Re: (Score:1)
Re: (Score:3)
Yep, we really need to rewrite our entire infrastructure in your favorite language platform flavor of the month.
Just to be secure. Think of the children.
Improved languages might help a little, but the deep cleaning required is that we get rid of X.509 and TLS and replace it with an auth model that works and crypto protocols that are simple enough that they can be understood and implemented well.
Trust isn't transitive (Score:2)
But what's "an auth model that works"? The PGP web of trust isn't it because trust isn't transitive. Just because I can vouch for someone's identity doesn't mean I can vouch for her ability to vouch for others' identities. That's why X.509 certificates have the "cannot act as a CA" flag.
Re: (Score:2)
But what's "an auth model that works"? The PGP web of trust isn't it because trust isn't transitive. Just because I can vouch for someone's identity doesn't mean I can vouch for her ability to vouch for others' identities. That's why X.509 certificates have the "cannot act as a CA" flag.
In most cases, nobody needs to know the identity anyway. It would be far more important to know that it is the same website I looked at before which can be trivially achieved by storing a hash to a certificate locally after the first visit. It would also be important to know whether the destination of a link is still the intended one which could be achieved very easily with link fingerprints.
MITM from day one (Score:2)
In most cases, nobody needs to know the identity anyway. It would be far more important to know that it is the same website I looked at before
That's called "key continuity management" (KCM) or "trust on first use" (TOFU). SSH uses it but recommends that you verify the key fingerprint out of band. It could be used with HTTPS or email as well, but without a way to verify the fingerprint out of band, it's vulnerable if your connection is compromised by a man in the middle from day one. Bug 460374 [mozilla.org] relates the story of how such an MITM in the wild was discovered.
Re: (Score:2)
In most cases, nobody needs to know the identity anyway. It would be far more important to know that it is the same website I looked at before
That's called "key continuity management" (KCM) or "trust on first use" (TOFU). SSH uses it but recommends that you verify the key fingerprint out of band. It could be used with HTTPS or email as well, but without a way to verify the fingerprint out of band, it's vulnerable if your connection is compromised by a man in the middle from day one. Bug 460374 [mozilla.org] relates the story of how such an MITM in the wild was discovered.
The benefit comes when everyone does it all the time. All traffic is encrypted and integrity checked thusly. Yes it is vulnerable to MITM on initial use, but it raises the bar for intelligence agencies because they now have to MITM everything, all the time to have a hope of pulling off a targeted attack later. Their bulk data browsing becomes fairly pointless. Instead they have to perform bulk MITMing.
Part of the dynamic here is that the PKI is so fragile that TOFU simply works better. It fails less often t
Re: (Score:2)
Part of the dynamic here is that the PKI is so fragile that TOFU simply works better.
Cite? I seriously doubt that TOFU would actually work better if it were used on a large scale (SSH is *not* large scale). Key rotation is particularly problematic; by default TOFU just says "no" to key rotation, which is also bad. PKI + TOFU has interesting properties, but key rotation is still a problem.
IMO, what would be best is PKI + Certificate Transparency [certificat...arency.org] + Convergence [wikiwand.com] + (limited) TOFU. Marlinspike touts Convergence as an alternative to PKI, but I think it would work better as an additional layer. P
Re: We need SSL/TLS infrastructure written in Rust (Score:1)
Good luck with that! I'm sure you'll do a great job.
Re:We need SSL/TLS infrastructure written in Rust. (Score:4, Informative)
99% of tbe infrastructure of the internet is written in c/c++, every OS, most of the webservers, all of the dns infrastructure, most mail mta's, most routers,. It would be infeasable to perform a complete rewrite.
Re: (Score:3)
>can we really consider the entire system to be secure?
It goes far deeper than the coding. It is insecure on many levels. I have deployed real world CAs. I know people embroiled in the day to day problems. While I'm not going to go into details, suffice to say the whole edifice is fragile and subject to many single points of failure and in general, the majority of single points of failure are humans.
Re: We need SSL/TLS infrastructure written in Rust (Score:2, Insightful)
Rust uses LLVM as it's backend compiler. LLVM is written in C++. Where is your rust god now?
Re:Totally over-stated summary (Score:5, Interesting)
Re: Totally over-stated summary (Score:4, Informative)
It is a really lousy summary. This is the G1 class 3 root CA VeriSign issued in 1996! If I remember correctly, it's a 1024 bit RSA root, and it hasn't been used in production in 5+ years. Removing it permanently from being trusted will doubtless break a few ancient systems that haven't been updated in forever, but it's the right thing to do. Not a sign of anything more than obsolescence.
Re: (Score:2)
Yea, Mozilla killed or limited to email this and most other 1024-bit roots sometimes ago.
Re: (Score:2)
Translation: the NSA no longer needs to use certificates that are signed against this root.
thats racist!!! (Score:1)
Re: (Score:3)
The summary tried as hard as possible to imply that this was some acrimonious thing, but it is not.
Symantec asked Google to distrust a specific CA root, end of story. Nobody affected in any way, except maybe people who do not install updates.
yup. (Score:2)
O cannot see the difference between one root ceritifcate owned my symatic/verisign, and an othter. So they just went bad on one root, they just move their bad practice to an other root CA they own.
Ban all verisign(=symatic) CA issued from now on!
Re: (Score:1)
Re:thats racist!!! (Score:5, Interesting)
The summary tried as hard as possible to imply that this was some acrimonious thing, but it is not.
Symantec asked Google to distrust a specific CA root, end of story. Nobody affected in any way, except maybe people who do not install updates.
Having spoken with some of the people involved, it certainly was an acrimonious thing.
You would be pissed too if a big CA was signing forged certs of your web site's identity to someone else.
Re: (Score:2)
Right, Google was not happy with Symantec about that happening, and the summary is strongly trying to imply that Google is punishing Symantec by interrupting the value of their certificates... from TFA we can read that Symantec does not anticipate that any of their SSL customers will be affected.
Re: (Score:3)
Google noticed that there were major problems with a Symantec root cert. Symantec were basically forced to ask for removal to retain accreditation on other root certs. If they can't say what this one is for, we can be 99% sure it was the government forcing them to issue it, which if itself quite a scandal. More proof that we can't trust Symantec software.
How about banning others? (Score:2, Insightful)
I wind up cleaning my Android device's cert store just because there are a lot of certs that are made by foreign governments, that are not really used, but can easily be abused. China's government has one, for example. Same with Turkey and Saudi Arabia.
What Google should do is figure out the geographical location used, disallow certs that are not directly appropriate to the region, perhaps allowing certs to be turned on/off if one travels. As it stands now, the fewer, the better.
After ?? in September-we must make a stand, nerds! (Score:3, Insightful)
Please, enough of improper use of English in our website! I don't mind so much in posts, but at least can we have decent grammar and syntax in TFS? Our website is not written by 11 year olds who missed Sesame Street's first ten seasons; they are written by adults who are expected to know that the words before and after are usually tied to a certain event, e.g. "after" the aliens came or "before" I lost all my hair. If I knew where you guys work, I could volunteer to work there full time, and help out.
Re: (Score:3)
There's an extension [dnssec-validator.cz] for both Firefox and Chromium that validates DNSSEC and DANE.
Not for public sites yet (Score:2)
If a first-time visitor tries to visit a site that exclusively uses DANE, he won't even get as far as the "please use DANE" page without seeing a certificate error. So you'll have to use either a traditional CA (such as WoSign or StartSSL) or Let's Encrypt (if you are root on the server) to handle visitors who don't already have the "extension for both Firefox and Chromium that validates DNSSEC and DANE" installed, as well as visitors using Edge, Safari, or a Safari wrapper. And yes, you'll end up having to
Re: (Score:2)
My self-signed certs (used internally) are trusted by me.
A lot of companies operate an internal CA. But what certs do you use publicly?
BTW, ever noticed their root CA's are self-signed, but we're told not to trust self-signed certs?
Root certificates are self-signed by definition. We're told not to trust self-signed certificates other than those that come in the system certificate store or the ones deployed by the employer's IT department through Group Policy.
Symantec will sell you internet security... (Score:2)
That doesn't mean they actually have any of it to sell you.
They do offer some of the best fake protection that you can download from torrent sites hosted in Somalia.
Always been a problem w/certificate authorities (Score:2)
They only thing they're an authority on is processing credit cards, and they only thing they certify is that your credit card didn't bounce.
Well, that explains things.... (Score:2)