On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi, > On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara <rona...@gmail.com> wrote: > >> When you have a group of front-end termination points in a pool, proxying >> requests off to hundreds of machines for thousands of applications, tying a >> session to any IP is a headache. IMO, sessions are supposed to be tied to >> users, not any given inbound IP that can, and may, jump between different >> routers, proxies, NAT hosts, etc. > > Session is tied to specific user(browser) regardless of IP unless session > ID is hijacked. > Renewing session ID does not matter. Regenerating session ID when IP has > changed > would help users to notice session hijack. This is the sole purpose of > regenerating > session ID when IP has changed. I think only few apps do this now. > So, say you have many front ends, with load balancing, and public IP addresses. Those front-ends talk on private IP ranges to back-end machines, so the session can come in from any public IP, be proxied, and handed off. This, BTW, is not hypothetical, it's about my work with http://appfog.com. Some actual numbers to explain : Our Singapore location (for example) has 29,088 websites, with 6 incoming IP addresses talking to 27 website nodes. Regenerating session keys is a waste of CPU at that scale, as a given user's requests may jump around 6 different inbound addresses, and any number of servers. Takeaway: 1) Binding session to IP doesn't work at scale. 2) Seeing that the IP has "changed" is totally useless to detect hijacking. 3) Session libraries that are expecting state, on the internet, are fundamentally broken by design. <rant> There is no such thing as a secure http session. Ever. The protocol, by design, does not allow it. Ever. You can add layers (such as https) to make things "better", but if you want secure communication, don't use the internet. </rant> -Ronabop
