"..although some browsers – such as Chrome – install such fixes automatically."
Could the fake cert be used to fix Chrome?
Google and other browser vendors have taken steps to block an unauthorized digital certificate for the " *.google.com" domain that fraudsters could have used to impersonate the search giant's online services. According to a blog post by software engineer Adam Langley, Google's Chrome team first discovered a site using the …
On linux you need the signing key for the packages and that is in a completely different trust chain - the gpg chain of the distribution you are using. On other OS-es it will probably be no as well - the certificates and keys for the packages are chained under the OS vendor root.
In any case, it just goes to confirm one more time how many of the certificate authorities do not belong on the trusted list in the first place.
"In any case, it just goes to confirm one more time how many of the certificate authorities do not belong on the trusted list in the first place."
Totally agreed, there was a recent update to the certificate authorities on Windows that broke my 802.1x because the number of trusted certificates went over 200. Some of them are just ridiculous, I can't remember the last time a site I went to had a certificate not signed by one of the major authorities
Revoking the intermediate certificate will be grand. If someone was checking the revocation lists of course.
The biggest problem of the certificate system is the positive thinking when designing it: it is good in delivering the positive message "trust me" and sucks royally in delivering the message "do not trust this one". CRLs have to be distributed to endpoints and no one uses OCSP. Even if it was used, it can be blocked which makes most implementations default to "I will trust this one".
Frankly it is time we relegate the current cert system for offline uses only (it is quite good for that) and switch to DANE for internet/online trust. This puts the "trust me" message into the hands of the domain owner. The only third party trust involved are the root signing key and the TLD signing key above your domain. That is 2 parties in total for most domains instead of a 100+ list (half of which we have never heard of) of certs which can spoof anything (not just something in their "zone").
Trust needs to be decentralised. SSL authorities must be assumed, like all commercial enterprises, to be willing to sell their grandmothers if the price is right, or their arms are twisted enough.
Firefox users should consider installing a decentralised certificate vetting system called Convergence. See the site at http://convergence.io . It checks that a certificate is the same certificate that other users are seeing.
"How do we know Convergence (or a party in between) isn't just telling the browser what it wants to hear?"
Because the man-in-the-middle would have to get into the middle of multiple independent lines of secure communication with different security keys. You can choose how many, according to need, and spread them around the world.
People independent of the inventor of the system are contributing to the system, so you don't have to trust the inventor of Convergence blindly, and shouldn't.
This is the sort of "trust no one" system that existing certificate authorities and governments will fight against, for obvious reasons.
Mistakenly issued ?
How does a Cert Issuer "mistakenly" issue wrong certificates ? The process is usually a pain and it would be surprising that they managed to make this kind of mistake unless it was intentional ( thinking extra dollars here)... Not what we can consider as being a very "trustworthy" organization.
But then again how do we know that Verisign ( cough Symantec) et al haven't made the same "mistakes" too.
That's not even close to be the problem. I could live with idiots generating certs mistakenly for this site or that site, as this would be dealt with eventually; on a case by case basis.
No, what is really baffling is they mistakenly issued intermediate certs, which are in essence delegations to generate as many certs as you want, for your web site, mine, or *.google.com, regardless of country, location etc ... ! And they apparently covered it until someone realises !
That means and shows:
- Turktrust are totally hopeless
- one hopeless link in the chain compromises everything
- Turktrust, no matter how hopeless, are the only ones in Turkey to deliver certs, so need and will be kept in charge
- as mentioned above, blacklisting doesn't work (de facto, and by design)
So, as others have hinted, and as has been already be discussed at El Reg, the TLS system no longer ensures security on da web, and needs to be replaced.
"That status could be in jeopardy, however, because the only solution to the spoofed-certificate problem, now that the cat is out of the bag, is to revoke the authority of some or all certificates issued by Turktrust."
How so?! All you have to do is issue revocation certificates for the mistakenly issued certificates. Then they can no longer be used to certify fraudulent keys and the keys already certified with them will become invalid, because the chain of trust will break.
That it might be advisable to revoke Turktrust's license for issuing certificates because of their demonstrated incompetence is a completely different matter.
If the intermediates that were wrongly released (more accurately, private keys revealed) were their standard ones in current use then revoking them will indeed revoke "some or all" of the certificates previously issued. So although they could in theory reissue a new intermediate and carry on, there's a good chance every one of their current customers will be baying for blood, never mind the browser developers wanting bits of their anatomy on skewers. Ouch.
But as others have said, every time this happens it shows the weakness of a distributed authority system where any branch can pretend to be any other branch. Proper integration with the domain system which provides firewalls between branches is the only solution.
On further investigation:
It looks like the intermediates/subordinate CA certs that were issued were *not* their standard ones, so other customers wouldn't be effected. That still leaves the issue of the whole system only being as strong as its weakest branch, though.
Instead of just displaying yellow or green in the bar, the bar should also display the name of the CA which is vouching for the user.
So if you are used to seeing "Google Inc (certified by Thawte Consulting)", and one day you see
"Google Inc (certified by Turkish Hotbaths Ltd)", at least a clueful user would be able to see the difference and decide if it is reasonable. I think there are enough clueful users around to be able to raise noise in forums and spread the alarm if something untoward started to happen.
Of course, the name of the CA displayed would always be the name stored in the local catalogue of root certs, and therefore not be spoofable (*).
Then CAs would become more publically visible and would have more of a vested interested in protecting their brand/reputation; equally, commerce sites would have a vested interest in buying their certificates from a well-trusted CA brand rather than some dodgy fly-by-night. And since you would start to learn which CAs you commonly come across, it would make it easier to disable the dozens of irrelevant root CAs which browser vendors throw in by default.
I think that if the SSL trust model requires us to have faith in literally hundreds of faceless CA corporations, at least we should know which one we are dealing with at any one time.
(*) If an intermediate CA was also involved, I suggest displaying an additional icon. Advanced users could then click to get details of the whole chain, as they can now. But the identity in the intermediate CA's certificate is only as trustworthy as the root CA which signed it, so it should not be shown by default.
So unless protected by a certificate revocation list (CRL) or OCSP Android are once again at the mercy of sporadic or non-existent updates from manufactures and carriers.
Google hardcode their own certificates into Android and Chrome to prevent impersonation, but no immediate information on how Android browsers will be updated with changes to the TURKTRUST CA which was apparently included from 2.0.3.
Of course if you have root on your Android device and feel brave enough you can go editing the Certificate store yourself, but this is not acceptable.
as I have noted in the past: the fundamental error here is that HTTPS bypasses the requirement for users to authenticate keys
this requirement is carefully detailed by Phil Zimmerman in his original PGP documentation in the section "Protecting keys from tampering"
HTTPS did not follow his requiremnts and got what they deserved
anyone using PGP ( or by extension x.509 certificates ) should generate their own keypair and sign any certificate that is used in a critical system. it should be noted that MSFT already does this for critical security bulletins .
the IT industry again is guilty of glossing over a critical requirement in favor of convenience
getting hacked ain't gonna be convenient
So, how are you going to authenticate the key you see from (say) Amazon? Phone them up - on what phone number? Not the one they publish on their website, obviously, as it could be spoofed.
Perhaps you only deal with companies where you have personally picked up a printed copy of their key fingerprint from their head office?
And of course, Amazon have hundreds of webservers with separate keys, so actually what you need is a copy of their key-signing public key, and you will then validate each time that the server you are talking to has a key signed by their KSK. Then you have to remember which websites go with which KSKs.
This is of course totally impractical, and it's the job that CAs are supposed to do on your behalf.
IMO, the main problem with the SSL model of trust is that it has no domain restrictions. I might trust a Turkish CA to sign certificates for *.tr domains, and a Brazilian one for *.br domains; I don't want to trust them to sign absolutely anything.
The problem with the current SSL cert system is that trust can be diluted.
Consider: what if there were only a couple of cert signers? Bad in that certs are going to be hellishly expensive, but good in that at least you only have a couple of entities that can screw you, so they can be watched like hawks (granted, if one of them DOES screw you, you are well and truly screwed).
But with the current model of tens of cert vendors, some of whom I've never heard of unless I go cruising through the depths of my system, any one of which is as "trusted" as any other, we see this current system.
I agree with the previous poster that any tool using SSL should, upon encountering a new cert, display a message to the user about the cert, and the chain of trust, and allow options of "trust once, trust always, trust never, research" - where "research" does some searches on that cert for any indications of trouble. Moreover, the user should be given the chance to say "not only do I not trust THIS cert, I now no longer trust the cert that signed it." - all the way up to the root if desired. If the user, who normally doesn't see any messages about https://www.example.com, is suddenly presented with a dialog, it may (*may* - we are talking about [l]users here) make them pause for those all-too-critical few seconds.
And why is it that a cert is only signed by ONE authority? Why not follow more of a web of trust model like PGP/GPG, wherein a cert can be signed by more than one entity? If I see a cert for "shadysite.com", and it is only signed by a single CA I've never heard of, I can be less trusting than it I see a cert signed by 5 different CAs, several of which I have a higher degree of trust. Even better: let people vouch for (OR AGAINST!) a cert by posting a signing statement (a file signed by the person's private key and the cert's public key, saying "I trust this entity" or "I DO NOT trust this entity"). Would I trust J. Random Person's signing? NO. But I would trust technically competent people I know, or at least know of (e.g. if RMS vouches for a cert, I can feel a pretty high degree of trust the cert's owners aren't looking to violate my rights. If Consumer Reports vouches for a cert, I can feel pretty good about it. If Steve Ballmer vouches for a cert....) That sort of "vouching" would be invaluable for most of us geeks that support non-technical family - I can set Granny Fanny's computer such that if I have vouched for a key, accept without question.
Trust shouldn't be about trusting any single entity without question, as the current SSL system does. It should be a Bayesian calculation - the product of a set of trust probabilities, yielding a figure of merit for the entity.
Is anyone else thinking this might be an inside job? Fraudsters pay off employee, who either has another job lined up, or plans to let a colleague take the fall. The alternative is that fraudsters are routinely checking the certificates on every SSL website in the hope that one day a CA will make this serious blunder and they will be able to find a way to steal the key from the cert holder. Sure, they can automate the search, but why wait for a blunder when you can pay for one?
Secondly, are the fraudsters now kicking themselves for issuing a fake "*.google.com" cert? They could have kept themselves busy and well-funded on dozens of low-profile domain certs, maybe some obscure badly-run banks, but they got greedy and went for the big one.
There is a massive trial going on in Turkey named "Ergenekon" which is based on forged digital documents, mail and files which were "put" inside victims computers.
Google/gmail is absurdly popular in Turkish media circles.
This mistake isn't some Turks being stupid to release a wrong certificate, it is a massive man in the middle attack which can't be done without government resources.
For more information in English about a connected trial with similar issues:
Biting the hand that feeds IT © 1998–2019