AW: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2

[Schütz Dominik]

Hi,

unfortunately I can't send the output of "-vv --dump-http-traffic" because it contains company-specific information.

I've tried it with Client Certificate and passphrase secured private key, but I get the same output as when I use a TPM2 key.
So I don't think it's the TPM2.

Nothing arrives at our Pulse Server (9.1R14) with Client Certificate.

If I do it without a Certificate, the realms selection comes up, even if I give a different Certificate (smart card), I get the realms selection and can even connect successfully.
 Could it be the format of the Client Certificate?

# Client Certificate with passphrase secured private key
dominik at host1:~$ sudo openconnect --script=/root/vpnc-script --certificate=/var/lib/802.1x/host1.pem --sslkey=/var/lib/802.1x/host1.key --protocol=pulse "https://vpn-gateway/linux"
Connected to xxx.xxx.xxx.xxx:443
Enter PEM pass phrase:
Using client certificate 'HOST1'
SSL negotiation with vpn-gateway
Connected to HTTPS on vpn-gateway with ciphersuite (TLS1.2)-(RSA)-(AES-128-GCM)
Got HTTP response: HTTP/1.1 101 Switching Protocols
Bad EAP-TTLS packet (len 93, left 0)
Failed to establish EAP-TTLS session
Failed to complete authentication
dominik at host1:~$ 

# Without Certificate
dominik at host1:~$ sudo openconnect --script=/root/vpnc-script --protocol=pulse "https://vpn-gateway/linux"
Connected to xxx.xxx.xxx.xxx:443
SSL negotiation with vpn-gateway
Connected to HTTPS on vpn-gateway with ciphersuite (TLS1.2)-(RSA)-(AES-128-GCM)
Got HTTP response: HTTP/1.1 101 Switching Protocols
Choose Pulse user realm:
Realm: [REALM_xxx_Productive|REALM_xxx_Limited_Initial_Network|REALM_xxx_Limited_Machine_Network]:REALM_xxx_Limited_Machine_Network
Choose Pulse user realm:
Authentication failure: Client certificate required
Failed to complete authentication
dominik at host1:~$ 

# With Smartcard Certificate
dominik at host1:~$ sudo openconnect --script=/root/vpnc-script --certificate="$(p11tool --provider /usr/local/lib/libcvP11.so --list-all-certs | grep -A 1 "Object 5:" | tail -n 1 | awk '{print $NF}')" --protocol=pulse "https://vpn-gateway/linux"
Connected to xxx.xxx.xxx.xxx:443
PIN required for Cryptovision SmartCard
Enter PIN:
Using client certificate 'Dominik'
SSL negotiation with vpn-gateway
Connected to HTTPS on vpn-gateway with ciphersuite (TLS1.2)-(RSA)-(AES-128-GCM)
Got HTTP response: HTTP/1.1 101 Switching Protocols
Choose Pulse user realm:
Realm: [REALM_xxx_Productive|REALM_xxx_Limited_Initial_Network|REALM_xxx_Limited_Machine_Network]:REALM_xxx_Limited_Machine_Network
Choose Pulse user realm:
Unexpected IF-T/TLS packet when expecting configuration.
Configured as xxx.xxx.xxx.xxx, with SSL connected and ESP in progress
Session authentication will expire at Thu May  5 05:01:24 2022

ESP session established with server


Regards,
Dominik

-----Ursprüngliche Nachricht-----
Von: David Woodhouse <dwmw2 at infradead.org> 
Gesendet: Mittwoch, 4. Mai 2022 12:49
An: Schütz Dominik <Dominik.Schuetz at esolutions.de>; openconnect-devel at lists.infradead.org
Betreff: Re: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2

On Wed, 2022-05-04 at 10:23 +0000, Schütz Dominik wrote:
> dominik at host1:~$ sudo openconnect --script=/root/vpnc-script --certificate=/var/lib/802.1x/host1.pem --sslkey=/usr/local/wlan/host1.key --protocol=pulse "https://vpn-gateway/linux"
> Connected to xxx.xxx.xxx.xxx:443
> Using client certificate 'HOST1'
> SSL negotiation with vpn-gateway
> Connected to HTTPS on vpn-gateway with ciphersuite 
> (TLS1.2)-(RSA)-(AES-128-GCM) Got HTTP response: HTTP/1.1 101 Switching 
> Protocols Bad EAP-TTLS packet (len 93, left 0) Failed to establish 
> EAP-TTLS session Failed to complete authentication dominik at host1:~$

I suspect that isn't really related to TPMv2 but actually affects all certificate authentication? Are you able to test with a certificate from a plain file? Probably doesn't even matter if it's a *valid* one since I don't think you're getting that far.

The Pulse protocol is kind of weird here. It tunnels a TLS negotiation
(EAP-TTLS) within multiple layers of binary protocols inside the original TLS connection to the server. Depending on the client version that we pretend to be, it might even attempt to tunnel EAP-TLS *within* EAP-TTLS, which is entirely bizarre.

Can you run with '-vv --dump-http-traffic' and show me the full session until it gets to that point please? Probably best to do that off-list.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6003 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220504/9e9d8628/attachment.p7s>