search

dlenski / gp-saml-gui

Interactively authenticate to GlobalProtect VPNs that require SAML
GNU General Public License v3.0
305 stars 69 forks source link

gp-saml-gui doesnt works on last palo alto updates (cookie is not in headers) #51

Closed agutierrm closed 1 year ago

agutierrm commented 2 years ago

Hi there: I was using gp-saml-gui to connect to my University Global Protect Vpn site until yesterday.

The behaviour is like this: I run the script 

eval $(OPENSSL_CONF=~/ssl.conf gp-saml-gui --gateway --clientos=Windows vpn.mysite.com)

and, I can auth with my Microsoft Authenticator app on mobile and I see: Login succesful! But after that, nothing happens.

On the console, last message is: 

[PAGE   ] Finished loading page https://XXXXXX.es/SAML20/SP/ACS

After a lot of researching, and running gp-saml-gui with -x parameter, If I open the login window with other browser I see that the cookie is embedded on the webpage as a comment, and is not returned on the Http headers. I think that this is the root of the problem:

image

I don't know what is the version running on the Vpn appliance as it depends on other Department, but I know that it was updated since two days ago. Now that I know that this is the problem, when I get the "Login succesful" window I press F12 and I copy the prelogin cookie :-(. Its so slow but it works..

I write this post if anybody has the same problem...

dlenski commented 2 years ago

After a lot of researching, and running gp-saml-gui with -x parameter, If I open the login window with other browser I see that the cookie is embedded on the webpage as a comment, and is not returned on the Http headers. I think that this is the root of the problem:

In fact, all of the other GP SAML server's I've seen embed the saml-* and *-cookie values as both HTTP headers and comments.

I made gp-saml-gui use the cookies since it was easier and more reliable.

Perhaps we need to check both to be sufficiently robust? PRs to do this welcome.

I donk know what is the version running on the Vpn appliance as it depends on other Department, but I know that it was updated since two days ago.

I wouldn't be surprised if the omission of the HTTP header versions is a mistake, perhaps due to some middlebox that filters out unknown HTTP headers.

I also wouldn't be surprised it this potential issue is already known to PAN, and if they make their servers emit both, and clients parse both, for this reason.

ByteCommander commented 2 years ago

We noticed the same issue in our network since today, likely there has been an update to some component that causes the changed responses. I wrote the PR above to keep checking for headers first, but also parse the body otherwise as a fallback.

messiahUA commented 1 year ago

I faced this issue as well. It's already December, any plans to merge the fix?