On Thu, 2019-04-18 at 11:27 -0400, Daniel Lenski wrote: > On Tue, Apr 16, 2019 at 1:20 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > > Hi. > > > SonicWall SMA is an SSL/DTLS based VPN. Is it feasible to add support > > > for it to openconnect, since it might be similar to Cisco AnyConnect > > > and Pulse solutions? > > > > > > Yeah, shouldn't be that hard. Stick a MITM proxy between client and server > > so we can see what happens over the SSL connection, and we can take it > > from there. > > A few more thoughts… > > 1. When MITM'ing a VPN protocol, it's very likely that you find that > the official client/server send and verify their TLS certificates in > some way outside the normal TLS handshake mechanism. > > For example, Juniper NC protocol server send an MD5 hash of their own > certificates to the official client, which will abruptly terminate the > connection if it's being run through a MITM proxy, which of course > replaces the certificate. In order to work around this, you'll need to > write a script for mitmproxy to find the hash of the "real" server > cert and replace it with the hash of the MITM cert. This is much > easier to do in mitmproxy v3.0+, due to a pull-request I submitted > which exposes the MITM cert to a script > (https://github.com/mitmproxy/mitmproxy/pull/2018). Junos Pulse (which we should support because it supports IPv6 and at some point they're doing to stop supporting the legacy NC protocol) has something similar. Hence the hack checking for cert_md5 in http://david.woodhou.se/proxy.go It's scary how often they are still using MD5.... We really ought to do IPSec support so we can obsolete vpnc. Our ESP support for AES-CBC-HMAC-SHA1 is *really* fast now on the 'perfhacks' branch... :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
