VaRA-Tool-Suite VS openconnect

I tried to understand the significance of this (parent maybe implied that they reused a completely fictitious identity generated by some test code), and I think this is benign.

That project just includes some metadata about a bunch of sample projects, and it links directly to a mirror of the xz project itself:

https://github.com/se-sic/VaRA-Tool-Suite/blob/982bf9b9cbf64...

I assume it downloads the project, examines the git history, and the test then ensures that the correct author name and email addresses are recognized.

(that said, I haven't checked the rest of the project, so I don't know if the code from xz is then subsequently built, and or if this other project could use that in an unsafe manner)

A lot of software (including https://gitlab.com/openconnect/openconnect of which I'm a maintainer) uses libxml2, which in turn transitively links to libzma, using it to load and store compressed XML.

I'm not *too* worried about OpenConnect given that we use `libxml2` only to read and parse uncompressed XML…

But I am wondering if there has been any statement from libxml2 devs (they're under the GNOME umbrella) about potential risks to libxml2 and its users.

From the article:

> Ubiquitous presence of HTTPS allows you to pass your data through very restrictive middle boxes!

This is, in fact, why all — or nearly all — proprietary VPN protocols (so-called "SSL VPNs") implement a mode that initiates a tunnel via HTTPS, at least as a fallback if not as the primary mode of operation: precisely in order to have a mode of operation that works with almost any connection to the global Internet.

I'm one of the main developers of https://gitlab.com/openconnect/openconnect, which implements many such protocols, and wrote https://github.com/dlenski/what-vpn, which sniffs or identifies even more flavors of TLS-based VPN servers.

Found the solution: It's as simple, as changing the user agent with --useragent=AnyConnect. This is ridiculous. https://gitlab.com/openconnect/openconnect/-/issues/544

Source: I am one of the lead developers of OpenConnect, a popular open-source client for many corporate VPNs, and have done all of the above.

Be careful you're not using an illicit fork. https://gitlab.com/openconnect/openconnect

I personally have an openconnect server, and I patched their client to let me specify the SNI, (it's set to the server's hostname by default (https://gitlab.com/openconnect/openconnect/-/blob/master/gnutls.c#L2366), but it's optional in the anyconnect protocol spec)

Thank you, trying openconnect for multiple hours, but cannot auth, created issue about that https://gitlab.com/openconnect/openconnect/-/issues/446

If this is for anything other than AnyConnect I feel like you're better off with a t4g.nano running OpenVPN. If it's AnyConnect, you can run OpenConnect.

I had similar issue with Fortinet VPN. Try using something like https://gitlab.com/openconnect/openconnect. Run this from terminal to connect to VPN when needed. If this doesn't work search for global protect open source and there are other options.