On 3/28/13 8:55 PM, Ron Monzillo wrote:
> 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?
I was also going to propose a second option, but forgot to change
this when I decided to just propose one.
>
> 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