Daniel Lenski [Tue, 21 Apr 2020 01:51:41 +0000 (18:51 -0700)]
periodic HIP fix: ping /ssl-vpn/hipreportcheck.esp at specified interval no matter what
This is a fix for the very subtle regression between v8.05 and v8.08 described in this thread: https://lists.infradead.org/pipermail/openconnect-devel/2020-April/005609.html
- Server never asks for HIP report submission, and no HIP script specified
with `--csd-wrapper`
- v8.05 successfully rekeys 1 minute before server-specified rekey interval,
and continues successfully
- v8.08 appears to successfully rekey, but then gets forced off one minute
later
- Only apparent difference between the two is that v8.05 re-pings
/ssl-vpn/hipreportcheck.esp every time it gets the config
(/ssl-vpn/getconfig.esp), whereas v8.08 only pings it exactly once.
The bottom line is that _even if_ we have no mechanism to actually submit a
HIP report (no `--csd-wrapper`) and _even if_ we think the server will say
"no HIP report needed" every time we check, in order to keep the server from
kicking the client off, we should still…
* ping /ssl-vpn/hipreportcheck.esp at the interval (specified by the portal or `--force-trojan` or 1 hour default)
* ping /ssl-vpn/hipreportcheck.esp every time we re-fetch the config (/ssl-vpn/getconfig.esp) in order to rekey or reconnect
Daniel Lenski [Mon, 20 Apr 2020 17:14:50 +0000 (10:14 -0700)]
Fix print_supported_protocols and print_supported_protocols_usage
These were broken in 7cb8996e21b442c4ec60ce25c87e8a69516fac17, when the
empty sentinel value at the end of the array was removed, without changing
the way these functions iterate over that array.
For some reason, this continues to work on Linux (probably due to `calloc`
allocating more zeroed bytes than we request, in
`openconnect_get_supported_protocols`), but is causing the expected SIGSEGV on
Solaris:
https://lists.infradead.org/pipermail/openconnect-devel/2020-April/005640.html
Fix:
- Modify `print_supported_protocols` and `print_supported_protocols_usage` to
rely on the length returned by `openconnect_get_supported_protocols`.
- Restore the sentinel value at the end of the array returned by
`openconnect_get_supported_protocols`, to preserve ABI compatibility for
other users who may depend on this sentinel.
David Woodhouse [Mon, 6 Apr 2020 10:20:06 +0000 (11:20 +0100)]
Open /dev/null instead of passing non-functional stderr to CSD trojans
When the auth-dialog is invoked from gnome-shell, it *closes* the other
end of our stderr. Detect this with ferror(stderr), and open /dev/null
instead. This prevents CSD scripts from taking SIGPIPE when writing to
stderr (which we also dup to be their stdout) and aborting.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Sat, 4 Apr 2020 21:27:12 +0000 (22:27 +0100)]
Make csd-post.sh cope with not being able to write to stdout
When invoked from gnome-shell for NetworkManager, curl takes a SIGPIPE
when writing the result of the final POST to stdout. It then exits with
result code 23, causing OpenConnect to whine about an error.
Make it return zero.
Also stop the pidof results making it to stdout when checking for a
process.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 4 Apr 2020 16:45:32 +0000 (09:45 -0700)]
Fix compilation on GnuTLS prior to 3.5.0
The macro gnutls_check_version_numeric, used in b974ed3c5bcccf7045af7ead4b711d0c6dcd5de9, wasn't added until GnuTLS 3.5.0
(and was in fact based on the gtls_ver macro from openconnect)
David Woodhouse [Mon, 30 Mar 2020 23:18:53 +0000 (00:18 +0100)]
Add changelog for RFC6750 bearer token support
Not utterly convinced I like treating it like a soft token; I wonder if
it should have a dedicated callback to the UI, or be handled through
the webview support that we're working on. But there's a release imminent
and this gets people something functional.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Mon, 30 Mar 2020 15:38:12 +0000 (08:38 -0700)]
add OC_PROTO_PERIODIC_TROJAN feature flag
Follow-up to !56. The API is now there for cross-protocol operation, and
oNCP is known to use this too, but only GP protocol currently has support in
OpenConnect.
Daniel Lenski [Tue, 17 Mar 2020 17:15:29 +0000 (10:15 -0700)]
Run Cisco CSD script as child, not daemonized grandchild
This allows us to capture a failure in the CSD script/binary much more
quickly, rather than spinning endlessly (see #108 for one of many examples
where this confuses users).
Tested with both “real” CSD trojan binaries and wrapper script, as well as
`trojans/csd-post.sh`.
GP already does this for the HIP script, and it works fine, including with
NM and Android clients based on libopenconnect.
David Woodhouse [Mon, 30 Mar 2020 11:02:10 +0000 (12:02 +0100)]
String fixes
A couple of cosmetic fixes suggested by "scootergrisen" in
https://gitlab.com/openconnect/openconnect/-/merge_requests/72
https://gitlab.com/openconnect/openconnect/-/merge_requests/73/
Also fix up translations so that they don't get lost and need to
be re-translated.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 2 Jun 2019 23:38:58 +0000 (16:38 -0700)]
oNCP: explain likely meaning of long-puzzling 'error 0x08'
It appears that the 'error 0x08' returned by some Juniper servers in
response to attempted initiation of the oNCP tunnel means that the server
doesn't support, or has disabled, the older oNCP protocol and only supports
the newer Junos Pulse protocol
This conclusion was based on the investigations of
https://gitlab.com/openconnect/openconnect/issues/42.
See also http://lists.infradead.org/pipermail/openconnect-devel/2018-August/005041.html
for a list of past reports of this error.
OpenConnect previously did not support the Pulse protocol at all (see
http://lists.infradead.org/pipermail/openconnect-devel/2019-April/005334.html),
but now has experimental support as of v8.04 (see
https://lists.infradead.org/pipermail/openconnect-devel/2019-August/005396.html).
jethrogb [Thu, 20 Feb 2020 17:43:00 +0000 (18:43 +0100)]
Always send client cert
TLS servers may request a certificate from the client. This request includes a list of 0 or more acceptable issuer DNs. The client may use this list to determine which certificate to send. GnuTLS's default behavior is to not send a client certificate if there is no match. However, we generally always have a specific certificate specified, so we just want to send that regardless.
Originally submitted as PR on GitHub: https://github.com/dlenski/openconnect/pull/164 Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Daniel Lenski [Fri, 27 Mar 2020 03:20:30 +0000 (20:20 -0700)]
ignore failure in downloading CSD stub if CSD wrapper is specified
Resolves the issue reported here:
https://lists.infradead.org/pipermail/openconnect-devel/2020-March/005554.html
Basically, what's happened here is that the Cisco VPN admins have
misconfigured things so that they require running CSD on all platforms, but
the CSD “stub” script specified for Linux _doesn't actually exist_. (They
probably only tested with Mac, Windows, and Android… and never considered
Linux clients.)
That said, the absence of the CSD stub *doesn't even matter* for those who
are running a recent version of `csd-post.sh`, which entirely sidesteps
running the server provided stub and binaries.
Long story short: This patch makes OpenConnect not fail if the CSD stub
can't be downloaded… as long as a CSD wrapper script was specified.
Daniel Lenski [Thu, 5 Mar 2020 02:26:53 +0000 (18:26 -0800)]
allow cipher list overrides with OpenSSL as well
This adds an undocumented `--openssl-ciphers` option.
Both `--openssl-ciphers` and `--gnutls-priority` options now manipulate the same
`vpninfo->ciphersuite_config`, but they should be kept with separate names
to avoid confusion, given that their contents are incompatible.
For reference:
* OpenSSL cipher list documentation: https://www.openssl.org/docs/man1.0.2/man1/ciphers.html
* GnuTLS priority string documentation: https://gnutls.org/manual/html_node/Priority-Strings.html Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Daniel Lenski [Mon, 3 Feb 2020 17:07:34 +0000 (09:07 -0800)]
Always openconnect_close_https() before intermittent HIP check
Even when tunnel is using ESP, attempting to reuse the stale HTTPS
connection from the last round can cause problems (half-open TCP sockets).
See this comment:
https: //gitlab.com/dlenski/openconnect/commit/a8dc68ae3ff9a9d492a839a385cc481d0c4bca73#note_281131962 Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Daniel Lenski [Mon, 27 Jan 2020 03:53:12 +0000 (19:53 -0800)]
HIP timing nitpicks
* If no HIP script was provided, we should only check HIP *once*, to warn
the user. Either the VPN won't work without HIP, or it will… because lots
of GP VPNs lie or don't enforce it.
There's no point in repeatedly checking it and warning about it, though.
* Set last_trojan and trojan_interval in gpst_setup(), not in gpst_parse_config_xml()
The gateway config doesn't actually specify anything about the HIP/trojan
requirements; those come from the portal config.
The HIP check and submission do need to run after connecting to the gateway,
though, because we need to know the client's assigned IP address(es) in
order for HIP submission to succeed.
projects / users / dwmw2 / openconnect.git / log