Question re session hijacking in dual stack environments w/MacOS
Hey all, as we've slowly deployed IPv6 to our end users, it has begun to cause some issues for those on Mac's specifically. Apple apparently has an algorithm at some point in the network stack to decide whether IPv4 or IPv6 is, perhaps, 'better' or 'faster' at any given point in time during an ongoing session. This allows a computer talking to a dual stack remote website to flip flop between v4 and v6 as activity is conducted. Websites that require some type of authentication that is handled via session cookies have been booting our users out randomly with "your ip address has changed" type message. This occurs when their Mac decides to switch between protocols because the site views it as a session hijacking attempt when Joe User with session ID xyz switches from 192.0.2.10 to 2001:db8::1:1:a or vice versa. Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not. Thanks, David
On Saturday, September 26, 2015, David Hubbard < dhubbard@dino.hostasaurus.com> wrote:
Hey all, as we've slowly deployed IPv6 to our end users, it has begun to cause some issues for those on Mac's specifically. Apple apparently has an algorithm at some point in the network stack to decide whether IPv4 or IPv6 is, perhaps, 'better' or 'faster' at any given point in time during an ongoing session. This allows a computer talking to a dual stack remote website to flip flop between v4 and v6 as activity is conducted.
Websites that require some type of authentication that is handled via session cookies have been booting our users out randomly with "your ip address has changed" type message. This occurs when their Mac decides to switch between protocols because the site views it as a session hijacking attempt when Joe User with session ID xyz switches from 192.0.2.10 to 2001:db8::1:1:a or vice versa.
Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not.
Thanks,
David
Info about Apple and their unique IPv6 selection process https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html
On 2015-09-26 14:34, David Hubbard wrote:
Websites that require some type of authentication that is handled via session cookies have been booting our users out randomly with "your ip address has changed" type message. This occurs when their Mac decides to switch between protocols because the site views it as a session hijacking attempt when Joe User with session ID xyz switches from 192.0.2.10 to 2001:db8::1:1:a or vice versa.
This sounds like a really poor practice on the part of the website operators. Users on wireless devices may be switching networks throughout the same session (wifi/LTE), or there could be a cluster of proxies, or short DHCP leases, or tor circuit changes, or privacy extensions, etc. This is almost as bad as using GeoIP databases to authenticate. -Laszlo
On 26/Sep/15 16:34, David Hubbard wrote:
Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not.
I have been tracking down an issue for months where SSH'ing to some devices (which picks IPv6 by default) from my Mac while in the office drops the connection, forcing me to reconnect. It's random; sometimes it happens a lot, sometimes, rarely, other times not at all. I've sort of suspected OS X to be the issue (10.10.5) here. The workaround has been to SSH strictly on IPv4 which is always stable. So it seems to be an issue when the session is carried over IPv6. This only affects OS X. SSH'ing from FreeBSD, for example, on IPv6 is stable. To be honest, I've been a little busy to look deeper into this, but it definitely has something to do with what you describe, I imagine. Mark.
On Tue, Sep 29, 2015 at 09:23:59AM +0200, Mark Tinka wrote:
On 26/Sep/15 16:34, David Hubbard wrote:
Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not.
I have been tracking down an issue for months where SSH'ing to some devices (which picks IPv6 by default) from my Mac while in the office drops the connection, forcing me to reconnect. It's random; sometimes it happens a lot, sometimes, rarely, other times not at all.
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not. sudo sysctl -w net.inet6.ip6.use_tempaddr=0 sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf'
On Fri, 02 Oct 2015 00:46:47 -0500, Doug McIntyre said:
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
Isn't the OS supposed to wait for the last user of the old address to close their socket before dropping it?
sudo sysctl -w net.inet6.ip6.use_tempaddr=0
sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf'
In message <132752.1443772000@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu writes:
On Fri, 02 Oct 2015 00:46:47 -0500, Doug McIntyre said:
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
Isn't the OS supposed to wait for the last user of the old address to close their socket before dropping it?
Bowser talks to server with temp address 1. Sockets close. New temp address generated. User click submit. New temp address used. It is stupid web site design to assume that addresses will be stable even within a session.
sudo sysctl -w net.inet6.ip6.use_tempaddr=0
sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf' -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Oct 02, 2015 at 03:46:40AM -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 02 Oct 2015 00:46:47 -0500, Doug McIntyre said:
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
Isn't the OS supposed to wait for the last user of the old address to close their socket before dropping it?
In my experience, no, it doesn't. Ie. the main reason I disable it is because my ssh sessions hung after some period of time, so ssh had sockets open, but yet the IPv6 addresses kept rotating out. Disabling it definately made the ssh sessions stable on OSX. Apple codes to the masses. Average web browser user or mail client won't care, that is all they test against. Not people that leave ssh sessions open for days to weeks at a time.
On Fri, 2 Oct 2015 06:58:43 -0500 Doug McIntyre <merlyn@geeks.org> wrote:
On Fri, Oct 02, 2015 at 03:46:40AM -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 02 Oct 2015 00:46:47 -0500, Doug McIntyre said:
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
Isn't the OS supposed to wait for the last user of the old address to close their socket before dropping it?
In my experience, no, it doesn't. Ie. the main reason I disable it is because my ssh sessions hung after some period of time, so ssh had sockets open, but yet the IPv6 addresses kept rotating out. Disabling it definately made the ssh sessions stable on OSX.
Apple codes to the masses. Average web browser user or mail client won't care, that is all they test against. Not people that leave ssh sessions open for days to weeks at a time.
Since no one else has mentioned it yet, mosh is another solution to this for ssh: https://mosh.mit.edu/
On Oct 2, 2015, at 00:46 , Valdis.Kletnieks@vt.edu wrote:
On Fri, 02 Oct 2015 00:46:47 -0500, Doug McIntyre said:
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
Isn't the OS supposed to wait for the last user of the old address to close their socket before dropping it?
No… It just waits for the valid lifetime to expire. Privacy addresses don’t refresh their preferred lifetime and start counting the valid lifetime from preferred expiration IIRC. Owen
On Oct 1, 2015, at 22:46 , Doug McIntyre <merlyn@geeks.org> wrote:
On Tue, Sep 29, 2015 at 09:23:59AM +0200, Mark Tinka wrote:
On 26/Sep/15 16:34, David Hubbard wrote:
Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not.
I have been tracking down an issue for months where SSH'ing to some devices (which picks IPv6 by default) from my Mac while in the office drops the connection, forcing me to reconnect. It's random; sometimes it happens a lot, sometimes, rarely, other times not at all.
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
sudo sysctl -w net.inet6.ip6.use_tempaddr=0
sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf'
I doubt it given the variable frequency he describes. If it were OSX timing out addresses, he’d see a session drop every day or two rather than frequently sometimes. Owen
On 2/Oct/15 07:46, Doug McIntyre wrote:
I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX generates a new random IPv6 address, applies it to the interface, and then drops the old IPv6 addresses as they stale out. Sessions in use or not.
sudo sysctl -w net.inet6.ip6.use_tempaddr=0
sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf'
Interesting. Thanks, Doug. I just upgraded to El Capitan, so I'll see if there are any changes in that when I'm back in the office, and then look at your suggestion if not. Thanks. Mark.
participants (9)
-
Ca By -
David Hubbard -
Doug McIntyre -
Laszlo Hanyecz -
Mark Andrews -
Mark Tinka -
Owen DeLong -
Valdis.Kletnieks＠vt.edu -
voytek