There is one potential exposure with cookies and HTTPS:
If the cookie is not sent with the attribute "secure", then that cookie will
be sent to the host whether the connection is HTTP or HTTPS. If the user
types in (e.g.) "wiki.mycompany.com", the browser will default to the
"http"
protocol (no "s"), the cookie will be sent unencrypted, and it might be
sniffed in transit, then replayed by someone else.
If the server sets "secure" in the cookie, then the browser will send it
only on HTTPS connections, and it is not subject to sniff/replay (at least,
not at all readily).
I'm not sure where in the MW code the cookie attributes are set; perhaps
someone else knows...
[BTW, this exposure is possible for both session cookies and persistent
cookies; it's just more likely that the exposure will actually occur with
persistent cookies.]
-- Joshua
On 10/26/06 8:47 AM, "Rick DeNatale" <rick.denatale(a)gmail.com> wrote:
On 10/25/06, Gary Kirk <gary.kirk(a)gmail.com>
wrote:
That kind of defeats the point of using HTTPS,
no?
I don't see how.
HTTPS is a transport level protocol which does several things:
1) It encrypts traffic between the client and server
2) It uses a certificate to authenticate the server so the client
knows who it's talking to.
3) It optionally uses a client-certificate to authenticate the client
machine to the server.
#3 is not often used.
Persistent cookies don't defeat https, since they are part of the
protocol at the application level.