OK. Fair point. If you believe it is dangerous to just turn it on for real, as someone might do that in prod without knowing what they are doing, then I think Tomcat should generate a WARNING during startup that explains that HSTS is ON, but not yet doing anything, and maybe point them to an article that explains the uses/dangers of HSTS and how to configure it right, and test it thoroughly, before they actually turn it on in prod.
As I said, I think turning it ON, but not really, and being silent about it is dangerous to the non-expert. And you say turning it ON automatically for the non-expert is dangerous too, and I agree. So what do you think about generating some kind of warning during startup along the lines I suggest? Maybe point them at an article like this: https://www.globalsign.com/en/blog/what-is-hsts-and-how-do-i-use-it - Although I would prefer a vendor neutral article provided by Apache or OWASP or something like that. I couldn't find one I liked with a quick Google search. -Dave On Wed, Aug 26, 2020 at 1:01 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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 > >
