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.

  • 5
    Your first diagram is right. Commented Sep 3, 2014 at 13:39

5 Answers 5


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.

  • 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! Commented Sep 7, 2013 at 22:44
  • 3
    Another solution is HTTPS-Everywhere.
    – Pacerier
    Commented Mar 29, 2015 at 7:32
  • 4
    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. Commented Jun 7, 2016 at 1: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. Commented Feb 24, 2017 at 21:04
  • 11
    @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. Commented Nov 8, 2017 at 2:29

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.

  • Doesn't cert pinning achieve the same thing? (And welcome to security.SE!) Commented Oct 9, 2015 at 2: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
    Commented Oct 10, 2015 at 4:08

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..

  • 10
    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. Commented Jun 7, 2016 at 2:02
  • You can only provide a HSTS header over an encrypted connection, as per the spec. MITM doesn't apply here.
    – Nemo
    Commented Feb 7, 2017 at 4: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
    Commented Jun 3, 2018 at 5:52

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.


The goal of the SSLstrip attack is to prevent the client from switching from http to https. Historically on the web there were two main ways the website(s) could cause the user to switch from http to https.

  1. Links included in pages can use https urls.
  2. The server can respond to a http request with a redirect to a https url.

The attacker prevents item 1 by rewriting page content, they prevent item 2 by requesting pages from the server over https while serving them to the client over http.

  • Can you provide a reference to the "rewriting page content" claim? I can't find it. And I question it because it seems entirely unnecessary if you are already successful in forcing HTTP....
    – schroeder
    Commented Sep 25, 2023 at 19:06
  • urls in links are part of page content, if the user follows one, they switch to https and the attacker can no longer continue their attack. Commented Sep 25, 2023 at 19:07
  • But that's not what you claim in this answer ... you claim that the URLs are rewritten as page content not that the URLs are redirected after being clicked. So, can you provide a reference to your claim that the URL itself is rewritten as page content. Because if that is not the case, then you are repeating the other answers and adding something that isn't true.
    – schroeder
    Commented Sep 25, 2023 at 19:08

You must log in to answer this question.

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