22

I'm wondering, does anyone have any suggestions to defend against SSLstrip particularly?

curiousguy
  • 5,028
  • 3
  • 25
  • 27
Skizit
  • 321
  • 2
  • 5
  • 3
    For those who are not so familiar with SSLstrip, here is a video tutorial: http://www.securitytube.net/video/193 – Chris Dale May 30 '11 at 10:16

4 Answers4

18

Here are my recommendations for what users can to defend themselves against SSLstrip, Firesheep, and similar attacks:

  • Install HTTPS Everywhere or ForceTLS. (HTTPS Everywhere is easier to use.) This tells your browser to use the SSL versions of web sites, where possible.

  • If the browser gives you a certificate warning, do not bypass the warning, and do not continue browsing that web site.

  • For critical sites, like online banking, go to the HTTPS (SSL) version of the site from your machine while using a secure network, and then bookmark that page. Then, always open the site by opening the bookmark whenever you want to go to that page. Never type its address into the address bar or search bar.

  • If you will only be browsing a single site, consider configuring a site-specific browser. This is probably not needed for most purposes, but it will provide additional security against some attacks; it might be appropriate, e.g., for businesses that are using online banking.

  • Alternatively, instead of HTTPS Everywhere, you can do your web browsing via a VPN service.

  • Configure your email client to use SSL (also known as TLS) and to check the validity of certificates. This will ensure the connection to the email server is encrypted.

Here are my recommendations for what web sites can do to protect their users against Firesheep, SSLstrip, and similar attacks:

  • Enable SSL sitewide (i.e., HTTPS).

  • Enable HSTS (HTTP Strict Transport Security).

  • Make sure that your certificate is valid. Consider buying an Extended Validation (EV) certificate, for more security-critical sites.

  • Enable secure cookies, i.e., ensure that all cookies are served with the secure attribute, so that your user's browsers will only send those cookies back over SSL-protected connections and never disclose them over any non-SSL (HTTP) link.

  • Disable HTTP (non-SSL) access, or redirect users to the SSL version of the web site.

  • Avoid or minimize use of third-party Javascript libraries, widgets, like buttons, etc. Or, if you must use them, make sure they are served from a https: URL and that the site hosting them is one you trust.

On a different topic, administrators of mail servers can protect their users by enabling SSL/TLS protection for IMAP (or, better yet, requiring use of SSL/TLS on all connections) and by enabling STARTTLS on their SMTP servers.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 1
    Is it requires to type https into the browser URL bar? I believe it is, even if HSTS exists, because the unencrypted HTTP redirect can be subverted. I guess even HSTS isn't perfect in this case? – atdre May 30 '11 at 06:21
  • 1
    @atdre, Nope, your understanding is not correct. I believe that using either HSTS (if the STS header has previously been sent) or HTTPS Everywhere takes care of that risk. Neither of them rely upon an unencrypted HTTP redirect; instead, the browser takes care of automatically turning http URLs into https URLs. The threat you are concerned about is exactly the sort of thing that both HSTS and HTTPS Everywhere were specifically designed to defend against. – D.W. May 30 '11 at 07:31
  • 1
    But, if this is the first time the user has been to the site on this device, the device doesn't know the HSTS policy. Therefore, an attacker can do what they like. The solution browsers have now arrived at is a global list of pre-configured HSTS sites. – O'Rooney Feb 05 '16 at 04:17
1

Using Privoxy rule: 

echo '{ +redirect{s@http://@https://@} }
.foo.org' >> /etc/privoxy/user.action

will redirect you to HTTPS if a site is whitelisted. In the example www.foo.org and foo.org and subdomain.foo.org can only use HTTPS because the proxy redirects it. If there's an SSLStrip mitm then the page would just load and load and load....it won't be reachable. I think this would be a very good solution (fixme).

LanceBaynes
  • 6,149
  • 11
  • 60
  • 91
-1

When you visit SSL secured web site or ssh to host, you accept certificate. If certificate is not validated with public Certificate authority servers, or any local CA, your browser warns you about the wrong certificate. So if you want to secure your traffic from ARP attacks, you have to use valid SSL certificate and don't browse web sites warning about invalid certificate. With SSH, if certificate was changed, SSH will inform you about public key change.

Tornike
  • 593
  • 1
  • 6
  • 8
  • 7
    No, no, no! This answer is simply wrong, and dangerously so. SSLstrip does not introduce certificate errors. SSLstrip can still screw you even if you never click through any browser warning about invalid certificates. That's because SSLstrip can *remove SSL entirely*, transparently converting a SSL site to a non-SSL site (converting HTTPS to HTTP). – D.W. Feb 12 '11 at 02:47
  • you're right, ettercap is capable changing SSL certificate. – Tornike Feb 12 '11 at 05:44
-2

SSLStrip merely redirects to http versions of the page. From the server side, you could introduce things like messages or images that state "your browser has been hijacked" or similar. If you are in a controlled environment this can be handled with an inline transparent web proxy that replaces all http content in this way. Similar to the forcetls etc answer, but handling the problem on the server side. This way, you don't have to worry about pebkac and unauthorised devices. Just a couple of thoughts.

RobotHumans
  • 335
  • 1
  • 12
  • "_From the server side_" how could you know the client is being MITM-ed? – curiousguy Jun 26 '12 at 04:34
  • 1
    @curiousguy Forcing https at the proxy as stated in the question(we're talking local proxy in a business case). If someone tries gets any assets via http, you replace all assets with "you have been hijacked." I thought that was relatively clear from the statement. – RobotHumans Jun 26 '12 at 16:47
  • "_If someone tries gets any assets via http, you replace all assets with "you have been hijacked."_" So you end-up with an http website that just says "you have been hijacked."? Why do you even have an http website then? why note https only? "_I thought that was relatively clear from the statement._" It isn't clear how this blocking might be useful in any way! – curiousguy Jun 26 '12 at 19:22
  • 1
    It would prevent a mitm-ed user from fetching non-http assets. Instead of a "Paypal" banner it would display "you have been hijacked". Hence, they don't continue entering data. Hence it is useful. – RobotHumans Jun 26 '12 at 19:28
  • "_Hence it is useful._" Sorry, it is not. It makes zero difference. You might as well not have an HTTP site at all. – curiousguy Jun 27 '12 at 02:53
  • 1
    You're totally missing the point. I'm not saying from the server hosting side e.g. mydomain.com. I'm saying from a local proxy for a LAN before ever leaving. I'm convinced at this point you're intentionally just being difficult. – RobotHumans Jun 27 '12 at 08:55
  • "_I'm not saying from the server hosting side e.g. mydomain.com._" Yet, **your answer says "server" twice**. Do you know you can edit your message in order to clarify it? "_I'm convinced at this point you're intentionally just being difficult._" how much would you bet? Do a poll: ask people if your answer is clear. – curiousguy Jun 27 '12 at 09:17
  • "_You're totally missing the point._" So: 1) I initially totally missed the point 2) Now I think I am getting 3) I stand by the fact that your answer is not clear as worded, and is difficult to understand without the comments 4) If you could rephrase your answer making clear this is about a proxy, I would remove the downvote. – curiousguy Jun 27 '12 at 11:08