The name '--usergroup' exists purely for historical/Cisco-specific reasons.
Its function is simply to override the *path* of the URL for the initial
HTTPS request to the server.
Thus 'openconnect --usergroup loginRealm vpn.server.com'
and 'openconnect https://vpn.server.com/loginRealm' are entirely equivalent;
with most front-ends, specifying the URL directly is the only way to set the
path.
Signed-off-by: Daniel Lenski <email address hidden>
The `--authgroup=GROUP` option is specifically designed for this purpose: it can enter
a value into "the right" dropdown/list field on multiple protocols:
- Cisco AnyConnect/ocserv: "authgroup" selection form field
- Juniper: "realm" OR "frmSelectRoles" selection form field
- Pulse: "realm" selection form field
- Fortinet: "realm" selection form field
- F5: "domain" selection form field
- GlobalProtect: "gateway" selection form field (found on the "portal" interface;
this one actually controls the choice of gateway server)
The functionality of the `--authgroup` option is not as obvious as
it could/should be because the name "authgroup" is Cisco-specific.
This patch improves the `--help` output and openconnect(8) man page to
show that it works with other protocols as well, and mention the names
of the relevant fields for those protocols.
Signed-off-by: Daniel Lenski <email address hidden>
6246bbd...
by
Dimitri Papadopoulos Orfanos <email address hidden>
Merge branch 'const' into 'master'
Fix constness again in HKDF/HPKE-related functions
Explain why explicit proxying usually doesn't work in MITM docs
Simply put, many VPN clients *ignore* an explicitly-set browser/system
proxy, whether as an intentional anti-MITM measure or as a consequence of
inconsistent and incompetent design and coding.
This is why transparent proxying is generally necessary in order to reliably
MITM a proprietary VPN client.
# Configure fake server for SAML on the portal interface
$ curl -sk https://localhost:8080/CONFIGURE -d portal_saml=portal-userauthcookie -d portal_cookie=portal-userauthcookie
The goal of this is to have a SAML-supporting GP server to test against
while modifying openconnect to directly call the GP SAML webview handler
itself (see https://github.com/dlenski/gp-saml-gui/issues/45).
Signed-off-by: Daniel Lenski <email address hidden>
Rework GP fake server to have a persistent configuration
Until now, all of our Flask-based servers for testing protocol
authentication flows have "cheated" a bit.
They're configurable (e.g. should the authentication require a 2FA token,
or should it not?), but this configuration has not actually been persisted
by the server.
Instead, the server sends the client a session cookie which has the desired
*server* configuration glommed into it, and relies on the client sending
this cookie back on every request (which OpenConnect obliges, for
authentication requests) so that the server can "remember" what it's
configured to do.
This is very confusing to read and understand, and it's also untenable to
continue using it for fake servers that simulate external authentication
(SAML/SSO). That's because external authentication uses a separate
browser/handler for the authentication flow, so it won't share the session
cookies.
This modifies the fake GP server to store a persistent in-memory
configuration which can easily be set and inspected with cURL:
$ ./fake-gp-server localhost 8080 certs/server-{cert,key}.pem 2>&1 >/dev/null &
$ curl -sk https://localhost:8080/CONFIGURE -d gw_2fa=1
$ curl -sk https://localhost:8080/CONFIGURE
Current configuration of fake GP server configuration:
TestConfiguration(gateways=('Default gateway',), portal_2fa=False, gw_2fa=True, portal_cookie=None, portal_saml=None, gateway_saml=None)
$ openconnect --protocol=gp localhost:8080
Please login to this fake GP VPN portal
Username: fakeusername
Password: *******
...
2FA challenge from gateway
Challenge:
Clearer error for list-system-keys on Unix-like platforms
It appears that the `gnutls_system_key*` functions are only implemented on
Windows currently. Lots of people are likely to test this executable on
Unix-y systems, so we should give a clearer error message.
Signed-off-by: Daniel Lenski <email address hidden>
