Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Encryption Government Privacy Security Your Rights Online

Government Could Forge SSL Certificates 168

Posted by Soulskill
from the bureaucrat-in-the-middle dept.
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."
This discussion has been archived. No new comments can be posted.

Government Could Forge SSL Certificates

Comments Filter:
  • by TheRaven64 (641858) on Friday March 26, 2010 @09:35AM (#31626072) Journal

    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)

    by ArsenneLupin (766289) on Friday March 26, 2010 @09:37AM (#31626096)
    Not a theoretical concern, but a very real one.

    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.

  • by johndoe42 (179131) on Friday March 26, 2010 @09:42AM (#31626184)

    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)

    by petermgreen (876956) <plugwash.p10link@net> on Friday March 26, 2010 @10:22AM (#31626882) Homepage

    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.

  • by thijsh (910751) on Friday March 26, 2010 @10:56AM (#31627320) Journal
    I really want web-browsers to support this properly, with a dialog that shows that it's self-signed and provides encryption but no verification. Self-signed certificates have a lot of advantages, and the only thing holding back widespread use is those crappy browser dialogs warning you that this website is going to cause the end of life as you know it. There is a legitemate use for encryption without a CA, and this article only confirms that.

    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?
  • by mlts (1038732) * on Friday March 26, 2010 @01:16PM (#31629936)

    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.

Take an astronaut to launch.

Working...