Is redirecting http to https a bad idea?

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.

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.

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).

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.

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

• Webmasters.SE: How to prevent access to website without SSL connection?
• Force HTTPS for specific URL

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.

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.

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.