Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69332
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZD7V+r5zDqO9_XdnRLyseG-fYa2nuhcP-PQHi-76VTrA@mail.gmail.com>
References: <CAGa2bXbh6dOf41nZ0r-RuRtkCuuiA=r=SnxS+A1+GgqFXPGOWQ@mail.gmail.com>
	<CAFWS2+EocvSsyQ2q4v+EvBSn+++kdurZ3XP8odeAzyAXde9pAQ@mail.gmail.com>
	<CAGa2bXZD7V+r5zDqO9_XdnRLyseG-fYa2nuhcP-PQHi-76VTrA@mail.gmail.com>
Date: Tue, 24 Sep 2013 22:51:59 -0700
Message-ID: <CAFWS2+F4U1CiX2J3w1Ep7brFUFKQ5UTdwfTd9hrzX1FyXojn0Q@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c257000ee1de04e72edad6
Subject: Re: [PHP-DEV] Regenerating session ID automatically when IP address
 has changed
From: ronabop@gmail.com (Ronald Chmara)

--001a11c257000ee1de04e72edad6
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi,
> On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara <ronabop@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

--001a11c257000ee1de04e72edad6--