Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally disable HSTS? #138

Closed
jk opened this issue Sep 6, 2014 · 12 comments
Closed

Optionally disable HSTS? #138

jk opened this issue Sep 6, 2014 · 12 comments

Comments

@jk
Copy link
Contributor

jk commented Sep 6, 2014

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.

@sameersbn
Copy link
Owner

@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
Copy link
Contributor Author

jk commented 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:

  • gitlab runs on port 443
  • gitlab-ci runs on port 3000
  1. Client browser requests gitlab at https://host.tld/
  2. Server responds as expected with gitlab and the HSTS header
  3. Client browser requests gitlab-ci at http://host.tld:3000/
  4. 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.

@sameersbn
Copy link
Owner

@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
Copy link
Contributor Author

jk commented 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
Copy link
Contributor Author

jk commented 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
Copy link
Owner

@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?

@jk
Copy link
Contributor Author

jk commented 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_ENABLED defaulting to true is a good idea.

@sameersbn
Copy link
Owner

@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
Copy link
Owner

@jk btw, do you think users would want to configure the max-age for HSTS?

sameersbn pushed a commit that referenced this issue Sep 19, 2014
@sameersbn
Copy link
Owner

@jk did i just hijack this commit of yours? you bet i did!

@jk
Copy link
Contributor Author

jk commented 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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants