On Mon, Sep 3, 2018 at 2:00 AM, Andreas Gnau <andreas at gnau.info> wrote: > > Hello Daniel, > I am experiencing the same problem. Thanks for bringing this up to a wider audience and doing the research. I have done the same kind of research a few months ago and I came to the same conclusion that many encountered this, but no-one found a solution. Glad to. Unfortunately, I do not have access to a Juniper VPN that is susceptible to this error so I have no way to poke it with a sharp stick and test ideas on my own. > If I remember correctly, I have tried connecting with the same hostname as the Windows machine I usually connect to and it did not make a difference. Can you tell us more details about the Juniper VPN where you encountered this problem? Does it use any kind of "Host Checker" or "TNCC" trojan? > What would be the next steps to investigate this further? Will the Pulse Secure let me MITM the TLS-traffic to capture it to learn more? Yes, it *is* possible to MITM the TLS connection between the client and the server. There are probably multiple ways to do it: * Network Connect is Java based, so there's probably a way to do it using the Java SSL key logger: http://jsslkeylog.sourceforge.net * I've had success with MITMproxy v4.0.4 and the attached script, which logs all the raw decrypted TCP traffic, and also finds the "real" MD5 hash of the server certificate and replaces it with the hash of the MITM'ed certificate, since some Juniper VPNs use this as a way to verify that they're not being MITM'ed. You need a newish version of MITMproxy incorporating this pull request I submitted, which allows the script to access the MITM'ed certificate (https://github.com/mitmproxy/mitmproxy/pull/2018): mitmdump --scripts=jun_ssl_log2.py --tcp-hosts=juniper.server.company.com * MITM'ing the Juniper clients is a really, annoyingly fiddly process. Another avenue to explore, which will avoid diving into the MITM process, is to try doing the Juniper VPN login from the browser, and going through the browser/Java-based Host Checker. *After* completing the browser-based host check, is it possible to "steal" the DSID cookie from the browser and use it to connect with openconnect? Or do you still get the 0x08 error? openconnect --prot=nc juniper.server.company.com -C "DSID=cookie stolen from browser after completing host check" Dan
