15

For a website, I force a 301 redirect from http://login.example.com to https://login.example.com using a .htaccess file.

As I read in this question this still imposes a security threat. I'm wondering how this still poses a threat. Could anyone explain this in a general way?

Jortiexx
  • 153
  • 1
  • 4
  • Someone intercepts the HTTP 301, alters the destination and redirects somewhere else... – ThoriumBR Dec 02 '15 at 21:31
  • 1
    Will the altered destination be visible in the browsers address bar ? If this is not the case, would one have to build a fake login form and redirect the visitor towards it? – Jortiexx Dec 02 '15 at 21:36
  • This would be MITM. You should enforce HTTPS and try to use HSTS to prevent such cases. But generally the very first access (even with HSTS enabled) is through HTTP instead of HTTPS which is normal. But further requests should be forced to HTTPS using HSTS. – Daniel Ruf Dec 02 '15 at 21:38
  • And what about bypassing HSTS as desribed [here](https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf) ? Is HSTS really save? Or are there any additional measurements to be taken? – Jortiexx Dec 02 '15 at 21:46
  • This depends on the OS like described in the paper and the NTP synchronization but this is not so easy as MITM attack. – Daniel Ruf Dec 02 '15 at 22:04

2 Answers2

18

Since you're doing a 301 redirect over HTTP, someone could man-in-the-middle that connection and redirect you anywhere they wanted - in particular they could actually not redirect you at all, and instead get between your computer and https://login.example.com, monitoring your connection and serving you its contents under the name http://login.example.com instead.

A way to mitigate this is to use an HSTS HTTP header - when the user first loads your page, it tells their browser that your site is to be loaded on HTTPS only until some date in the future (the directive typically has an expiration date set in the far future). This means that once the user connects to your site once via HTTPS, they will always do so in the future until the expiration of the HSTS directive.

This leaves one last scenario - say that the attacker MITMs the connection BEFORE the user's browser ever sees the HSTS header from your server. In that case the user's browser never knows that it shouldn't use non-HTTPS connections. A way to mitigate this is to include your website in the HSTS preload list, which means that web browsers ship already knowing that your site is HTTPS-only. Chrome, Firefox, Safari, IE11, and Edge all have an HSTS preload list that includes the Chrome HSTS Preload List, and in a few steps you can submit your site too - more information on the Chrome HSTS Preload List.

If you put your site on the HSTS preload list and complete what that entails, then you can have reasonable assurance that anybody using new versions of those browsers won't be vulnerable to an HTTPS-to-HTTP MITM downgrade attack by a casual attacker.

Just keep in mind that once your site is on the HSTS preload list, it's not very quick to get it back out of everybody's browsers, since any browser that hasn't been upgraded (again) will expect your site to be loaded via HTTPS only.

  • One problem with HSTS preload site for Chrome is that Chrome still doesn't support valid TLSv1.2 256-bit cipher suites like ECDHE-RSA-AES256-GCM-SHA384 (with P-521 curve) or DHE-RSA-AES256-GCM-SHA384 (with 4096 dhparam), so people interested in 256-bit security level might be out of luck. – Michał Staruch Dec 03 '15 at 06:48
5

From this question it may look like the 301 redirect per se is posing a threat, but it is not.

It doesn't pose a security threat. It only bears the same risks of serving a normal HTTP page.

fiatjaf
  • 149
  • 1
  • 5
  • "It only bears the same risks of serving a normal HTTP page." Which, to be fair, is still a pretty significant risk. – Ajedi32 Dec 01 '16 at 18:26
  • The point here is that it wasn't asked if HTTP was risky. Of course it is. Everything is risky. – fiatjaf Dec 02 '16 at 12:57