I am disabling all http access and want to return an error code to indicate that http is disabled and use https instead.
what is the best error code response for that request?
400 Bad Request
403 Forbidden
There's not much value in listening on port 80 unless you're either going to serve up content or point clients to somewhere else.
Either issue a 301 Moved Permanently redirecting to https (Redirect http to https in default.aspx) or do not listen on port 80.
403.4 should be the best, as IIS returns exactly this to client side if HTTPS is required,
https://support.microsoft.com/en-us/kb/943891?wa=wsignin1.0
Related
I have a web application running on AWS EC2 using a load balancer which only listens for HTTPS requests on port 443 along with a security group which only allows for traffic on port 443 so my application cannot be reached via HTTP (as far as I am aware).
The application has recently been pen tested which resulted in the recommendation to implement HSTS. From what I can see one of the requirements for implementing HSTS is to redirect ALL HTTP links to HTTPS with a 301 Permanent Redirect. Upon trying to do this through another listener on the load balancer redirecting traffic from port 80 to port 443 I get a warning that the security group attached "does not allow traffic on this listener port."
My question is should I consider enabling HTTP traffic so that I can implement the permanent redirect and then implement HSTS or am I better off leaving things the way they are? I'm inclined to think that because my load balancer does not allow HTTP traffic that I'm better off leaving my current set up as is but not 100% sure. Can anyone explain which is the safer option and why? Thanks in advance.
It totally depends on whether you want to allow and redirect HTTP traffic to HTTPS. For example if it's a user facing application then generally HTTP traffic allowed at gateway/load balancer and then redirected to HTTPS as end user shouldn't get any error on accessing on HTTP. Then in this case HSTS header plays important role.
But it's not end-user facing application and you know consuming entity will always access using HTTPS then don't allow HTTP traffic. So here you won't need to have HSTS header set.
Webserver using is nginx
Suppose i have a website http://www.test.com. and then there is https://test.com?market.
Iam redirecting all https to 301 http for test.com
Suppose i want to enable https strict transport security header for url
.I can add it easily in nginx.
But the problem is that test is also moving to https by browser (which is a 307 redirect) and from the server it is again redirecting to resulting in a infinite loop for test,
HSTS apply for all the page of the domain without exception. So it's not possible. (307 is just an internal code of the browser to indicate the http->https redirect forced by HSTS)
Furthermore, it's important to use https even for static pages. (If you need more details just ask!)
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 :-( )
Got a problem with squid. I'm using 3.1 version with my own redirector.
My problem was when a client for example request https://twitter.com (with https) but somehow got a logic with my redirector that twitter.com is invalid page so i redirected this request to my invalid page. Let say 302:http://mydomain.com?invalid=twitter.com, in this stage process will not continue and browser will say "HTTP gateway failed".
So, my theory is when a request is https redirected to http, squid will not work. Is there any configuration i need to be done so that it will work?
Thank you guys..
RFC 2817 isn't very clear about the behavior of CONNECT and redirect. I think that most of the browser won't accept a redirect as a reply to the CONNECT method. So, there is no way to do what you want.
Is not an Squid issue, is a protocol/browser issue.
well, i think the best way to redirect is when:
- if the request is https the response should be https
- and if the request if http response should be http
that's the best way i can't think at the moment...
I have a production server with a live website configured to use SSL. It has also been configured to redirect any HTTP URLs to the HTTPS.
I would like to be able to view the website from the server and test the redirect taking place. Instead I get an error message about permissions.
If I type the the HTTP url from a different machine I am able to view the website, i.e. the HTTP url has automatically been converted into an HTTPS url.
The question is how can I test the HTTP redirect from the production server?
You either make the webserver also listen to localhost (127.0.0.1), or you make the test bind to the external IP of the host.