1

I am reading up on SSL stripping and I have a fundamental question on the injection point that makes this MITM attack a success. I understand the typical scenario -

A (victim) <-- plain --> M (MITM) <== SSL ==> B (Server)

Now, lets assume M and A are on the same coffee shop wifi network and M starts proxying A's traffic by ARP poisoning etc. If A is accessing B over SSL, then the traffic M intercepts is encrypted. How is M able to replace HTTPS with HTTP, strip HSTS headers and so on when all he has to work with is an encrypted stream? I imagine the entire payload, including the URL (which would include the protocol 'https://'), is encrypted.

In other words, where is the injection point from which stripping/manipulating encrypted data becomes possible? Does it happen further down on the network stack? Would M be able to switch protocol at the packet level?

Some posts talk about packet capture certs but I'm not sure if there is a well-accepted way to strip SSL without being able to decrypt the data.

1

How is M able to replace HTTPS with HTTP, strip HSTS headers and so on when all he has to work with is an encrypted stream?

They can't. An SSL strip attack needs an initially unencrypted stream to work with. It bypasses SSL rather than attacking it. The idea is to prevent your browser from initiating an HTTPS connection by turning redirects and links to HTTPS pages into plain HTTP ones. Alternatively, they can also redirect you to an actual HTTPS page but change the domain name to a similar one which is owned by the attacker (e.g. https://faceboook.com). This has benefit of still showing the green SSL indicator lock (but a false domain name).

A common injection point would be when a user first types mybank.com into the address bar and (given the site is not in the HSTS preload list) the browser first starts with a regular HTTP request where they would receive an unencrypted response redirecting them to HTTPS. That response is usually the last time you can tamper with the traffic on the application layer.

HSTS is trust-on-first-use. If the attacker doesn't catch the victim on their very first plain HTTP connection attempt where it's still possible to strip the HSTS header then they will be unsuccessful in the future because the browser will prevent any plain HTTP until the HSTS header expires.

  • "or by redirecting you to completely diffferent HTTPS pages owned by the attacker" - HTTPS.. wouldn't that mean the MITM uses a server certificate that the victim's browser trusts? – katrix Nov 17 '16 at 18:42
  • @katrix Yes. The idea is to set up a legitimate domain with a similar name (homograph). In theory I could register facbook.com and get a trusted SSL certificate for that. That has the benefit that you see the green security lock and probably don't notice it's a different domain. The other way round it would be the correct domain name but the missing SSL indicator could make you suspicious. – Arminius Nov 17 '16 at 18:49
  • 1
    Got it. So SSL stripping as a successful attack, then is not so much a traditional vulnerability, but more of MITM followed by phishing-esque steps (success hinges on the victim letting something slip past them). Thank you! – katrix Nov 17 '16 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.