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