Slashdot Mirror
Google Reducing Trust In Symantec Certificates Following Numerous Slip-Ups (bleepingcomputer.com)
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.
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.
Slashdot: providing anti-social weirdos a soapbox, since 1997.
They issued root faking ability to bluecoat. Their certs are untrustable at this point.
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.
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.
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?
Poor Symantec. Google is making their CA business worthless. Microsoft is making their antivirus business worthless.
What's left? VPN?
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 to the company using them.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
http://saveie6.com/
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
No it's not. Let's Encrypt is even a bigger offender. Example: Let's Encrypt issued over 15,000 certificates for domains containing PayPal in their name (obvious phishing sites): https://crt.sh/?identity=paypa...
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 am TheRaven on Soylent News
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/server/etc are related to the company name "paypal"
EV certs are in theory meant to do that, but as Let's Encrypt doesn't issue such certs at all (can they even?), that's moot for your point.
Even for other CAs that can, EV certs will make your browser show the issued-to company name to inform you specifically of that fact.
Certificates only address encryption and identification, and your examples prove that's exactly what they are doing.
They do not address the issue of a human failing to care about which server they are going to, only addressing the server they instructed the browser to go to us the one the server was identified as.
Now you may very well think that function is useless because it doesn't go above and beyond its goal. And that's fine.
But the actual function they perform is still very important and very much desired by those of us that don't have expectations beyond what is offered. And that should be fine with you too instead of trying to argue a useful tool be taken away from us.
Sorry if that sounds elitist, but it's hard not to when those of us that know how to use a tool are speaking to those that don't understand why the tool even exists let alone how to use it.
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 /release fixes it shows it is easy to spoof before MS took security more seriously as it does today.
http://saveie6.com/
the Treasury department's Inspector General's page that I used to report an IRS phishing call.
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 involved in the channel and the certificates can be validated both ways. At least as long as neither of the end systems are compromised.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
I am TheRaven on Soylent News
> 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 succinctly as follows:
Why aren't the people who run DNS also certificate authorities?
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?
From the link;
Huawei Symantec and Symantec Corporation are two separate entities.
The contents of this message have been doubly encrypted by ROT13
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 connections are useful in the same way that physical locks are useful - they make it unlikely that anyone will in fact defeat your security. Both *can* be defeated by a skilled person using the right tools, given they invest enough time in doing so. Both are more secure than leaving stuff wide open for any passerby to take.
Self-signed certificates are slightly more secure than plain text on a *technical* level, but because they may create an illusion of strong security where none exists, they may be less secure in practice.
We have customers using self-signed certs (without pinning) who mistakenly think the self-signed certs prevent MITM attacks, so they send sensitive data over these connections, "secured" by TLS using self-signed certs. They'd arguably be more secure overall if they understood they have no protection on those connections, so they wouldn't use them for sensitive data (or would encrypt the data before sending it over the non-secured connection). A misunderstanding of the "protection" offered by self-signed certs leads them to do something foolish.
In this regard, there is a counterpoint to what I said above about it being folly to ask "is it secure?" as a yes or no question. It may be wise to try to create a binary secure/non-secure label in order to ease understanding. Weak security can fool users into thinking it's "secure", so it may be better to either secure something strongly or not at all, so users can easily tell that it's obviously not secured.
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, and if the CA is a third part you have a higher risk of a MITM situation - like the Symantec CA.
The reasoning that self-signed certificates are less secure is based on that they aren't validated, but if they are properly validated at both ends they are more secure. But that's not something the popular CAs want to inform you about since that would be bad for their business.
And how many really validates the certificates of a https connection anyway?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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 different CAs, one for DNSSEC and another for TLS.
As a bonus, with DANE records for a site "example.com." there are only three entities you need to trust: the domain administrator for "example.com.", the registrar for "com.", and the root authority. In the traditional CA system any CA can issue a certificate for any domain, so you're forced to trust dozens (if not hundreds) of CAs both to maintain the security of their signing keys and to refrain from issuing an unauthorized certificate for your domain. A breach at any one of those CAs can compromise the security of your site.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
> 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.
If your security depends on trust in private companies then you really are in trouble.
"Trump!!", the new Godwin.