[vox-tech] UC Davis VPN using openconnect

T. Mark techmark at tutanota.de
Sat Jan 21 15:21:23 PST 2017


Yeah, it's light years ahead of Winbloze in the general sense-- but much depends on getting current updates obviously.  As the prevalence of the Linux kernel has shot up with the onset of the worrying "IoT" for example, script kiddies who once relied on ubiquitous Win worms & viruses are now utilising known Linux exploits as well.  Listening to the BSD podcast, though way nerdier / more technical than something like LinuxVoice, I notice how they enjoy taking jabs at Linux for being a sprawling mess &  hence necessarily less secure.
And I actually just remembered something I'd meant to include in that last response..   maybe you don't need it now, but if you're ever stuck falling back on the unencrypted connection, one free VPN equivalent you can try is what now is part of the regular Opera browser..  I was trying this when it came in the Developers' Release only, but I guess they got all the kinks out.  Usually wouldn't plug a non-OpenSource app like this, but at least they have a solid Linux version available.  Of course, it only applies its "VPN" to the Opera browsing..  I'm curious as to its inner workings actually, & whether anyone has taken a close look whether it's "leaking" anything in the clear, and whether an equivalent to "torify" could be written so as to move all of one's traffic thru the encryption vs just the web browsing..

Good to hear you sorted your issue though!


20. Jan 2017 12:44 by amichuda at ucdavis.edu:


>
> Sorry for the late reply. It's a shame that using it on openconnect doesn't work, but I was able to get the Pulse client working. My problem is that I'm using Arch Linux but was unable to get it working even after I converted the .deb file. But finally tweaked the script and it seems to be working now...
> Thank you for the help and insight! Hopefully, openconnect will work on it at some point... seems a bit sad that we have to use something inferior, especially in the security department, which Linux (with my very limited knowledge of it) is supposed to be stellar at.
> On Tue, Jan 17, 2017 at 8:17 PM T. Mark <> techmark at tutanota.de> > wrote:
>
>>           
>>
>> Just wondering if you're still looking for a solution..  you might consider a 3rd party VPN.  (And just use their "ucd-guest" unencrypted connection to get to it.)  Quite awhile back when I didnt want creepy strangers even seeing the fact that I was connecting to my stockbroker (over public hotspots which was all I had access to) I resorted to a provider stated as trustworthy by a long, longtime radio show.  (I'll refrain from naming them in case doing so might result in a demand spike with resulting price increase, as I might one day be able to afford it again.)  Something like $5/mo for the most minimal service, SSH tunnelling,  which I'd use via
>>
>>    ssh -L 5000:>> 127.0.0.1:1080>>  >> account at assignedsshserver.io
>>
>> or so.. the full-fledged VPN service is a bit more.  Hit me up off-list for their url, and if anyone else has thoughts on good services (good call on digitalocean btw-- used by at least a couple podcasts I know of) let me/us know, by all means.
>>
>> --
>> https://twitter.com/linuxusergroup
>>
>> 20. Dec 2016 21:43 by >> mmstigler at ucdavis.edu>> :
>>
>>
>>> Hi 
>>>
>>> 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?
>>>
>>> Thanks!!
>>>
>>> Matthieu
>>>
>>> On Sat, Dec 17, 2016 at 12:27 AM, Bill Broadley <>>> bill at 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 at lists.lugod.org
>>>> http://lists.lugod.org/mailman/listinfo/vox-tech
>>>>
>>>
>>>
>>   >> _______________________________________________
>> vox-tech mailing list
>> vox-tech at lists.lugod.org
>> http://lists.lugod.org/mailman/listinfo/vox-tech
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lugod.org/pipermail/vox-tech/attachments/20170122/7add608b/attachment.html>


More information about the vox-tech mailing list