Am 13.10.25 um 23:10 schrieb James H. H. Lampert:
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?
I haven't looked this up, but from your description my assumption is
that the default duration might be 0, so it's pointless to include the
header. Easy to test by configuring it to 1 (second) and then inspecting
the new header.
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.
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, you're correct: Activating HSTS means that you trust yourself to
properly set up https, and you tell the world.
/If/ you anticipate that your certificate might be expiring before you
notice, /and/ you anticipate your users to be willing to override their
browser's warning, /and/ you're accepting/intending to train your users
to do so: Then HSTS is /not/ for you. This use of "and" is - explicitly
- the binary logic "and". If /any/ of those conditions is false (and my
assumption in my previous answer was that they're /all/ false): HSTS is
safe for you to use.
As a user, I can tell you though that an expired certificate is /only/
fine (for me) if I'm looking for some text to read, not to do anything
interactive with the site. I'm questioning the competency of a team that
does not manage their https-certificates well and assume that there's a
lot more complicated stuff that they don't take proper care of in the
background.
You're asking this question about configuring extra security in the
infrastructure, and follow with the argument of a deliberately outdated
certificate being a blocker to try this option. The fix for this blocker
is to update the certificate: No offense, but if you're not willing or
able to maintain https certificates, don't worry about clickjacking.
And if this just applies to a test server on a private network: Don't
use HSTS /on it/.
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.
Correct. And you are in control of that (also the "includeSubdomains"
option).
In general, HSTS communicates to the public that you're claiming to be
able to provide a proper https setup, as much as the use of http
communicates that you're not able to do so. I was assuming that you're
in the first group, so I stand by my word that HSTS is without risk.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
