Public key crypto = fail?

I’ve been experimenting with SSLstripper the last few days.  I highly recommend playing with it; even if you have no need to actually use it, you’ll learn a lot about SSL, https, and general security failures.

But beyond the actual tool, which can intercept and “decrypt” a lot of – but not all – existing SSL connections with little chance of being noticed, it got me thinking about the process in general.  We, and the Internet, absolutely depend on SSL to protect our passwords, financial records, etc.  One could say truthfully that eCommerce would have never taken off without it.  But there is a fundamental problem with using public key crypto in this manner.  Cryptographers have known this forever, but it’s been blown off because intercepting traffic was hard.  Now, with the proliferation of WiFi and laptops, it’s much easier to snoop on people’s traffic.

The problem is this:  If you can intercept all traffic coming from the client, you can *always* find a way to fool them in to sending you their supposedly-encrypted data in a format you can read.  SSLstripper does this by intercepting the original http request, establishing its own SSL session to the server for that request, then decrypting every response and passing it on to the client.  I don’t think this will work if someone types in https:// to start with (as opposed to clicking a link or getting a redirect from a page you’ve also intercepted) – although I have yet to try it.  But even if it does, there is another way.

You’re already proxying all their traffic (using arp spoofing, probably).  So you can intercept the initial setup of the SSL connection.  You could trick SSL in to thinking they are connecting to the server that matches the certificate… but even easier, you could just proxy their DNS traffic and create fake values that match the site they’re trying to go to.

This is not a revolutionary idea, but what it points out is that the assumption of public key crypto was always that you could disseminate the public key in a secure manner.  It doesn’t have to be confidential, but it does have to maintain its integrity.  As long as you are relying on the same network that you use to access the encrypted resource to validate the public key, you’re screwed.

PGP users have long faced this problem – it’s why people don’t use encrypted email much.  But thanks to a huge campaign by eCommerce sites 10 years ago, consumers – even security experts – tend to trust SSL.  As we move more and more from wired networks run by big telcos to wireless / WiMax / cell / mesh networks, we’re going to have to start assuming that any hop in the network may be hostile.

Advertisements

3 Responses to “Public key crypto = fail?”

  1. Twitted by johnnycocaine Says:

    […] This post was Twitted by johnnycocaine […]

  2. Eduardo Habkost Says:

    You’re already proxying all their traffic (using arp spoofing, probably). So you can intercept the initial setup of the SSL connection. You could trick SSL in to thinking they are connecting to the server that matches the certificate… but even easier, you could just proxy their DNS traffic and create fake values that match the site they’re trying to go to.

    That’s exactly the point of having a certificate system. This is why we have the scary “the SSL certificate isn’t valid” screen on Firefox. It is not as easy as a middle man saying “I am http://www.yourbank.com, believe me” and having the client blindly accepting it.

    As we move more and more from wired networks run by big telcos to wireless / WiMax / cell / mesh networks, we’re going to have to start assuming that any hop in the network may be hostile.

    You seem to be implying that SSL does not assume this. SSL already assumes this, that’s why we have a complex certificate system in place. This was always taken into account on every sane public key crypto system. See http://en.wikipedia.org/wiki/Public_key_infrastructure for pointers.

    • johnnycocaine Says:

      Eduardo, thanks for the feedback. You’re right that given a properly implemented PKI system that transfers keys out-of-band, the attack surface is greatly reduced. However, there must be no failures – in the browser, the PC, or the user. We’ve already seen how SSLstrip can bypass a lot of SSL implementations, and there are studies about how many people click through browser warnings – it’s a lot! There are other issues that scare me, but they deserve their own blog post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: