Fix store_le16/store_le32 harder

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

Use C99 initializer instead of memset.

Strictly speaking, using memset() here violates strict aliasing rules,
and it would be entirely permissible for an assert() like this example
to *fail*:

struct gtls_cert_info gci;

memset(&gci, 0, sizeof gci);
assert(gci.pkey == NULL);

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>

Add more buf_append_base64() tests... and fix it.

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

Fix first line length in buf_append_base64()

We need to add four (for the characters we're about to append) *after*
checking against line_len and resetting ll to zero. Otherwise the first
line thinks it starts at 4 while the others start at 0.

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

Validate line_len argument to buf_append_base64() too

Based on a patch by Tom Carroll <incentivedesign@gmail.com>

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

Don't leak memory in buftest

It makes ASAN unhappy

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

Update translations from GNOME

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

Fix buftest to build on Windows

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

Fix fallback/big-endian store_le16() and store_le32()

These were swapped.

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

Limit oc_text_buf to 16MiB, start adding test cases

We really ought to unit test this a lot harder. This is a start...

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

Move oc_text_buf functions out to textbuf.c for easier unit testing

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

Correct calculation of base64 encode buffer length.

In the previous formulation, it would first multiple then divide. It would then
promote to unsigned int. The formula would overflow for large len. For example,
needed = 2 when len == INT_MAX. In the revised formulation, it is promoted,
divided, then multiplied. The revised calculation avoids the overflow and
computes needed correctly over len in {0, 1, ..., INT_MAX}.  For len == INT_MAX,
needed is correctly computed as 2863311533.

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>

Check gnutls_pubkey_init return code.

gnutls_pubkey_import_x509 doesn't verify if pubkey == NULL.

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>

Add line length argument to buf_append_base64()

The multicert support will want to use this.

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

gnutls.c:943:21: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare]

The gci->nr_certs field is an unsigned int. Use that as the loop variable
for freeing them too. And we don't actually need the if (gci->certs)
condition here either because ->nr_certs won't be non-zero in that case
anyway.

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Remove NULL checks before deinit GnuTLS objects.

GnuTLS handles these just like a traditional free() function and copes
if they're NULL. We don't have to check.

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Convert x509_privkey to abstract privkey in load_certificates.

Prefer the use of privkey to x509_privkey, reducing branches in later code.

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>

Remove field free_certs from gtls_cert_info.

There was only one place in the code requiring special treatment supported by
free_cert == 0. Instead, make a copy of the certificate, transforming the case
to free_cert == 1. This allows the removal of free_certs from the gtls_cert_info
structure.

Signed-off-by: Tom Carroll <incentivedesign@gmail.com>

GnuTLS: Refactor test sign/verify loop over available digests

Some compilers don't like the loop and switch statement for setting 'dig':

warning: ‘dig’ may be used uninitialized in this function [-Wmaybe-uninitialized

It's a false positive, since we only looped over the values that are
handled in the switch statement and which *do* set 'dig'.

But let's refactor it a little anyway, to make it less obscure for humans
and compilers alike.

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

Add openconnect_get_connect_url(), use it in --authenticate output

As noted in the long comment in openconnect.h, we need to provide the
actual *URL* for the connection including the real hostname. And that
means we also need to provide a suitable --resolve argument to pass on
to the connecting openconnect.

Add openconnect_get_connect_url() for the GUI auth-dialogs to use, and
make 'openconnect --authenticate' emit the same. If we just put it into
$HOST that might break existing setups that don't use the newly-added
$RESOLVE variable too, so put it in another new variable $CONNECT_URL
and leave the original $HOST alone.

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

Update translations from GNOME

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

Update translations from GNOME

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

Update TPMv2 documentation a little, add changelog for TLSv1.3 and swtpm

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

Actually add P384 files so they aren't generated locally

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

Add NIST P384 curve to swtpm tests

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

Disable swtpm testing for ancient Fedora/EPEL

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

Add swtpm-tools to COPR build too, to enable auth-swtpm test

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

Add tests for TPMv2 with both swtpm and hardware

For normal builds, the auth-swtpm test runs a new swtpm with a temporary
state directory, imports a pregenerated TPM state which matches the
keys that are also pregenerated and committed to git.

As with the normal keys/certs and SoftHSM state, there are also rules
for *generating* all this, to ensure that what's committed is entirely
reproducible and serve as documentation. But those rules are mostly
dormant from this point onwards (hence my not caring about parallel
builds being broken for the swtpm startup).

There's an attempt at supporting *real* TPM testing, with a 'hwtpm'
variant. In that case the rules for generating the key/cert and for
importing the existing EC cert into the TPM are *not* dormant. But
this isn't quite working yet and is going to need to be an explicit
invocation by those who care about such things.

There are three keys tested here. Firstly the original EC key used
by all our certificate tests, imported into the TPM with the
create_tpm2_key tool from James's openssl_tpm2_engine. We cannot
import our original RSA key as it deliberately had a strange key
size, and the TPM can't cope.

Then we *generate* EC and RSA keys in the TPM too, using the
tpm2tss-genkey tool from the Intel engine. That one isn't capable
of importing existing keys yet but *is* more widely available in
distro packages.

For swtpm we use both since it's only necessary for the tools to be
present at the time we add all this. For hwtpm where users will want
to do this at build/test time, they get a subset of the keys depending
on which tools they have available.

We preserve the existing nomenclature for matching keys/certs, where
NAME-key-STORAGETYPE.pem matches with NAME-cert.pem. So the *imported*
version of our existing EC key ends up being ec-key-swtpm.pem and
ec-key-hwtpm.pem to match the existing ec-cert.pem

For the *generated* keys, we need a new 'NAME' since they are actually
new keys. So 'swtpm-ec' 'swtpm-rsa' 'hwtpm-ec' 'hwtpm-rsa' are the names
of those keys, and since they were generated in the TPM and never
existed as a file, we need a new pattern-match rule to generate the
corresponding CSR and then certificate, using the ENGINE to do so.

But we want this pattern rule *not* to match the imported keys like
ec-key-swtpm.pem, because we don't want to trigger a generation of
ec-cert.pem from the TPM when it's already right there in a file.

So we *don't* want to use 'swtpm' and 'hwtpm' as the STORAGETYPE part of
the filenames of the generated keys; we just use 'tpm' instead, and then
the pattern rule matches 'swtpm-%-key-tpm.pem' and 'hwtpm-%-key-tpm.pem'.

This doesn't yet test NV-parented keys or any kind of passwords, but
it's a start.

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

Allow TPM_INTERFACE_TYPE=socsim to force swtpm even for Intel TSS

If we want to have a swtpm-based test, we need to *use* the swtpm even
if a real hardware TPM is available. Not for general purpose use, but
allow it to be overridden by using the same TPM_INTERFACE_TYPE variable
that already works for the IBM TSS because the IBM library handles it
internally.

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

Update translations from GNOME

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

Resync translations with sources

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

Implement RSA-PSS padding for TPMv2

Now I can connect using TLSv1.3 using a TPMv2 RSA key. And my list of
"stuff I should never have had to do for myself in the application,
just to ask the crypto library to use the key that the user pointed
it at" has *really* jumped the shark now.

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

Add IBM TSS CI build on Fedora

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

Allow TSS2 library to be chosen by --with-gnutls-tss2

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

Support TLSv1.3 sign functions on SECP curves with TPMv2

For these curves at least, it basically already works.

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

Tell TPMv2 the hash type based on size

The TPM doesn't really have any business knowing this, and the only thing
that matters is the size. Which is truncated to the curve bit length even
for larger hashes.

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

tss2-esys: Don't try password for TPM2 keys with emptyauth set

The auth-certificate test always sets --key-password=password, and when
a TPM2 key has 'emptyauth' the IBM TSS code was trying the empty auth
first, as it should. But the Esys code was always trying the password,
and then prompting the user; the user had to just press enter.

Try empty auth first if the key says so.

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

GnuTLS: Fix user-visible strings and dialog auth_id for multicert

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

OpenSSL: Fix user-visible strings and dialog auth_id for multicert

The visible messages and the keys in the dialog prompts should make it
clear whether they are for the primary or secondary cert.

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

OpenSSL: Factor out load_certificate() from load_primary_certificate()

Much the same as we've done on the GnuTLS side, separate out *loading*
the certificate, from installing it into the SSL_CTX.

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

GnuTLS: Move TPMv2 context to certinfo

Precisely the same as we just did for TPMv1, to make the TPM context
per-cert instead of per-vpninfo.

As with TPMv1, some of this *could* be global state in the future.

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

GnuTLS: Move TPMv1 context to certinfo

If we want to support multiple certificates, the TPM context needs to
be managed per cert, not per vpninfo.

Strictly, some of this *could* be global state while some of it is
per-key. But that's an optimisation for the future.

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

GnuTLS: Really only install certs from load_primary_certificate()

Finally actually finish the job: load_certificate() fetches the key
and certs into a data structure that its caller can use as it sees
fit, and the *caller* then installs them into the https_cred in
the case of the primary certificate.

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

GnuTLS: Split out free_gtls_cert_info()

If we want load_certificate() to actually *return* this stuff to its
caller for real and then load_primary_certificate() to actually install
them into the https_cred, then we're going to have to be able to free
it sanely.

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

GnuTLS: Extend certinfo to callbacks

Now that the cert_info struct has a back-reference to the vpninfo, we
can use it as the private data for callbacks.

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

OpenSSL: Pass certinfo through load_certificate() functions

Much like in GnuTLS except in GnuTLS we already separated out the bit
which installs the key/certs into the https_cred while all these
OpenSSL functions are still just installing directly into the SSL_CTX
so we're going to want to fix that separately.

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

GnuTLS: Pass certinfo into load_certificate() and subordinate functions

Instead of blindly referencing vpninfo->certinfo[0], pass the required
certinfo pointer into load_certificate() and down to the various
subfunctions which get invoked from there.

A couple of places still need fixing; notably gnutls_pin_callback() and
auth_tpm2_key(). Both of which are *callbacks*. I think we'll end up
adding a self-referencing vpninfo pointer to the struct cert_info, then
using the cert_info as the 'private' data for those callbacks. But that
can come later.

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

Move cert/sslkey/cert_password into a 'struct cert_info'

This paves the way for having more than one of them.

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

GnuTLS: Start to factor out load_certificate() for reuse

Introduce a struct with the key/cert information and start pretending
that the load_certificate() function is only obtaining those, and add a
load_primary_certificate() function which will actually be responsible
for installing them into vpninfo->https_cred.

This is step 1 which isn't even pretending very hard; it's just adding
the structure and doing a search/replace to use the fields therein
instead of local variables in load_certificate().

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

kill redundant free_certs argument to GnuTLS assign_privkey() function

This was added in commit 04ccc265c ("Simplify extra_certs handling
w.r.t. assign_privkey()") because GnuTLS 2 didn't take a copy of the
certs which were assigned to the creds, and we needed to keep track of
which extra certs were used and which weren't.

The GnuTLS 3 variant of assign_privkey() didn't use it, since GnuTLS 3
takes a copy of the certs and we can just free them normally.

Now that we've dropped GnuTLS 2 support, we can drop this argument too
and simplify assign_privkey() a little bit.

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

Fix Coverity complaints about array.c

A couple of leaks on error paths, and there are only three DNS servers
in ip_info.

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

Only require json-parser for Fedora packages, not EPEL

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

Add documentation for array protocol, remove HIDDEN flag

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

Implement DTLS support for Array

This is fairly straightforward once you spot the "13" at the end of the
first DTLS packet. Without that, we can *send* data and even do keepalives
but the worker process on the server would crash the moment it has actual
*packets* to send back to us.

Like fairly much every other SSL VPN using anonymous DTLS, they don't
cope well with that first DTLS packet (or the response to it) being
lost. We don't get anything back if we resend it. And if we send a
keepalive that *might* elicit a response... or might cause them to tear
down the connection if they haven't seen the initial auth packet yet.

So... we send only the auth packet first. If we don't see a response we
send the auth packet *and* a keepalive in quick succession. If we start
seeing IP packets (which includes the keepalive as that's Legacy IP
protocol #0xff), we jump to DTLS_ESTABLISHED state too.,

We also need to send a 'dtls off' packet when we want it to switch back
to sending over TCP, much like the oNCP queue_esp_control().

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

Start to implement config parsing for Array

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

Add hackish array auth

It's woefully incomplete but it means I don't have to mess with curl
each time.

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

Initial shell of Array Networks SSL VPN support

Can't resist a packet dump...

https://gitlab.com/openconnect/openconnect/issues/102

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

json_parse_ex: Remove redundant assignment to unused 'b'.

The static analyser complains 'Value stored to 'b' is never read'.

There isn't even much of a defence that it's just being defensive; we
ought to *know* it isn't used from that point on.

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

json: Fix undefined behaviour when converting integer to double

Coverity doesn't like this, complaining that assignment to an object
with overlapping storage without exact overlap and compatible types can
cause undefined behaviour.

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

Import json-parser library

Imported v1.1.1 from https://github.com/ShahinSorkh/json-parser

Commit 7c46f9c ("bump package version to 1.1.1")

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

Use BIO_dgram for OpenSSL DTLS

This way it can find a sane MTU and doesn't have to fragment the handshake
packets, which the Array server can't cope with.

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

Fix DTLS state reporting

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

Improve Fortinet auth

Use the same 'auth_id' values as GlobalProtect uses ('_login' for the normal
username/password form, and '_challenge' for the MFA challenge form). This
is a follow-on to 613fa87dd64853a042d982aca4a94279cd78ff58.

This also fixes:

- A potential double-free() issue if the challenge form is loaded repeatedly,
  adding a test of 2 rounds of challenge 2FA to verify it.
- Warnings about the unused 'invalid_cookie' label.

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

Merge branch 'add_GP_flask_tests' of gitlab.com:openconnect/openconnect

Merge branch 'do_not_use_inet_ntoa' of gitlab.com:openconnect/openconnect

openssl: Add SSL_OP_LEGACY_SERVER_CONNECT to allow-insecure-crypto

OpenSSL 3.0.0 onwards will require secure negotiation by default, which
Cisco servers don't seem to cope with. Let --allow-insecure-crypto turn
that off.

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

Add OPENSSL_SUPPRESS_DEPRECATED

We will eventually update to the OpenSSL 3.0.0 APIs but for now there
is no overriding need to, so shut the warnings up the easy way.

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

DTLS: Don't require secure renegotiation from Cisco

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

Keep comments next to live code in fortinet.c

In c0ca8c632566bf423d3ac23b8b21ef353e399c33, the fetch of the legacy/HTML
Fortinet config was preprocessor'ed out.  The comment about the subtle
behavior of unfetched redirects should be kept next to live code.

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

Replace all use of inet_ntoa() with inet_ntop()

inet_ntoa() uses a statically-allocated buffer, which means that it wouldn't
be safe for use by an a multithreaded application using libopenconnect (as
yet hypothetical).

We should use inet_ntop() instead in all cases, even though it's slightly
less convenient.

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

Fix setting of IP addresses in ip_info from PPP

We were clearing vpninfo->ip_info.addr if it was already set, as shown in
https://github.com/adrienverge/openfortivpn/issues/112#issuecomment-831471948

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

Fix EXTRA_DIST to include all $(POTFILES)

Some files such as gnutls_tpm2_ibm.c were not being included in the
tarball.

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

Refuse to handle forms without ->auth_id

GUI authentication dialogs will really want this for saving responses.
And saved_form_field() will crash if it's NULL too.

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

Fix Juniper role select form to have an auth_id too

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

Partial fix for Fortinet auth

We have to fill in form->auth_id in all cases, and were forgetting in
the synthesised password form.

Also, on a redirect we would get an empty resp_buf from do_http_request()
which would cause a crash when we dereference it. Don't do that.

We still need some more work here (and a webview at least for the GUI
case) but this at least fixes the worst of it.

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

GP: Pass 'preferred-ipv6' parameter among auth requests, just like 'preferred-ip'

Testing against a real GP server with IPv6 support shows that the
"preferred" IPv6 address can be passed in the /ssl-vpn/login.esp request
arguments, as well as returned by it. (Even if unprompted; some GP VPNs
seem to track a persistent mapping of user accounts to IP addresses on the
server side.)

We should save the 'preferred-ipv6' parameter from the login results in
vpninfo->cookie, just as we do with its Legacy IP counterpart,
'preferred-ip'.

Also adds Flask tests to verify the correct passing of
'preferred-ip'/'-ipv6'.

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

GP: fix bug in blind retry of login credentials after portal-to-gateway redirect

We had been incorrectly relying on the first character of the 'auth_id'
being '_' to indicate a non-challenge form, in which case the
username/password can be "blindly retried" from portal to gateway.

However, this has been wrong since v8.09 (specifically, the commit
593df6b1c09ea525a913d4d8401a95ffdb1877db). Unfortunately, it may be
responsible for some user reports of inability to login via portal
interface.

Discovered while writing gp-auth-and-config tests.

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

Add tests of GlobalProtect auth with gateway selection and challenge-based 2FA

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

GP auth: don't modify URL path if it ends with .esp

If the URL path ends with .esp (possibly followed by a query string, e.g.
/ssl-vpn/prelogin.esp?magic_parameter=123), then let's assume that the user
knows exactly what they're doing and that we shouldn't rewrite the path.

This will help with GP auth tests, by allowing us to get parameters into the
test session setup (just as fake-{f5,fortinet,juniper}-server.py do), in
order to configure gateways, 2FA requirement, etc.

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

Consolidate check_http_status from gpst.c and ppp.c

This function checks a buffer for an unexpected HTTP status line ("HTTP/xxx
nnn ...") and returns the numeric status value (nnn) if found.

Also fixes a crash when GP config request ("/ssl-vpn/getconfig.esp") returns
no body at all.

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

Add fake-gp-server.py and gp-auth-and-config test

Another set of Flask-based tests.

TODO: need a way to get parameters into the initial session setup (just as
fake-{f5,fortinet,juniper}-server.py do), in order to configure gateways,
2FA requirement, etc.

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

Fix potential NULL dereference in Java example code

Coverity tells us that getline() can return null. Don't blindly reference
it.

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

Fix potential leak of 'domains' in parse_fortinet_xml_config()

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

Fix potential memory leaks in ppp.c

Spotted by Coverity.

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

Ensure pulse_connect() can never attempt to monitor fd -1

Coverity wasn't sure that this could never happen. I'm *fairly* sure but
let's add a check anyway.

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

GlobalProtect IPv6 ESP support

ESP for IPv6 is be initiated in the same way as for Legacy IP: send a
ping (ICMPv6 echo request) to the "magic address" from <gw-address-v6>,
with the same "magic payload."

With a hop limit of 128 and random ICMPv6 ID (I think), this exactly
matches what the Windows client sends out. (Good job by me with the PAN
GlobalProtect mind-meld. 🧠😝)

Based on my testing, it appears that the resulting tunnel works for
*both* IPv4-over-ESP and IPv6-over-ESP. (Whew! No need to do 2 separate
sets of "magic pings.") It appears that when `<gw-address-v6/>` is
present in the config, we *must* send the magic pings via ICMPv6 to that
address (rather than ICMPv4 to the `<gw-address/>`) in order for the
IPv6-over-ESP tunnel to work.

Given the pre-existing weirdness of GP ESP, it could be worse.  ¯\_(ツ)_/¯

[ dwmw2: Fix type aliasing abuse, update for new ip_info handling ]

From the original separate commit fixing the aliasing issues:

I believe we get away with it for the address fields and the icmph
because all those structures have uint16_t members, and the compiler
realises that in valid C code, those *might* alias to the uint16_t*
argument to csum_partial().

But the pseudo header, being an array of bytes in Dan's original
version, couldn't *possibly* have been what csum_partial() was going to
look at, so the compiler was free to reorder the writes into it so they
happen *after* the call to csum_partial(). With predictably unhappy
results.

Setting it up as a type which some uint16_t members would make it work,
but really there's not a lot of point. Just add the length and the
next_header field directly to the checksum.

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

Add IPv6/ICMPv6 header and flags to win32-ipicmp.h

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

GP config: hush warning about unknown <quarantine>no</quarantine>

Commit 958da82445d ("Warn if <quarantine> is set in GlobalProtect XML
config") attempted to avoid emitting the warning for the value "no".
But the way the condition was constructed, it left the "quarantine"
node unhandled and triggered the later 'else' condition reporting it
as an 'Unknown GlobalProtect config tag'.

Fix it so that it really does silently ignore the "no" case.

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

Log address family of ESP packets sent/received

Aids in debugging GlobalProtect IPv6+ESP.

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

Split ESP checksum functions into csum_partial and csum_finish

csum_partial() feeds more uint16_t words into the checksummer;
csum_finish() does the final condensation down to uint16_t, and
conversion to network order.

[dwmw2: Note this still doesn't cope with odd-sized packets but
        we don't care for now.]

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

Attempt to allow Fortinet reconnect over TCP

We can't just reconnect; we have to fetch the XML config again. Even that
isn't always sufficient; it seems the server only allows *one* reconnect
before it starts to fail.

The *first* reconnection shows this in server logs:

[2326:root:0]ipcp: down ppp:0x7f1e1d218000 caller:0x7f1e1d15f900 tun:37
[2326:root:78]sslvpn_ppp_deassociate_fd_to_ipaddr:318 deassociate 10.212.134.200 to tun (ssl.root:37)
[2326:root:78]tunnel is down, wait for next connection.
[2326:root:78]sslvpn_release_dynip:1309 free app session, idx[0]
...
[2326:root:79]req: /remote/fortisslvpn_xml
[2326:root:79]deconstruct_session_id:426 decode session id ok, user=…
[2326:root:79]deconstruct_session_id:426 decode session id ok, user=…
[2326:root:79]sslvpn_reserve_dynip:1275 tunnel vd[root] ip[10.212.134.200] app session idx[0]
[2326:root:79]req: /remote/sslvpn-tunnel
[2326:root:79]sslvpn_tunnel_handler,52, Calling rmt_conn_access_ex.
[2326:root:79]deconstruct_session_id:426 decode session id ok, user=…
[2326:root:79]sslvpn_tunnel_handler,153, Calling tunnel.
[2326:root:79]tunnelEnter:498 0x7f1e1d15f900:0x7f1e1d1e9000 sslvpn user[dwmw2],type 1,logintime 0 vd 0
[2326:root:79]sconn 0x7f1e1d15f900 (0:root) vfid=0 local=[178.238.156.110] remote=[90.155.92.213] dynamicip=[10.212.134.200]
[2326:root:79]Prepare to launch ppp service...

The *second* reconnection doesn't say anything about waiting for next
connection:

[2326:root:0]ipcp: down ppp:0x7f1e1d21a800 caller:0x7f1e1d15f900 tun:37
[2326:root:79]sslvpn_ppp_deassociate_fd_to_ipaddr:318 deassociate 10.212.134.200 to tun (ssl.root:37)
[2326:root:79]sslvpn_release_dynip:1309 free app session, idx[0]
...
[2326:root:7a]req: /remote/fortisslvpn_xml
[2326:root:7a]deconstruct_session_id:426 decode session id ok, user=…
[2326:root:7a]deconstruct_session_id:426 decode session id ok, user=…
[2326:root:7a]sslvpn_reserve_dynip:1275 tunnel vd[root] ip[10.212.134.200] app session idx[0]
[2326:root:0]sslvpn_internal_remove_apsession_by_idx:2586 free app session, idx[0]
[2326:root:7a]req: /remote/sslvpn-tunnel
[2326:root:7a]sslvpn_tunnel_handler,52, Calling rmt_conn_access_ex.
[2326:root:7a]deconstruct_session_id:426 decode session id ok, user=…
[2326:root:7a]sslvpn_tunnel_handler,153, Calling tunnel.
[2326:root:7a]tunnelEnter:498 0x7f1e1d15f900:0x7f1e1d1e9000 sslvpn user[dwmw2],type 1,logintime 0 vd 0
[2326:root:7a]tunnelEnter:520 failed to retrieve tunnel address

Compare with the behaviour when we don't get the XML config again and
just try to re-establish PPP:

[385:root:0]ipcp: down ppp:0x7f19b6084800 caller:0x7f19b5fb2b00 tun:36
[385:root:f]sslvpn_ppp_deassociate_fd_to_ipaddr:318 deassociate 10.212.134.200 to tun (ssl.root:36)
[385:root:f]tunnel is down, wait for next connection.
[385:root:f]sslvpn_release_dynip:1309 free app session, idx[0]
...
[385:root:10]req: /remote/sslvpn-tunnel
[385:root:10]sslvpn_tunnel_handler,52, Calling rmt_conn_access_ex.
[385:root:10]deconstruct_session_id:426 decode session id ok, user=…
[385:root:10]sslvpn_tunnel_handler,153, Calling tunnel.
[385:root:10]tunnelEnter:498 0x7f19b5fb2b00:0x7f19b6043800 sslvpn user[dwmw2],type 1,logintime 0 vd 0
[385:root:10]tunnelEnter:512 no more IP address available.

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

Don't fetch legacy Fortinet config

It really doesn't seem to make any difference.

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

Abort when install_vpn_options() fails

When we get given a different IP address, don't turn the -EPERM into
-EINVAL. We *want* the -EPERM because it terminates the retry loop.

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

Abort if PPP transport is closed in PPPS_ESTABLISH

The Fortinet server just closes the connection on us when it screws up
reconnection and thinks it can't allocate an IP address. Don't retry
ad infinitum; give up.

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

Only set ip_info addresses from PPP if they aren't already set

Fortinet reconnection, in particular, didn't like the addr6 being set
because it *isn't* set in the new ip_info we receive in XML; only the
netmask6 is set there.

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

Fix sloppy cookie construction for Fortinet

Using the "default" cookie behavior of internal_split_cookies() should be a fallback, not the standard behavior.

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

Fix Fortinet IPv6 config and add tests for it

1. Fortinet IPv6 config uses 'prefix-len' attributes where the Legacy IPv4
   config uses 'mask' attributes.
2. Also, we need to set ip_info.netmask6 instead of ip_info.addr6 if it
   includes a prefix-len (for compatibility with the vpnc-script, which was
   originally written based on Cisco's dichotomy here).
3. Align the cstp_option name, "ipaddr6", with other protocols (cf.
   792647ee1b9a1eca9cffc79dab746f8273d2279a).
4. Add IPv6 config to Fortinet test server:

   <ipv6>
     <dns ipv6="cafe:1234::5678"/>
     <assigned-addr ipv6="faff:ffff::1" prefix-len="64"/>
     <split-tunnel-info>
       <addr ipv6="fdff:ffff::" prefix-len="120"/>
     </split-tunnel-info>
   </ipv6>

   Results in:

   Got IPv6 DNS server cafe:1234::5678
   Got IPv6 address faff:ffff::1/64
   Got IPv6 route fdff:ffff::/120

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

Add IPv6 support for Fortinet

The Fortinet SSL VPN does not support dual stack tunnels. If you connect
over IPv6 you get only IPv6 in the tunnel. And if you connect over Legacy
IP you only get Legacy IP in the tunnel. This is even more insane than
the Pulse abomination which only lets you use the same protocol for ESP
but at *least* let you send the other protocol over the TCP connection.

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

Merge branch 'master' of gitlab.com:openconnect/openconnect

F5, Fortinet: ignore errors in landing page once we've got a cookie

Like Juniper, F5 and Fortinet redirect the user to a landing page (“webtop”)
after a successful authentication.  We should ignore HTTP errors in fetching
the landing page if/when we've received a valid cookie, as done for Juniper
in 3e77943692b511719d9217d2ecc43588b7c6c08b.

Tests for {f5,fortinet}-auth-and-config are still passing with these
changes.

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