-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dave,

On 8/25/20 14:05, Dave Wichers wrote:
> Per:
> https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#HTTP_Heade
r_Security_Filter
>
>
and
https://tomcat.apache.org/tomcat-8.5-doc/config/filter.html#HTTP_Header_
Security_Filter
>
> they both say:
>
> hstsMaxAgeSeconds  - The max age value that should be used in the
> HSTS header. Negative values will be treated as zero. If not
> specified, the default value of 0 will be used.
>
> So, if a Tomcat user (like I did at first), configures
> hstsEnabled=true, the HSTS response header is set by Tomcat, but
> with a max age of zero (since that is the default).
>
> However, per the HSTS RFC:
> https://tools.ietf.org/html/rfc6797#section-6.1.1 it says:
>
> NOTE:  A max-age value of zero (i.e., "max-age=0") signals the UA
> to cease regarding the host as a Known HSTS Host, including the
> includeSubDomains directive (if asserted for that HSTS Host).
>
> I noticed this problem when I first enabled HSTS on my Tomcat dev
> instance, and then passively scanned my web app with OWASP ZAP
> (https://owasp.org/www-project-zap/). ZAP, correctly I believe,
> pointed out that enabling HSTS with a MaxAge of zero is effectively
> a no-op. (i.e., does nothing).

Correct.

> If I'm correct, then I think having a default of zero is dangerous
> and should instead default to something useful and effective.

I disagree.

> Such as one year (in seconds) which is what many developers
> set/configure this value.  Otherwise, I think turning HSTS ON in
> Tomcat might be giving people a false sense of security because it
> really doesn't doing anything unless you also set MaxAge (which to
> me isn't intuitive that you should have to do that).
>
> Do you agree with me that this is a problem that should be fixed?
Here's why I disagree: if you configure your server to reply with
HSTS=on with a meaningful expiration, then the browser is *going to
enforce it*. If you have not configured it correctly, or you are just
testing, you can basically lock your site out from all clients for
e.g. a year before they are willing to re-connect to you.

AFAIK, there is no recognized mitigation for "oops we enabled HSTS for
our site but actually we need parts of it to remain non-encrypted so
please please please forget we ever said anything about HSTS". If you
enable it and don't know what you are doing, you can SERIOUSLY fubar
your infrastructure.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GlU0ACgkQHPApP6U8
pFgQfQ//XnGay5wOwEIixUb/8PoioJHNLZLgqwShePVRnAkgyzCxRl+yWDonC7pX
BcA4MwI5d/UcivGILor2VH5WXZYeI0e/zlneMT5P9hz9cBrUM4YTSx/wdUNA8a12
mznC7T9fRZiUrgCHhEcgJaAL+rrPXDSAMVq6vVZBhTQBPd0igLmqxf1I8vA2hc8p
Rk8oa6mb2YLSNvIjJAGqYaV1VIg4oMyNjowi5RmpFn/4h3Kk3rnPWY3kFlvi8t3W
JGM3l7tGU8aFxrdCEVO+ypsCCtNsRbGWFGCaETITAHwYVnXEwk9wZNnOA51sJeQE
aRyyo6KyJi7nqKEjlsXV2DBqCmjv8ToWv1INyZrGxJXNojThbeWhexKjrKu8FOXW
RZMnOc6BMfQPb8673lGjLoGzcyjlgLSRhUTNwHaIwTGV8a6nK5+E/GNPr+x00Wei
KumMnm/AB1haBLRPgX+A5elneOnedPweWE00KqH7uBOkUbHCquwOf/9YnmsJBji+
KGIXecNk5pC2bwZF17ULYoC25UEBePyDbJNV5wEOZGLL+ayUtNFhtCSYB30+AWJT
3CqbHb0oMsb9kGQkEqScklzOBRsmHxvDZ4JSswO3rmKEUY+yGWKUbpxdZu6s/HSj
DeaCEnqTByBocQDl8UWRruWwGXX7QC3Dk4z7CZdU1gLFAgMncm0=
=tfoo
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to