GP gateway expects client certificate, but gp_saml_gui.py "-c" option does not pass it to openconnect

[lvml]

Hi Dan, first of all thanks for the gp-saml-gui tool, which works for me to establish a VPN connection via a GlobalProtect gateway after an SAML authentication detour through login.microsoftonline.com.

But I had to apply a minor modification, as gp_saml_gui.py seems to use client certificates supplied with the -c option only for the TLS connections that it establishes itself - it does not pass the certificate to openconnect via openconnect's -c option:

+++ b/gp_saml_gui.py
@@ -336,6 +337,10 @@ def main(args = None):
     if args.user_agent:
         openconnect_args.insert(1, "--useragent="+args.user_agent)

+    if args.cert is not None:
+        openconnect_args.insert(1, args.cert[0])
+        openconnect_args.insert(1, "-c")
+
     openconnect_command = '''    echo {} |\n        sudo openconnect {}'''.format(
         quote(cv), " ".join(map(quote, openconnect_args)))

Above change may not be as generic as one might want it to be, but it worked for my case where the GP gateway expects me to present a valid client certificate.

BTW: While debugging this, I noticed that the output of print('''Launching OpenConnect with {}, equivalent to:\n{}''' ... is somewhat misleading when the openconnect conversation with the GP gateway expects some input from standard-in - using --passwd-on-stdin along with piped input the way suggested by the printed command line does not work then - while the direct invocation of openconnect by the gp_saml_gui.py script works just fine.

[dlenski]

But I had to apply a minor modification, as gp_saml_gui.py seems to use client certificates supplied with the -c option only for the TLS connections that it establishes itself - it does not pass the certificate to openconnect via openconnect's -c option:

Yes, that's a good catch.

Explanation of why this happened:

• Normally, gp-saml-gui takes care to specify equivalent options to openconnect as it uses for its own connections, e.g. --clientos Windows not only modifies the HTTPS requests sent by gp-saml-gui itself but also provides the --os=win argument to openconnect.
• However, I intentionally made the case of gp-saml-gui --cert different. That's because the client certificate should only be needed in the "authentication phase" of the GP VPN connection. Once the authcookie has been determined and OpenConnect is ready for the tunnel/transport phase, there should be no need for TLS certs.
• … but clearly, I didn't think this through sufficiently when I wrote the script: OpenConnect is still in the "authentication phase" when it's completing the SAML auth, as invoked by gp-saml-gui. So we do need to provide the --certificate/--sslkey args to it.

[dlenski]

Now I'm wondering if the webview may also need the client cert in some cases :thinking:. Probably not, because it's always hosted on a third-party domain in "real" GP VPNs, but perhaps we should include it for future-proofing.

[dlenski]

@lvml wrote:

BTW: While debugging this, I noticed that the output of print('''Launching OpenConnect with {}, equivalent to:\n{}''' ... is somewhat misleading when the openconnect conversation with the GP gateway expects some input from standard-in - using --passwd-on-stdin along with piped input the way suggested by the printed command line does not work then - while the direct invocation of openconnect by the gp_saml_gui.py script works just fine.

Hmmm. Can you show me a (redacted) example of this? What OS are you running on? What openconnect --version?