James,
On 10/13/25 5:10 PM, James H. H. Lampert wrote:
I'm looking into the docs for this filter in a bit more depth, and
something I see doesn't make any sense:
The Tomcat 9 doc says:
hstsEnabled
Will an HTTP Strict Transport Security (HSTS) header
(Strict-Transport-Security) be set on the response for
secure requests. . . . If not specified, the default value of true
will be used.
As I read this, that would seem to mean that if I have the filter block
for httpHeaderSecurity uncommented, and the *only* parameter I have in
the init-param clause is antiClickjackingOption, the mere fact that the
filter is enabled will send an HSTS header (albeit with a max age of
zero). And yet, if I have the browser console up and looking at headers,
when I load the sign-on page for the webapp, there's no "Strict-
Transport-Security" header to be found. Am I misunderstanding the doc?
Do you have any reverse proxy or anything like that? Does Tomcat serve
HTTPS directly? If not, it will not return HSTS headers.
On 10/13/25 1:42 PM, Olaf Kock wrote:
You have almost no chance to screw it up (provided
you use standard ports 80 and 443)
and
HSTS is /not/ tied to any certificate. It's literally
just the single "s" that's added to URLs. The rest of
the handling is 100% standard no matter any HSTS setting
And yet, something I read on Friday, at
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/
Strict-Transport-Security>
tells me that setting HSTS with my "guinea pig" server would be bad. As
in "Don't cross the streams" bad.
Why is that?
If a TLS warning or error, such as an invalid certificate,
occurs when connecting to an HSTS host, the browser does
not offer the user a way to proceed or "click through"
the error message, which would compromise the intention
of strict security.
Doesn't that mean that HSTS would block the browser from even offering
one the option of overriding an out-of-date cert? (the one on my "guinea
pig" server is 5 years out-of-date, and up until I looked at it just
now, I thought it was probably also wrong-domain-name). I *do* have a
permanent override for it in Firefox, though. But would HSTS kill that,
too?
Yes. When you enable HSTS, browsers enable a bunch of additional checks.
For example, if you visit your server with the out-of-date certificate
right now, your browser will probably tell you "Warning: this cert has
expired" but give you the option to (paraphrasing) "Accept the Risk &
Continue" and you can still visit the site.
With HSTS enabled, the browser will just say "no site for you." (Pro
tip: in Google Chrome, you can type (literally, without quotes)
"thisisinsafe" while looking at that "no site for you" page and it will
switch to the "accept & continue" page and you can, in fact, get in.
I did just re-read what I'd read at cheatsheetseries.owasp.org on
Friday, about persistent effects, and now realize that I was looking at
the "preload" option.
I agree with Olaf that the risk is minimal, but if you are super worried
you can do this: enable HSTS with a max-age of something short like 5
minutes. DO NOT ENABLE PRELOAD. Do not "include subdomains". Put it out
there and make sure you can load your test site.
Once you are happy that (a) the HSTS header is present and (b)
everything works, you can raise the max-age to something higher and more
useful. Qualys's SSL Server Test will give you a higher score if HSTS is
enabled and the max-age is high enough.
At this point, you can enable PRELOAD and the browser vendors will seed
their products with your site's domain in their HSTS lists. At this
point, no browser will ever visit your web site again with plain-old HTTP.
Olaf's comment about this protecting you from MITM or in case of
breaches is essentially the *only* protection that HSTS gives you. That
isn't to say that it's unimportant. It's a fairly minimal change to you
and your site and gives both you and your users a significant security
benefit.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
