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

Comments

Projects
None yet
2 participants
@jk
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

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 7, 2014

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.

Owner

sameersbn commented 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

This comment has been minimized.

Show comment
Hide comment
@jk

jk Sep 7, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 8, 2014

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.

Owner

sameersbn commented 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

This comment has been minimized.

Show comment
Hide comment
@jk

jk Sep 10, 2014

Contributor

@sameersbn Sorry for not answering earlier. I'll test that and will get back to you. Need a couple more days - packed schedule here.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jk

jk Sep 18, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 19, 2014

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?

Owner

sameersbn commented 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_ENABLED set to true by default.

What do you think?

@jk

This comment has been minimized.

Show comment
Hide comment
@jk

jk Sep 19, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 19, 2014

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.

Owner

sameersbn commented 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

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 19, 2014

Owner

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

Owner

sameersbn commented Sep 19, 2014

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

@sameersbn sameersbn closed this in 9458cb6 Sep 19, 2014

sameersbn added a commit that referenced this issue Sep 19, 2014

@sameersbn

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 19, 2014

Owner

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

Owner

sameersbn commented Sep 19, 2014

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

@jk

This comment has been minimized.

Show comment
Hide comment
@jk

jk Sep 22, 2014

Contributor

@sameersbn Glad I could help, albeit I never made it an official pull request. I still struggle a bit with those dockerfiles 😦

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sameersbn

sameersbn Sep 22, 2014

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.

Owner

sameersbn commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment