1. 08 Oct, 2018 6 commits
    • David Woodhouse's avatar
      First pass at proper TPM2 support for GnuTLS using tss2-esys · b7b29a5a
      David Woodhouse authored
      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: default avatarDavid Woodhouse <dwmw2@infradead.org>
      b7b29a5a
    • David Woodhouse's avatar
      Parse TPM2 ASN.1 blob · e1f2bb72
      David Woodhouse authored
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      e1f2bb72
    • David Woodhouse's avatar
    • David Woodhouse's avatar
    • Daniel Lenski's avatar
      Fix GlobalProtect authgroup handling · 72243129
      Daniel Lenski authored
      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: default avatarDaniel Lenski <dlenski@gmail.com>
      72243129
    • Daniel Lenski's avatar
      Fix issue causing front-ends/GUIs to be insensitive to changes in the Juniper realm dropdown · 669c7d3e
      Daniel Lenski authored
      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: default avatarDaniel Lenski <dlenski@gmail.com>
      669c7d3e
  2. 06 Oct, 2018 2 commits
  3. 03 Oct, 2018 8 commits
  4. 01 Oct, 2018 1 commit
  5. 30 Sep, 2018 4 commits
  6. 27 Sep, 2018 1 commit
  7. 22 Sep, 2018 1 commit
  8. 21 Sep, 2018 6 commits
  9. 17 Sep, 2018 1 commit
  10. 08 Sep, 2018 1 commit
  11. 02 Sep, 2018 1 commit
  12. 15 Aug, 2018 2 commits
  13. 09 Aug, 2018 6 commits