2015-05-11 11:56 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 08/05/2015 23:49, Rémy Maucherat wrote: >> 2015-05-08 21:14 GMT+02:00 Mark Thomas <ma...@apache.org>: >> >>> I'd like to back-port this but before I do I'd like to hear other >>> people's views on the following? >>> >>> - Should it be back-ported to 8.0.x >>> - Should it be enabled by default >>> - Should it be back-ported to 7.0.x >>> - Should it be enabled by default >>> - Should it be back-ported to 6.0.x >>> - Should it be enabled by default >>> >>> My own views are: >>> Yes/No >>> Yes/No >>> No/Not applicable >>> >> +1
+1 >> >> No for enabling it by default in 9.0.x as well. For now my feeling is that I do not like (as in '-0') it being enabled in conf/web.xml. My concerns and review comments are below. > The catalyst for work this was reading RFC 7525 [1]. That got me > thinking about similar headers. > > In [1] HSTS support is a MUST and using it is a SHOULD. On that basis I > think 9.0.x should use it by default unless there is a really good > reason not to. > > While the other headers are not required by any RFC (as far as I am > aware) they are good for security so again I think they should be > enabled by default unless there is a good reason not to. > > Mark > > > [1] https://www.rfc-editor.org/rfc/rfc7525.txt [[[ // HSTS if (hstsEnabled && request.isSecure() && response instanceof HttpServletResponse) { ((HttpServletResponse) response).addHeader(HSTS_HEADER_NAME, hstsHeaderValue); } ]]] I see the following problems: 1) It does not play well with other components. 1. Tomcat may be behind Apache HTTPD that can itself be configured to set those headers. 2. There are other ways to set headers. E.g. urlrewrite filter. There may be 3rd party components (Spring? Some security libraries?). The current code that does "addHeader" is problematic, because it may result in multiple copies of that header. 2) I think that it is hard to disable something that is enabled in conf/web.xml Can this filter be disabled or overwritten in a specific web application? (I just do not have enough practical experience here. I am sure that it is easy to overwrite a servlet by mapping another one onto the same URL. I am not sure about filters, but I have to re-read web fragment merging rules. I do not remember any way to delete/disable a filter.) In case of HSTS header global configuration is justified, but in general I have concerns. conf/web.xml is a big file (~5K lines). It is hard to configure it manually. Editing server.xml is a lot easier. (Though there is at least one widely used use cases to edit web.xml: change configuration of JspServlet to set development=false). 3) How this configuration plays with error pages provided by Tomcat? I guess that the default 404/403/401/503 pages may end without HSTS header. If error page is generated by Connector (400/404/500 pages at early stages of processing, e.g. if there is no ROOT web application) the header won't be set even if one uses a Valve to implement it instead of a Filter. If moving the implementation elsewhere, one of places is Http11Processor.prepareResponse(). 4) rfc7525 mentions that there are some configurations where using HSTS weakens security. From page 7: [[[ o Web servers SHOULD use HSTS to indicate that they are willing to accept TLS-only clients, unless they are deployed in such a way that using HSTS would in fact weaken overall security (e.g., it can be problematic to use HSTS with self-signed certificates, as described in Section 11.3 of [RFC6797]). ]]] (I wonder whether HSTS spec mean that if I access the same site locally via https://localhost/, connection will fail unconditionally. Shall this configuration host-specific, e.g. part of new SSLHostConfig element in Connector?) Usually people start experimenting with running tomcat as localhost. If in this case there is no way to make connection to it unless manually reconfiguring Tomcat first, then it would better be an opt-in feature that administrators enable explicitly. BTW, "Using HSTS on any port turns on HSTS for the entire host", https://bugzilla.mozilla.org/show_bug.cgi?id=613645#c1 5) From code quote above " if (hstsEnabled && request.isSecure()" This "request.isSecure()" condition is not mentioned in documentation (config/filter.html). The documentation text leaves an impression that the header is always added. Though wikipedia mentions that "HSTS headers over HTTP are ignored", with a link to https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security (I have not found this "ignore" behaviour by quick search through RFC text, but Mozilla document notes and explains it). 6) Documentation for blockContentTypeSniffingEnabled attribute should mention the name of HTTP header that it generates. ("X-Content-Type-Options") I'd be better to mention header name for hstsEnabled attribute as well. ("Strict-Transport-Security") Header name is a useful visual clue, as well as a way to resolve ambiguity in understanding the text. 7) I do not see any mention of this filter in docs/security-howto.html 8) All those X-something headers are non-standard. It is good to use them, but they may change in a future specification. In general there is a bunch of those, e.g. X-UA-Compatible. In general I would like that browsers worked "the best and secure way" without all those headers. It may be hard to remove that filter from our default conf/web.xml if we change our mind later, e.g. if browsers behaviour changes (for the good) in the next 5-7 years. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
