Government Could Forge SSL Certificates 168
FutureDomain writes "Is SSL becoming pointless? Researchers are poking holes in the chain of trust for SSL certificates which protect sensitive data. According to these hypothesized attacks, governments could compel certificate authorities to give them phony certificates that are signed by the CA, which are then used to perform man in the middle attacks. They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers' private data to US government law enforcement. The researchers are developing a Firefox plugin (PDF) that checks past certificates and warns of anomalies in the issuing country, but not much can help if government starts spying on the secure connections of its own citizens."
Re:DNSSEC has a similar attack against it (Score:3, Interesting)
Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.
It's very different. The server does not need modifying at all. It only needs a single IPSec private key, you are just distributing the public key via two different routes. The client doesn't even need to try connecting in order to verify the integrity of the key, it just needs to try fetching the two different DNS records and comparing their IPSECKEY entries. If they are different, don't connect at all. Importantly, individual clients don't need to do this check; you just need someone to be perform this lookup periodically to see if either of the DNS entries has been modified. Because the DNS entries are cached, you can't easily perform this attack on a single client, you need to do it on a network, and that makes it a lot harder to do secretly.
Banking secrecy laws (Score:5, Interesting)
Many European countries (Germany, Belgium) now have electronic identity cards, which double as PKI signing tokens, with which you can authenticate yourself to web services, such as your bank.
When Luxembourg introduced a similar system [luxtrust.lu] they didn't piggy back it on an id card, but issued "signing stick" and smart cards just for the purpose of PKI.
You may wonder why, especially since an electronic id card is already in planning in Luxembourg as well.
The answer is obvious: many customers of Luxembourgish banks are foreigners, couldn't thus get a Luxembourgish id card, but wouldn't trust their own government's id cards, so an ad-hoc system was needed: Luxtrust.
Unfortunately, Luxembourg doesn't have any native smartcard industry, so they had to buy the chips from the French [gemalto.com]... who just shipped units with a predictable random number generator, dramatically reducing the number of possible private keys. FAIL.
And the BSI [www.bsi.de] institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks. DOUBLE FAIL.
So trust the CAs a little less (Score:2, Interesting)
There a "fix" that should help a lot: have browsers cache all certificates that they've accepted. Then, whenever a site *changes* its certificate, give a bit fat warning and optionally send the new certificate to some repository of questionable certificates.
If that repository starts to see bogus certificates signed by a CA, revoke that CA's root certificate.
To really make it work, HTTPS should have a mechanism to indicate that a certificate may not be changed until such-and-such a time, and there should be a way to (later, when using a different internet connection) tell a website what certificates you've seen that claim to identify it. That way the web site operator can go after bad CAs itself.
Re:Is it time yet? (Score:4, Interesting)
The problem is they don't need to get the cooperation of the CA that is actually in use, only that of one of the long list that your browser trusts.
Re:If security is really important to you (Score:3, Interesting)
The way I see it you have the following levels:
- HTTP (unencrypted, but free)
- HTTPS SSC TOFU (encrypted and free + as a bonus no government can mess with certs apparently)
- HTTPS CA (encrypted + verified)
- HTTPS CA+ (better verification + whatever extra shit they can sell for overpriced certificates)
The question is now: which browser will be the first to support true free and 'open' HTTPS?
Re:If security is really important to you (Score:3, Interesting)
Perhaps have Web server certs trusted by multiple CAs, so you might have a level of trust above that. This way, if a website had a cert validated by a CA in the US, Israel, Germany, Russia, and China, one of those CAs might get compromised, but it would take a pretty big international agreement to compromise all of them and generate a bogus cert.