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.
Symantec need to grow the fuck up and take responsibility rather than passing blame to rogue employees.
They are a major security platform of the world whose processes apparently suck as bad as the TLA's of USA.
What would Peter Norton say?
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.
Google went full nuclear, but the tactical nuke variety rather than full scorched earth.
Not entirely clear if this covers only EV, or what the fallout for DV cert owners will be.
They issued root faking ability to bluecoat. Their certs are untrustable at this point.
That's what you get for outsourcing security (and trust).
Symantec sold their share of the joint venture in 2012.
Personally, I don't trust any of the CA's in my browser after the Digi-Notar problems
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?
Just switch to Let's Encrypt and be done with it. It's better and it's free.
Still, I don't trust "Google", or whatever their name is nowadays.
the Treasury department's Inspector General's page that I used to report an IRS phishing call.
> 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
See subject: Especially ones infecting/tracking/slowing us? Stop ads via APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
Ads/script & malware rob speed/security/privacy
Hosts add speed (via hardcodes/adblocks), security (vs. bad sites/malware/poisoned dns), reliability (vs. dns down), & anonymity (vs. dns requestlogs/trackers).
Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus + less security bugs/complexity & faster vs. addons/routers/remote dns!
Avoids DNSChangers in routers/IP settings & dns redirects (99.999% of ISP DNS != patched vs. it) + lightens DNS load & resolves faster from local system RAM!
* Via what u NATIVELY have built into the IP stack in FASTER kernelmode!
APK
P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/
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.
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.
If your security depends on trust in private companies then you really are in trouble.
You are probably 100% right but;
If you are right then almost everybody is fucked.