22

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

Improve this question
1

4 Answers 4

Reset to default
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.

Improve this answer
3
  • 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
    Commented May 30, 2011 at 6: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.
    Commented May 30, 2011 at 7: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
    Commented Feb 5, 2016 at 4: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).

Improve this answer
-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.

Improve this answer
2
  • 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.
    Commented Feb 12, 2011 at 2:47
  • you're right, ettercap is capable changing SSL certificate.
    – Tornike
    Commented Feb 12, 2011 at 5: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.

Improve this answer
8
  • "From the server side" how could you know the client is being MITM-ed?
    – curiousguy
    Commented Jun 26, 2012 at 4: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
    Commented Jun 26, 2012 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
    Commented Jun 26, 2012 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
    Commented Jun 26, 2012 at 19:28
  • 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
    Commented Jun 27, 2012 at 8:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .