76

I'm reading over this page and it says that if a site is SSL and the user tries to access it via regular http, the application should not redirect the user to https. It should just block him. Can someone verify the validity of this? It doesn't sound like a good idea, and I wonder what the real risk is of just forwarding the user to https. It seems that there is no technical reasons behind it, just that it's a good way to educate the user.

Disable HTTP access to the domain, don’t even redirect or link it to SSL. Just inform the users this website is not accessible over HTTP and they have to access it over SSL.

This is the best practice against MITM and phising attacks. This way your users will be educated that application never accessible over HTTP and when they come across to a phising or MITM attack they will know something is wrong.

One of the best ways to protect your application against MITM attacks and phising attacks is educating your users.

Brad Koch
  • 19,267
  • 19
  • 110
  • 137
sami
  • 7,515
  • 8
  • 33
  • 37

6 Answers6

50

An HTTP request that includes a session ID cookie is subject to session hijacking attacks. It is important that if you do allow HTTP and redirect to HTTPS, that cookies are marked as secure.

I can't see any technical reason why HTTP needs to be completely blocked either, and many sites do forward HTTP to HTTPS. When doing this it is highly advisable to implement HTTP Strict Transport Security (HSTS) which is a web security mechanism which declares that browsers are to only use HTTPS connections.

HSTS is implemented by specifying a response header such as Strict-Transport-Security: max-age=31536000. Complying user agents will automatically turn insecure links into secure links, thereby reducing the risk of man-in-the-middle attacks. Additionally, if there is a risk that the certificate isn't secure, e.g. the root authority isn't recognised, then an error message is displayed and the response is not shown.

cspolton
  • 4,495
  • 4
  • 26
  • 34
  • 8
    +1. Session cookies that persist across the redirect are to be considered can be considered compromised. Usually, sites invalidate the original cookie, and create a new one to be used for HTTPS traffic (the good sites enable the secure cookie flag as well). – Vineet Reynolds Dec 06 '10 at 10:51
  • 4
    If you are offering a "secure" service use always the "Secure" flag at your session cookies! – Pedro Laguna Dec 06 '10 at 11:49
  • Vineet - ideally sites invalidate the original cookie, however this is still not nearly common enough, even in banking applications! – Rory Alsop Dec 06 '10 at 23:27
  • 2
    While you may not need to block HTTP completely with recent protocol enhancements like HTTP Strict Transport Security, forwarding HTTP to HTTPS is not safe because of SSL stripping attacks like Moxie Marlinspikes sslstrip. It's not even save to have HTTPS links on an HTTP page for the same reason. http://www.thoughtcrime.org/software/sslstrip/ – Zach Burlingame Sep 09 '11 at 02:35
  • CORS makes you need https – alemac852 May 13 '17 at 06:13
27

Going from HTTP to HTTPS is actually a not-so-good idea. For example, an attacker could do a man-in-the-middle attack using a tool like ssl strip. To address this problem, you should use the HSTS protocol. It's supported by all major browsers (Internet Explorer, which is the latest adopter, is supporting it starting from IE12), and in use by many of the top sites (e.g., Paypal, Google).

Luca Invernizzi
  • 6,489
  • 3
  • 28
  • 26
  • 8
    Absolutely spot-on with the reference to sslstrip. If the client initiates the connection over HTTP to the server, the MITM can hijack the session, keeping the connection between the client and the attacker in plaintext, even if the attacker follows the HTTPS redirect on it's connection to the server. The server thinks the client is connected via HTTPS and the client thinks the site operates on HTTP. – Zach Burlingame Sep 09 '11 at 02:31
  • 13
    But wouldn't the same MITM attack work equally well on a site that simply refuses HTTP? HSTS only helps after at least one clean connection (whether HTTPS or an HTTP that wasn't attacked). – Beni Cherniavsky-Paskin Jan 24 '14 at 03:28
  • 4
    That's correct. That's why some browsers are distributed with a preloaded list of domains that should be contacted via HSTS (http://dev.chromium.org/sts). This mitigates the attack you describe. – Luca Invernizzi Jan 27 '14 at 23:05
  • 1
    Regarding "all major browsers", IE hasn't supported it, though they say they will in IE 12: https://www.eff.org/deeplinks/2014/02/websites-hsts – weotch Jun 25 '14 at 22:28
  • It is a fundamental violation of best practices to mix non-secure and secure pathways in any case. In fact, it is considered a major security breach in military communications systems. It is not the task of the implementer to second guess these things; that is exactly how so-called secure systems get breached in the first place. Changing protocols is likewise not a good idea, in my estimation. This is not something that ought to be up for debate. Secure systems are supposed to be difficult for authorized users to use. – jinzai Sep 15 '16 at 14:58
  • The most correct answer. If you don't use HSTS the redirect is insecure. It's about educating the user that they shouldn't go to the http but rather link/bookmark/type in the https url. And even if they keep access the http version for some reason they should get used to the warning. – Mikael Eliasson Nov 14 '16 at 04:24
9

I don't see any technical risk (except from the one in the update at the end of my answer) on redirecting from HTTP to HTTPS. For example, gmail and yahoo mail are doing it. You can check that by using a HTTP debugging tool (like Fiddler), where you can clearly the 302 redirect response returned by the server.

I believe that blocking is a bad idea from an usability perspective. Many times users are entering an address in the browser without specifing HTTP or HTTPS. For example, I access gmail by typing "mail.google.com", which defaults to "http://mail.google.com" and which is automatically redirected to "https://mail.google.com". Without the automatic redirect I will always have to type the full address.

I agree with the quoted article that HTTPS is the best method against MITM attacks, but I don't agree it is the best practice against phising. User education is indeed a key factor against phising attacks (the users have to check that they are accessing the site from the correct domain), but in no way you make that education by blocking HTTP redirect to HTTPS.

Update @Pedro and @Spolto are right. Special care must be taken related to sensitive cookies (like session or authentication cookies), which indeed should be marked as secure, so that they will only be transmitted over HTTPS. I've missed that one. +1 both you guys.

Florin Dumitrescu
  • 8,182
  • 4
  • 33
  • 29
  • 3
    The redirection not should be done at if the application is not using cookies with the secure flag activated an attacker can capture the cookie in the insecure request. – Pedro Laguna Dec 06 '10 at 11:51
4

I've only just noticed this question, but I've written a couple of answers to similar questions:

I don't think redirecting from HTTP to HTTPS is necessarily harmful, but this should be done carfully. What's important is that you shouldn't rely on these automatic redirections to be present during the development phase. They should at most be used for users who type the address in the browser by themselves.

It's also solely the responsibility of the user to check than they're using HTTPS (and that the certificate is verified without warning) when they expect it.

The actual risks of switching from HTTP to HTTPS is that you can reliably trust what was done before the switch, if you choose to keep the session. The flow and process of your website should take this into account.

For example, if your users browses your shopping site and adds various items into the cart using HTTP and you plan to use HTTPS to get the payment details, you should also make the user confirm the content of their basket using HTTPS.

In addition, when switching from HTTP to HTTPS, you may have to re-authenticate the user and to discard the plain HTTP session identifier, if any. Otherwise, an attacker might be able to use that cookie to move to that HTTPS section of the site too and potentially impersonate the legitimate user.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
3

From technical perspective, IMO there are no side affect besides what HTTPS takes.

From UX/UI perspective, it is advised to use click-through or delayed redirection, providing visual indication to ask people typing HTTPS URL at the first place, since the redirection itself is subject to MITM attack. Not many HTTPS website do this however, because they provide visuals asking people to look for the lock icon on the browser on their HTTPS pages.

timdream
  • 5,914
  • 5
  • 21
  • 24
1

It's a perfectly acceptable "bootstrap" method - 301 redirect from HTTP to HTTPS then on the HTTPS side return a Strict-Transport-Security header in order to lock the browser into HTTPS.

It would be a major usability issue to block HTTP entirely, as web browsers will attempt the HTTP protocol when a URL is entered without a protocol designator, unless the browser supports HSTS and an HSTS token is found in either the browser cache or the preload list.

William
  • 309
  • 1
  • 9