IPv6 & IPv4 cookie validation
As a System Administrator, I would like cPanel to be able to monitor and detect IP changes between IPv4 and IPv6 so that users will not be logged out automatically when their IP is changed dynamically.
====================
Most routers (& ISPs) nowadays support both IPv4 and IPv6.
Some of my clients reported me that they are facing login issues (immediately logout) or they auto-logout to soon. (after a while)
cPanel and Webmail auto-logout very often because client IP is changed dynamically!
This is happening because randomly IPv4/6 is forwarded as client IP.
A client may log in with IPv4 and after a while the client IP that forwards to browser to be the IPv6!
This issue has to be solved before IPV6 support became mainstream to all servers.
Some solutions/suggestion
1) If a logged user with IPv4 comes up with IPv6 update the cookie with the IPv6 and the opposite.
So client logins with IP 10.10.10.10 and IPv6 are unknown, if has successful login and IPv6 detected (using same user agent and session-id), add the "IPv6 cookie"
2) Ajax request that monitors the client IP, if IP is changed from IPv4 to IPv6 (or the opposite) prevent logout
In other words, should be created a unique pair of valid IPv4 and IPv6
Some sites like whatismyipaddress.com can detect both IPs.
cPanel can do that too!
A temporary and bad solution is to turn off the IP validation Cookie.
PS: Loose option does not solve the issue
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
This is an interesting problem, and with growing take up of IPv6 resulting in more dual-stack environments, this problem is only going to grow. (Even for those of you on DS-Lite without a public IPv4 address.) It also impacts end users in the Webmail portal so this isn't something we can just brush aside as an understood quirk for technical folks to endure. This is a usability problem.
This appears to be because web browsers will hot swap between using IPv6 and IPv4 according to network reliability, but as you may already know, Google Chrome in particular has a very low tolerance when deciding to switch. (The tiniest blip in connectivity even for a fraction of a moment can cause this.) I have full dual stack both at home and at work, but typically use Firefox and rarely have this problem.
WHM's "Cookie IP Validation" setting on either strict or loose switching between IPv6 and IPv4 cannot possibly match the same or even a subnet/24, so I can somewhat appreciate the difficulty WHM has here. It's also unreasonable to disable this security entirely due to cookie theft etc etc.
Both of zstergios' suggestions involve monitoring IP address changes are interesting however doing this after a session is established would defeat the purpose of loose or strict cookie security entirely, because if I stole the cookie I could then just send WHM a HTTP request with the opposite IP version and cause it to accept me as a stack switch. WHM would have no way of knowing who I really was. Binding with user agent can make it a little harder to fool but nothing beyond the scope of a pro.
Solving this would need to be done at the authentication stage to conform with cookie security whereby WHM must gather both versions of IP address upfront.
A possible long term solution would be at the point of successful login the client should be told (in the response payload) what the public facing IPv6 and IPv4 addresses are of the WHM server, along with a TOTP. Then the client can make AJAX requests to each of those to confirm their valid login, thereby WHM would know both the IPv6 and IPv4 public address of the user and tag their session cookie with these.
Use of a TOTP could help ensure this binding only works by the real user shortly after the login is successful though I'm sure someone smarter than me on the topic can think of a more robust answer should the TOTP be stolen, though it'd only be sent from WHM to client once over SSL/TLS, so if it does get stolen I think the client would have bigger problems much broader than their WHM session anyway. (The token may not even need to be time limited as it'd already be session specific.)
This may not be practical for SSL/TLS unless cPanel's CA include the server's IP addresses in the SAN properties. IPv4 should be fine because we bind our license to one of these already, but may need to start doing this with an IPv6 address too. (Not practical for servers using SLAAC but servers should be using static IP addresses.) Otherwise WHM servers would need "ipv6." and "ipv4." subdomains on its FQDN (and also as part of the certificate SAN), which adds an extra layer of administration for WHM customers, and may not always be possible if the server's primary FQDN is outside their control (e.g. autogenerated/issued by an ISP).
This is an interesting problem, and with growing take up of IPv6 resulting in more dual-stack environments, this problem is only going to grow. (Even for those of you on DS-Lite without a public IPv4 address.) It also impacts end users in the Webmail portal so this isn't something we can just brush aside as an understood quirk for technical folks to endure. This is a usability problem.
This appears to be because web browsers will hot swap between using IPv6 and IPv4 according to network reliability, but as you may already know, Google Chrome in particular has a very low tolerance when deciding to switch. (The tiniest blip in connectivity even for a fraction of a moment can cause this.) I have full dual stack both at home and at work, but typically use Firefox and rarely have this problem.
WHM's "Cookie IP Validation" setting on either strict or loose switching between IPv6 and IPv4 cannot possibly match the same or even a subnet/24, so I can somewhat appreciate the difficulty WHM has here. It's also unreasonable to disable this security entirely due to cookie theft etc etc.
Both of zstergios' suggestions involve monitoring IP address changes are interesting however doing this after a session is established would defeat the purpose of loose or strict cookie security entirely, because if I stole the cookie I could then just send WHM a HTTP request with the opposite IP version and cause it to accept me as a stack switch. WHM would have no way of knowing who I really was. Binding with user agent can make it a little harder to fool but nothing beyond the scope of a pro.
Solving this would need to be done at the authentication stage to conform with cookie security whereby WHM must gather both versions of IP address upfront.
A possible long term solution would be at the point of successful login the client should be told (in the response payload) what the public facing IPv6 and IPv4 addresses are of the WHM server, along with a TOTP. Then the client can make AJAX requests to each of those to confirm their valid login, thereby WHM would know both the IPv6 and IPv4 public address of the user and tag their session cookie with these.
Use of a TOTP could help ensure this binding only works by the real user shortly after the login is successful though I'm sure someone smarter than me on the topic can think of a more robust answer should the TOTP be stolen, though it'd only be sent from WHM to client once over SSL/TLS, so if it does get stolen I think the client would have bigger problems much broader than their WHM session anyway. (The token may not even need to be time limited as it'd already be session specific.)
This may not be practical for SSL/TLS unless cPanel's CA include the server's IP addresses in the SAN properties. IPv4 should be fine because we bind our license to one of these already, but may need to start doing this with an IPv6 address too. (Not practical for servers using SLAAC but servers should be using static IP addresses.) Otherwise WHM servers would need "ipv6." and "ipv4." subdomains on its FQDN (and also as part of the certificate SAN), which adds an extra layer of administration for WHM customers, and may not always be possible if the server's primary FQDN is outside their control (e.g. autogenerated/issued by an ISP).
Replies have been locked on this page!