The HSTS config for trunk.rdoproject.org overrides *.rdoproject.org

[dmsimard]

How to reproduce:

1. Clear HSTS config for rdoproject.org (i.e, in chrome chrome://net-internals/#hsts)
2. Visit something that is http only ( status.rdoproject.org or uchiwa.monitoring.rdoproject.org )
3. Visit trunk.rdoproject.org
4. Visit something from step 2

Now.. we could argue that everything under rdoproject.org should be SSL, but it's probably not a decision that should be made by trunk.rdoproject.org :)

[apevec]

Where is that configured in httpd config?
@javierpena @dmsimard afaict HSTS[1] is not configured on trunk.rdoproject.org, there isn't Strict-Transport-Security: header in response and http: is not redirecting to https: ?

[1] https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

[apevec]

From bash history I see @javierpena used puppet apache module to configure httpd, so leaving this one for him.
And here is the manifest where SSL is enabled: https://github.com/rdo-infra/puppet-dlrn/blob/master/manifests/web.pp#L67

[javierpena]

I think the HSTS header is defined in rdoproject.org rather than trunk.rdoproject.org.

Using a Firefox extension, I've seen that anytime we fetch the CSS content from rdoproject.org, we get the Strict-Transport-Security header. Since the CSS is loaded by the front page, we get the HSTS content.

Just tried the reproduction steps using http://trunk.rdoproject.org/centos7/report.html instead of the front page, and no HSTS is enforced.

[mscherer]

yeah, that's set on rdoproject.org.

[dmsimard]

That's interesting because visiting rdoproject.org doesn't generate the problem for me, just trunk.