Optionally disable HSTS?
jk opened this issue · comments
What's the best way to make HSTS in config/nginx/gitlab-ssl:113 optional? It gets in the way, if I run gitlab with HTTPS enabled on the standard SSL port, for any other HTTP based docker image on the same host - for example I wanted to run an instance of gitlab-ci on the same host.
@jk I dont exectly get what issue you are facing. If you can send me same docker run commands for the two images maybe I will get a better idea.
However, If you want to run two or more images to use standard http/https ports, you should use a load balancer.
I think you misunderstood me. If a web server sends the browser the HSTS header (line 113) every subsequent browser request to any other port will be locally redirected by the browser to HTTPS port.
For example:
- gitlab runs on port 443
- gitlab-ci runs on port 3000
- Client browser requests gitlab at https://host.tld/
- Server responds as expected with gitlab and the HSTS header
- Client browser requests gitlab-ci at http://host.tld:3000/
- Client browser rembers HSTS header → checks HSTS lifetime:
- if now is within the lifetime, client browser redirects without requesting the server to https://host.tld/ instead of the requested http://host.tld:3000/ on behalf of the user ( gitlab, not gitlab-ci)
- otherwise: I think it rechecks the header and if it's there it also redirects - not sure about this part
So the server is not reachable via Port 3000. And that's what is expected if the server admin sends the HSTS header (it's there to avoid any plain HTTP traffic).
More over: since the load balancer setup requires turning on HTTP it downgrades the security of the gitlab instance unnecessarily.
I'll see if I can supply you with the parameters of our in-production container.
@jk i think I understand what you are saying. But its weird that the browser would not connect to the 3000 port when you are expliciltly specifying it. When you remove the HSTS line from the nginx config do you notice that everything works right?
I will try reproducing this case locally.
If the HSTS line causes this issue, then probably I could just remove it from the config.
@sameersbn Sorry for not answering earlier. I'll test that and will get back to you. Need a couple more days - packed schedule here.
@sameersbn Finally I found the time to check it. After deleting the HSTS entry for my specific domain in Chrome (you can do that via chrome://net-internals/#hsts) I can reach the port. So yes, removing that header does solve my problem.
But HSTS isn't bad. If you got a server facing the public internet and you want to ensure your users with modern browsers only interact with your server via HTTPS, HSTS is the best option. So making this its own config flag is good idea, instead of removing it all together.
@jk I understand.
If I can remember correctly, earlier when the HSTS option was not added to the nginx config, web browsers used to remember that the website redirects you to https. As a result future connections to the website would be done over https only (until the browser cache is cleared). However, thats beside the point.
Anyway, maybe I will add an option to enable/disable HSTS, nothing fancy, something like HSTS_ENABLED set to true by default.
What do you think?
@sameersbn purging the normal browser cache doesn't get rid of the flag. For Chrome you have to use the specific HSTS hidden pref pane. For other browser I don't know of a way to remove the flag - google finds a lot of forum threads where people ask about to remove it for their specific browser.
HSTS_ENABLED defaulting to true is a good idea.
@jk you misunderstood. that was the behaviour before the HSTS config was added to nginx. Its a different case. Was just pointing out that it was doing something similar.
After reading the HSTS documentation at http://dev.chromium.org/sts I realized that it has good purpose.
@jk btw, do you think users would want to configure the max-age for HSTS?
@sameersbn Glad I could help, albeit I never made it an official pull request. I still struggle a bit with those dockerfiles 😦
@jk well it had all the bits that were required.
I discovered your changes only after I had already done it myself. Else I would have just picked all your commits.