openconnect stoken support not working properly with our form

[Andy Wang]

On Sun, Nov 12, 2017 at 11:16 AM, Kevin Cernekee <cernekee at gmail.com> wrote:
> I worked on the original stoken integration, but have only ever used
> it with Cisco VPNs.  It looks like the Juniper logic was updated in
> this commit:
>
> commit 1ff34cb9689fbaf57decac537df1e32e799bb9c7
> Author: Janne Juntunen <janne.juntunen at hermanit.fi>
> Date:   Tue Nov 29 22:37:22 2016 +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 at hermanit.fi>
>     Signed-off-by: David Woodhouse <dwmw2 at infradead.org>
>
> Maybe the Google Authenticator form (OC_TOKEN_MODE_TOTP) needs to be
> handled differently from the RSA SecurID form (OC_TOKEN_MODE_STOKEN).

I had done some more digging and adding:

+           strcmp(form->auth_id, "ftmTotpToken") &&
+           strcmp(form->auth_id, "frmLogin"))

gets me part of the way there.  The problem is both the 2FA and actual password
forms use the same frmLogin form type and type="password" form field.

I initially thought that was the only problem so I hacked http.c to set a
vpninfo->token_successful (and then skipped generating a token
if that was already successful).

That still didn't solve my problem and I used --dump-http-traffic and see that
the stoken code being sent is completely different than what
the stoken command actually generates.  I had no idea why that would
have been the case.

That's where I was last at when I put this aside to get real work done :)

Andy