You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID> on 2025/10/13 15:30:15 UTC
HSTS parameters in the httpHeaderSecurity filter
I've recently been asked to look into the HSTS parameters in the
httpHeaderSecurity filter. To date, I've only used the anti-clickjacking
parameters, and had no idea what HSTS even *is.*
As it stands, our Tomcat installations, at least those directly exposed
to the outside, are all set up as HTTPS-only, with no active listener
*at all* on 80 or 8080.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Olaf Kock <to...@olafkock.de>.
Am 13.10.25 um 19:43 schrieb James H. H. Lampert:
> On 10/13/25 9:02 AM, Olaf Kock wrote:
>> HSTS can still help you, as even in case of a breach, or a MITM
>> attack, no browser (that has seen your site's HSTS header before)
>> will ever even try to access port 80, but automatically rewrite URLs
>> to https.
>>
>> The only drawback (if I remember correctly) is that it doesn't play
>> well with non-default ports, e.g. 8080, if it's exposed publically.
...
> One of the things that scares me the most about this is that I got the
> impression that browsers will remember that a site has HSTS turned on,
> even if it's subsequently turned off, making it difficult to "unscrew"
> something that is screwed up.
You have almost no chance to screw it up (provided you use standard
ports 80 and 443):
* As you say in your initial message, you're not serving any http
traffic anyway, so there can't be anything hidden that needs to be
served through http instead of https
* The most you can do is to force browsers to replace any http with
https in any links (or in user input). And that already works for you
* If you screw something up, it'll be because you suddenly stop serving
https. Which, these days, would trigger all kind of browser warnings and
render your site unusable anyway. 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
* if you don't use the "includeSubdomains" option, there's no impact
outside of the current host name
* And if you are still fearful: /You/ are in control of the duration
that is flagged to the browser. I typically set it to 1 year (if I
remember correctly: in seconds), but you can certainly start with
testing it for 1 hour or 1 day. Not too useful in practice, but good for
testing the impact.
Yes, other configuration options can be much more impactful. But if you
don't serve https these days, you're screwed to begin with. So there is,
IMHO, no risk to enforce it.
Best,
Olaf
>
> The most convenient "guinea pig" Tomcat server (because it isn't
> normally used for anything else) would make a lousy candidate for
> testing this functionality with our webapps, because (as a guinea pig
> environment) its cert is long out-of-date (among other things),
> requiring me to override several browser complaints. And the only
> other one suitable for use as a guinea pig isn't doing its own HTTPS;
> it's sitting behind something else (not sure whether it's the httpd
> server on the same box, or something between the box and the rest of
> the world) that's doing it.
>
> So it should come as no surprise that I'm reluctant to do anything
> with it, without a lot of guidance, in case it breaks our webapp
> (using the wrong anti-clickjacking parameters will do that), and
> breaks it in a way that might have lasting effects that would be
> difficult to undo.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HSTS parameters in the httpHeaderSecurity filter
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 10/13/25 9:02 AM, Olaf Kock wrote:
> Do you have any question about this, that is missing in your original post?
>
> HSTS can still help you, as even in case of a breach, or a MITM attack,
> no browser (that has seen your site's HSTS header before) will ever even
> try to access port 80, but automatically rewrite URLs to https.
>
> The only drawback (if I remember correctly) is that it doesn't play
> well with non-default ports, e.g. 8080, if it's exposed publically.
Thanks. Basically, when the subject first came up (late Friday
afternoon), I took a brief look through the docs, but really didn't get
a whole lot of practical information. (As it stands, with the
anti-clickjacking parameters, I'm only doing what our web development
team said to do, and they're currently hip-deep in other projects that
I'd rather not interrupt).
One of the things that scares me the most about this is that I got the
impression that browsers will remember that a site has HSTS turned on,
even if it's subsequently turned off, making it difficult to "unscrew"
something that is screwed up.
The most convenient "guinea pig" Tomcat server (because it isn't
normally used for anything else) would make a lousy candidate for
testing this functionality with our webapps, because (as a guinea pig
environment) its cert is long out-of-date (among other things),
requiring me to override several browser complaints. And the only other
one suitable for use as a guinea pig isn't doing its own HTTPS; it's
sitting behind something else (not sure whether it's the httpd server on
the same box, or something between the box and the rest of the world)
that's doing it.
So it should come as no surprise that I'm reluctant to do anything with
it, without a lot of guidance, in case it breaks our webapp (using the
wrong anti-clickjacking parameters will do that), and breaks it in a way
that might have lasting effects that would be difficult to undo.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Olaf Kock <to...@olafkock.de>.
Am 14.10.25 um 09:41 schrieb Olaf Kock:
> 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.
Just remembering: Even for your guinea pig server, you /might/ be on the
safe side:
If I'm not mistaken, the browser will honor the HSTS flag only when
transmitted through a (valid) https connection. So you'd /first/ need a
proper https setup, before the HSTS flag is honored.
I'm not 100% sure about this though, but it should be easy to test for
you, with a short validity duration
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Olaf Kock <to...@olafkock.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 10/16/25 9:51 AM, Christopher Schultz wrote:
> :)
Thanks. By later yesterday afternoon, I'd found other parameter
structures to use as a model, and figured it out. I think I have HSTS
taken care of now, and my guinea-pig server is working just fine with it.
But see my later thread about keeping manager either blocked,
lobotomized, or physically absent when not in actual use. I find that I
can turn it on or off from a jmxterm session, but I can't make it reload
its context.xml, or get JMX to find the bean to turn it on if it wasn't
present at Tomcat launch (or is protected by an ignoreDeploy). (If
anybody has insights, please reply in that thread, rather than this one.)
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 10/14/25 1:22 PM, James H. H. Lampert wrote:
> On 10/14/25 6:33 AM, Christopher Schultz wrote:
>
> Thanks for reminding me about the filter-mapping; I'd forgotten to
> uncomment it when I'd stuck the filter configuration onto the "guinea
> pig" server. Once I did that, and restarted, Firefox started showing:
>
>> Strict-Transport-Security
>> max-age=0
>> X-Content-Type-Options
>> nosniff
>> X-Frame-Options
>> SAMEORIGIN
>
> Wait a second. Could I have . . . HOLY [redacted], I *WAS* that
> [redacted] stupid! When I was pre-staging the customer's update to
> 9.0.106, I'd uncommented the filter configuration and added the anti-
> clickjacking parameters, but I'd forgotten to uncomment the filter-mapping!
:)
> But I still do have a question:
>
> My filter configuration looks like this:
>
> <filter>
> <filter-name>httpHeaderSecurity</filter-name>
> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
> <init-param>
> <param-name>antiClickJackingOption</param-name>
> <param-value>SAMEORIGIN</param-value>
> </init-param>
> <async-supported>true</async-supported>
> </filter>
>
> If I'm adding more parameters, do I put them within the same <init-
> param> tags, or a separate pair of <init-param> tags?
Each parameter needs to be in a separate <init-param> wrapper, but they
can be all added to the same <filter> like this:
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
<init-param>
<param-name>other-param/param-name>
<param-value>value</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 10/14/25 6:33 AM, Christopher Schultz wrote:
Thanks for reminding me about the filter-mapping; I'd forgotten to
uncomment it when I'd stuck the filter configuration onto the "guinea
pig" server. Once I did that, and restarted, Firefox started showing:
> Strict-Transport-Security
> max-age=0
> X-Content-Type-Options
> nosniff
> X-Frame-Options
> SAMEORIGIN
Wait a second. Could I have . . . HOLY [redacted], I *WAS* that
[redacted] stupid! When I was pre-staging the customer's update to
9.0.106, I'd uncommented the filter configuration and added the
anti-clickjacking parameters, but I'd forgotten to uncomment the
filter-mapping!
But I still do have a question:
My filter configuration looks like this:
> <filter>
> <filter-name>httpHeaderSecurity</filter-name>
> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
> <init-param>
> <param-name>antiClickJackingOption</param-name>
> <param-value>SAMEORIGIN</param-value>
> </init-param>
> <async-supported>true</async-supported>
> </filter>
If I'm adding more parameters, do I put them within the same
<init-param> tags, or a separate pair of <init-param> tags?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 10/13/25 8:01 PM, James H. H. Lampert wrote:
> On 10/13/25 4:36 PM, Christopher Schultz wrote:
>
>> Do you have any reverse proxy or anything like that? Does Tomcat serve
>> HTTPS directly? If not, it will not return HSTS headers.
>
> Hmm. It is definitely serving HTTPS directly, because I'm seeing the
> same cert serial number as the one in the Java Keystore I personally
> plugged into their Tomcat server.
Okay. Can you show your Tomcat version number, security header filter
config, including the <filter-mapping> from web.xml, the context-path of
the web application, and a sample of:
curl -v https://example.com/yourapp/does_not_exist?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 10/13/25 4:36 PM, Christopher Schultz wrote:
> Do you have any reverse proxy or anything like that? Does Tomcat serve
> HTTPS directly? If not, it will not return HSTS headers.
Hmm. It is definitely serving HTTPS directly, because I'm seeing the
same cert serial number as the one in the Java Keystore I personally
plugged into their Tomcat server.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 10/14/25 6:05 PM, James H. H. Lampert wrote:
> On 10/13/25 4:36 PM, Christopher Schultz wrote:
>> 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.
>
> I tried it on the guinea-pig box with 60 seconds, and it worked, at
> least far enough to present a sign-on page.
>
> The complaint in the report is demanding that the max-age is less than a
> full year, and that includeSubDomains is absent. So my second test is
> with a full year, and includeSubDomains.
Increasing the max-age isn't a big deal, but includeSubDomains *can be*
a big deal. If you use www.example.com for everything and you
essentially have a single service then everything is fine, but if you
have other services on another.example.com and those can't use HTTPS
then it's critically important that you do not enable
"includeSubDomains", otherwise you'll basically kill those other services.
This is more impactful when you are using example.com without any "www"
prefix, or you have complicated domain name deployments.
> As to preload, (1) the word literally never occurs in the report with
> the complaint, (2) the webapp is not intended for public use, and (3) no
> browser has ever been able to visit it with "plain-old HTTP," because
> (going back to Tomcat 7) it has never been set up to serve "plain-old
> HTTP" (it's never been set up to even listen on 80 or 8080).
Preload will just load your domain into the preload list for browsers.
The reason that's helpful is to close the "TOFU" (trust on first use)
hole. If an attacker can MITM your client the first time they try to use
the service, then they can downgrade the connection from HTTPS to HTTP
and strip-out the HSTS headers, removing their efficacy.
Adding preload means that the browser knows to always use HTTPS even
before it makes a connection and sees the HSTS header for the first time.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Olaf Kock <to...@olafkock.de>.
Am 15.10.25 um 00:05 schrieb James H. H. Lampert:
> On 10/13/25 4:36 PM, Christopher Schultz wrote:
>
> And . . . once I fixed a typo on the hstsIncludeSubDomains parameter
> name . . .
I feel with you and I'm guilty of this as well. Quite often it takes
embarrassing myself with a public question in order to discover problems
of this nature. Good to know that it's solved - from your original
message I expected you to be on the side that benefits from HSTS despite
the scepticicity (if that's a word).
> It still works, and I'm able to sign on to it, and do simple
> operations with it.
>
> Thanks Messrs. Schultz and Kock for the hand-holding. Now about that
> other question I had, concerning starting and stopping contexts from
> "under the hood . . ."
Mark already answered it authoritatively before I returned to my desk.
My answer would have included only half the options he provided.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 10/13/25 4:36 PM, Christopher Schultz wrote:
> 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.
I tried it on the guinea-pig box with 60 seconds, and it worked, at
least far enough to present a sign-on page.
The complaint in the report is demanding that the max-age is less than a
full year, and that includeSubDomains is absent. So my second test is
with a full year, and includeSubDomains.
As to preload, (1) the word literally never occurs in the report with
the complaint, (2) the webapp is not intended for public use, and (3) no
browser has ever been able to visit it with "plain-old HTTP," because
(going back to Tomcat 7) it has never been set up to serve "plain-old
HTTP" (it's never been set up to even listen on 80 or 8080).
And . . . once I fixed a typo on the hstsIncludeSubDomains parameter
name . . .
It still works, and I'm able to sign on to it, and do simple operations
with it.
Thanks Messrs. Schultz and Kock for the hand-holding. Now about that
other question I had, concerning starting and stopping contexts from
"under the hood . . ."
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Specific questions, Re: HSTS parameters in the httpHeaderSecurity filter
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
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?
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?
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.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HSTS parameters in the httpHeaderSecurity filter
Posted by Olaf Kock <to...@olafkock.de>.
Hi James,
Am 13.10.25 um 17:30 schrieb James H. H. Lampert:
> I've recently been asked to look into the HSTS parameters in the
> httpHeaderSecurity filter. To date, I've only used the
> anti-clickjacking parameters, and had no idea what HSTS even *is.*
>
> As it stands, our Tomcat installations, at least those directly
> exposed to the outside, are all set up as HTTPS-only, with no active
> listener *at all* on 80 or 8080.
Do you have any question about this, that is missing in your original post?
HSTS can still help you, as even in case of a breach, or a MITM attack,
no browser (that has seen your site's HSTS header before) will ever even
try to access port 80, but automatically rewrite URLs to https.
The only drawback (if I remember correctly) is that it doesn't play
well with non-default ports, e.g. 8080, if it's exposed publically.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org