Slashdot Mirror


Government Could Forge SSL Certificates

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."

22 of 168 comments (clear)

  1. Can we get rid of SSL now please? by TheRaven64 · · Score: 4, Informative

    SSL is, and always has been, and ugly hack. End-to-end encryption should be done at the IP layer, not the TCP layer. Now that we have IPSEC, we have a standard way of doing it properly. The only remaining part of the problem is key distribution, but with DNSSec we can put IPSEC public keys in DNS entries and get end-to-end encryption.

    A government able to insert something into the chain of trust is still able to fake a connection, but distributing the chain of trust makes this a bit harder. The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can. For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two. Unlike an SSL certificate, the IPSec key is visible to anyone, even people who don't try to make a connection, so it's much easier to spot if someone has tampered with the connection, and will be cached in ISP's DNS caches, making an unnoticed attack much harder.

    --
    I am TheRaven on Soylent News
  2. If security is really important to you by DarkOx · · Score: 5, Insightful

    If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.

    --
    Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    1. Re:If security is really important to you by Anonymous Coward · · Score: 5, Insightful

      I like the way OpenSSH does it -- Trust On First Use (TOFU). First time you visit a server you're warned of possible MITM and given a fingerprint (which you could have, say, confirmed in person). After that you never see a warning again unless the server's key unexpectedly changes. No forcing you to automatically trust CAs, and no overstated warnings about self-signed certs.

    2. Re:If security is really important to you by thijsh · · Score: 2, Interesting

      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?

    3. Re:If security is really important to you by icebraining · · Score: 2, Insightful

      Exactly like Firefox (and probably other browsers): if you delete all the CA certificates, you'll get warned the first time you visit an encrypted site. Firefox shows you the certificate data, and you can accept and mark "Permanently store this exception".

    4. Re:If security is really important to you by mlts · · Score: 2, 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.

  3. what no one wants you to know by yup2000 · · Score: 5, Informative

    And it took you how long to figure this out? Anyone with real security in mind would create their own certificates and sign them. What's always been missing is a convenient way to verify the identify of the person you're communicating with. CAs only help in certain situations. SSL has always been more about encrypted content than identification no matter what people try to tell you.

  4. Generate your own certificates... by Anonymous Coward · · Score: 2, Insightful

    and distribute them by mail or something. That doesn't help taking to your bank,
    but then again if the government wants your bank balance they'll just ask the bank.

    1. Re:Generate your own certificates... by plover · · Score: 2, Insightful

      Actually, the banks already have a way to distribute the certs: put them on smart cards. The bank can trust the cert because they issued it. The customer can trust the cert because the bank handed it to them.

      There are many good security features a smart-card based solution brings to the table. First, the bank is entirely in charge of their own security from end-to-end. There is no trusting of third parties*. The bank is able to uniquely verify the presence of your card, and can refuse to transfer money without it. And if the bank is compelled by a warrant to cooperate with the government, they just hand over the data without fooling around with a clumsy man-in-the-middle attack, .

      What's really needed is a ubiquitous smart card reader to be included on standard computer builds.

      *Actually, you still have to trust the third parties who provide the applications, operating systems and hardware. The only completely secure way around that is for the bank to provide the actual computer to the customer, via a handheld card device like Vasco makes. A close second is by providing a custom bootable image on read-only media.

      --
      John
  5. SSL / HTTPS by bbroerman · · Score: 2, Funny

    One more nail in the coffin... (See http://nearlyperfectsoftware.com/secureajax.html for other hacks). Good thing I'm working on a protocol and libraries / utilities that can be used to replace it for all of my work, and my clients... Starting with a secure ajax framework, then on to things like POP, IMAP, SMTP, FTP, Telnet, etc. Should be cool once I get them all done.

    --
    Logic is the beginning of reason, not the end of it.
  6. DNSSEC has a similar attack against it by tepples · · Score: 3, Insightful

    with DNSSec we can put IPSEC public keys in DNS entries

    Unless the government compels domain name registrars to sign phony DNS public keys.

    For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.

    Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.

    1. Re:DNSSEC has a similar attack against it by TheRaven64 · · Score: 2, 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.

      --
      I am TheRaven on Soylent News
    2. Re:DNSSEC has a similar attack against it by iluvcapra · · Score: 3, Insightful

      Putting it further down the stack makes it easier to update/patch etc.

      It's worth pointing out that the technique described here isn't a "hack" that can be patched, it's an intrinsic feature of public-key crypto, and specifically a direct consequence of unreservedly trusting the CAs. The CAs are capable, using no tricks or computer hackery, of creating as many "redundant" signed certs for the same qualified name as they wish.

      --
      Don't blame me, I voted for Baltar.
    3. Re:DNSSEC has a similar attack against it by MasterOfMagic · · Score: 3, Insightful

      The problem with a system that relies on trusted third parties is that these third parties have to be, well, trusted. This implies that they are trustworthy. Have you evaluated all of the CAs on the list included with your operating system and browser for trustworthiness? I know I haven't. I've delegated that to the OS vendor and the browser vendor. Should I be doing this? Do I have evidence that shows that my OS vendor and browser vendor are trustworthy? And whose interest do they work for?

      These are all things that need to be evaluated when dealing with a system that requires trusted third parties. The problem, of course, is that very few people actually do this. SSL is a system that requires trusted third parties if you are to put any trust in the fact that the certificate signed by a CA really belongs to the person the CA says it belongs to.

      [This is, technically not true with self-signed certificates. Anybody can be a CA. Just self-sign a certificate and use that to sign the certificates of others. The problem is that you're not included by default. Of course, there are some sites that have their own CA, either for business reasons or because they can. They have an internal CA that they use to sign certificate for business purposes. These CAs are verified and pushed to machines, either by Active Directory at Windows sites or some other mechanism. There's no reason that an individual can't do the same when they generate certificates. The problem is that the fingerprint of CA certificates needs to be validated out of band in order for you the avoid a man in the middle attack when distributing the CA certificate to somebody else. This sort of distribution of SSL certificates would not require a trusted third party, but you would need to be able to identify the person or organization giving you the fingerprint and judge their trustworthiness.]

  7. They've Always Been Pointless by segedunum · · Score: 3, Insightful

    SSL certificates only provide the ability to encrypt communication between a browser and a server. That's all it's for. Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey. Those root certificates in your browser are just money for old rope. We definitely need something better.

  8. Banking secrecy laws by ArsenneLupin · · Score: 4, Interesting
    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 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... who just shipped units with a predictable random number generator, dramatically reducing the number of possible private keys. FAIL.

    And the BSI 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.

  9. no duh by Sloppy · · Score: 2, Insightful

    Nobody would ever seriously say that x.509's single point of failure for trusted introducers is a good idea; it just happened to be easy to deploy and got some encouragement along the way because some people could make money on it. But as soon as you look at it in terms of security, it doesn't fare very well.

    OpenPGP encourages multiple certifiers for an identity: so they're all required to conspire to sell you out. Conspiracies are hard. Build your next network app on top of Gnu TLS and make sure you test with OpenPGP, so that some day we can switch to modern (and by modern, I mean about 1990-level tech) crypto.

    BTW, governments are a great example, but always remember that they are not the only entities with capability or motivation to point a gun at someone. And even if you don't believe that, you've got to admit there are multiple governments, and only one of them at most, is accountable to you. Anyone who says that the cert system should be left vulnerable because the public has an interest in making sure that communications aren't "too secure," definitely isn't thinking about all the angles. The inherent weaknesses of X.509 should never have been used as an argument for building the web on it.

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  10. So trust the CAs a little less by johndoe42 · · 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.

  11. Story misses the point by Old97 · · Score: 2, Insightful

    The fact that governments can use or abuse technology to spy on its citizens is not news. That's as newsworthy as saying that if I had possession of your computer long enough I could find out all your secrets. If you want protection from your government, you have to do something about your government. In democracies you have some options and generally have laws and the rule of law (mostly). In such countries being vigilant and vocal can make the government behave if enough citizens participate. In autocratic countries you have to expect the worst I suppose and try to work around it. Which ever is the situation, you can't trust technology, especially one relying on a shared infrastructure (e.g. internet, ca's, etc.) to safeguard your secrets from everyone, especially anyone who has physical access to it.

    --
    Very often, people confuse simple with simplistic. The nuance is lost on most. - Clement Mok
  12. Re:Does that mean... by fuzzyfuzzyfungus · · Score: 4, Insightful

    Self-signed certs are more secure; but only if you have some way of distinguishing them. "Self signed certs" as a generic class, are man-in-the-middle city because anybody can produce one. The feds don't even have to coerce the CA, they can just sign their own.

    A specific self-signed cert, that you have some out-of-band reason for trusting, is extremely secure because only by compromising the computer storing the signing key could an adversary produce a fake one of those.

    The problem is, outside of fairly trivial scenarios(corporate intranet with self-signed certs, worker drones' browsers trust that cert by group policy; small group of paranoics who know each other IRL exchange keys under the bridge at midnight), establishing that out of band reason for trusting a cert is a pain in the ass, and not amenable to any particularly clear solution.

    CAs are basically the ugly-not-really-all-that-good solution that has the virtue of working in practice. You trust the cert because the big corporation whose business is attesting to the trustworthiness of certs says you should trust it. Easy, simple, and actually works ok from a strictly financial perspective(ie. the amount of money that Verisign can make by selling overpriced sequences of bits that make the magic green bar appear in consumer browsers is greater than the amount that they could make by MiTM attacking a whole bunch of banking sessions and then fleeing to Namibia with their reputation in tatters).

    Where it breaks down is non-strictly-financial situations. It is highly unlikely that clandestine cooperation, for surveillance purposes, with state agencies is all that costly to Verisign, or their ilk(and may in fact be lucrative, as doing various sorts of wiretaps is for the telcomms). If your threat space is just occupied by script-kiddies and Ukranian cyber criminals, commercial CAs work pretty well. If it is occupied by state entities who want information rather than money, there is no particular reason to expect them to work.

  13. Paranoia is all well and good... by DrgnDancer · · Score: 5, Insightful

    Essentially if you really want secure end to end communication with someone that is more or less fool proof and not subject to outside interference you have to manually exchange keys. It's always been this way. Any time you do less you are trusting *someone* other than yourself and person at the remote end. The simple point is that we *have* to trust someone to exist in society. We trust that the government will not suddenly decide to print "Braquats" and declare Dollars (or Pounds, or Euros, or whatever) useless. We trust that the bank won't wander off with all our money. We trust that our ISP isn't just putting up servers that pretend to be the Internet and are slowly stealing everything we type into our browsers. We trust that the grocery store hasn't poisoned all the produce. Virtually every social action we take involves some modicum of trust that the "other guy" is acting in reasonably good faith.

    Thus far the certificate authorities have been trustworthy. Could they be compromised? Of course. Could the clerk at the grocery store be bribed to poison all the produce? Of course. Do we have any reason to think the CAs *have* been compromised? Not that I'm aware of. It's pretty straightforward. Are you doing something that needs to be *completely* secret? Exchange keys with the remote end manually. Are you doing something that needs to be as secret as one can reasonably expect while still dealing public entities? Use the CAs. They have an extremely good track record and seem to be about as trustworthy as anyone can reasonably expect.

    --
    I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
  14. Re:Is it time yet? by petermgreen · · Score: 3, 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.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register