Olaf,
On 10/14/25 3:41 AM, Olaf Kock wrote:
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.
Using max-age=0 actually *disables* HSTS on the browser end. So it's not
useless... just counter-productive if you are trying to enable HSTS.
Easy to test by configuring it to 1 (second) and then inspecting
the new header.
+1
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.
And, honestly, if you are comfortable with all those ANDs, you should
seriously consider whether your service is actually secure.
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.
+1
If you don't want to set a calendar-reminder (I sure don't), then use an
automated monitoring system that can check for upcoming expirations.
It's so easy there is no excuse not to do it.
There are LOTS of ways to do it. One way is to use something like this
on a schedule:
https://github.com/ChristopherSchultz/certcheck
It can check multiple certificates and key/trust stores. I typically use
this tool for services that have no public-facing HTTPS endpoint.
For the public-facing ones, I use something like this:
https://nagios-plugins.org/doc/man/check_http.html
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.
+1
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
