On Thu, Jan 31, 2019 at 9:02 PM Andreas Weber <andy at josoansi.de> wrote: > > Hi Daniel, > > Am 31.01.2019 um 20:13 schrieb Daniel Lenski: > > This is an error that has been observed by many others in the past. I > > attempted to compile an exhaustive list? > > Thank you very much for the list. > > > I believe the latest theory is that this error has something to do > > with TNCC / host checker. I'm not able to reproduce it myself on > > either of the Juniper VPNs that I currently have access to, > > unfortunately. > > Is there something I can do to help? I never run fiddler for a MITM but > I can try with the pulse secure client if this would help. Yes, more traffic captures would certainly help. It's crucial to figure out what is *different* between the traffic from the official client and that sent by OpenConnect. Using mitmproxy with the script I reference in http://lists.infradead.org/pipermail/openconnect-devel/2018-September/005060.html is probably the easiest way to do it. There is a place in the authentication flow where the server sends the MD5 digest of its certificate to the client, and the official Juniper NC client will hang up if this hash doesn't match the cert of its peer; my script simply replaces it with the MITM's cert, so that it will continue. > Would running the official pulse secure client and capturing the traffic > would help? Yeah. You'll want to use an official client that speaks the older Juniper NC (Network Connect) protocol, rather than the newer Pulse protocol, because NC is what OpenConnect implements. Thanks, Dan
