8

So I just learned about SSLStrip now--I feel like I'm so late to the game. What I want to know is: If your site only serves content over HTTPS and hard fails on HTTP requests, with no redirect, are you still vulnerable? Can an attacker intercept your HTTPS request and perform the request "on your behalf", so-to-speak, and serve your browser an HTTP version, if you type into your browser's address bar? (Using either SSLStrip or some other attack?)

The TL:DR;

Below user10008 gives the answer. SSLStrip doesn't depend on the server's behavior, it depends on the client. If you can get the client to make the request over HTTP, instead of HTTPS, you can perform the attack, even if the server only supports HTTPS. HSTS prevents the browser from performing the plain HTTP request in the first place (on subsequent requests).

John
  • 2,242
  • 2
  • 28
  • 45

4 Answers4

11

Yes, without further measures, the attacker still can perform SSLStrip. For SSLStrip to work, the attacker only needs to be a man in the middle, unrelated from your behaviour regarding HTTP. On an incoming HTTP request, the attacker would open an HTTPS connection to the real server, and "strip" the SSL off the HTTPS. So, there would be no HTTP communication between the attacker and the server. Even if the server's HTTP behaviour seems irrelevant, it is better for further mitigations to disable HTTP or create a permanent redirect.

When you only serve HTTPS, and you are sure you want HTTPS in the future, you can partially mitigate by using HTTP Strict Transport Security (HSTS) to tell users you only serve HTTPS. This will mitigate SSLStrip for all users from the time they connect at least once without being attacked.

You can achieve full mitigation for Firefox and Chrome by requesting to add yourself to a HSTS whitelist. Firefox and Chrome assume HTTPS use for websites on that whitelist, but a requirement for being on that list is sending the HSTS header. More info on applying here.

user10008
  • 4,315
  • 21
  • 33
  • Ok, but this seems to contradict what some responders are saying below. I'm proposing that your site never serves HTTP and that the user types in HTTPS directly in the address bar. You're saying that SSLStrip can redirect the client's browser from HTTPS to HTTP? The responders below seem to indicate that you're safe if you type HTTPS... – John Aug 11 '14 at 14:47
  • I think your first paragraph needs to be reworked to be accurate. It sounds like you're trying to say that the initial HTTP request is vulnerable (before the user has received an HSTS header). On subsequent requests, the browser will not accept an HTTP connection to the site, only an HTTPS connection. PLEASE CLARIFY YOUR FIRST PARAGRAPH TO RECEIVE ACCEPTED ANSWER. – John Aug 11 '14 at 15:36
  • Thanks for the feedback. Please don't yell. Of course, when the user types in HTTPS, they won't get to a forged site, however if the attacker wants, they won't get the valid site either. SSLStrip is all about when the user enters HTTP. – user10008 Aug 11 '14 at 16:15
  • Sorry, I meant it as italic, not yelling. Just formatting. Oh, ok, so SSLStrip can't attack you per-se, if you type HTTPS in the address bar, but it can block you. And the confused user might try something different. So if they had HTTPS://www.example.com bookmarked, they might trying typing in example.com in their address bar, and pwned. – John Aug 11 '14 at 16:22
  • Oh and I get your first paragraph now. Any client HTTP request can be intercepted and proxied, even if the site only supports HTTPS. – John Aug 11 '14 at 16:27
  • I've reworded the 1st paragraph to your suggestions – user10008 Aug 11 '14 at 16:36
  • Thanks. I understand the attack better now. Time to update some sites... lol – John Aug 11 '14 at 19:22
  • @John FYI you can use asterisks, e.g. \*text\*, to write *italics*. See http://security.stackexchange.com/help/formatting. – Dan Sep 15 '14 at 17:54
4

If your site only serves content over HTTPS and hard fails on HTTP requests, with no redirect, are you still vulnerable?

If the user accidentally enters http://example.com in their address bar instead of https://example.com, sslstrip could still intercept the connection and trick the user.

This could also be true of user's following malicious links - if they do not notice the missing padlock in the address bar they could be vulnerable.

HTTP Strict Transport Security can guard against this if you are sending the header, but only if the user has previously visited your site over HTTPS using that particular instance if their browser, or if you have requested that browser vendors include your site in their HSTS preloaded list. Please note that IE doesn't yet support HSTS.

Another thing to note that unless you are marking cookies as secure, an attacker may be able to MITM any other HTTP request from their victim and inject a request to the insecure version of your site (e.g. adding <img src="http://example.com/mitm.jpg" /> which will then allow them to MITM any cookies for your site. Please note that HSTS will also protect against this.

Also, if there are any XSS vulnerabilities on your site from rendering cookie values, it is possible for an attacker to use a MITM attack to inject malicious script here unless HSTS is active. This is possible even if you are setting secure cookies - the server cannot distinguish which cookies are secure when it reads them (it only gets the values) so it does not know if the attacker has manipulated anything during a MITM attack over any HTTP connection to your server.

I've covered quite a bit of ground with the above, expanding on what you asked, however these are all types of attack that can be used even though you are not listening over plain HTTP at the server side.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
1

Can an attacker intercept your HTTPS request and perform the request "on your behalf", so-to-speak, and serve your browser an HTTP version

If you access an HTTPS site directly (from bookmark for example) then a SSLStrip MITM attack would be highly unlikely. The request would either fail due to the browser looking for a TLS handshake, or prompt you with a certificate error if the attacker is using a fake cert.

Now if you are enforcing this on the server side, you cannot always rely on the server to redirect HTTP to HTTPS as this redirect could be intercepted.

Also, if you access the page via a hyperlink from an unencrypted source, you will also be vulnerable to SSLStrip. I know your question didn't ask about these last two situations specifically, but I just wanted to mention them to be thorough. There are ways to mitigate these latter attacks by using HSTS.

With HSTS, the server tells a web client to use HTTPS only. So long as the first request to the site is done without modification, all subsequent visits to the site will be forced to use SSL/TLS. This would work to prevent SSLStrip from working on an hyperlink from an unsecured website, as even though https:// was changed to http:// the browser knows to use https:// only.

David Houde
  • 5,464
  • 1
  • 27
  • 22
1

As part of the attack is doing a MITM for all the victims TCP/UDP traffic, as long as the user does not use an https address explicitly, he could be tricked.

For example: if a victim tries to go to "mail.google.com" and trusts the automatic redirect Google does from the http to https (try it for yourself), and he does not check the address bar gots the keylock icon/green bar/whatever, an attacker which has already done the MITM would get all traffic from that site in clear text.

Nevertheless, there is a new HTTP header that can be included in all of the server responses which was designed to minimize the chances to suffer from such an attack if the client has successfully connected to the HTTPS at least once before (and uses a modern web browser which supports it):

Strict-Transport-Security

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

For an apache server to include this header in all responses:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

NOTE: if you have both HTTP and HTTPS versions of your web, as soon as the client gets that header from your server, he won't be able to connect to the HTTP version (until he erases cookies or uses a different browser or (maybe) uses private navigation)

NuTTyX
  • 693
  • 4
  • 9