Re: AW: AW: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2
On Wed, 2022-05-04 at 18:26 +, Schütz Dominik wrote: > Thank you for the guidance :) > > I'll try to solve it myself first. I'll get back to you then. > You can use a MITM proxy like http://david.woodhou.se/proxy.go to watch all the TLS traffic; I found it really useful for Pulse. Note the 'myrawcopy' function has the ability to do a search/replace on the transferred data. Sometimes we've needed that because the server sends its own certificate fingerprint and the client may abort the connection if it doesn't match the *proxy's* cert. smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: AW: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2
On Wed, 2022-05-04 at 16:54 +, Schütz Dominik wrote: > unfortunately I can't send the output of "-vv --dump-http-traffic" > because it contains company-specific information. Fair enough, although that obviously makes it difficult to try to help. Without even seeing the final offending EAP-TTLS (or not?) packet that it didn't like, it's hard to even guess about what's happening. Note that a public-facing VPN server will be receiving hundreds or more likely thousands of *random* connection attempts per day. To reproduce this and have a chance of helping you, I wouldn't need to get any further than any of those random port scans do — I don't need a username, a password, or a certificate or anything like that; just the IP address that is receiving thousands of stray connections a day. But OK, if you're not comfortable with that, then take a look at that final packet and see what it is. Is it a *different* EAP type? Have they changed to EAP-TLS or something else? Does it change if you vary the user-agent you advertise (see the comments in the source about the way that changes things). Those are rhetorical questions, of course, intended to help guide you if you want to try to solve this on your own. I don't *actually* have any real insight into this other than having watched the Windows client attempt to connect through a MITM proxy, and trying to work out what the many levels of nested binary protocols actually were. smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2
On Wed, 2022-05-04 at 10:23 +, 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. smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
