If R or S have the top bit set, we need to prepend a zero byte to prevent
them from being interpreted as negative.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

For auto-provisioning via NetworkManager it's actually quite useful to be
able to set vpninfo->cert_password and have that special case handled,
instead of having to inject the password into the user's keyring somehow.

It's either that or revise the FSID hack...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Various caveats, including the complete lack of authentication, lack
of EC and policy support, hard-coded use of PKCS#1 padding, etc.

But hey, it works for my test case.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

When connecting to a GlobalProtect server via the portal interface, then
`vpninfo->authgroup` needs to be set to the URL of one of the allowed
gateways.

The problem here is that if the user actually wanted to select the _first_
gateway in the dropdown list, it was already pre-selected, and thus clicking
"continue"/"login" on the form wouldn't trigger `OC_FORM_RESULT_NEWGROUP`.

This would prevent `vpninfo->authgroup` from getting set correctly, and the
gateway redirect would be skipped entirely.  Thus it was effectively
impossible to select the first option in the gateway dropdown.
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

This has been a persistent, puzzling issue
(http://lists.infradead.org/pipermail/openconnect-devel/2018-July/004926.html,
http://lists.infradead.org/pipermail/openconnect-devel/2017-November/004558.html,
etc.).  When connecting to a Juniper VPN from a front-end (e.g.
NM-OpenConnect, OpenConnect-GUI for Windows, OpenConnect for Android),
changing the selected realm/`authgroup` in the drop-down box causes the form
to immediately reload *without* saving the change.

This turned out to be a rather subtle issue…

The meaning and usage of `vpninfo->authgroup` differs across the different
protocols, which made this hard to isolate.

* With AnyConnect, changing the authgroup value in the form is supposed to
  trigger an immediate reload of the form, since the form contents can
  differ from one authgroup to another.  Hence a `process_auth_form`
  callback should immediately return `OC_FORM_RESULT_NEWGROUP` when the form
  value changes.
* With Juniper, the authgroup dropdown don't *actually* need to trigger a reloading
  of the form, since the form won't change if the authgroup field changes.
  (At least not on any Juniper VPN I have access to.) However, it doesn't
  hurt anything either, and setting the dropdown as `form->authgroup_opt`
  allows CLI users to specify the desired setting with `--authgroup`, which
  is very convenient.
* With GlobalProtect, the authgroup has been repurposed to represent the desired
  *gateway* to connect to, in the cases where the user is connecting via the
  *portal* interface.  The authgroup selection always appears in a form by
  itself, currently.  This similarly allows CLI users to pick the desired
  gateway with `--authgroup`.

Long story short, the problem here was that `form->authgroup_selection`
needed to be set to a specific index (within `form->authgroup_opt->choices[]`)
 of the currently selected value, in order
for the GUI to show the right value as selected.  If this wasn't set, then
every time the selection was changed (causing the form handler to return
`OC_FORM_RESULT_NEWGROUP`), the selected index would revert to `0` on the
next iteration of the form.

For AnyConnect, the `form->authgroup_selection` was already set correctly;
for Juniper and GlobalProtect, it wasn't.  It seems to me that the most
robust fix here is to ensure that `process_auth_form` itself always sets
`form->authgroup_selection` to the index of the value matching
`vpninfo->authgroup` _before_ handing the form off `process_auth_form_cb`.

Tested that this change makes Juniper realm dropdowns work correctly in the
NM-OpenConnect and Android front-ends.
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Don't segfault when search domain list is empty (and thus `domains->pos == 0`)

See merge request openconnect/openconnect!11

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

This doesn't do anything useful at all yet. It would be nice if the two
available OpenSSL engines were actually compatible.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

TPM2 support wants its own BOOL definition which conflicts with the
"standard" Windows one from libpcsc. Let's just isolate things so that
we only need to include PC/SC header files from within yubikey.c.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

The protocol should validate which form fields are OK; no need to apply
CSTP-specific filters (which are now out of date) in the yubikey code.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

This was found in the wild on an AnyConnect instance which is hooked up
to a Microsoft 2FA platform.
Signed-off-by: James Laird-Wah <james-oc@laird-wah.net>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

GlobalProtect: query and parse prelogin.esp and use it to build auth forms, including preliminary SAML support

Until recently, I've believed the prelogin.esp to be useless, because the
initial GlobalProtect login form always contains the same two fields:
username and password.

However, the prelogin response is also important for signalling when SAML
login is required.  When the VPN uses SAML login, the official GP clients
redirect the user to a web-based authentication flow (e.g.  Okta,
https://github.com/dlenski/openconnect/issues/116).

That auth flow eventually sends the official client back to the GP VPN,
armed with a special cookie field, `portal-userauthcookie` or
`prelogin-cookie`, that needs to be submitted in place of the password
(already supported by openconnect as of 8b2bc5f2).

This preliminary SAML support simply includes the SAML method and URL in the
form banner, and fails with an error message if the cookie field name was
not specified (since it cannot be autodetected).
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

* replace GPST-specific xmlnode_get_text() with global xmlnode_get_val(), and make it free existing values (simplifies config loading)
* don't deal with numeric error codes in gpst_xml_or_error, only parsing
* make gpst_xml_or_error take 2 calbacks: one for XML, one for challenge (whether in XML or JavaScript form)
* allow callbacks to take cb_data
* use all this to simplify form handling
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

We should look at whether we want to do this natively (probably not; we
should rely on the OpenSSL STORE mechanism instead), and we should
definitely look at how we're going to do it for GnuTLS. But this is a
start...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

Code to set UID, GID according to csd_user was factored out into set_csd_user().
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

command-line client should fill in any password-type field with value supplied via --passwd-on-stdin

See merge request openconnect/openconnect!6

I previously proposed adding form field hints to suggest which fields should
be populated with username/password values.  David Woodhouse was hesitant to
accept this and we settled on matching the form field names by the first
four characters ("user", "pass") as a temporary compromise:

    http://lists.infradead.org/pipermail/openconnect-devel/2017-August/004458.html

There's at least one specific case where this interferes with the
usage of the command-line client: some GlobalProtect users need to
specify an "alternative secret field" instead of the default "passwd"
field (using `--usergroup :field_name`).

Because this field's name normally doesn't start with "pass", openconnect
won't accept it via `--passwd-on-stdin`:

    script_to_do_fancy_GlobalProtect_SAML_login |
      openconnect --protocol=gp -u user --passwd-on-stdin --usergroup portal:portal_cookie_field_name globalprotect.company.com

As far as I can tell, there's not actually any good reason why openconnect
should *only* fill in a password-type field with the supplied password
if its name starts with "pass", so we should get rid of that check.
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Always set `clientos=Windows` in GlobalProtect requests

See merge request openconnect/openconnect!5

I've tried, whenever possible not to lie to the server about the client
configuration.  However, there are now multiple cases where a GlobalProtect
server responds with a misleading error when the `ssl-vpn/login.esp` request doesn't
contain the exact, magic value of `clientos=Windows`.

* https://github.com/dlenski/openconnect/issues/86
  ("Assign private IP address failed" unless `clientos=Windows` in `ssl-vpn/login.esp` request)

* https://github.com/dlenski/openconnect/issues/116
  ("Invalid username or password" unless `clientos=Windows` in `ssl-vpn/login.esp` request)

These cases are very difficult to debug because they seem to be suggesting totally unrelated
errors.

For reliability, this patch makes openconnect always specify `clientos=Windows` in relevant
requests, regardless of the actual `vpninfo->platname`. (The `vpninfo->platname` value can
still be sent in the "free-form" `os-version` field, as far as I can tell.)
Signed-off-by: Daniel Lenski <dlenski@gmail.com>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>