Slashdot Mirror
Google Bans Symantec Root Certificates
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.
not ALL symmantec certificates...
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.
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.
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!
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.
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.
WARNING: Smartphones have side effects--most of them undocumented.
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.
Mod me down, my New Earth Global Warmingist friends!
No, Symantec didn't just inform Google that they should just remove the certs. Google found something "not quite right" multiple times after which they informed Symantec, and are now in the process of having the CA root cert removed. It's at THIS point that Symantec said "oh yeah, just remove it, no one will be affected". They would have never said anything had Google not found something, and they still haven't publicly made a statement.
Good luck with that! I'm sure you'll do a great job.
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.
hilarious!
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.
>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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Rust uses LLVM as it's backend compiler. LLVM is written in C++. Where is your rust god now?
There's an extension for both Firefox and Chromium that validates DNSSEC and DANE.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
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 cater to Safari because all other web browsers on iOS are Safari wrappers, except for a couple that are remote desktops to a browser running on someone else's computer.
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.
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.
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.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
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 relates the story of how such an MITM in the wild was discovered.
I was wondering why my cable company would be using an invalid certificate for the secure portions of their site. Now I know.