Thanks Bill for the explanation! But I am not sure I fully understood your
answer: is the issue coming from openconnect, or from how the library guys
did setup the certificate? What is weird is that it used to work for a
while, and then not anymore. In the latter case, will asking the
#openconnect people help resolve the situation?



On Sat, Dec 17, 2016 at 12:27 AM, Bill Broadley <b...@broadley.org> wrote:

> > I hit the same error yesterday. Bill said the Library broke it somehow.
> > The 'Official' Pulse client is working on Linux. And someone I chatted
> > with yesterday had an interested SSH port forwarding method of VPN, if
> > you have access to a server on campus.
> The first time I tried it, I stopped by the openconnect irc channel and
> worked
> with (I think) the primary dev.  We tracked it down to a SSL problem,
> which I
> could even confirm with a browser.
> I reported that to the library, and they tweaked the SSL cert (it wasn't
> properly signed).
> I lobbied for them to support openconnect since it was compatible, a signed
> binary, 64 bit, and open source.  The pulse client seems like some orphaned
> juniper project that some 3rd party is trying to make some money off of.
> They
> haven't even recompiled for 64 bit since.  What's worse is that the binary
> includes an old SSL library with known exploits, turns out that you need a
> fairly new openssl library which actually emulates the broken behavior, but
> doesn't allow the exploit.
> Kinda sad that campus is standardizing on an orphaned insecure unsigned
> binary
> for such a critical piece of security infrastructure.
> In any case the #openconnect folks were really helpful, if you want to try
> to
> get it working again I suggest trying there.
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
vox-tech mailing list

Reply via email to