HSTS implementation

[denbatte]

Would love to see HSTS implemented but first I would like some opinions. https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

• Implement it by default on the admin panel or by option? By default, than https needs to be enabled on all client sites
• Make it optional on the frontside? -> less secure
• Have it enabled by a config flag or in the admin settings?

cheers

[mlebkowski]

How about sending the header every time the site is served via HTTPS? If the production site is over HTTP, or if it’s a dev env, then the HSTS would be automatically disabled.

[tarjei]

@denbatte This belongs in you NGINX config :)

[svenluijten]

Even in 2017, some people will be unable to use HTTPS because their current server architecture might not support it (yet). Making this change would push those people away from using Kunstmaan Bundles, which would be a shame.

@mlebkowski: That'd kind of defeat the purpose of HSTS 😉

[mlebkowski]

@svenluijten, I disagree, can you elaborate? I think HTTP — as an insecure channel — should only respond with a 301 redirect to the HTTPS version. Then, when visiting the secure version, the client should be instructed to never again visit HTTP version (using the HSTS header).

This is all assumed the actual content can’t be reached via HTTP, and the traffic is actually redirected. YMMV if you wanted to use HSTS as the redirect mechanism.

[svenluijten]

The idea of HSTS is to tell the browsers that honor the preload list to never make an insecure request to the domain.

So let's say I own example.com and enabled HSTS on it. When a user requests http://example.com, the browser will automatically make this https://example.com. In a non-HSTS scenario, the user would make an insecure request to http://example.com, my server would tell the browser to use https://example.com instead, and the user('s browser) has to make another seperate request to https://example.com.

During the initial HTTP-only call to the server, the user can be MITM'd and potentially compromising data can be intercepted.

More info on this can be found on the offcial preload list website: https://hstspreload.org/

[mlebkowski]

@svenluijten, quoted from the page you mentioned:

Redirect from HTTP to HTTPS on the same host, if you are listening on port 80. (...) Serve an HSTS header on the base domain for HTTPS requests:

Besides that, HSTS Preload is something different. Without the preload (which doesn’t determine if I need to send the header in the insecure response or not), the first request over HTTP is made and can be MITM’d (and the HTTPS redirect stripped for example), you’re right. But you don’t even have to listen on port 80 if you’re on the preload list, hence my argument — only send the header if the site is requested via HTTPS, and configure your load balancer, or possibly application, to redirect insecure requests on production (or on development machines if you can) to HTTPS.

This way there is zero configuration on the CMS part — if the site is requested on the secure channel, tell the browser to always use it via the Strict-Transport-Security header. If not — don’t. And leave it to the load balancer / infrastructure to decide if SSL is required in a given scenario.