Attempt to spawn browser on Windows

Fixes: #553
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Build COPR package with xdg-open

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Switch from egrep to 'grep -E'

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Consolidate browser spawn functions

These were almost identical except that the one in main.c would allow the
browser to be overridden. Combine them, as it's only going to end up with
more duplication if we manage to add Windows support.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Silence warnings about type aliasing when resolving wintun DLL functions

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Make GCC shut up about unknown pragmas in wintun.h

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix stray (null) in URL path after Pulse authentication

When using 'openconnect --authenticate' with a Pulse server, if the urlpath
is empty we append '(null)' to the URL instead of appending nothing as we
should. This also affects NetworkManager-openconnect, since it started to
use openconnect_get_connect_url() in v1.2.8 (commit 911151fc966790c).

Fixes: ec6c0caed28e ("Add openconnect_get_connect_url(), use it in --authenticate output")
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Document that OpenConnect calculates TOTP/HOTP codes on its own

OpenConnect has calculated TOTP/HOTP token codes without liboath since 554454bf;
we should document that.

Alo:

- Remove the unnecessary downloading and building of liboath from 'android/Makefile'.
- Remove obsolete references to liboath in comments and error messages
- Fix man page formatting surrounding token mode

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Add os-tcp-mtu utility

Makes a host connection to an arbitrary TCP/IP host:port, and checks the
estimates of the MTU/MSS provided by various getsockopt() calls, just as
OpenConnect uses in calculate_mtu().

TODO:

1. Implement a working os-tcp-mtu for Windows, and build that too.
2. Use https://github.com/morristech/android-ifaddrs as
   as a drop-in replacement for `getifaddrs(3)` on Android

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Merge branch 'softhsm' into 'master'

OBS: softhsm is not available in SUSE

See merge request openconnect/openconnect!472

OBS: softhsm is not available in SUSE

Signed-off-by: Luca Boccassi <bluca@debian.org>

Build release builds as snapshots for COPR

We can't have a GPG signature on a tarball we create ourselves.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Tag version 9.10

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix use-after-free in realloc_inplace()

In file included from auth-globalprotect.c:20:
auth-globalprotect.c: In function 'parse_prelogin_xml':
openconnect-internal.h:1180:17: warning: pointer '__realloc_old_176' may be used after 'realloc' [-Wuse-after-free]
 1180 |                 free(__realloc_old);                    \
      |                 ^~~~~~~~~~~~~~~~~~~
openconnect-internal.h:1178:13: note: call to 'realloc' here
 1178 |         p = realloc(p, size);                           \
      |             ^~~~~~~~~~~~~~~~

This is a true warning. The second argument to the realloc_inplace()
macro includes a strlen() of the first. Evaluate it first, before the
attempt to realloc().

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Resync translations with sources

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Rework ESP probe retries

We weren't attempting to resend ESP probes at all, except at the retry
interval of about a minute. In a lossy network, or perhaps when the
server is slow to configure its end and start accepting ESP probes,
this meant that users sometimes saw the ESP failing to establish for
a whole minute (or multiple thereof).

Drop the loops in the protocol-specific udp_send_probes() functions
which were a primitive attempt to handle packet loss, and instead
deliberately send one probe a second for five seconds, before giving
up for the remainder of the dtls_attempt_period.

Fix up the reconnect handling with vpninfo->dtls_need_reconnect while
we're at it; it looks like that would just cause us to keep sending
probes and the flag would never be cleared.

Fixes: #601
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

pulsesecure.net → ivanti.com

We should also rename Pulse Connect Secure to Ivanti Connect Secure
at some point. For now, even the Ivanti web site uses both, perhaps
we should wait before we switch Pulse to Ivanti.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Merge branch 'hipreport' into 'master'

Add MacOS support to the hipreport

See merge request openconnect/openconnect!471

Update changelog

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Add MacOS support to the hipreport

DRL tweaked:

1. Fixed indentation
2. Populated datemon/dateday/dateyear attributes
3. If reporting MacOS, but not actually running on MacOS, then fall back to
   reporting OS version 10.16.0 (see https://ss64.com/osx/sw_vers.html)

Signed-off-by: Alex Samorukov <samm@os2.kiev.ua>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Attempt to handle Legacy IP frames in the middle of oNCP config

Is there no end to the stupidity of these proprietary protocols?

So... TCP provides you with a byte stream. Forget IP packets underneath;
TCP hides all that for you, and all there is is a hosepipe of bytes.

On top of that, TLS provides 'records' of up to 16KiB, encrypting each
record and sending it down the TCP pipe, then collecting the whole record
on the receiving end, decrypting it and providing it to the user. Mostly,
nobody cares much about TLS records, and they choose to treat TLS just as
a byte stream too.

The Juniper oNCP protocol adds its own layers on top of that TLS byte
stream. First there's the thing which OpenConnect has been calling the
'SSL record', which has a little-endian 16-bit length followed by that
many bytes of data. Then another 16-bit length and that much data, etc.
Those "SSL records" may be correlated with the TLS records, or maybe I
just chose a really stupid name back in 2015 when I first did this. Who
knows, who cares, since we mostly ignore TLS records anyway.

On top of *this* there is an actual packet-based protocol which may
perhaps be called something like KMP. There's a 20-byte header, most of
which we don't understand but it has a type field and a length that we
do understand. This one is big-endian, unlike the layer below it The
type 300 is data, while type 301 is the configuration we get when we
first connect.

Within the KMP300 packets there can be multiple actual IP packets; we
need to look at the length field of the IP packet and split them apart
for delivering them to the tun device. There is no apparent relationship
between the KMP300 packets and the SSL record below; you can have many
KMP300 packets within an SSL record, and the SSL record boundary can
fall *within* a KMP300 packet. So the SSL records have, thus far, just
been a pointless nuisance which means we occasionally have to drop a
2-byte length field from what would otherwise just be treated as a
simple byte stream of data which packetises itself.

Thus far.

If you have a large enough KMP301 config frame (for example, if you have
lots of split include routes), it might get sent in more than one SSL
record. So OpenConnect has code to keep reading those records until the
KMP301 frame is complete. And it *did* assume that the SSL record would
end at the end of the KMP301 frame, since we haven't even finished the
negotiation at this point; we have to send a KMP303 frame back to the
server with our idea of the MTU.

Today we have learned that the server might throw a KMP300 packet with
an IP frame into the *middle* between the two consecutive records that
comprise the KMP301 config frame:
https://gitlab.com/openconnect/openconnect/-/issues/562#note_1358466466

It's not clear if this will only ever be *one* IP packet, or if it can
end up being lots of packets and split across multiple SSL records. In
the example I've seen, it was a *unicast* packet for the VPN client
address.

Attempt to work around the case we've already seen, by discarding a
continuation that looks like a KMP300 with precisely one Legacy IP
packet in it. We *are* also assuming that we at least get the *start*
of the KMP301 config frame first.

Perhaps we'll end up having to keep a list of the records we receive,
then attempt to piece them together more flexibly. But this should
suffice for now.

Fixes: #562
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix EINTR handling for select() on cmd_fd

KDE plasma-nm was failing with external browser authentication, reporting
'Socket connect cancelled' immediately after spawning the browser command.

This was caused by the SIGCHLD which kded handles (instead of it being
ignored as in the standalone openconnect process). Thus, the select()
call returns with EINTR, and the fd sets are not changed.

So when check_cmd_fd(vpninfo, &rd_set) is called, it looks like the cmd_fd
was readable. And since plasma-nm uses the legacy cancel_fd setup, the
mere fact of it being *readable* is enough to set vpninfo->got_cancel_cmd.

Instead of forging ahead and interpreting the fd_sets after select()
returns with EINTR, loop and go straight back into select() instead.

For signals like SIGINT from Ctrl-C, we *handle* those and deliver the
cancel command anyway, so we don't depend on the EINTR return in that
case.

cf. https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/merge_requests/49#note_1725203

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

More specific error message with proposed workaround for Pulse EAP-TLS requests

See https://gitlab.com/openconnect/openconnect/-/merge_requests/414#note_1149887354
for discussion of the apparent layering insanity that's going on in this
corner case.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Report unexpected Pulse EAP requests more explicitly

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Add --no-external-auth option, and follow it for Cisco protocol

This option is intended to prevent OpenConnect from advertising to the
server that it supports any kind of authentication mode that requires an
external browser.  Some servers will force the client to use such an
authentication mode if the client advertises it, but fallback to a
"scriptable" authentication mode if the client doesn't appear to support it.
See https://gitlab.com/openconnect/openconnect/-/issues/470#note_1028595620
for an example.

This option is only implemented here for the Cisco protocol, in which case
it causes OpenConnect not to advertise the 'single-sign-on-v2' or
'single-sign-on-external-browser' auth-methods.

I have verified on one Cisco VPN that this works as intended, as has one
other user (see
https://gitlab.com/openconnect/openconnect/-/issues/470#note_1045509425).

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Fix --server vs. positional argument handling

If we have a --server argument, we shouldn't expect to find a positional
argument at argv[optind]. We mostly got this right, except that we still
called config_lookup_host() with argv[optind] even when --server was
given.

The only thing that saved us from dying with a strcmp() on NULL was
the fact that the loop over the XML elements is using the fact that
vpninfo->hostname gets set as its terminating condition, so it never
got that far.

Fix that, because it's icky. And make the --server argument work for
XML config lookups too.

Fixes: a2fd6f4f2e8a ("New option to define server name in config file")
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Set SOCK_CLOEXEC on listening socket for Cisco external browser support

Not entirely sure, but it seems to be accused of causing a hang in
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/merge_requests/49#note_1720281
and regardless of whether that's the case or not, we should be consistent
about using {SOCK,O}_CLOEXEC whenever we can.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Resync translations with sources

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix installer suffix handling

Generate $(INSTALLER_PREFIX) automatically instead of having to pass it
in explicitly, and then the COPR builds should probably work again.

It's kind of awful that we can't get the real version string in the
Makefile so we don't actually know what the true target name is, but
we can live with it.

Fixes: a2dbef082512 ("Unique names for each variant openconnect-installer.exe")
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Revert "html.py is a Python 3 script"

This reverts commit 98423ba715de07cbbcea4070b44984074d83e6f8.

It breaks the build on distros with only Python 2, like EPEL7.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix F5 build with json-parser 1.1.0

The json_object_entry structure doesn't exist in json-parser 1.1.0, which
is the latest release and what's shipped by distributions. It's an
anonymous struct as part of the union there, so reference its 'name'
and 'value' as separate pointers.

This should fix the COPR package builds which have been failing.

Fixes: 514cacaff59f ("Parse JSON login forms for F5")
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Redirect stdout to stderr when spawning external browser

When running in --authenticate mode we don't want to pollute stdout. So
just redirect it to stderr instead.

Chrome is known to be noisy to stdout when it's reusing an existing
session, and we've already patched NetworkManager to do the same because
it also suffers from stdout pollution.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Update docs on running as non-root

Make the use of the --authenticate option clearer, and why you might want
it with SAML authentication.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix missing TX stats on vhost

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Update translations from GNOME

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Bump default queue length to 32

Some users are reporting that transfer speeds with the default queue
length of 10 packets are poor. Increasing to 32 shouldn't be causing
too much bufferbloat, and appears to resolve the issue.

There's more to be understood here; OpenConnect is in the middle of
multiple other queues for the inbound and outbound traffic paths, and
we should never be starving any of them. And for a bunch of protocols
OpenConnect isn't even honouring the queue length. For *incoming* as
a VPN client, that's probably a bad idea anyway; if packets have made
it all the way across the Internet and the wet piece of string that
connects our client, then we should make sure we accept them and don't
let them build up in the UDP socket receive buffers to the point where
the kernel drops them.

My previous testing of this was in 2008, and was focused on performance
across a local 1GbE connection, which will behave differently.

This change will enable vhost-net by default. That does also help, but
isn't the only factor. And it doesn't help much until the queue length
is higher anyway.

See https://gitlab.com/openconnect/openconnect/-/issues/582 for
further discussion.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Update translations from GNOME

[ DL: re-fixed inconsistent line endings in po/ug.po; see
https://gitlab.com/openconnect/openconnect/-/commit/682553ecbdd9d159e358e190f6f6009f2e2c9864
for where these were previously fixed, and
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/merge_requests/54
for MR to fix upstream ]

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Fix Solaris build

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Fix mixed line endings

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Bugfix Y2038 for F5 authentication timestamp

This good recent article on Y2038
(https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit) reminded me to look for
Unix-epoch integer timestamps that are <64 bits in OpenConnect.

This is the only one I found.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Tell Apple users not to use '-i tunX', but '-i utunX' instead.

Per discussion in https://gitlab.com/openconnect/openconnect/-/issues/18#note_953145553,
the BSD "tun" devices have been obsolete for a long time on Mac OS; "utun"
needs to be used instead on modern versions.

However, many users still find suggestions to use `--interface tunX`
floating around the web, and try them.  The resulting error message from
OpenConnect is somewhat confusing:

    Cannot open '/dev/tunX': Invalid argument
    Set up tun device failed

Perhaps we could improve the logic to precisely detect whether or not the OS
wants us to use "tun" or "utun", but that would require a contribution by
someone who understands and cares about Mac OS.  In the absence of that, we
can simply add a warning to Mac OS users who attempt to use "tun", telling them
that it's probably wrong.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Update docs related to vpnc-script, platform, Trojans

We've long since had "native/emulated" CSD, but we still need Windows
support.

References to vpnc, and its bundled vpnc-script, are quite obsolete.

Add a wee little plug for vpn-slice as an alternative vpnc-script (😬).

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Small additions to changelog before release

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Merge branch 'Pulse_unstupid_ESP' into 'master'

IPv6-related improvements for Pulse

See merge request openconnect/openconnect!414

Document the potential need for an EAP-TLS-within-EAP-TTLS workaround for Pulse

See https://gitlab.com/openconnect/openconnect/-/merge_requests/414#note_1149887354
for a more thorough description of this problem by dwmw.

He commented about it in the source code very early on in the development of
the Pulse protocol support, specifically in
https://gitlab.com/openconnect/openconnect/commit/3fb7645608e49c875c20f55352990c7c883bbf96.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Pulse needs an 'official' version string in IF/T-T establishment to support IPv6

According to end-user testing in
https://gitlab.com/openconnect/openconnect/-/issues/506#note_1145946165 and
https://gitlab.com/openconnect/openconnect/-/issues/506#note_1146848739,
recent Pulse servers will not send correct IPv6 settings, or simply will not
enable IPv6 traffic, unless the client version string sent in the IF/T
session establishment begins with "Pulse-Secure/" followed by a digit >=8.

From Ivanti/Pulse documentation at
https://help.ivanti.com/ps/help/en_US/PCS/9.1R14/ag/network_n_host_admin.htm#network_and_host_administration_1399867268_681155:

> Only the Pulse client supports IPv6.

> Ivanti Connect Secure release 8.0 and later supports Pulse client access
> to the IPv6 corporate network using VPN Tunneling Connection Profile
> features.

In order to enable IPv6 support, while not misinforming the server about its
identity to an unnecessary disagree, OpenConnect should therefore include an
official-looking prefix ("Pulse-Secure/9.0.3.1667 " for now) in front of its
default user-agent string.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Newer Pulse servers can disable their ESP protocol layering malpractice

See b4f50f8bd5da7e6ac926ddd5095501edbc204cd0 for the way that the Pulse ESP
tunnel is mangled.  In brief, if the Pulse ESP tunnel is running over IPvX,
then it will only transport tunnelled packets of address family IPvX;
tunnelled packets of IPvY must go over the TLS/TCP tunnel.

In addition to being a complete inversion of the abstraction of a protocol
with independent layers:

- This results in poor performance for tunnelled IPvY packets (TCP-over-TCP)
- Our original implementation of this caused a regression for the
  Juniper/NC ESP tunnel (fixed in 3d1ec6e0a126d4b9fdd18473558cf816d2045b76).

As reported in http://lists.infradead.org/pipermail/openconnect-devel/2020-October/004934.html
and https://gitlab.com/openconnect/openconnect/-/issues/506, newer Pulse
servers starting with 9.1R9 can apparently use the ESP tunnel in a sane way,
if the administrator sets a flag labelled "Use ESP tunnel for 6in4 and 4in6
traffic".

OpenConnect should try to coax the server to use this saner tunnel setup
if possible.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Add FTM-push token mode for Fortinet

If the server sends a "tokeninfo-style" 2FA request (`ret=N,…,tokeninfo=…`)
with the special value `tokeninfo=ftm_push`, then it means that it
can (optionally!) use mobile-device "push"-based authentication instead of
having the user enter a token code.

If (and only if) the user leaves the token code blank, we must (1) remove
`magic` from the response and (2) add `ftmpush=1`, in order to trigger the
correct response.

This also adds a "type_2fa=ftmpush" mode to our fake Fortinet server, and
simulates this option in our tests.

Thanks to Ivan Futivić for the very useful and detailed report in
https://gitlab.com/openconnect/openconnect/-/issues/555#note_1239886436.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Update .mailmap

Include full names of a few recent contributors.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Merge branch 'tap_wintun' into 'master'

Remove TAP-Windows driver from installer, and update docs to reference Wintun's default inclusion

See merge request openconnect/openconnect!427

Use the timeout command in csd-wrapper.sh

The timeout command (from coreutils) can replace the more complex
job-control-based approach which we current use to limit the execution time
of the Trojan binary (`cstub`).

Signed-off-by: Andy Teijelo Pérez <ateijelo@gmail.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Bundled Cisco CSD wrapper script only works on GNU/Linux on Intel x86/x86_64 processors

See discussion at
https://gitlab.com/openconnect/openconnect/-/merge_requests/455#note_1275204407.

It appears that wrapper scripts for MacOS (aka Darwin) have been written,
but would need testing in order to integrate into our repository.  See
https://gist.github.com/asarkar/fb4452a4abdf9e4a9752a7d55d2cdc93.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Cherry-pick several one-line cleanup MRs

Closes https://gitlab.com/openconnect/openconnect/-/merge_requests/444,
https://gitlab.com/openconnect/openconnect/-/merge_requests/447, and
https://gitlab.com/openconnect/openconnect/-/merge_requests/454

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Make it clearer that the preferred driver is Wintun

We continue to load TAP-Windows preferentially, if it is installed.

However, we always install Wintun as part of the OpenConnect installer, and
do *not* always install TAP-Windows.  If users want to use TAP-Windows with
OpenConnect, they need to install it manually.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Remove TAP-Windows driver from installer, and update docs to reference Wintun's default inclusion

Re-apply 8c1d2de0.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

GnuTLS: Add UNSAFE_RENEGOTIATION to allow-insecure-crypto

When `--allow-insecure-crypto` is specified, we should explicitly enable
unsafe/legacy TLS renegotiation.

Recent distributions and library versions disable unsafe/legacy TLS
renegotiation by default, because it is vulnerable to a MITM-like attack
(see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555).

However, many older Cisco servers don't appear to be able to cope *without*
unsafe/legacy TLS renegotiation (see
https://gitlab.com/openconnect/openconnect/-/issues/558 for an example).

We already made the equivalent change for OpenSSL in 2021, back in
https://gitlab.com/openconnect/openconnect/commit/c8dcf10cb9bd63c3148922c42b9c47392c89fe9d.
Because of that partial change, OpenConnect+OpenSSL has been able to connect
to Cisco servers that OpenConnect+GnuTLS *can't* connect to.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Add a more modern LIMITATIONS section to man page

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Remove obsolete LIMITATIONS from man page

This might have been an issue 10 years earlier, but nowadays I doubt
the script from vpnc 0.5.3 would be used instead of vpnc-scripts.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Deprecate option --juniper, suggest --protocol=nc instead

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Fortinet: send dual_stack parameter to support IPv6 and Legacy IP simultaneously

Fixes https://gitlab.com/openconnect/openconnect/-/issues/568

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Add openconnect_set_sni API function and Java setSNI() wrapper

The `--sni` command-line option was added in
https://gitlab.com/openconnect/openconnect/-/merge_requests/297, in order to
experiment with domain fronting.

It seems to have proven useful for many users in Iran (see
https://gitlab.com/openconnect/openconnect/-/merge_requests?label_name[]=Damet%20Garm),
so we should enable front-ends/GUIs to integrate this option.

Signed-off-by: Hossein Khoujani <hosseinkhojany1380@gmail.com>
Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

GnuTLS: Print more relevant information in the case of a fatal TLS alert

End users are frequently confused by "TLS fatal alert" messages.  These are
commonly caused by bad (incorrect/expired/mismatched/missing) client
certificates.

Rather than printing a generic "TLS fatal alert" message, we can get GnuTLS
to provide a message about this specific alert.

Before:

    $ openconnect -c cert-and-key-for-wrong-domain.pem vpn.company.com
    SSL negotiation with vpn.company.com
    SSL connection failure: A TLS fatal alert has been received.
    Failed to open HTTPS connection to vpn.company.com
    Failed to complete authentication

After:

    SSL connection failure due to fatal alert: Certificate is bad

The analogous OpenSSL code already prints a relevant—though cryptic—message
about the specific alert (e.g. "SSL3_READ_BYTES:sslv3 alert bad certificate").

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Ignore blank labels sent in GlobalProtect prelogin

Some GlobalProtect servers will apparently send prelogin XML with
blank/empty contents for tags that are supposed to contain human-readable
labels (`<authentication-message/>`, `<username-label/>`,
`<password-label/>`). See https://gitlab.com/openconnect/openconnect/-/issues/561
for an example of such a server.

We should simply ignore these blank labels, and continue to use our default
labels, rather than give the form fields confusingly-blank labels.  Happily,
our `xmlnode_get_trimmed_val` function will do this automatically for us.

(Also, correctly handle asprintf()'s OOM return value.)

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Junos/Pulse → Junos/Ivanti Pulse

As if there's isn't enough confusion surrounding this very unloved protocol,
the corporate ownership and branding of Juniper/Junos/Ivanti Pulse servers
has changed over the past decade.

Our docs should reference all the names that users might recognize.

Also expand the docs' explanation of the relationship and differences
between Pulse and Juniper NC protocols, and the completeness of our
implementations.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Merge branch 'lzo' into 'master'

Latest version of lzo.c and lzo.h

See merge request openconnect/openconnect!443

Apply local changes to lzo.c and lzo.h

The idea is to add to lzo.h whatever is necessary to lzo.c, in order to
avoid including other FFmpeg header files.
* FFMAX:             copied as is from libavutil/macros.h
* AV_COPY32U:        rewritten, original in libavutil/intreadwrite.h
* av_memcpy_backptr: rewritten, original in libavutil/mem.c
* av_assert0:        adapted from avassert.h

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Latest version of lzo.c and lzo.h

Both files are part of current release 5.1.2 of FFmpeg from 2022-09-25:
* lzo.c: commit 636631d9 from 2022-02-24
* lzo.h: commit e427ba5c from 2019-05-02

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Merge branch 'persist-windows-builds' into 'master'

Persist Windows installer artifacts (openconnect-installer.exe) for tagged commits/releases

See merge request openconnect/openconnect!391

Update changelog and README

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Unique names for each variant openconnect-installer.exe

We need to rename the installers so that they don't clash and overwrite each
other when persisted. Generate both of the following:

- `openconnect-installer-MinGW{32,64}-{GnuTLS,OpenSSL}.exe`
- `openconnect-installer-MinGW{32,64}-{GnuTLS,OpenSSL}-${VERSION}.exe`

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Persist Windows installer artifacts (openconnect-installer.exe) for tagged commits/releases

We shouldn't expire these, as explained in
https://gitlab.com/openconnect/openconnect/-/issues/463.

Solution is based on the Gitlab-CI formula described at
https://stackoverflow.com/a/65478446.

(Thanks to Markus Oppmann <markus@memotech.franken.de> for contributing
several small fixes.)

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Remove support for LibreSSL

* The LibreSSL API is stuck to compatibility with OpenSSL 1.0.1,
  which reached EOL in 2016.
* Most Linux distributions have stopped shipping LibreSSL (see
  https://lwn.net/Articles/841664)
* LibreSSL appears not to have been tested with OpenConnect at all
  since 2016 (specifically, since
  https://gitlab.com/openconnect/openconnect/-/commit/d37c3e0527a05c375488850cfd0fdda3b04a83dc)

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Verbatim LGPLv2.1, to the byte

Directly copied from the source:

curl https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt > COPYING.LGPL

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Make xmlnode_bool_or_int_value() a global, internal function

Also, remove the unnecessary vpninfo argument, and change if → 'else if' as
appropriate.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Remove support for OpenSSL 0.9.8

We have to go back to CentOS 5 to find OpenSSL 0.9.8. Since CentOS 5 is
neither supported nor tested any more, let's get rid of this obsolete
compatibility hack intoduced to support the transition from OpenSSL 0.9.8
to OpenSSL 1.0.0.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

html.py is a Python 3 script

It begins with a `python3` shebang, so remove Python 2 stuff.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Merge branch 'parse_JSON_login_forms_F5' into 'master'

Parse JSON login forms for F5

See merge request openconnect/openconnect!431

Update changelog

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Parse JSON login forms for F5

Lots of F5 VPNs don't send normal HTML authentication forms at all, but
instead generate forms on-the-fly using JavaScript.

Until now, we've "faked it" by just assuming that the initial login form
contains plain username/password fields, but in
https://gitlab.com/openconnect/openconnect/-/issues/512 we have a case where
there's a subsequent "challenge" form which also lacks an HTML rendering.

We don't want to actually execute JavaScript in OpenConnect, but as far as
we can tell, these JavaScript forms always involve a `<script>` tag
containing a call to a function `appLoader.configure()`, with a JSON object
literal as its sole argument, and that object contains the details of the
form fields.  Like so:

    <script type="text/javascript">appLoader.configure({"logon": {
        "form": {
            "id": "auth_form",
            "title": "Please log into our F5 VPN",
            "fields": [
                {"type": "text", "name": "username", "caption": "Username", "value": "", "disabled": false},
                {"type": "password", "name": "password", "caption": "Password", "value": "", "disabled": false}
            ]
        }
    });
    </script>

Since we have json-parser as a dependency, let's parse that awful mess, and
build our authentication form from it. Yay, JSON.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Add 'except' clause for Gitlab-CI Android builds

Matches other CI builds; prevents unnecessary duplicate builds for tagged
releases.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Merge branch 'FAIL_obsolete-server-crypto' into 'master'

Fix Fedora/OpenSSL CI tests

Closes #541

See merge request openconnect/openconnect!437

obsolete-server-crypto and auth-certificate tests are now XFAIL in Fedora/OpenSSL CI test

Recent changes in Fedora crypto policies have enabled our obsolete-crypto
tests to start working again in Fedora with GnuTLS (see
4dd6c6f0d3b3ec4dbfa2c6ce74a4e5e65214c2af), but the opposite appears to have
happened for Fedora with OpenSSL.

The obsolete crypto polices such as 3DES, RC4, SHA1 seem to have been
removed from the LEGACY crypto policy of recent Fedora releases, so we can no longer
successfully run tests relying on them in Fedora CI with OpenSSL.

Mark them as XFAIL for now.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

obsolete-server-crypto test is no longer XFAIL in Fedora/GnuTLS/*

Re-apply 4dd6c6f0d3b3ec4dbfa2c6ce74a4e5e65214c2af to:

- Fedora/GnuTLS/ibmtss
- Fedora/GnuTLS/clang
- ubsan/GnuTLS/Fedora

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Replace deprecated libtasn1 macros

New macros were introduced in libtasn1 3.0 on 2012-10-28:
* `ASN1_TYPE` → `asn1_node`
* `ASN1_DATA_NODE` → `asn1_data_node_st`
* `ASN1_TYPE_EMPTY` → `NULL`

We would have to go back to RHEL 6 or Fedora 16 in order to find a version
of libtasn1 which is so old that it only supports the old names.

Because OpenConnect no longer tests against CentOS 6 in CI, and no longer
supports it, we can get rid of the deprecated types.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Expand examples of '--useragent' in manual page

Apparently, some newer Cisco clients use a different format for the HTTP
'User-Agent' headers that they send, and some Cisco servers require this
format for the clients connecting to them.

See https://gitlab.com/openconnect/openconnect/-/issues/544#note_1222936179
for an example of this.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Remove deprecated option cookie-validity from ocserv test configurations

It would generate a warning in CI tests:

    warning: skipping unknown option 'cookie-validity'

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

obsolete-server-crypto test is no longer XFAIL in Fedora/GnuTLS

Per https://bugzilla.redhat.com/show_bug.cgi?id=1960763#c32, the upstream
RedHat/Fedora bug has been fix:

> Related change mentioned above is going to rawhide
> as crypto-policies-20220119-1.git50109e7.fc36 and gnutls-3.7.3-1.fc36.
> In addition to gnutls 3.7.3 introducing `gnutls_protocol_set_enabled`,
> reenabling with the priority string should also be possible now.

The obsolete-server-crypto test no longer fails on Fedora CI, so it should
no longer be marked as XFAIL (expected failure).

OpenConnect's approach to explicitly enabling obsolete ciphers with a GnuTLS
priority string override now works again in Fedora.

[ DL added details to commit message. ]

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Give more details about unexpected Pulse configuration packets

Until now, we have logged the same catch-all message in the case of any
unexpected value in the header of the Pulse configuration packet:
"Unexpected IF-T/TLS packet when expecting configuration."

This is confusing to users and makes it hard to narrow down the actual
problem (see https://gitlab.com/openconnect/openconnect/-/issues/538#note_1220538728
and https://gitlab.com/openconnect/openconnect/-/issues/459#note_1220539246).

The configuration packet format seems to be an area of ongoing change in
recent Pulse server releases (see #58, #98, #379 → !331 and #472 → !401).
We should log more precise messages to aid in debugging and in adding
support for newer server versions.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Persistent configuration for fake Juniper server

1. Rework fake Juniper server to have a persistent configuration
2. Factor out some of the most repetitive elements of juniper-auth tests

This was already done for the fake Fortinet, F5, and GP servers.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Persistent configuration for fake Fortinet server

1. Rework fake Fortinet server to have a persistent configuration (as already
   done for fake GP server in c9b54dbf95a694ec23368ce7cd1da06335ff0d7c, and
   for fake F5 server in 7ebcc447d2f5aca72c4d267f47f237f39a638c5c)
2. Factor out some of the most repetitive elements of fortinet-auth-and-config
   (as already done for GP in 1172d80721d6a94e294b2f9e02171b3646dc3857, and
   for fake F5 server in 7ebcc447d2f5aca72c4d267f47f237f39a638c5c)

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Merge branch 'parse_GP_javascript_better' into 'master'

Better parsing of GlobalProtect JavaScript challenge fields

See merge request openconnect/openconnect!430

Parse GlobalProtect JavaScript challenge 'respMsg' as JSON string

We already have json-parser as a dependency (in order to support the Array
protocol), so we may as well use it to parse JavaScript strings for
GlobalProtect challenge messages. Yay?

JavaScript/JSON strings can be mangled in various ways (like `\u` followed
by anything other than 4 hex digits), so we still need the
naïve/non-JSON-aware handling as a fallback.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

GlobalProtect JavaScript challenge fields can contain literal newlines

From https://gitlab.com/openconnect/openconnect/-/merge_requests/411#note_1186323993,
there are GlobalProtect servers which send 2FA challenges in JavaScript-y form,
and where the `respMsg` fields contain literal '\n'.

It's straightforward to modify the "parser" to handle embedded newlines, and
even escaped double quotes (`\"`).  I probably should've anticipated these
cases from the beginning.

This also adds production of 2FA challenges containing embedded newlines and
escaped quote marks to the fake GP server, so that we can test against it.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Bugfix tests/fake-gp-server.py

In 76dc6794a4150dcf62ad42d4e286d5df5f0da091, I intended to add a test case
to actually verify that we handle the JavaScript-wrapped-in-HTML format of
challenge-based 2FA for GlobalProtect VPNs. However, I botched it.

Fix that test here.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Mention newer/non-PPP-based wire protocol in the Fortinet docs

This apparently-newer wire protocol has been discussed in
https://gitlab.com/openconnect/openconnect/-/issues/297#note_1173189545.

Thus far, we do not know of any advantages relative to the existing
PPP-based wire protocol, which remains available on all known Fortinet
servers.  If we discover some advantage of the new wire protocol — perhaps
less-broken handling of reconnection?  — then it should be relatively easy
to add support.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Simplify port list in csd-post.sh

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Update .mailmap

One more address to consolidate

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Free vpninfo->urlpath before re-assigning

Prevents memory leak in a diagnostic code path used to help figure out why
Fortinet server is refusing (re)connection.

Signed-off-by: Dimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>

Merge branch 'tap' into 'master'

Case-insensitive TAP component ID

Closes #507

See merge request openconnect/openconnect!424

Merge branch 'wintun-0.14.1' into 'master'

Upgrade to Wintun 0.14.1

Closes #507

See merge request openconnect/openconnect!426