Google Reducing Trust In Symantec Certificates Following Numerous Slip-Ups (bleepingcomputer.com) 78
An anonymous Slashdot reader writes from a report via BleepingComputer: Google Chrome engineers announced plans to gradually remove trust in old Symantec SSL certificates and intent to reduce the accepted validity period of newly issued Symantec certificates, following repeated slip-ups on the part of Symantec. Google's decision comes after the conclusion of an investigation that started on January 19, which unearthed several problems with Symantec's certificate issuance process, such as 30,000 misused certificates. In September 2015, Google also discovered that Symantec issued SSL certificates for Google.com without authorization. Symantec blamed the incident on three rogue employees, whom it later fired. This move from Google will force all owners of older Symantec certificates to request a new one. Google hopes that by that point, Symantec would have revamped its infrastructure and will be following the rules agreed upon by all the other CAs and browser makers.
Re: (Score:1)
Huawei Symantec and Symantec Corporation are two separate entities.
Bluecoat (Score:5, Informative)
They issued root faking ability to bluecoat. Their certs are untrustable at this point.
Re: Bluecoat (Score:5, Insightful)
Also, they straight bought out BC, meaning a major root CA owns a major SSL/TLS intercept platform as well. But of course, we can trust them...
Re: (Score:2)
They issued root faking ability to bluecoat. Their certs are untrustable at this point.
Cool. Can we get someone who owns one of the Bluecoat appliances to extract the private key that it's using to sign the SSL intercept certs with?
Re: (Score:2)
The root certs in question were not widely deployed and were revoked long ago not that that excuses the CA from issuing them.
Re: (Score:2)
The root certs in question were not widely deployed and were revoked long ago not that that excuses the CA from issuing them.
It could still be useful if someone were to extract them on one of the few deployments in existence.....
Just because the cert has been "Revoked", does not mean people are not still running around with hardware or software that will trust it. Because many applications don't even bother to check for revocation, example: Firefox doesn't check CRLs, instead they have their own pro
Re: (Score:2)
Symantec, really... Symantec...
You mean they once had trust?
What a strange world we live in.
And you're trying to tell me we're *not* living in a simulation?
Re: (Score:1)
Re: Pass the security (Score:2)
Re: (Score:3)
More important is that this further highlights that the "trust" system as it is designed today is broken.
The trust system is based on that you get a default trust of a few CAs in the top, and if one is compromised the house of card suffers severely. And what happens if a CA is ordered by a government to provide false certificates? We can't know if that's the case or not because it will look identical to a real certificate unless it's inspected on a very low level and compared with the certificates assigned
Re: (Score:2)
Fine. You have a better solution? Active Directory on corporate networks work the same way with trusts on other domains. DNS root servers too have trusts before they replicate.
Re: (Score:2)
Step one: Any browser that cares about security MUST stop regarding https with CA certificates as any more trustworthy that self-signed certificates or plain http.
Why? Plain HTTP can be compromised by anyone on a hop between you and your destination. HTTPS with a self-signed certificate can be compromised by anyone on a hop between you and your destination, but can be detected if you do certificate pinning or certificate transparency. HTTPS with a signed cert can only be compromised with cooperation from a CA. The set of people that can compromise signed HTTPS is significantly lower than the set that can compromise self-signed HTTPS.
Re: (Score:2)
Step one: Any browser that cares about security MUST stop regarding https with CA certificates as any more trustworthy that self-signed certificates or plain http.
Why? Plain HTTP can be compromised by anyone on a hop between you and your destination. HTTPS with a self-signed certificate can be compromised by anyone on a hop between you and your destination, but can be detected if you do certificate pinning or certificate transparency. HTTPS with a signed cert can only be compromised with cooperation from a CA. The set of people that can compromise signed HTTPS is significantly lower than the set that can compromise self-signed HTTPS.
I remember in the days of IE 6 and me opening questionable porn in my youth I would get slow or weird responses from HTTP websites. I do an ipconfig of the name of the site. I then disconnect and then reboot and or sometimes do a ipconfig /release and VIOLA now when I do an ipconfig it points to a different IP address.
MITM was quite on occurrence in the old days. Of course if my DNS is pointing to somewhere else it means my PC was probably compromised but my point is changing something and a ipconfig /relea
Re: (Score:2)
The difference now is that many hackers have developed tools for MITM attacks on https.
And it still doesn't validate that sites running https are seen as more trustworthy and allows the browser to do more.
In addition to that - realize that with increased number of parties involved the security issues increases. I would prefer that my bank signed their own certificates and sent a keycard to me with the certificate that I should use combined with the CA certificate for the bank. That way only two parts are in
Re: (Score:3)
The difference now is that many hackers have developed tools for MITM attacks on https.
Yes and the same tools work with a self-signed cert or with HTTP. To make them work with HTTPS and a signed cert, you need to have a compromised CA signing cert. This is still currently mostly limited to nation-state adversaries.
Re: (Score:2)
No, you don't understand that - if you have three involved in a certificate management you have a higher risk than if you have two involved where you have exchanged the certificate validation only between those two parts. A certificate created where one of the parts is a private CA is what you need for best security, and that's essentially what a self-signed certificate is.
But if you don't validate the certificate at either end to ensure that the signer is a valid signer you have a MITM attack possibility,
True. Anyone who has ever called a locksmith knows (Score:2)
What you've said is exactly right. Anyone who has ever called a locksmith because they were locked out of their house or car understands two things:
1) They weren't able to get in without the key - it was secure.
2) The locksmith got in without a key, probably in under 2 minutes. It was not secure.
Security is a quantitative thing, not a binary thing. You can ask HOW secure something is. Asking "is it secure, yes or no?" is folly.
Standard TLS (https) is much more secure than plain text (http).
Standard TLS conn
Re: (Score:2)
The only defence we have is that if a CA was forced to issue a cert and it was discovered in the wild, it would destroy the CA. Well, that and certificate pinning for important sites. Even if a government did get a cert for google.com, Chrome would not accept it because the google.com cert is pinned.
Objective Case (Score:2)
Are editors asleep at the wheel? Google fired the employees, so the employees should be addressed in the objective case. Whom it later fired, not who.
Re: (Score:2)
Re: Objective Case (Score:2)
Re: (Score:2)
Re: (Score:1)
You do realize that this site has always been accessible and viewable all without an account, right?
Re: (Score:2)
Objectively, it was Symantec that fired the employees.
Re: (Score:1)
If you hired a law firm and obtained the services of a specific lawyer who was extremely negligent and completely threw your case to the wolves, do you find fault with the specific lawyer, or the law firm that you actually have the contract through? It's similar here - you do not buy your Symantec SSL cert from one of those three rogue employees, but rather from Symantec itself. It is the entire company that bears the burden of the misdeeds of any of its employees.
Re: (Score:1)
Google fired Symantec's employees? lolwut?
The Dying Days of the Certificate industry (Score:5, Interesting)
If there is one thing the certificate industry has proven it's that you can't trust any of them. The only solution is the automated solutions like the non-profit Let's encrypt have built. You know it's a good cert because only the person in control of the domain could get it. And I'll tell you what even with it's warts I trust it way more than I trust these damn companies that have 4 year olds signing off on certificate procedures and handing certificates to anyone with the cash.
Ultimately it's going to be movements like Let's Encrypt that fix this trust issue by taking it out of the hands of people trying to make a buck on "trust" when none of them could be trusted.
Re: (Score:2)
You know it's a good cert because only the person in control of the domain could get it.
...or anyone p0wning enough of their services at any particular time.
Re: (Score:3, Informative)
And?
If somebody is capable of getting into the system far enough that they can spoof the authentication methods Let's Encrypt uses to verify ownership/control of the domain, they can also, in all likelihood, gain access to the private key as well.
If they can gain access to the private key, then that's it: game over. Doesn't matter what you do, TLS is not going to save your customers' hides. The only way to deal with that problem is to lock down the server so they can't get back in, and create a new certific
Re: (Score:2)
There are various attack vectors that allow spoofing of those creds without access to the private key.
What such an attacker can't likely do is answer an on-premises phone call from an extended validation CA to get a new cert for the domain in question.
Don't get me wrong -- letsencrypt is a good thing for encouraging at least the possibility of security among those who cannot afford a real CA. But no fully automated system will ever be able to offer better guarantees than a staffed-up CA (not that all staff
Re: (Score:2)
You have a better solution? You want the US government deciding instead like ICAAN in addition to being a central point of exploit?
If you let others self sign that means you risk having the private keys known and it's game over. Let's encrypt has same problem in which they can screw up and hand out extra certificates. Also if they are hacked and private key is leaked then game over the Internet is done as we know it. This makes me not want lots of players on the CA space
Re: (Score:3)
Let's Encrypt doesn't verify identity, which is one of the major functions of the certificate system. The certs that Let's Encrypt offer are enough to enable HTTPS, but not to confirm the identity of the organization running the web site. Such a cert won't give you confidence that randombank.com is actually being run by Random Bank Inc.
Put another way, if you managed to register gooogle.com you could get a Let's Encrypt cert for it. What certificate authorities are supposed to do is verify that the person r
Re: The Dying Days of the Certificate industry (Score:1)
That's right. Just as we fixed the crooked financial industry by starting our own distributed currency, Bitcoin, which has never had any problem.
Symantec's take on security (Score:3)
I met a marketing exec at the Freescale Technology Forum in Austin last May. Their take on things was the good 'ol way was still the best way. I need to find his business card since he said he'd buy me lunch if Bitcoin was still around a year later.
Why do we need CAs at all? (Score:1)
Can someone explain to me why domains don't just include a public key in their DNS record (signed all the way up to a root authority), and to verify the site you're connecting to is indeed that site, you ask that site to sign a random number with their matching private key?
Why, exactly, are we still fucking around with certificate authorities, decades after having the knowledge, ability, and incentive, of being able to implement something like the above?
Re:Why do we need CAs at all? (Score:4, Interesting)
What you suggest exists. Its called DANE.
However browser vendors (like Google and Mozilla) have been reluctant to implement it because there are many real-world cases where DNS servers of various sorts simply dont support DNSSEC and DANE and also because DNSSEC and DANE use weaker 1024 bit keys in some places (chosen to keep bandwidth usage lower).
Re: (Score:2)
Browser vendors like (Google, Mozilla, Microsoft, and Apple) don't support DANE because they're big enough to each run their own trusted (by the other browsers) CA and so they don't feel the pain of having to buy certificates and "trust" third parties. They're fully invested in the CA model: sometimes charging for continued inclusion on their root CA lists and other times proposing standards that further cement the mandatory role of CAs (Certificate Transparency).
Just like you'll never see laws that are gen
"Signed all the way". That's just a different CA (Score:3)
> Can someone explain to me why domains don't just include a public key in their DNS record (signed all the way up to a root authority) ...
> Why, exactly, are we still fucking around with certificate authorities
Okay, so the DNS record would have a signed certificate. You'd have "the root authority" sign certificates? You would trust this authority for certificates, and this "certificate signing authority" would be better than having a certificate authority?
What you've suggested can be said more
Re: (Score:2)
You still have CA, you've just decided that the CA needs to be the same people who run DNS, because ... well no good reason that I can think of. What does that gain you?
First, this is for Domain Validation certificates only. The normal CA process would still apply if you wanted an EV certificate—though you could restrict your domain to a specific EV certificate for additional security.
If someone has control over your domain records they can already obtain a DV certificate for your domain from just about any CA by redirecting the domain to their own servers. What DANE buys you is all the security you would get with Domain Validation minus the need to deal with two dif
There are 900 .com registrars (Score:2)
> there are only three entities you need to trust: the domain administrator for "example.com.", the registrar for "com.", and the root authority.
There are 900 registrars handling .com, any of which can issue a transfer and change the root DNS servers for any .com domain.
Re: (Score:2)
There are 900 registrars handling .com, any of which can issue a transfer and change the root DNS servers for any .com domain.
So they don't keep track of which registrars are responsible for which domains? That does seem a bit messed up, if true. My impression was that there was a formal process registrars had to go through to transfer control over a domain name—or does that only restrict domain owners, and not registrars? If the control over .com domains is really as chaotic as you say then that is a separate issue that ought to be addressed independent of DANE or DNSSEC.
Even so, DANE still gives you the benefit of domain v
Re: (Score:2)
The registrar doesn't sign the TLD, the administrator for that TLD does. So for .com, it's Verisign.
Re: (Score:2)
Right, but if Verisign allows any registrar to update DS records for any domain, and not just the ones they're individually responsible for, then a registrar other than your own could push a malicious DS record for your domain into the TLD where it would be duly signed by Verisign, and you're back to trusting 900 separate registrars rather than just your own authorized registrar and Verisign. The TLD should only allow one registrar to update any given domain.
Poor Symantec (Score:2)
What's left? VPN?
Re: (Score:3)
Re: (Score:1)
I don't see any certs in that list issued for "paypal.com" however.
Unless you can show that the owner of any of those domains was not the one(s) to have the certificate issued for that domain, then Let's Encrypt has done their part of the job in full.
For example, the cert issued for "www.paypal-securepyment.flu.cc" is and only ever was intended to ensure that you are speaking to the server under the same name.
Class 1 certs are not and never were intended to go further, and make no claims that domain/cert/se
That explains the "not entirely secure" note on (Score:2)