GnuTLS: Print more relevant information in the case of a fatal TLS alert
End users are frequently confused by "TLS fatal alert" messages. These are
commonly caused by bad (incorrect/expired/mismatched/missing) client
certificates.
Rather than printing a generic "TLS fatal alert" message, we can get GnuTLS
to provide a message about this specific alert.
Before:
$ openconnect -c cert-and-key-for-wrong-domain.pem vpn.company.com
SSL negotiation with vpn.company.com
SSL connection failure: A TLS fatal alert has been received.
Failed to open HTTPS connection to vpn.company.com
Failed to complete authentication
After:
SSL connection failure due to fatal alert: Certificate is bad
The analogous OpenSSL code already prints a relevant—though cryptic—message
about the specific alert (e.g. "SSL3_READ_BYTES:sslv3 alert bad certificate").
Signed-off-by: Daniel Lenski <email address hidden>
Ignore blank labels sent in GlobalProtect prelogin
Some GlobalProtect servers will apparently send prelogin XML with
blank/empty contents for tags that are supposed to contain human-readable
labels (`<authentication-message/>`, `<username-label/>`,
`<password-label/>`). See https://gitlab.com/openconnect/openconnect/-/issues/561
for an example of such a server.
We should simply ignore these blank labels, and continue to use our default
labels, rather than give the form fields confusingly-blank labels. Happily,
our `xmlnode_get_trimmed_val` function will do this automatically for us.
As if there's isn't enough confusion surrounding this very unloved protocol,
the corporate ownership and branding of Juniper/Junos/Ivanti Pulse servers
has changed over the past decade.
Our docs should reference all the names that users might recognize.
Also expand the docs' explanation of the relationship and differences
between Pulse and Juniper NC protocols, and the completeness of our
implementations.
Signed-off-by: Daniel Lenski <email address hidden>
09d9f6f...
by
Dimitri Papadopoulos Orfanos <email address hidden>
Merge branch 'lzo' into 'master'
Latest version of lzo.c and lzo.h
See merge request openconnect/openconnect!443
39619a5...
by
Dimitri Papadopoulos <email address hidden>
Apply local changes to lzo.c and lzo.h
The idea is to add to lzo.h whatever is necessary to lzo.c, in order to
avoid including other FFmpeg header files.
* FFMAX: copied as is from libavutil/macros.h
* AV_COPY32U: rewritten, original in libavutil/intreadwrite.h
* av_memcpy_backptr: rewritten, original in libavutil/mem.c
* av_assert0: adapted from avassert.h
1218766...
by
Dimitri Papadopoulos <email address hidden>
Latest version of lzo.c and lzo.h
Both files are part of current release 5.1.2 of FFmpeg from 2022-09-25:
* lzo.c: commit 636631d9 from 2022-02-24
* lzo.h: commit e427ba5c from 2019-05-02
