[BUG] HSTS loaded over HTTP

[TommyTran732]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

HSTS when set in ssl.conf is loaded over HTTP

Expected Behavior

HSTS when set in ssl.conf is loaded over HTTPS

Steps To Reproduce

1. Setup Swag and enable HSTS
2. Scan the website with Hardenize

Environment

- OS: Fedora CoreOS
- How docker service was installed: Built in

CPU architecture

x86-64

Docker creation

yaml file from documentation

Container logs

None

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[TommyTran732]

This is caused by nginx.conf loading in ssl.conf in the http block, which in turns include the hsts header and load everywhere, including on port 80.

The proper way for this to work is for NGINX to make a 301 redirect first, and only then load in the SSL configs.

Dealing with the HSTS header alone is easy: the user can just set it in the reverse proxy config instead of in SSL.conf. However, I think that is a pretty ugly fix, and swag should change how ssl.conf is loaded in in general.

[d4rklynk]

Same problem here with Fedora Server 37 as an OS and docker installed from the offical doc

[nemchik]

What issue is this causing?

Yes the header is loaded (if you enable it) but what problem does this create?

If the header is enabled, browsers should automatically switch to https even without a redirect (which we also include by default).

[d4rklynk]

@TommyTran732 will tell you more about that, but from what I understand, the HSTS policy are sent through HTTP which is completely insecure, if an attacker wanted to change these (or whatever, idk), he can just using HTTP to get that done.

These kind of setup should be enforced as much as possible server-side and we should not rely on client-side to have proper security configuration.

[thespad]

It's worth noting that while this is technically correct, if your website is not on the HSTS preload list then it makes very little difference because if someone can MITM your http connection to change the HSTS header you're recieving over http they can MITM to stop the https redirect that would get you the HSTS header over https anyway and so you're still just as screwed.

And if you're connecting over https in the first place then you'll get the correct HSTS header and never connect over http again, rendering it moot in any case.

[d4rklynk]

We both have preloaded our domains

[thespad]

Then the issue is moot because anyone connecting to your domain will do so over https, based on the preload list, without requiring a header from you at all, and any changes to the header will be provided over that https connection.

At no point should anyone, other that someone using a method that doesn't support HSTS preload (see my previous point), be connecting to your site over http.

I agree that it's a technical implementation issue, and we should probably fix it when we get a chance, it just isn't a factor in an actual deployment.

[TommyTran732]

@thespad Yes, this is more about being spec compliant than anything. It's a bit annoying to get the error out with security assessment checks. I agree that it makes very little differences in reality, because the SWAG does 301 redirect then send the HSTS header again anyways, and if there is an attacker on the first connection the user is still screwed.

Still, I really do not like how it's implemented.

Another thing to note: I noticed that in the reverse proxy config, there is include /config/nginx/ssl.conf; which is already set in nginx.conf, so it really does nothing. Removing include /config/nginx/ssl.conf; from nginx.conf will just cause SWAG to stop working, despite of it still being there in the reverse proxy config. There is probably something not right about how how the configs are loaded in, though I haven't spent much time checking it yet.

[nemchik]

The correct implementation would be to include it in the server blocks with a 443 listen directive. This isn't out of reach for swag. It's only in the nginx.conf because that's where Alpine's upstream nginx config has other SSL config lines, and it seemed reasonable to not need it in every server block (which is every subdomain proxy conf).

[TommyTran732]

That's what I am saying, currently it is included in the server blocks with a 443 directive:

However, this currently does nothing, and if you remove it from nginx.conf (while still keeping it in the reverse proxy configs), SWAG just stops working. I am not entirely sure why yet.

[nemchik]

It's also needed in the server block in the site-confs/default.conf
That could be why it breaks when removed from nginx.conf, but I'm not positive.

If we move it back it'll be done in multiple repositories where our various images use the nginx base image.