Some pages on my website (authentication, payment) must be served over HTTPS.
When a client hits such a page over HTTP, I want to redirect it to the HTTPS version.
At the moment I'm using a 301 Moved Permanently code with a Location header that points to the same URL with the scheme modified to HTTPS.
I'm wondering: is there a specific HTTP response code for using the wrong protocol?
Something that would be similar to 405 Method not allowed for the HTTP verb.
Not as such, no — the 301 permanent redirect is exactly the right choice here.
However, there is such a thing as HTTP Strict Transport Security (HSTS), which allows you, once you've told the browser to use HTTPS using the 301 redirect, to also tell it never to use the unencrypted HTTP protocol again on your site. The way you do this is by including a header like shown below in the HTTPS response (not in the redirect, which is sent over plain HTTP):
Strict-Transport-Security: max-age=31536000; includeSubDomains
For more details, see the Wikipedia article linked above and RFC 6797.
According to this, 403.4 seems to be what you want (in IIS), but I don't believe there is an equivalent in the HTTP standard.
Response 301 seems reasonable for the login pages etc. (where no credentials are needed to be transmitted to load the page). Otherwise when personal details have been sent it is wise to say not found (401) as somebody is being mischievous. It is also wise to check the referrer URL and also periodically check the log files.
(People do copy web sites and masquerade as yours, just forwarding traffic and collecting personal details in the process :-( )
Related
For example, does the URL http://www.google.com/ make the URL less safe, even though the default for this domain is with https?
Accessing a site using http:// (thus the unprotected unecrypted HTTP protocol) means that at least one unprotected HTTP request is sent to the server (most sites that support https will automatically redirect you to the https version).
This unprotected request can be intercepted by an attacker and thus send you arbitrary data back (malicious JavaScript code, redirect to other sites and so on).
The only exception is if you type http://www.google.com/ and you are using Chrome browser because Chrome will for addresses on google.com automatically change the entered URL to https:// before anything is sent on the network.
I'm trying to redirect HTTP to HTTPS on Akamai but it says...
Enhanced Akamai Protocol is not compatible with Request Protocol and
cannot be used with a rule using this match.
It also says...
Caution! You should not remove the Enhanced Akamai Protocol without an
extremely good reason to do so.
How can I implement the redirect with Enhanced Akamai Protocol enabled?
Well you are using a wrong behavior. user redirect behavior, you will have option to set either 301 or 302 etc.
I've seen lot of software that tries to determine if current protocol is HTTP or HTTPS, mainly to output links and avoid the Mixed content error.
Usually the software checks some server variables (for example, $_SERVER['HTTP'] in PHP, see this question: PHP Get Site URL Protocol - http vs https).
This method may work, but fails for example when you have a reverse proxy that receives SSL traffic and requests content to a web server over HTTP (so when the software checks the HTTPS status it's off). Web server will response with HTTP links but content is actually server over HTTPS.
There's a simple solution for this: just use links without protocol: '//' instead of 'http://' or 'https://'.
So, my question is: is a better practice to detect current protocol (http or https) instead of just using default protocol for content links (CSS, JS, images, AJAX, etc)? If yes, why is this?
Using '//' works, but it means your resources must be available with http and https.
So you can simply use 'https://' so you are sure to always use the secure connection, and avoid mixed-content errors.
(Of course, the most secure option is to always use https, with a 301 redirect on http and HSTS)
If I open my FF developer tools, and look at the network tab, then enter http://mywebsite.com, there would be a 301 moved permanently to the https website as the first network request. If you do that to http://facebook.com, then the first request would be 200 with a request URL of https://facebook.com.
However, if you run a curl -I on both websites, the same result of 301 moved permanently would show. How do they do that?
I am using nginx that redirects to HTTPS behind Amazon ELB.
I think this is an effect of HSTS: HTTP Strict Transport Security
On the facebook responses headers you have this:
Strict-Transport-Security: max-age=15552000; preload
This tells your browser to memorize this HTTP to HTTPS redirection for this domain for a big amount of time, without trying a real HTTP connection to get the 301.
And if you think that having something in your browser which is stored in memory and affects the way the first requests are made on some already visited domains, even after a browser close, could have some privacy impact, well... you would be right.
I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.