Brian McBride wrote:
On 14/09/2010 23:17, André Warnier wrote:
[...]
Personal interpretation : if the browser receives a cookie marked
"secure", it should only send it back with requests happening over an
HTTPS connection.
(No matter if it was received over HTTP or HTTPS).
I'm using httpunit for testing. I observe it receiving a new JSESSIONID
cookie over SSL and immediately sending it back over on open connection.
See generic comment at end.
...
RFC 2965 does not say that it overrides the older RFC 2109.
It does, at the end of the Abstract :
This document reflects implementation experience with RFC 2109 and
obsoletes it.
And, both RFCs are written by the same authors.
My
interpretation is that a user agent can follow RFC 2109 for Set-Cookie
headers, and possibly should. My Tomcat is sending Set-Cookie headers,
not Set-Cookie2 headers.
The text in RFC 2109 for the secure attibute is different to that in RFC
2965:
...
Note that the text about not sending a cookie received over a channel
back over a less secure one is omitted.
Considering that the authors seem to want to obsolete RFC 2109 with RFC 2965, I would thus
say that the previous omission in RFC 2109 has been corrected in RFC 2965, and not the
other way around.
So I guess, strictly speaking, no user agent sending secure cookies
over an insecure channel is actually in violation of the RFC :(
Strictly speaking, probably not. But I would say that it violates the spirit
of RFC 2965.
Is there a way to persuade Tomcat to use Set-Cookie2 headers?
That last, I don't know (except from adding the header yourself of course).
Generically, RFCs are written by the people most competent in the domain they are talking
about, and reviewed by other competent people. They tend to make sense.
That does not mean that there is not from time to time an omission or a
contradiction.
But in any case, RFCs are the best we have in terms of "standards of interoperability" on
the Internet.
And a general - but often unwritten - principle is : be strict in what you emit, and
tolerant in what you receive.
So my personal tendency, when I develop something Internet-wise, is to do it according to
the strictest (personal) interpretation of the latest version of an RFC. In other words,
to follow the MUST's and SHOULD's. Then on a second pass, I would look at the MAY's, to
make the code, possibly, tolerant of the other side's interpretation of the RFC.
And then I will test this in the real world, and try to find out all the kinks that happen
with various IE versions (always a good test of server code tolerance), and see if that
can be compensated for in a way that makes sense.
Of course that never catches everything that users may and will throw at you, so it is a
recursive process.
And, let's face it : since 95% of corporate users still use one or the other version of
IE, as developers we have not much choice but to accept what it throws at us and code
around it. (On the positive side, it is also a very convenient scapegoat when you make a
booboo and have to explain it to a customer; nobody ever questions the existence of bugs
in IE anymore).
About the behaviour you are seeing with httpunit, in view of the cumulative interpretation
of RFC 2109 and 2695, my view would be that this is sloppy behaviour of httpunit (but
maybe that is the point, since it is a testing tool ?).
But then also, you did not say if the cookie sent over HTTPS was marked "secure" (inasmuch
as this attribute exists for a Set-Cookie header; I have not checked).
If it was, and httpunit sends it back over a non-secure connection, then I definitely
think it's sloppy. If it wasn't, then my reading is that the server should know that if
it does not mark the cookie as "secure", a user agent is entitled to consider that the
cookie contains no sensitive information, and to do with it what it wants.
Now one more thing :
"> I'm using httpunit for testing. I observe it receiving a new JSESSIONID
> cookie over SSL and immediately sending it back over on open connection.
>
"
Which means that you have a Tomcat-based application of which part happens under HTTPS,
and part over normal HTTP. I personally find this iffy. If you are going through the
burden of setting up HTTPS, then why not run the entire session under HTTPS ?
If your login data is sensitive, then surely it is because what you are going to exchange
as data afterward is sensitive also, no ?
And if you relying on the fact that a JSESSIONID cookie received by the browser under a
HTTPS connection, will be resent by the browser on a non-HTTPS connection, then in my view
you are exposing yourself to some next browser version which will have a stricter
interpretation of these RFCs, and not send it anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
