100

I've been reading up on SSLstrip and I'm not 100% sure on my understanding of how it works.

A lot of documentation seems to indicate that it simply replaces occurrences of "https" with "http" in traffic that it has access to. So a URL passing through such as "https://twitter.com" would be passed on the to victim as "http://twitter.com".

At this point does SSLstrip continue to communicate with Twitter via HTTPS on our behalf? Something like this:

Victim  <== HTTP ==>  Attacker  <== HTTPS ==>  Twitter

Or is it just the fact that the client is now communicating with Twitter over HTTP that gives us access to the traffic?

Victim  <== HTTP ==>  Attacker  <== HTTP ==>  Twitter

My guess is it would be the first option where the Attacker continues to communicate with Twitter via HTTPS as it is enforced by Twitter but I would just like some clarification, thanks.

Scott Helme
  • 3,178
  • 3
  • 21
  • 32

4 Answers4

86

You should watch Moxie Marlinspike's talk Defeating SSL using SSLStrip. In short SSLStrip is a type of MITM attack that forces a victim's browser into communicating with an adversary in plain-text over HTTP, and the adversary proxies the modified content from an HTTPS server. To do this, SSLStrip is "stripping" https:// URLs and turning them into http:// URLs.

HSTS is a proposed solution to this problem.

rook
  • 46,916
  • 10
  • 92
  • 181
  • Brilliant, that answered my question. It was actually problems I encountered with HSTS in Chrome and it's preloaded list of sites that got me questioning how it works. Thanks! – Scott Helme Sep 07 '13 at 22:44
  • 3
    Another solution is HTTPS-Everywhere. – Pacerier Mar 29 '15 at 07:32
  • 3
    HTTPS-Everywhere isn't really a solution to this problem. It can mitigate it for sites with explicit rules defined, but that's not really a scalable solution. – Brandon Paddock Jun 07 '16 at 01:59
  • HTTPS-Everywhere is a solution when provider start serving TLS only! Then there is no need to upgrade the connection and no possibility to downgrade it in this way. And there a some pages proving that TLS-only is perfectly doable. – Florian Loch Feb 24 '17 at 21:04
  • 8
    @FlorianLoch Whether the site accepts HTTP connections (HSTS or not) has nothing to do with this problem. Just because you can't connect to the site with HTTP doesn't mean you can't connect to the attacker with HTTP. – user253751 Nov 08 '17 at 02:29
4

Talking about possible solutions: The only truly reliable way to prevent/detect SSL stripping is using always-encrypted communication & side-channel authentication of the TLS (basically use the TLS key exchange, but replace PKI/certificate based authentication with user or device based authentication). This means in practice that after an key exchange the server and the user end up with certain shared secrets or keys. Client and server then use a discrete authentication channel (eg. using SSH or other methods of strong asymmetric authentication) and authenticate both their identities and the TLS keys. If the keys are the same, you have a certainty of 100% end-to-end encrypted channel.

If there is a man-in-the-middle, he could do 2 attack vectors:

  1. MITM could terminate TLS communication with the server at his point and let user communicate via HTTP. This causes no alerts in traditional TLS/HSTS. However, this will be discovered by the side-channel authentication, because the server and the client have different TLS keys (key 1 and no-key).

  2. MITM could use a forged or stolen certificate. This might or might not trigger an alert, depending on the used certificate (it might be increasingly easy thanks to Let's Encrypt initiative). This attack would again be discovered by the side-channel authenticated TLS, because the server would have different key than the client (server has key1, MITM has key1 to the server, MITM has key2 to the client, client has key2).

This kills the SSL certificates as a bonus and it would also work with with CDNs Please note that this solution is not immune to backdoors to encryption.

Ivo
  • 61
  • 2
  • Doesn't [cert pinning](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning) achieve the same thing? (And welcome to security.SE!) – Neil Smithline Oct 09 '15 at 02:31
  • Cert pinning is quite an ugly work around in terms of manageability, but it does indeed solve the some of the problems with fraudulent certs. If you however have a MITM on DNS server, he can fairly easily work around it and I don't believe that cert pinning solves the SSL stripping (unless you combine it with HSTS for all domains and subdomains). – Ivo Oct 10 '15 at 04:08
2

HSTS is a simple "http header" that can be tampered and changed by MITM

Prefer addons like HTTPnowhere or HTTPS Everywhere, with 90% of sucess... Another type of addon is https://addons.mozilla.org/en-US/firefox/addon/enable-disable-weak-ssl-cip/ to encrypt data after SSL handshake negotiation.

Obvious as an client, you are in a INFERIOR position and routers between you and internet are controlled easily . So, compreheend that clients have low resources to control the traffic..and for that only the best solution is VPN /Stunnel.. but never knows if NSA/ISP's/previligied people have the magic secret to intercept and decrypt that comunication..

Mário Guedes
  • 37
  • 1
  • 9
    I think you're misunderstanding how HSTS is intended to work. It doesn't matter whether the HSTS header is present or tampered with in the common scenario, as the assumption is that the user has connected to the real site at least once (or the site is in the built-in whitelist browsers have). From then on the header doesn't matter, the client will refuse to initiate a non-HTTPS connection. – Brandon Paddock Jun 07 '16 at 02:02
  • You can only provide a HSTS header over an encrypted connection, as per the spec. MITM doesn't apply here. – Nemo Feb 07 '17 at 04:27
  • 1
    @Nemo: More accurately, a conforming user agent (i.e. browser) will *ignore* any `Strict-Transport-Security` header it sees in an insecure response. You (or a MitM) can provide the header all day long; the browser will just pretend it isn't there until it receives over an HTTPS connection. – CBHacking Jun 03 '18 at 05:52
1

I think it's important to note that the stripping is done on the client to server payloads and requires the client to first request HTTP content.

Using the Twitter example, the client would first need to request http://www.twitter.com - when the site redirects the client to HTTPS SSL Strip will strip the "s" in the response such that the client will continue to request HTTP content, not HTTPS.

If a client requested https://www.twitter.com (or HSTS is in use), an SSL MiTM attack would be required to intercept the response, which defeats the purpose of this attack.

Matt
  • 11
  • 1