Problem:
Security scanners continue to mark the foreman-proxy daemon as not enabling HSTS. Would like the ability to enable HSTS on the foreman-proxy. I realize this provides no substantive benefit to the application stack, but it would provide a positive user experience for those of us actually using the product in enterprises. (both Foreman and Satellite). Obtaining security exceptions or variances from information security groups is becoming more cumbersome and rejections are becoming more commonplace.
Expected outcome:
A setting to enable HSTS on the foreman-proxy daemon
Foreman and Proxy versions:
Current / Any
Foreman and Proxy plugin versions:
Current / Any
Distribution and version:
Red Hat Enterprise Linux 9
Other relevant data:
I would settle for a workaround at this point. I’m into this far enough that I’m working on my own “hack” to the webrick definitions to enable the header if thats what it takes. Thanks!
I think Tenable is misinterpreting RFC6797. Quoting that abstract:
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.
I don’t consider our API a website and we take very explicit care to only serve APIs on HTTP that can’t be served over HTTPS. In fact, in various deployment scenarios there isn’t even a HTTP version available.
If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types http://www.foo.com/ or even just foo.com. This creates an opportunity for a man-in-the-middle attack. The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.
In many cases it’s deployed in a way that there is no connection possible over HTTP so there is no risk of MITM.
I appreciate you taking the time to work up an implementation and I also appreciate the context. I don’t disagree with your assessment of Tenable (or likely Nessus’s) interpretation of the RFC or its detection. I’m sure both of those companies simply detect if its enable or disabled on a http(s) connection and pass / fail based on that.
I also don’t believe this should be enabled by default, but it would be nice if it was an option to enable it.
I submitted an RFE through Red Hat for this (Case 03927201) in the hopes that it might some day make it downstream. That said, I’ll likely implement your solution in our non-prod and prod Satellite and capsules to relieve us of this vulnerability finding.
