What is session roaming?
Session roaming is a user role-based VPN tunneling option that when enabled, allows the Pulse Connect Secure gateway to accept a session cookie from an IP address other than the IP address that the user initially signed into the Pulse Connect Secure gateway from.
By default, session roaming is disabled and the Pulse Connect Secure gateway will not accept a session cookie from any IP address other than the one the user signed in from. If the user’s IP address changes during their session, the Pulse Connect Secure gateway will terminate the user’s session, forcing them to sign-in again.
When session roaming is enabled, a user can initiate their secure session from one IP address and if their IP address changes during the session, the Pulse Connect Secure gateway will accept the session cookie and the user will remain signed in.
Note: The Pulse Connect Secure gateway provides configuration options to limit the allowed IP address range to be in the same subnet as the IP address the user signed in with, or can be configured to allow any IP address.
What are the security aspects around session roaming?
Once a user initiates a session with the Pulse Connect Secure gateway, a session cookie is used to secure the session. A secure cookie is stored in the browser and the browser will only present the cookie to other servers via the SSL connection to the Pulse Connect Secure gateway.
For a session to remain secure with session roaming enabled, the session cookie must remain secure. If the session cookie can be stolen then session hijacking could take place. As long as the session cookie is not compromised and cannot be stolen, then a session roaming is as secure as any other SSL connection.
How can session roaming be exploited or become vulnerable to an attack?
If, at any time during a secure session, the session cookies are stolen, an attacker could hijack the session to the Pulse Connect Secure gateway, however, there are only a few ways in which an attacker could gain access to the session cookie:
• By gaining physical access to an end-user’s device, an attacker could then run a traffic monitoring tool locally such as httpwatch, httpfox, or burp proxy, to gain visibility of the traffic going across the secure tunnel which would also reveal the cookies.
• By exploiting an unknown vulnerability in SSL.
• By gaining access to the cookies by launching a DNS attack. This would only succeed if the user ignored the certificate warnings which would be generated by the browser.
• By launching a man-in-the-middle attack. Again, this would only succeed if the user ignored the certificate warning that would be generated by the browser.