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

HSTS options are misleading #206

Closed
badsyntax opened this issue Nov 17, 2014 · 2 comments
Closed

HSTS options are misleading #206

badsyntax opened this issue Nov 17, 2014 · 2 comments

Comments

@badsyntax
Copy link

Hey there.

Related to #138

It seems the "Strict-Transport-Security" header will exist in the response, no matter what the HSTS* options are.

In both scenarios below, assume that GITLAB_HTTPS="true" and GITLAB_HTTPS_ONLY="false"

Scenario 1:

GITLAB_HTTPS_HSTS_ENABLED="true"
GITLAB_HTTPS_HSTS_MAXAGE="0"

Outcome:

You get two "Strict-Transport-Security" entries in the response headers:

strict-transport-security:max-age=31536000
strict-transport-security:max-age=0

Scenario 2 :

GITLAB_HTTPS_HSTS_ENABLED="false"

Outcome:

You get one "Strict-Transport-Security" entry with a max age of 31536000

strict-transport-security:max-age=31536000

I believe the reason for this here: gitlabhq/gitlabhq@94c96cd

The way I read it, there is no way to prevent HSTS headers being sent in the response, without sticking a proxy in the middle and removing those headers. Am I missing something?

@sameersbn
Copy link
Owner

@badsyntax We are correctly configuring HSTS in the nginx configs as user specifies them in the configs.However as you indicated, in the commit gitlab seems to be doing its own thing which I was not aware of. The HSTS config was contributed by another user and I am sure he had no idea that this was happening.

However, it seems the way to fix it is to request gitlab upstream to drop their HSTS configs and allow the user to specify it in the nginx configs because it messes with installations where relative_url is used to host multiple applications on a domain.

edit:
Else we will have to patch gitlab ourself.

@badsyntax
Copy link
Author

@sameersbn Thanks for the prompt response. Yea, it's a disappointment to find this in gitlab source. If I have time I'll try send a PR upstream. There's probably a good reason why they're setting some response headers like that.

Personally, after finding this problem, I have taken a different route, and have resolved my problems doing SSL Termination at haproxy rather than SSL Pass-Through to let nginx handle the SSL. Unfortunately I wasn't able to test whether HSTS was the culprit :(

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