You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Martynas Jusevičius <ma...@atomgraph.com> on 2018/08/16 12:40:02 UTC
[tomcat:8.0-jre8] CONFIDENTIAL
adds Cache-Control: private?
Hi,
my initial observations suggest, and SO post [1] seems to confirm, that when
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
is specified on a security-constraint in web.xml, Tomcat does two things:
1. automatically redirects to HTTPS
2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970
01:00:00 CET response headers
Is that correct?
I had added the CONFIDENTIAL because I want the redirect to HTTPS.
What I don't want is Tomcat overriding my caching headers and
effectively disabling browser caching.
Why in the world would those two things be conflated? And how do I
disable this header override behavior?
Does disableProxyCaching attribute need to be set to false to in order
to do that? [2]
I'm running the tomcat:8.0-jre8 on Docker.
[1] https://stackoverflow.com/questions/21829553/tomcat-security-constraint-impact-cache
[2] https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat:8.0-jre8]
CONFIDENTIAL adds Cache-Control:
private?
Posted by Olaf Kock <to...@olafkock.de>.
Hi Martynas,
On 16.08.2018 14:40, Martynas Jusevičius wrote:
> Hi,
>
> my initial observations suggest, and SO post [1] seems to confirm, that when
>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
>
> is specified on a security-constraint in web.xml, Tomcat does two things:
> 1. automatically redirects to HTTPS
> 2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970
> 01:00:00 CET response headers
>
> Is that correct?
Without looking at the code, but with you stating this as an
observation, I'd say yes, there's a good chance for it to be correct
(well, you obviously observe it, and I can imagine it being on purpose)
> I had added the CONFIDENTIAL because I want the redirect to HTTPS.
> What I don't want is Tomcat overriding my caching headers and
> effectively disabling browser caching.
There's a better way to redirect to HTTPS, rather than using this
declaration. You can either do this in a servlet filter, proxy through
Apache httpd or similar (where you can redirect/rewrite), or just deny
tomcat to serve on port 80 anyways (just have a static redirect on port
80). Add a pinch of HSTS, and you're set.
If an application declares CONFIDENTIAL, it might not like the content
to be stored on any disc cache. Sending expired content will serve that
purpose beautifully. And you're asking for CONFIDENTIAL, not ENCRYPTED
(note: the ENCRYPTED declaration doesn't exist AFAIK)
> Why in the world would those two things be conflated? And how do I
> disable this header override behavior?
My best guess: Because one is not meant to be The Solution (TM) for the
other.
> Does disableProxyCaching attribute need to be set to false to in order
> to do that? [2]
>
> I'm running the tomcat:8.0-jre8 on Docker.
Pardon the sneaky comment:
Why on earth would someone ask for security related features on a server
that has reached its end of life?
(this won't solve your problem, but static redirecting will)
I hope that helps,
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat:8.0-jre8] CONFIDENTIAL
adds Cache-Control: private?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
I've solved this by removing the <security-constraint> completely and
doing a 301 redirect to https:// in nginx (which is in front of
Tomcat) instead:
https://nginx.org/en/docs/http/converting_rewrite_rules.html
Also added HTST header as suggested in this thread:
https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#HTTP_Header_Security_Filter
On Fri, Aug 17, 2018 at 8:24 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 8/17/18 11:49 AM, Mark Thomas wrote:
>> On 17/08/18 14:57, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 8/17/18 4:09 AM, Mark Thomas wrote:
>>>> On 16/08/18 13:40, Martynas Jusevičius wrote:
>>>>> Hi,
>>>>>
>>>>> my initial observations suggest, and SO post [1] seems to
>>>>> confirm, that when
>>>>>
>>>>> <user-data-constraint>
>>>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>>>> </user-data-constraint>
>>>>>
>>>>> is specified on a security-constraint in web.xml, Tomcat does
>>>>> two things: 1. automatically redirects to HTTPS 2. appends
>>>>> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00
>>>>> CET response headers
>>>>>
>>>>> Is that correct?
>>>
>>>> It is broader than that. Tomcat adds those headers to any
>>>> resource that is protected by any security constraint.
>>>
>>>>> I had added the CONFIDENTIAL because I want the redirect to
>>>>> HTTPS. What I don't want is Tomcat overriding my caching
>>>>> headers and effectively disabling browser caching.
>>>
>>>> Those headers shouldn't disable browser caching.
>>>
>>> Expires: 1970 certainly effectively disables browsed caching.
>>
>> My understanding was that the browser caches the resource but marks
>> it as stale which means it needs validation on the next request.
>
> That's essentially the same thing. The server can still return a 304
> response if the browser thinks it has an up-to-date copy, but it's
> still a round-trip to the server that might be avoided.
>
>>>> They will mean the client has to revalidate the request. How
>>>> relatively expensive that is will depend on the resources.
>>>
>>>>> Why in the world would those two things be conflated?
>>>
>>>> Security. Any resource protected by a security constraint
>>>> should not be stored in a shared cache else information
>>>> disclosure could occur.
>>>
>>> I'm curious, too: I can understand the "Cache-Control" header,
>>> but why the "Expires" one? What about some CSS file that can
>>> surely be cached by the browser?
>>
>> Looks like an HTTP/1.0 solution from a very short amount of
>> research. Revalidation for a static file shouldn't be too
>> expensive.
>>
>>> Is it possible for a servlet to override a single header -- say,
>>> the "Expires" header? It might be nice to have a facility to
>>> allow applications to override maybe just this one header (or,
>>> optionally, just one *other* header). I glossed-over the servlet
>>> spec and I don't see much in the way of proscriptions for
>>> precisely how to handle security-constraints e.g. when it comes
>>> to setting headers.
>>
>> It depends when the header is added. In this case the Authenticator
>> adds them before the filter chain is invoked so it should be
>> possible for an application to remove them.
>
> That's very good to know.
>
> There are very few headers that Tomcat automatically adds (at any
> stage). Could those be described somewhere including when/where they
> are added and whether they can be overridden?
>
> For example, I tried (and failed) to override the "Date" response
> header at some point while testing my "replay response" sample code.
> It might be nice to know that Tomcat adds (overwrites) that header
> fairly late in the process.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt3EskACgkQHPApP6U8
> pFg9TQ/9E2lLXq8ZjBBU1bMvd66jHJ4RgruQYG3sViaTA6xkk0zF1YWmAH0fquZV
> Xnid0102FteOZ7uqsMvzIRNywvnuL6S1nq9ItIvBMIQofZZnTnu275Xetq6smOHR
> j+o51S1sq5WwFP1ypijnYwT1KHmc1eQ9XwubsxmWgxVw33nJNhfsLr2BWMs9xWsT
> lG+iHA1ArIxRjx/oTtjuZAXgyH2PsB5T91huOmrzeR9uXbXfUGj+/qCoS33KcMyq
> +qQT/iDFH/z6i0g50a95fl6dLb3Tizmpwk7xikhd4eZ+D05qJEQAH0Vnyff8a/NA
> leHjeouGgo0ZaSBGWByYDZno1q34QkwOUfv6UGaHD0fw21yGsxWt1mfo6jedHNQ3
> ZhXbEQMhM8uYIHYuKAaMcXSEbOvMkd7SsoqZGRzK6t1HptgtGN6NyRQA9U6hLT8I
> 5eGad3Bdx2nbnR7KDqcizJZ/Ulx5Be6XIQE4pncf2OLgfB6H3EkJ8FUkeU74i6W5
> se0z9vECh7zBxEAaCm0u7bVH1NK5zZKcOgPxzFvtHrkj7bnpBXcN9Qm6G1OkEfjG
> d7rxnQtzG/d38YL0LQy3VsMp+q0Va9sRSztKpmmSU+se2904R/mj4ITz3M7e6VTE
> 1+LhS4WSf4yriC7qmShd5d/CzDW3Pvz0S0uyoV5MduQWtBbnDbQ=
> =8Svp
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat:8.0-jre8]
CONFIDENTIAL adds Cache-Control:
private?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 8/17/18 11:49 AM, Mark Thomas wrote:
> On 17/08/18 14:57, Christopher Schultz wrote:
>> Mark,
>>
>> On 8/17/18 4:09 AM, Mark Thomas wrote:
>>> On 16/08/18 13:40, Martynas Jusevičius wrote:
>>>> Hi,
>>>>
>>>> my initial observations suggest, and SO post [1] seems to
>>>> confirm, that when
>>>>
>>>> <user-data-constraint>
>>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>>> </user-data-constraint>
>>>>
>>>> is specified on a security-constraint in web.xml, Tomcat does
>>>> two things: 1. automatically redirects to HTTPS 2. appends
>>>> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00
>>>> CET response headers
>>>>
>>>> Is that correct?
>>
>>> It is broader than that. Tomcat adds those headers to any
>>> resource that is protected by any security constraint.
>>
>>>> I had added the CONFIDENTIAL because I want the redirect to
>>>> HTTPS. What I don't want is Tomcat overriding my caching
>>>> headers and effectively disabling browser caching.
>>
>>> Those headers shouldn't disable browser caching.
>>
>> Expires: 1970 certainly effectively disables browsed caching.
>
> My understanding was that the browser caches the resource but marks
> it as stale which means it needs validation on the next request.
That's essentially the same thing. The server can still return a 304
response if the browser thinks it has an up-to-date copy, but it's
still a round-trip to the server that might be avoided.
>>> They will mean the client has to revalidate the request. How
>>> relatively expensive that is will depend on the resources.
>>
>>>> Why in the world would those two things be conflated?
>>
>>> Security. Any resource protected by a security constraint
>>> should not be stored in a shared cache else information
>>> disclosure could occur.
>>
>> I'm curious, too: I can understand the "Cache-Control" header,
>> but why the "Expires" one? What about some CSS file that can
>> surely be cached by the browser?
>
> Looks like an HTTP/1.0 solution from a very short amount of
> research. Revalidation for a static file shouldn't be too
> expensive.
>
>> Is it possible for a servlet to override a single header -- say,
>> the "Expires" header? It might be nice to have a facility to
>> allow applications to override maybe just this one header (or,
>> optionally, just one *other* header). I glossed-over the servlet
>> spec and I don't see much in the way of proscriptions for
>> precisely how to handle security-constraints e.g. when it comes
>> to setting headers.
>
> It depends when the header is added. In this case the Authenticator
> adds them before the filter chain is invoked so it should be
> possible for an application to remove them.
That's very good to know.
There are very few headers that Tomcat automatically adds (at any
stage). Could those be described somewhere including when/where they
are added and whether they can be overridden?
For example, I tried (and failed) to override the "Date" response
header at some point while testing my "replay response" sample code.
It might be nice to know that Tomcat adds (overwrites) that header
fairly late in the process.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt3EskACgkQHPApP6U8
pFg9TQ/9E2lLXq8ZjBBU1bMvd66jHJ4RgruQYG3sViaTA6xkk0zF1YWmAH0fquZV
Xnid0102FteOZ7uqsMvzIRNywvnuL6S1nq9ItIvBMIQofZZnTnu275Xetq6smOHR
j+o51S1sq5WwFP1ypijnYwT1KHmc1eQ9XwubsxmWgxVw33nJNhfsLr2BWMs9xWsT
lG+iHA1ArIxRjx/oTtjuZAXgyH2PsB5T91huOmrzeR9uXbXfUGj+/qCoS33KcMyq
+qQT/iDFH/z6i0g50a95fl6dLb3Tizmpwk7xikhd4eZ+D05qJEQAH0Vnyff8a/NA
leHjeouGgo0ZaSBGWByYDZno1q34QkwOUfv6UGaHD0fw21yGsxWt1mfo6jedHNQ3
ZhXbEQMhM8uYIHYuKAaMcXSEbOvMkd7SsoqZGRzK6t1HptgtGN6NyRQA9U6hLT8I
5eGad3Bdx2nbnR7KDqcizJZ/Ulx5Be6XIQE4pncf2OLgfB6H3EkJ8FUkeU74i6W5
se0z9vECh7zBxEAaCm0u7bVH1NK5zZKcOgPxzFvtHrkj7bnpBXcN9Qm6G1OkEfjG
d7rxnQtzG/d38YL0LQy3VsMp+q0Va9sRSztKpmmSU+se2904R/mj4ITz3M7e6VTE
1+LhS4WSf4yriC7qmShd5d/CzDW3Pvz0S0uyoV5MduQWtBbnDbQ=
=8Svp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat:8.0-jre8]
CONFIDENTIAL adds Cache-Control:
private?
Posted by Mark Thomas <ma...@apache.org>.
On 17/08/18 14:57, Christopher Schultz wrote:
> Mark,
>
> On 8/17/18 4:09 AM, Mark Thomas wrote:
>> On 16/08/18 13:40, Martynas Jusevičius wrote:
>>> Hi,
>>>
>>> my initial observations suggest, and SO post [1] seems to
>>> confirm, that when
>>>
>>> <user-data-constraint>
>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>> </user-data-constraint>
>>>
>>> is specified on a security-constraint in web.xml, Tomcat does two
>>> things: 1. automatically redirects to HTTPS 2. appends
>>> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00 CET
>>> response headers
>>>
>>> Is that correct?
>
>> It is broader than that. Tomcat adds those headers to any resource
>> that is protected by any security constraint.
>
>>> I had added the CONFIDENTIAL because I want the redirect to
>>> HTTPS. What I don't want is Tomcat overriding my caching headers
>>> and effectively disabling browser caching.
>
>> Those headers shouldn't disable browser caching.
>
> Expires: 1970 certainly effectively disables browsed caching.
My understanding was that the browser caches the resource but marks it
as stale which means it needs validation on the next request.
>> They will mean the client has to revalidate the request. How
>> relatively expensive that is will depend on the resources.
>
>>> Why in the world would those two things be conflated?
>
>> Security. Any resource protected by a security constraint should
>> not be stored in a shared cache else information disclosure could
>> occur.
>
> I'm curious, too: I can understand the "Cache-Control" header, but why
> the "Expires" one? What about some CSS file that can surely be cached
> by the browser?
Looks like an HTTP/1.0 solution from a very short amount of research.
Revalidation for a static file shouldn't be too expensive.
> Is it possible for a servlet to override a single header -- say, the
> "Expires" header? It might be nice to have a facility to allow
> applications to override maybe just this one header (or, optionally,
> just one *other* header). I glossed-over the servlet spec and I don't
> see much in the way of proscriptions for precisely how to handle
> security-constraints e.g. when it comes to setting headers.
It depends when the header is added. In this case the Authenticator adds
them before the filter chain is invoked so it should be possible for an
application to remove them.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat:8.0-jre8]
CONFIDENTIAL adds Cache-Control:
private?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 8/17/18 4:09 AM, Mark Thomas wrote:
> On 16/08/18 13:40, Martynas Jusevičius wrote:
>> Hi,
>>
>> my initial observations suggest, and SO post [1] seems to
>> confirm, that when
>>
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>>
>> is specified on a security-constraint in web.xml, Tomcat does two
>> things: 1. automatically redirects to HTTPS 2. appends
>> Cache-Control: private and Expires: Thu, 01 Jan 1970 01:00:00 CET
>> response headers
>>
>> Is that correct?
>
> It is broader than that. Tomcat adds those headers to any resource
> that is protected by any security constraint.
>
>> I had added the CONFIDENTIAL because I want the redirect to
>> HTTPS. What I don't want is Tomcat overriding my caching headers
>> and effectively disabling browser caching.
>
> Those headers shouldn't disable browser caching.
Expires: 1970 certainly effectively disables browsed caching.
> They will mean the client has to revalidate the request. How
> relatively expensive that is will depend on the resources.
>
>> Why in the world would those two things be conflated?
>
> Security. Any resource protected by a security constraint should
> not be stored in a shared cache else information disclosure could
> occur.
I'm curious, too: I can understand the "Cache-Control" header, but why
the "Expires" one? What about some CSS file that can surely be cached
by the browser?
>> And how do I disable this header override behavior?
>>
>> Does disableProxyCaching attribute need to be set to false to in
>> order to do that? [2]
>
> That would work. The consequence is that the application has to
> take responsibility for setting all of the caching headers -
> including those served by container servlets such as static
> resources and JSPs.
Is it possible for a servlet to override a single header -- say, the
"Expires" header? It might be nice to have a facility to allow
applications to override maybe just this one header (or, optionally,
just one *other* header). I glossed-over the servlet spec and I don't
see much in the way of proscriptions for precisely how to handle
security-constraints e.g. when it comes to setting headers.
This is an academic question for me... all of our static resources are
served by httpd and not Tomcat, so those headers that are advantageous
for caching are handled there and not in Tomcat.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt21EkACgkQHPApP6U8
pFiJBRAAx/e2eagrr6OFv8yrX0C3ckxTC3aahSqGISieunlBb1TypdygqAtt0/Ro
P+40LplhT17U+bvFU1HYacq2m4lswYUosaPKRcQEh5lqcP0DXCMPX3kBk0C8Wlw1
g5aJMha/21YDZysITzJzppGiBtqSIsdKH8yIhgOf1yR5U/oMR4UMFMDqZI1cLf4X
vPDROT3f+SNLfmPglXMlGbYvXI2fauel1sHbdjttUNdbneAVJwDS5Szc36uj2Cpq
7SophzD37FbroBfa/Ylxs5yI+p88gQjOHS96ebqNElNtosiidrwK6ysn8qVtgbGb
v4oZeWqahrwkDRBibWAIGJjiNiO0/pB2hLSuxuuBG1JapTOeawZ8WwJLTZ9iiX71
ThI7L7t7iBEIB1I1dpq8KrIUP/dJc6H0ekFlW6Q87cZcvWTyRB45gibNC2tRNxwz
7x2Pm7MU0eB7fihKNJuMmYUY0N+QUlqetMEkwEFbmMrIL4Wn6MGTAYgRu3Y5OqE1
Ctlil/SCEgZHpXEXU86xTTEQVB0gei0k4KbXlld0vuF9dzAxGA/AuwnjygihAigL
PNlbNHhfFmYn+UGMoP2+J3CKYJc9Eu/xZfhrQebEJ80GWK3NPZTEoEu/iz70B/Pf
LqSeENgMi6hQZYDn8xpLSzKm1S4XzmwNb2pW3pfUaeqMclAZylk=
=HIre
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat:8.0-jre8]
CONFIDENTIAL adds Cache-Control:
private?
Posted by Mark Thomas <ma...@apache.org>.
On 16/08/18 13:40, Martynas Jusevičius wrote:
> Hi,
>
> my initial observations suggest, and SO post [1] seems to confirm, that when
>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
>
> is specified on a security-constraint in web.xml, Tomcat does two things:
> 1. automatically redirects to HTTPS
> 2. appends Cache-Control: private and Expires: Thu, 01 Jan 1970
> 01:00:00 CET response headers
>
> Is that correct?
It is broader than that. Tomcat adds those headers to any resource that
is protected by any security constraint.
> I had added the CONFIDENTIAL because I want the redirect to HTTPS.
> What I don't want is Tomcat overriding my caching headers and
> effectively disabling browser caching.
Those headers shouldn't disable browser caching. They will mean the
client has to revalidate the request. How relatively expensive that is
will depend on the resources.
> Why in the world would those two things be conflated?
Security. Any resource protected by a security constraint should not be
stored in a shared cache else information disclosure could occur.
> And how do I
> disable this header override behavior?
>
> Does disableProxyCaching attribute need to be set to false to in order
> to do that? [2]
That would work. The consequence is that the application has to take
responsibility for setting all of the caching headers - including those
served by container servlets such as static resources and JSPs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org