Daniel Lenski [Sun, 15 Nov 2020 23:32:08 +0000 (15:32 -0800)]
GP: ask user to report unexpected value of <connected-gw-ip>
We don't know what this one means, but it seems likely that we need to do
some special processing if this differs from the VPN server's external IP
address.
See https://gitlab.com/openconnect/openconnect/-/issues/193#note_447466255
for an example of this field observed "in the wild".
Daniel Lenski [Mon, 16 Nov 2020 22:00:47 +0000 (14:00 -0800)]
less confusing output when authentication fails
* "Failed to obtain WebVPN cookie" → "Failed to complete authentication"
(WebVPN is Cisco-specific and unclear to end users)
* GlobalProtect shouldn't treat a SAML-required login response as a failure to *parse*
the login response. This results in unnecessary and confusing logging. (ping #197)
Daniel Lenski [Wed, 20 May 2020 05:06:34 +0000 (22:06 -0700)]
use setup_tun callback to defer printing connection status AND backgrounding until tun_is_up
This will make scripted use of OpenConnect a lot less sensitive to timing of the tunnel
coming up, if a script is trying to use the tunnel as soon as the main process exits.
(See https://gitlab.com/openconnect/openconnect/-/issues/117 for examples.)
Here's a log of OpenConnect connecting to a GlobalProtect server where ESP
fails to start succesfully due to a firewall blocking UDP. With this
change, it doesn't print the connection status or go to background until after the
attempt to connect ESP has failed, and the tunnel has been started.
$ echo PASSWORD | sudo ./openconnect -u USERNAME vpn.company.com/gateway --prot=gp --passwd-on-stdin -b \
-s 'echo +++ vpnc-script called with reason $reason'
POST https://vpn.company.com/ssl-vpn/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to 1.2.3.4:443
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
Enter login credentials
POST https://vpn.company.com/ssl-vpn/login.esp
POST https://vpn.company.com/ssl-vpn/getconfig.esp
Session will expire after 1440 minutes.
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
No MTU received. Calculated 1214 for ESP tunnel
POST https://vpn.company.com/ssl-vpn/hipreportcheck.esp
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Delaying tunnel for 1000 ms with reason: awaiting GPST ESP connection
Failed to connect ESP tunnel; using HTTPS instead.
Connected as 10.0.1.2, using SSL, with ESP unsuccessful
Continuing in background; pid 1234
+++ vpnc-script called with reason pre-init
+++ vpnc-script called with reason connect
$
Here's an example of attempted DTLS connecting on an AnyConnect VPN, where DTLS
never succeeds. This right away gives us some good feedback that we could probably
reduce the duration of the loop:
Connected to 1.2.3.4:443
SSL negotiation with vpn.company.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(ECDHE-RSA-SECP384R1)-(AES-256-GCM)
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
DTLS handshake failed: Resource temporarily unavailable, try again.
Delaying tunnel for 1000 ms with reason: DTLS MTU detection
Connected as 10.0.1.2, using SSL, with DTLS in progress
There's no clear rationale for using with Pulse/oNCP ESP setup (yet):
- We don't do any MTU detection
- Unlike GPST, we can start sending and receiving packets via the TLS tunnel
immediately, while attempting to connect ESP as well.
Daniel Lenski [Sun, 17 May 2020 00:06:10 +0000 (17:06 -0700)]
add delay_tunnel_reason and delay_close
- As long as the protocol-specific mainloop sets delay_tunnel_reason to a non-NULL value, tunnel
device creation will be delayed.
- If delay_close is set, mainloop will continue to iterate even if cancel_cmd or pause_cmd is set.
A protocol should set DELAY_CLOSE_IMMEDIATE_CALLBACK for the case where its mainloop needs an
immediate callback (e.g. to send some kind of termination request), and DELAY_CLOSE_WAIT for the
case where its mainloop is waiting to receive something (e.g. a termination acknowledgement).
openconnect_mainloop() will unset both delay_tunnel_reason and delay_close on each iteration. A
protocol mainloop must thus affirmatively extend a delay in order for it to continue.
Daniel Lenski [Thu, 15 Oct 2020 05:01:34 +0000 (22:01 -0700)]
finesse the URL-decoding of the GP login args
Unsurprisingly, it's messier than I thought it was. Some of them definitely
need to be URL-decoded, and some definitely shouldn't be.
https://gitlab.com/openconnect/openconnect/-/issues/147#note_429943037
Daniel Lenski [Sun, 24 May 2020 18:47:37 +0000 (11:47 -0700)]
GP: Fix the issue of a 0.0.0.0/0 "split"-include route by swapping the "split" route with the default netmask.
GlobalProtect VPNs always or almost always send `<netmask>255.255.255.255</netmask>` (host route). If they
wish to include a true IPv4 default route (`0.0.0.0/0`), they send it a "split"-include route.
This interferes with NetworkManager users’ ability to use the "Use only for
resources on this connection" feature of NM's VPN plugins. (Which basically
tells NM to use only split routes from the connection, and ignore a default route.)
This patch detects the case of a 0.0.0.0/0 IPv4 "split"-include route, and swaps it to become the default
default route.
Daniel Lenski [Mon, 18 May 2020 21:59:40 +0000 (14:59 -0700)]
add obsolete-server-crypto and pfs tests
These are designed to ensure that we don't inadvertently break compatibility
with legacy/obsolete server crypto, and also that we don't *inadvertently
connect* to less-secure crypto than requested.
Current checks:
- connect to a server whose only ciphers are 3DES and/or RC4 [if and only
if] `--allow-insecure-crypto` is specified
- connect to a server whose only KX is RSA KX [if and only if] `--pfs` is
[not specified]
Tricky parts:
- Override GnuTLS system crypto policy in obsolete-server-crypto test config,
because this may be needed for newer versions of GnuTLS to obey it. (per nmav:
https://gitlab.com/openconnect/openconnect/-/issues/145#note_346497960)
- OpenSSL 1.1.0+ removes 3DES and RC4 from the default build
(https://www.openssl.org/blog/blog/2016/08/24/sweet32), so there is no way
to re-enable without rebuilding from source. Therefore, obsolete-server-crypto
test is marked as XFAIL on all CI builds using it.
- Recent GnuTLS versions which support TLS1.3 implicitly allow non-RSA KX (due to
VERS-TLS1.3 ciphersuites) even when -KX-ALL:+RSA is in the priority string; in
order to actually test RSA-only KX, we need to ensure that TLS1.3 is disabled.
See #149.
Daniel Lenski [Mon, 18 May 2020 17:54:03 +0000 (10:54 -0700)]
add --allow-insecure-crypto, and corresponding API functions, to explicitly enable 3DES/RC4/SHA1
This closes #145, and adds tests intended to prevent similar situations from recurring.
Allowing the ancient, broken 3DES and RC4 ciphers is insecure; we do not
want to (re-)enable them by default. (See discussion:
https://gitlab.com/openconnect/openconnect/-/issues/145#note_344687335)
However, some still-in-use VPN servers can't do any better. So instead, we
explicitly disable them, unless explicitly enabled with the
`--allow-insecure-crypto` option, or corresponding API functions.
Also attempts to future-proof --allow-obsolete-crypto a bit, by setting
`%VERIFY_ALLOW_SIGN_WITH_SHA1` (per nmav:
https://gitlab.com/openconnect/openconnect/-/merge_requests/114#note_346496796),
and explicitly enabling SHA1 (which was moved to GnuTLS “bad hashes list” in 1d75e116b1681d0e6b140d7530e7f0403088da88)
Ash Holland [Wed, 24 Jun 2020 21:26:28 +0000 (22:26 +0100)]
Juniper: support password and 2FA fields in the same form
Juniper login forms typically ask for the password in the first form,
then put the 2FA field in a later form. However, some use a second
password field in the first form (usually frmLogin) for the 2FA token.
We now assume password fields after the first in a frmLogin to be 2FA
fields to cope with this case.
Daniel Lenski [Thu, 13 Aug 2020 17:00:58 +0000 (10:00 -0700)]
bump emulated GlobalProtect version number
Apparently some GlobalProtect servers complain about old versions of the client connecting to them, so we should periodically bump up the version number of the client that we emulate.
See https://gitlab.com/openconnect/openconnect/-/issues/176#note_395207613
.gitlab-ci.yml: run coverity weekly with a scheduled run
This also fixes the image for coverity to fedora31 to avoid
gcc compatibility issues. The reason for moving to scheduled
runs is that there is a limit to coverity runs per project.
Daniel Lenski [Thu, 21 May 2020 17:52:11 +0000 (10:52 -0700)]
re-add socket_wrapper and softhsm support to CentOS8 CI
It appears that a separate Power Tools repository needs to be enabled for `{uid,socket}_wrapper` in CentOS8.
See https://centos.pkgs.org/8/centos-powertools-x86_64/uid_wrapper-1.2.4-4.el8.x86_64.rpm.html and https://serverfault.com/questions/997896/how-to-enable-powertools-repository-in-centos-8
For softhsm, this should work per nmav: https://gitlab.com/openconnect/openconnect/-/issues/145#note_347864560
The auth-nonascii test, and DSA cert tests, are now failing again, and needs to be disabled.
Daniel Lenski [Wed, 14 Oct 2020 23:27:20 +0000 (16:27 -0700)]
fix CI
- dtls-psk is frequently failing; add 1-second wait AFTER tunnel interface appears
- (already merged in !128) CentOS8 now has GnuTLS with client random bug fixed (remove XFAIL_TESTS="dtls-psk")
- (already merged in !128) Fedora 32 needs crypto-policies-scripts package for update-crypto-policies to work
Daniel Lenski [Tue, 28 Jul 2020 21:38:31 +0000 (14:38 -0700)]
enable csd-wrapper.sh/csd-post.sh to run insecurely (no cert validation) for compatibility with ancient cURL
cURL <7.39 doesn't have `--pinnedpubkey` option. Falling back to insecure connection to CSD server (as we did until 4385272562d8e01166f31207938a08bec0a6fc4f) is the easiest band-aid.
CentOS 7 is affected, as described in https://lists.infradead.org/pipermail/openconnect-devel/2020-July/004886.html
Daniel Lenski [Thu, 21 Dec 2017 06:56:58 +0000 (22:56 -0800)]
Protocols should try explicitly request the same IP addresses on reconnect, since they will abort if new addresses are sent by the server.
* GlobalProtect:
- Supported and used by official clients (POST /ssl-vpn/getconfig.esp with preferred-ip form field).
- GlobalProtect servers often give different IP addresses on reconnect if this mechanism is *not* used,
so this mechanism is necessary.
- Same mechanism appears to exist for IPv6 (preferred-ipv6) and was added to OpenConnect in d6db0ec03394234d41fbec7ffc794ceeb486a8f0, even though IPv6 support is not yet complete.
* AnyConnect:
- Not (yet) supported by ocserv
- It appears that *some* AnyConnect server will try to provide the IP address provided in the X-CSTP-Address
*request* header along with the CONNECT request, but other servers appear not to
- This patch reproduces the behavior of GPST: attempt to request same IPv4 and IPv6 addresses on reconnect,
via CONNECT headers.
* Juniper:
- There does not appear to be any way to provide this using the Juniper NC protocol.
- No known reports of Juniper servers giving out different IP address on reconnect.
projects / users / dwmw2 / openconnect.git / log