-----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