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 amich...@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 <> techm...@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>> >> acco...@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 >> mmstig...@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 <>>> 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
>> vox-tech@lists.lugod.org
>> http://lists.lugod.org/mailman/listinfo/vox-tech
>>
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
