Daniel Lenski [Tue, 27 Mar 2018 15:39:58 +0000 (08:39 -0700)]
check for oversize ESP packets, with 256 bytes of headroom above calculated MTU
Because GlobalProtect VPNs have no practical mechanism for negotiating the
MTU whatsoever, it is entirely based on a client-side guess. Therefore,
extra headroom is needed to reliably receive packets via both the HTTPS and
the ESP tunnels.
A similar patch by Nikolay Martynov <mar.kolya@gmail.com> was originally
applied for the Juniper HTTPS tunnel:
http://lists.infradead.org/pipermail/openconnect-devel/2017-May/004320.html
And similar functionality was incorporated into the GlobalProtect HTTPS
tunnel as well (gpst.c).
This patch adds the extra headroom for the ESP tunnel (used by both Juniper
and GlobalProtect VPNs) as well, after unexpectedly-large ESP packets were
observed "in the wild":
https://github.com/dlenski/openconnect/issues/96
Signed-off-by: Dan Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Thu, 31 May 2018 15:25:15 +0000 (18:25 +0300)]
fix typo in Juniper TOTP form name
There's a thread from November 2017 in which Kevin Cernekee and Andy
Wang discuss a Juniper VPN where TOTP fails to work:
http://lists.infradead.org/pipermail/openconnect-devel/2017-November/004569.html
… and in that thread both "ftmTotpToken" and "frmTotpToken" are
mentioned. It appears that the reason for the misbehavior discussed in
the November 2017 is because of the (overlooked) typo in the code.
I'm not sure how the "ftm" version got committed in the first
place. ¯\_(ツ)_/¯. I did a bit of archeological digging, and I can't
find the original patch (from November 29, 2016) anywhere on the
mailing list, but it's obviously in the Git history:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/1ff34cb9689fbaf57decac537df1e32e799bb9c7
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 29 May 2018 13:40:18 +0000 (14:40 +0100)]
Gitlab CI updates
Install 'make' and disable DSA tests on Fedora.
Remove vestiges of CentOS locale stuff which never worked.
Drop libp11 since it doesn't exist in Fedora any more.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 22 May 2018 15:57:10 +0000 (18:57 +0300)]
GlobalProtect can apparently deliver the challenge 2FA forms as XML in addition to JavaScript
This patch also prevents openconnect from reusing the last portal login form
wholesale on the gateway *if* it's a challenge form, since the same auth_id
and 2FA token won't work twice.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:32:00 +0000 (11:32 +0200)]
Add support for checking and submitting HIP reports
Unlike CSD, the HIP security checker runs during the connection phase, not
during the authentication phase.
Therefore we need to build the CSD token (an MD5 digest identifying the
client) without relying on the authentication phase having run in the same
process.
We build it from the cookie containing authentication information,
but exclude the volatile field (which changes from session to session)
and the preferred-ip field (which may not be present in all cases, or may
change from session to session).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:31:59 +0000 (11:31 +0200)]
Add support for GlobalProtect ESP tunnel
Most of the existing ESP support code (written for Juniper/nc) can be reused
for GlobalProtect ESP. The ESP algorithms, SPIs, and keys are sent as part of the
getconfig XML response.
GlobalProtect requires a fairly awkward "tap dance" between the TCP mainloop and
the UDP mainloop in order to support ESP:
* Prior to the getconfig XML request, the HTTPS tunnel will not work (even though
the authcookie is already known from the login response) and the ESP tunnel
also will not work (because the ESP keys are not known).
* After the getconfig XML request, either the ESP tunnel or the HTTPS tunnel can
be connected, but not both. As soon as the HTTPS tunnel is disconnected,
the ESP keys are invalidated. On the other hand, if the ESP tunnel stops
responding due to some firewall that interferes with UDP, the HTTPS tunnel
can still be connected.
* Therefore, in order to allow the ESP tunnel to start, the TCP mainloop must
refrain from actually connecting to the HTTPS tunnel unless the ESP tunnel
is disabled or has failed to connect... but it can't wait *too* long
because then the HTTPS keepalive connection may be dropped, and the user
will wonder why no traffic is flowing even though the VPN has allegedly
started. The wait time is currently hard-coded at 5 seconds (half the DPD
interval used by the official clients).
Another quirk of the GlobalProtect ESP support: it uses specially
constructed ICMP request/reply ("ping") packets as the probes for ESP
initiation and DPD.
* These packets must contain a "magic payload" in order to work.
* In most GlobalProtect VPNs, the packets are addressed to the public, external IPv4
address of the VPN gateway server even though they are sent over the ESP
tunnel (???), but in some cases they must be addressed to a different address
which is misleading described as <gw-address> in the getconfig XML response.
Don't blame me. I didn't design this.
GlobalProtect also has the strange quirk that incoming (server → client) ESP
sequence numbers start at 1, not 0, but this just causes a one-time offset
for the replay protection checker.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:31:58 +0000 (11:31 +0200)]
add PAN GlobalProtect protocol support (HTTPS tunnel only)
This includes support for generating an xmlconfig so that NetworkManager can
list all the gateway servers, when connecting to a GlobalProtect portal (not
gateway):
GlobalProtect distinguishes "portal" and "gateway" servers. Often the same
server supports both (/global-protect URLs are for the portal, /ssl-vpn URLs
are for the gateway). The official clients always connect through the
portal. Mostly, the portal configuration is not useful for OpenConnect; it
restricts the behavior of the official clients.
However, the portal configuration does contain a list of allowed gateways
(just as AnyConnect VPNs can list other servers). We therefore generate an
xmlconfig in the same format as AnyConnect VPNs, so that the NetworkManager
plugins can list all the supported gateways.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 4 Mar 2018 09:31:57 +0000 (11:31 +0200)]
detect user[name], pass[word] form fields using only the first 4 characters
The current process_auth_form_cb hard-codes the interpretation of these form
fields based on their names. GlobalProtect has identical fields but with
slightly different names.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 15 Apr 2018 23:40:35 +0000 (16:40 -0700)]
move sending of ONCP control packets for enabling/disabling ESP into oncp.c
This is another small case of Juniper-specific handling in the ESP code.
The ONCP protocol needs to tell the server to explicitly enable or disable
the ESP tunnel, and uses the same oncp_control_queue for ESP rekeying.
Simplified and refactor by David Woodhouse.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 29 May 2018 11:55:31 +0000 (12:55 +0100)]
Cope with gnutls_pkcs11_obj_get_info() ABI change in 3.6.0
Since 3.6.0, gnutls_pkcs11_obj_get_info() no longer includes the NUL
terminator in the output_size it returns. This was causing fields to
be truncated by one character.
David Woodhouse [Tue, 13 Mar 2018 15:32:19 +0000 (15:32 +0000)]
Fix translation of ESP warning messages
In commit 4daac3fa2e2 ("Save latest ESP sequence number even if replay
protection isn't in use") the messages for discarded packets were mangled
in a horribly untranslatable way. I should know better than that. Stupid
dwmw2; no biscuit.
Thanks to Marek Černocký for pointing it out.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 27 Feb 2018 10:11:16 +0000 (12:11 +0200)]
fix a bug leading to incorrect split-include netmasks
This bug was my fault. Introduced in 881eb286499baf78afbaeff4dbc5f055d23f1e4f on 15 Oct 2016 ("Correctly handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24")
Left shift of >=32 bits is undefined on x86 (https://stackoverflow.com/a/7471843/20789), and it was causing split-includes of 0.0.0.0/0 to output inconsistent values to
the vpnc-script variables for split-includes:
CISCO_SPLIT_INC_12_MASKLEN=0
CISCO_SPLIT_INC_12_ADDR=0.0.0.0
CISCO_SPLIT_INC_12_MASK=255.255.255.255 # generated by netmaskbits() in script.c -- WRONG!
Caught due to an assertion failing in vpn-slice: https://github.com/dlenski/vpn-slice/issues/9
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Mon, 8 Jan 2018 01:54:38 +0000 (17:54 -0800)]
Save latest ESP sequence number even if replay protection isn't in use
In the current source, incoming ESP sequence numbers
(vpninfo->esp_in[vpinfo->current_esp_in].seq) are not actually tracked at
all unless replay protection is in use.
At the time of a rekey, old_esp_maxseq is *set based on the current value of
the incoming seq* at the time of the switchover:
if (new_keys) {
vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
And then esp.c rejects packets with the old incoming SPI, unless seqp < old_esp_maxseq:
This code is supposed to allow a smooth handover from the old incoming SPI
to the new one after a rekey, so that in-flight packets from the old SPI
aren't totally dropped, but also aren't allowed to continue forever.
This patch tracks the latest sequence number even if ESP replay protection
isn't in use -- however inadvisable that may be -- allowing the handover to
work correctly.
This patch also improves the confusing trace message shown when a packet
from the old SPI is received.
[dwmw2: Just call verify_packet_seqno() every time, and let it return an
artificial 'success' when replay protection is turned off. Also
add changelog entry.]
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Ľubomír Carik [Wed, 21 Feb 2018 20:29:31 +0000 (21:29 +0100)]
Windows application icon
This tool is console application only, but many terminals re-use
the icon if exists. In addition window tab-switching with that
terminal window is decorated by this icon as well.
Signed-off-by: Ľubomír Carik <Lubomir.Carik@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Kevin Cernekee [Mon, 12 Feb 2018 01:02:04 +0000 (17:02 -0800)]
android: Re-enable optimization
The introduction of $(EXTRA_CFLAGS) in commit 00f0b80e4befe4
("android: Build ARM with -march=armv7-a") inadvertently overrode the
default "-O2 -g" CFLAGS. Fixing this + enabling Thumb reduces the ARM
libopenconnect.so from ~3.5MB to ~1.9MB.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Kevin Cernekee [Fri, 2 Feb 2018 04:47:15 +0000 (20:47 -0800)]
java: Bump to Java 8
This fixes the following warnings:
[javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5
[javac] warning: [options] source value 1.5 is obsolete and will be removed in a future release
[javac] warning: [options] target value 1.5 is obsolete and will be removed in a future release
Java 8 was released in 2014 so it should be widely available now.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Kevin Cernekee [Mon, 29 Jan 2018 00:56:18 +0000 (16:56 -0800)]
android: Build libraries --with-pic
Recent Android OS releases have become stricter about TEXTRELs in
native code. When built without -DPIC, a few of the libgmp assembly
files generate problematic code sequences:
In this case, adjusting the address at 23f320 would require making .text
writable, which Android does not want to do.
The solution is to specify --with-pic which causes the LEA macro
($GMP/mpn/arm/arm-defs.m4) to embed a PC-relative address into the code,
avoiding the issue.
Tested on ARM + x86.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Kevin Cernekee [Mon, 29 Jan 2018 06:33:58 +0000 (22:33 -0800)]
android: Upgrade liboath
liboath requires minor hacks to build with the latest NDK releases:
1) __freading() cannot be implemented, because older versions of
Bionic[0] do not keep track of the last operation on the stream.
2) Some of the autoconf checks need to be overridden from "cross" to
"yes".
3) Most of the stdio replacement code in gnulib doesn't compile,
because it requires access to internal libc structs. The internals
are no longer exposed through NDK headers, and they vary from one
Android version to the next.
Fortunately, while these hacks would not pass muster upstream, they
are good enough for the special case of compiling liboath.
Kevin Cernekee [Mon, 12 Feb 2018 03:34:22 +0000 (19:34 -0800)]
Fix crash on DTLS resumption
If the mainloop is paused and then resumed, DTLS will attempt to
reconnect at the same time as CSTP. When DTLS-PSK is in use,
gnutls_prf() will be called on a NULL vpninfo->https_sess pointer.
Avoid this by deferring DTLS resumption until CSTP has reconnected, if
DTLS-PSK is in use.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Daniel Lenski [Wed, 21 Jun 2017 18:23:52 +0000 (11:23 -0700)]
try alternate vpnc-script location (used by Debian-based distros)
This patch checks for the vpnc-script in the location used by
the standard vpnc-script package on Debian- and Ubuntu-based
Linux systems, /usr/share/vpnc-scripts/vpnc-script, in addition
to the standard /etc/vpnc/vpnc-script.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:27 +0000 (15:43 -0700)]
add new_keys argument to esp_setup_keys() in preparation for supporting GlobalProtect ESP
The existing ESP key setup code can be almost entirely reused for
GlobalProtect ESP, except for the fact that esp_setup_keys() always
overwrites the secret keys with new random keys.
Since GlobalProtect ESP always uses keys provided by the server, a new
argument is added to esp_setup_keys() to make this behavior optional.
The Juniper-specific code in oncp.c calls it with new_keys=1 in order
to explicitly request it.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:26 +0000 (15:43 -0700)]
add vpn_proto member functions .udp_send_probes and .udp_catch_probe in preparation for supporting GlobalProtect ESP
The existing Juniper ESP code can be almost entirely reused for
GlobalProtect ESP, except for the Juniper-specific code for sending and
recognizing the probe packets used for ESP initiation and DPD.
The Juniper-specific code is moved into functions names esp_send_probes
(sends Juniper probe packets) and esp_catch_probe (recognizes Juniper probe
packet responses), which are called via vpn_proto member functions.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:25 +0000 (15:43 -0700)]
tweak the dtls_state handling in preparation for supporting GlobalProtect ESP
If a protocol wishes to have dtls_state set to DTLS_SLEEPING after closing
UDP, then it must now do so explicitly, because the mainloop will no longer
set it. This patch make both existing protocols set dtls_state explicitly
after closing the UDP connection. (The nc protocol already did so
explicitly, but the anyconnect protocol didn't.)
The previous behavior, wherein dtls_state was *always* set to DTLS_SLEEPING
after closing UDP, was incompatible with the GlobalProtect VPN.
Disconnecting and reconnecting GlobalProtect VPN doesn't just require
require reconnecting the UDP socket and resending probes; it actually
invalidates any previously-obtained ESP secret.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Wed, 14 Jun 2017 22:54:56 +0000 (15:54 -0700)]
relax requirements for Juniper hostname packet response
This fixes the "Unexpected response of size 3 after hostname packet" or "Invalid packet waiting for KMP 301" errors
which I get intermittently when connecting to an old Juniper NC server:
Here's what is going on: this server is (sometimes) concatenating the 3-byte
response packet together with the longer IP-configuration packet that
follows. When they are concatenated together, the server sends only a
single 2-byte length prefix for both (0x01d2 = 466).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:22 +0000 (15:43 -0700)]
factor out common dump_buf_hex() and free_optlist() utility functions
These will be used in GlobalProtect protocol support, so it makes sense
to factor them out into shared utility functions rather than use slight
variants for each protocol.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 14 Aug 2017 10:33:16 +0000 (11:33 +0100)]
Require GnuTLS 3.2.10+ for GnuTLS builds
It's not worth the effort to keep it building for <3.2 any more; nobody
cares... or noticess when we accidentally break it. So kill it; we've
been threatening to for ages.
Use 3.2.10 as the base because 3.2.x before that was broken on Windows.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 14 Aug 2017 09:42:41 +0000 (10:42 +0100)]
Allow reading stdin on Windows instead of forcibly opening console
This was filed against Ľubomír Carik's github project for openconnect-gui;
https://github.com/openconnect/openconnect-gui/issues/101
It isn't perfect, as the ANSI code page on Windows can be different
from the OEM code page used for the console, so fgetws() is likely
to do the wrong thing — which is why we force-opened the console and
used ReadConsoleW() in the first place. But perfect is the enemy of
good in this case, as reading from something other than stdin is
*definitely* wrong. We still use ReadConsoleW() when stdin does happen
to be the console, so that part shouldn't regress.
I hate Windows...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Thu, 25 May 2017 20:15:27 +0000 (21:15 +0100)]
Fix charset handling for --key-password on command line
It was always converting to UTF-8 for input from the terminal; there
was a plausible reason for using the legacy charset as-is but it's
better to be consistent.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Mon, 15 May 2017 04:22:06 +0000 (21:22 -0700)]
store length of ESP encryption and HMAC keys so that they can be manipulated separately for both Juniper and GP
David Woodhouse wrote:
> Daniel Lenski wrote:
>> - unsigned char secrets[0x40];
>> + unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
>
> You're allowed to object to that horridness and split it into two
> separate fields for the encryption and HMAC keys, instead of just
> documenting it.
>
> In fact, one might argue that would be the better approach...
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikos Mavrogiannopoulos [Sun, 5 Mar 2017 10:43:15 +0000 (11:43 +0100)]
Added support for RFC7469 key PIN
That allows the hash provided to the client to be the RFC7469 key PIN.
That is, a base64 encoding of the public key sha256 hash instead of the hex
equivalent. That reduces the number of characters that need to be typed.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 8 Jan 2017 20:27:54 +0000 (12:27 -0800)]
add oncp_bye() to logout the Juniper session
The nc protocol lacked a .vpn_close_session function; without logout, the
VPN cookie remains active and can be used to restart the session, which is a
security hazard—especially when passing around OpenConnect logs on the
mailing list for development and troubleshooting.
Juniper logout is straightforward: GET /dana-na/auth/logout.cgi (with the
appropriate DSID cookie set).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Wed, 19 Apr 2017 20:12:48 +0000 (13:12 -0700)]
enumerate supported VPN protocols via openconnect_get_supported_protocols()
Add two new public functions:
* int openconnect_get_supported_protocols(struct oc_vpn_proto **protos)
Fetches a list of protocols supported by the client. Each supported
protocol has a short name (as accepted by the --protocol command-line
option), pretty name, longer description, and list of flags.
The return value of the function is the number of protocols supported (or
negative if an error occurred).
The flags indicate features that are meaningful for this protocol, to be
used by tools like the Networkmanager configuration UI. Current flags:
* OC_PROTO_PROXY: can connect via HTTP or SOCKS proxy
* OC_PROTO_CSD: supports verification of the client via CSD trojan
* OC_PROTO_AUTH_CERT: supports authentication by client certificate
* OC_PROTO_AUTH_OTP: supports authentication by OATH HOTP/TOTP token
* OC_PROTO_AUTH_STOKEN: supports authentication by RSA SecurID token (stoken)
Frees the list of protocols fetched by openconnect_get_supported_protocols()
The description of the "anyconnect" protocol matches the IETF draft
standard for openconnect VPN (https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikolay Martynov [Fri, 12 May 2017 23:57:29 +0000 (19:57 -0400)]
Do not drop vpn connection if packet arrived is larger than MTU
Sometimes server sends us packets that are larger than negotiated MTU.
Current implementation bails out in this case.
This patch makes openconnect to reserve space and handle incoming packets
that have size up to 16384 (to match CSTP).
This improves connection stability.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikolay Martynov [Thu, 11 May 2017 03:02:59 +0000 (23:02 -0400)]
Do not try to establish DTLS on reconnect if it wasn't established before
Currently when TCP SSL fails reconnect attempt happens. This attempts tries to establish DTLS connection regadless if it existed before. Code ends up in infinite loop doing that.
This changes fixes this by disabling DTLS at startup if DTLS connection cannot be established.
Also change ESP handling code to not reenable DTLS on ESP close.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Piotr Kubaj [Fri, 12 May 2017 13:24:37 +0000 (14:24 +0100)]
Fix build with LibreSSL 2.5.1 and higher.
We don't actually care if we use the read or write state; we're only
calculating the cipher/protocol overheads which are the same in both
directions.
In LibreSSL they were all removed in
https://github.com/libressl-portable/openbsd/commit/122ecd906da7
and the read side was restored in
https://github.com/libressl-portable/openbsd/commit/0d7a7d5f5a44
so just use that.
Signed-off-by: Piotr Kubaj <pkubaj@anongoth.pl> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Wed, 14 Dec 2016 20:30:47 +0000 (20:30 +0000)]
Rely on SoftHSM being installed correctly with a p11-kit .module file
I don't actually remember why I added my own; it *ought* to be installed
correctly by the distribution's packaging of SoftHSM.
There was a brief discussion about my hard-coded version being
Fedora-specific, followed by a suggestion that I could pick up the
proper path from and existing module file, followed by the realisation
that said existing module file would suffice anyway. So just require it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Janne Juntunen [Tue, 29 Nov 2016 22:37:22 +0000 (22:37 +0000)]
Add support for Google Authenticator 2fa on Juniper VPN
We resently changed our Juniper VPN from SMS 2fa to use Google
Authenticator instead. Before it worked perfectly with "openconnect
--juniper" switch, but after the change all we got was:
Unknown form ID 'frmTotpToken'
and a dump of the form.
I spent some time debugging the issue, and managed to write a very
simple fix for it.
Signed-off-by: Janne Juntunen <janne.juntunen@hermanit.fi> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Mike Miller [Wed, 14 Dec 2016 18:02:13 +0000 (10:02 -0800)]
tests: avoid using eval with variable assignments
For shell portability, avoid using eval with variable assignments to set
openconnect's environment. Shell implementations vary on whether
variable assignments in front of eval are marked as environment
variables or just treated as ordinary shell assignments.
Every call to $OPENCONNECT already has LD_PRELOAD=libsocket_wrapper.so
in front of it, so the "eval LD_PRELOAD=libsocket_wrapper.so" was
redundant anyway.
Signed-off-by: Mike Miller <mtmiller@debian.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikolay Martynov [Thu, 17 Nov 2016 03:26:17 +0000 (22:26 -0500)]
IPv6 packet size field doesn't include header size, take this into account
IPv6 packet's 'length' field contains length of payload excluding headers.
Header's length (40) needs to be added to that to get complete packet length.
This patch seems to be fixing random VPN drops.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Dan Lenski [Sun, 16 Oct 2016 01:56:30 +0000 (18:56 -0700)]
Correctly handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24
The existing process_split_xxclude() only handles IPv4 routes
formatted as "10.1.2.0/255.255.255.0", not those formatted as
"10.1.2.0/24".
It's possible to unambiguously distinguish the two and handle the
latter case correctly, because no IPv4 netmask address can possibly
have a decimal integer value <= 32.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 15 Oct 2016 01:46:34 +0000 (18:46 -0700)]
Unset got_cancel_cmd after reacting to it, as is already done for got_pause_cmd
Per David Woodhouse (http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004034.html):
> I think it's probably OK to set vpninfo->got_cancel_cmd=0 in the mainloop
> right before calling proto->vpn_close_session. If we get cancelled
> *again* then we'll give up on that too.
Without this fix, do_https_request() can't be used to close the
session — it interrupts itself as soon as it sees that got_cancel_cmd is
set.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 16 Oct 2016 19:37:58 +0000 (12:37 -0700)]
Make buf_append_urlencoded() percent-encode fewer characters.
Per RFC 3986, the characters '-', '_', '.', '~' don't need to be
percent-encoded anywhere in a URL or query string.
Removed special case for ' ' → '+' to prevent incompatibility with ocserv:
http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004042.html
/* else if (c==' ')
buf_append_bytes(buf, "+", 1); */
Signed-off-by: Dan Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
projects / users / dwmw2 / openconnect.git / log