Daniel Lenski [Thu, 9 Apr 2020 00:35:48 +0000 (17:35 -0700)]
GP auth: give challenge/2FA forms a constant auth_id/name of "_challenge"
Until now, we've been using the `inputStr` value (hex token that has to
accompany challenge form submission) as the `auth_id` for challenge forms,
but it appears these values aren't fixed from run-to-run, which makes it
impossible to use `--form-entry` to fill them out.
This patch makes all challenge forms have `auth_id=_challenge`, so they can
be filled with `--form-entry=_challenge:passwd=VALUE`. The `inputStr` value
will now be shoehorned into `form->action`.
Unless we find a GP VPN that uses multiple independent challenges (3FA?),
this should work better.
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.
David Woodhouse [Wed, 15 Jan 2020 13:11:58 +0000 (14:11 +0100)]
http: Retry request (once) on error receiving response
A Juniper server has been encountered in the wild which sends an initial
302 redirect without Connection:close, but then just closes the connection
when it receives the next request.
This happens only for the first redirect to /dana-na/auth/… and not for
subsequent redirects through cookie-check and realm stuff. So instead of
a preemptive hack to avoid connection reuse for *all* redirects in NC,
just cope with it when it happens.
Since rq_retry is only set when the connection is already open, it won't
get set again the second time round, thus avoiding endless retries.
Fixes: #96 Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 30 Dec 2019 00:36:15 +0000 (00:36 +0000)]
Update translations from GNOME, prioritising GNOME translations
Previously, translations from NetworkManager-openconnect have only been
pulled in if there was no existing translation in OpenConnect. Since the
GNOME translations are maintained and corrected, it's better to let them
overide the ones in OpenConnect.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
projects / users / dwmw2 / openconnect.git / log