- From: Walter H. <Walter.H@mathemainzel.info>
- Date: Thu, 02 Apr 2015 21:08:07 +0200
- To: Willy Tarreau <w@1wt.eu>
- CC: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <551D9397.3070300@mathemainzel.info>
On 01.04.2015 13:46, Willy Tarreau wrote: > On Wed, Apr 01, 2015 at 11:32:05AM +0000, Eric Vyncke (evyncke) wrote: >> In the era of scarce IPv4 addresses, servers should NOT link the HTTP session >> cookies to the user-agent IP address... >> >> I have posted in the IETF V6OPS WG the following: >> http://www.ietf.org/proceedings/92/slides/slides-92-v6ops-6.pdf >> https://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie >> >> In short, heavy use of NAT and/or dual-stack (IPv4/IPv6) can cause a change >> of user-agent address => lost of session. >> >> Any suggestion on how this can be addressed? I know at least two major web >> sites in Belgium that removed IPv6 from their web site due to this issue (and >> their security department not wanting to unlink IP address from the session >> cookies) > I'm amazed people still do that in 2015, I had the idea to do it in 1999 > until I realized it was stupid and never did it! it is not stupid, it is very clever ..., why see below > So I'd have guessed that > 16 years later everyone would have also figured this! If IP addresses > were stable during a session, cookies would not be needed, the address > would be used instead. the WAN address, that everybody inside the LAN has in common? think of the following: in my country there existed a bank, that had in its electronic banking no session cookies; they had a worse solution, the session was stored in the URL, so it was possible not only on another browser or session of the same computer to use this URL also on another computer, because, the WAN address was the same ... and now think of MITM, nothing easier than this, you use the same session; can you really proof, money is lost, and it was not you?
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 2 April 2015 19:08:40 UTC