openconnect+OpenSSL failing DTLS handshake with ocserv+GnuTLS

[Daniel Lenski]

On Wed, Jul 7, 2021 at 7:05 AM Vuille, Martin (Martin)
<vmartin at avaya.com> wrote:
>  Client is invoked with the command:
>
>        openconnect --protocol=anyconnect -c user-cert.pem -k user-key.pem --cafile=ca-cert.pem --dump -vvv 10.215.0.62:8443
>
> DTLS handshake fails, server logs show:

Can you reproduce the server error with 'openssl s_client'? E.g.
something like the following, perhaps futzing with -psk* options in
addition to -dtls/-dtls1/-dtls1_2…

   openssl s_client -debug -dtls -connect 10.215.0.62:8443

> I'm about to start digging into the code, but hoping this might be "obvious"
> to someone with more experience with openconnect and DTLS.

This is definitely not obvious to me.

Your version ("v8.05-275-g9d287e4") is the commit which is tagged as
v8.10, but your build of OpenConnect represents it as "v8.05 + 275
further commits". Effectively, you're running OpenConnect v8.10 here.
We do have an automated test of OpenConnect's ability to connect to
ocserv using PSK
(https://gitlab.com/openconnect/openconnect/-/blob/master/tests/dtls-psk),
which is working on recent OpenSSL builds. We're not running the exact
same OpenSSL library version or ocserv version, nor do we have any
automated testing of the client on arm/aarch64. We *have* made some
post-v8.10 changes that affect the choice of DTLS 1.0/1.2 handshake,
although nothing that was intended to address an issue resembling this
one.

One approach would be to try to git-bisect the code forward (from
v8.10/9d287e4 to current master) and backwards (from v8.10/9d287e4 to
???) and see if you can find a client-side change where it
starts/stops working. May find nothing… I'm not confident that this is
an issue in the OpenConnect client itself.

Dan