tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martynas Jusevičius <marty...@atomgraph.com>
Subject Re: [tomcat:8.0-jre8] <user-data-constraint>CONFIDENTIAL</user-data-constraint> adds Cache-Control: private?
Date Mon, 20 Aug 2018 14:30:47 GMT
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
<chris@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


Mime
View raw message