On 3/25/13 4:25 PM, Mark Thomas wrote:
> On 25/03/2013 17:41, Rémy Maucherat wrote:
>> On 03/21/2013 09:37 PM, Shing Wai Chan wrote:
>>> In the schema, web-common_3_1.xsd (and web-common_3_0.xsd), we have
>>> the following
>>> <xsd:element name="secure"
>>> type="javaee:true-falseType"
>>> minOccurs="0">
>>> <xsd:annotation>
>>> <xsd:documentation>
>>>
>>> Specifies whether any session tracking cookies created
>>> by this web application will be marked as secure
>>> even if the request that initiated the corresponding session
>>> is using plain HTTP instead of HTTPS
>>>
>>> </xsd:documentation>
>>> </xsd:annotation>
>>> </xsd:element>
>>>
>>> When it is HTTPS and secure = false, we have a cookie with Secure
>>> attribute in our implementation.
>>> Do we need any clarification in the above description?
>> Probably this kind of setting it useful when using a proxy that uses
>> https with the client and the application server is communicating with
>> it with something lighter like regular http or ajp. If that's the use
>> case you're thinking about and you think it is not as clear as it should
>> be, you could add ", for example when using a proxy server".
>>
>> Similarly, could the opposite be true ? [as in, it is possible to
>> configure the cookie as not secure even if the connection is apparently
>> secure, due to some proxying] This seems a bit less likely to me, but
>> perhaps we should be careful.
>
> I have seen users reverse proxy HTTP connections over HTTPS. The usual
> response when this is questioned is "The security team says we have to
> do this."
>
> I think it would be a bad idea to prevent non-secure cookies over HTTPS
> but it certainly should require positive action from the sysadmin to
> make it happen.
>
> It should be possible for the reverse proxy to correct the secure flag
> if necessary but how easy/possible that is will depend on the reverse proxy.
Mark,
As I understand reverse proxying, it sounds like the session cookie
would be returned to the browser (across the internet) over an
unprotected transport, and that the proxy could unset the secure
bit on the cookie, so that the browser would be willing to send it
back again over an unprotected transport;
Maybe I have my proxying confused, but perhaps the use case you have in
mind would would position the browser and the proxy within the same
intranet, or corporate network, and the hop from the proxy to the
servlet container would be over the internet; in which case, I would
suggest as you did
that this be handled within the proxy, as appropriate to the desires and
ambitions of the
"security" team responsible for the proxy.
If I understand Shing Wai, he is noting that the cited text may not
allow a seesion cookie to be
marked as secure unless the session cookie config value is set to true;
even though common
practice may be to set the secure flag on the session cookie, when the
session cookie is returned
in response to an HTTPS/secure request.
Would either of the following be an improvement?
A} "Specifies whether any session tracking cookies created
by this web application will be marked as secure. When true,
all session tracking cookies must be marked as secure independent
of the nature of the request that initiated the corresponding session.
When false, the session cookie should only be marked secure if the
request that initiated the session was secure.
Ron