You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2015/05/08 21:14:00 UTC
Back-porting the new HttpHeaderSecurityFilter
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
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by Mark Thomas <ma...@apache.org>.
On 11/05/2015 14:05, Rémy Maucherat wrote:
> 2015-05-11 14:28 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> Which features are you thinking of and are you suggesting they should be
>> enabled as well?
>>
> I vote "not enabled" :) I'm not a big fan of these security features
> usually (just like when my browser decides I am stupid and must reject
> "fake" certs on my behalf).
>
> There is:
> - CorsFilter
> - CsrfPreventionFilter
>
> And there are also dos style filters and valves too:
> - CrawlerSessionManagerValve
> - StuckThreadDetectionValve
> - app servers usually add a valve or filter for JCA as well in that category
Understood. I'll make it disabled when I back-port.
For 9.0.x I'm going to leave it enabled for now (if anyone agrees or
disagrees with that view please speak up).
I think this Filter should be enabled by default but if the community
feels differently I'm happy to change the default.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-11 14:28 GMT+02:00 Mark Thomas <ma...@apache.org>:
> Which features are you thinking of and are you suggesting they should be
> enabled as well?
>
> I vote "not enabled" :) I'm not a big fan of these security features
usually (just like when my browser decides I am stupid and must reject
"fake" certs on my behalf).
There is:
- CorsFilter
- CsrfPreventionFilter
And there are also dos style filters and valves too:
- CrawlerSessionManagerValve
- StuckThreadDetectionValve
- app servers usually add a valve or filter for JCA as well in that category
Rémy
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by Mark Thomas <ma...@apache.org>.
On 11/05/2015 13:13, Rémy Maucherat wrote:
> 2015-05-11 10:56 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> 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
>>
> Hm, there are other really "nice" security "features" that are done in
> filters in Tomcat and they are not enabled by default.
Which features are you thinking of and are you suggesting they should be
enabled as well?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-11 10:56 GMT+02:00 Mark Thomas <ma...@apache.org>:
> 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
>
> Hm, there are other really "nice" security "features" that are done in
filters in Tomcat and they are not enabled by default.
Rémy
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by 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
>
> No for enabling it by default in 9.0.x as well.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
Posted by Rémy Maucherat <re...@apache.org>.
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
No for enabling it by default in 9.0.x as well.
Rémy