Repository navigation
Optionally disable HSTS? #138
Description
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.
Activity
sameersbn commentedon Sep 7, 2014
@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.
jk commentedon Sep 7, 2014
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:
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.
sameersbn commentedon Sep 8, 2014
@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.
jk commentedon Sep 10, 2014
@sameersbn Sorry for not answering earlier. I'll test that and will get back to you. Need a couple more days - packed schedule here.
jk commentedon Sep 18, 2014
@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.
sameersbn commentedon Sep 19, 2014
@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_ENABLEDset to true by default.What do you think?
jk commentedon Sep 19, 2014
@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_ENABLEDdefaulting to true is a good idea.sameersbn commentedon Sep 19, 2014
@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.
sameersbn commentedon Sep 19, 2014
@jk btw, do you think users would want to configure the max-age for HSTS?
readme: add section on `Configuring HSTS`
sameersbn commentedon Sep 19, 2014
@jk did i just hijack this commit of yours? you bet i did!
jk commentedon Sep 22, 2014
@sameersbn Glad I could help, albeit I never made it an official pull request. I still struggle a bit with those dockerfiles 😦
sameersbn commentedon Sep 22, 2014
@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.