5

I've read you can attack connections using tools like sslstrip, if you are on the same network. So what ensures that our SSL connections remain safe?

  1. Does it depend on the cert strength?
  2. Do you have to have control of the router? (like using a pineapple mark IV)
D.W.
  • 98,420
  • 30
  • 267
  • 572
Travis Thompson
  • 539
  • 1
  • 5
  • 9

2 Answers2

6

To defend against SSL Strip:

  • Use SSL sitewide. In other words, use only HTTPS, not HTTP.

  • Use HSTS (Strict Transport Security). This will tell browsers to only connect via HTTPS, and never via HTTP.

If you use those two protections, you will be safe against SSL Strip. Search on this site to find a lot more information about how to go about enabling those protections on your site properly.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 3
    "Use SSL sitewide." If you do this, then users who enter http://yoursite.com will get a connection refused error, unless you have a non-SSL server listening on port 80 that redirects to port 443. But if you do that, then your users are susceptible to sslstrip, which is the whole point of sslstrip. – Mark E. Haase Feb 09 '13 at 04:46
5

If you're talking about Moxie's "sslstrip" attack, it's more of a user-oriented attack than an actual technical attack on SSL. It doesn't break the underlying cryptography or trust model. (He has another tool, sslsniff, which actually does attack some of the technical implementations of trust and certificate checking.)

First of all, you should watch his Defcon presentation on sslstrip, if you haven't already: http://www.thoughtcrime.org/software/sslstrip/. If nothing else, it's a great insight into how reason about security flaws.

The origin of sslstrip was based on a simple observation: most users don't arrive at SSL sites by directly typing in the URL or typing a bookmarked https:// URL. Most users connect to a non-SSL site and get redirected (e.g. HTTP 302 redirect), or they connect to a non-SSL site that has a link to the SSL site and they click the link.

In either case, the non-SSL site can easily be man-in-the-middled, and therefore the URL that the user is redirected to can be silently modified by an attacker. E.g. your link to https://bankofamerica.com/ can be changed to https://bankofamerica.com@www.badguy.com/. The end users still sees a padlock and a valid certificate, it just happens to a certificate for www.badguy.com instead of bankofamerica.com. Moxie also showed some other cool stuff with unicode in URLs and finding glyphs that look like forward slashes in order to further deceive the end user, but that stuff has since been fixed in most browsers and is ancillary to the root cause of the problem.

To answer your questions:

  1. No certificates are compromised in this attack, so "strength" doesn't matter at all. All certificates used are completely valid in a cryptographic sense.

  2. You don't have to own the local router. You can use an ARP spoofing attack to man-in-the-middle your target if you are on the same network as them.

Mark E. Haase
  • 1,902
  • 2
  • 15
  • 24