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

That format got removed before it was ever released...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

This doesn't seem to be needed; all the TPM engines (even v1) handle
the callback properly now.
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>

We should now be able to cope with anything James's tpm2 engine creates,
except for the policies.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

These need to be returned in 5 bytes because they have the top
bit set and would otherwise be interpreted as negative.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

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

In preparation for potentially implementing a version using ibmtss.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

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>