How does SSLstrip work?
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.
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
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!
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.
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.
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:
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).
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!)
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).
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..
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.
You can only provide a HSTS header over an encrypted connection, as per the spec. MITM doesn't apply here.
@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.
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.