mbox series

[Openvpn-devel,0/2] Stop failed cipher/digest lookups from polluting the OpenSSL error queue

Message ID 20260922140520.71500-1-drew@linuxkids.com
Headers
Series Stop failed cipher/digest lookups from polluting the OpenSSL error queue |

Message

Drew Blokzyl Sept. 22, 2026, 2:05 p.m. UTC 
  This is the root-cause follow-up to the "CRL: cannot read CRL from file"
report (GitHub #1103, PR #1104, which Arne rightly called a symptom fix).

Traced with gdb on OpenVPN 2.7.0 and master against OpenSSL 3.5.5: the
entry that misleads the CRL reload is left by cipher_get() being asked
for the cipher "none". That is the pre-negotiation key_type every server
without --cipher gets (BF-CBC default, not in --data-ciphers), and every
new client instance walks it in do_init_crypto_tls() and the frame/OCC
calculations. cipher_kt_block_size()'s CBC-sibling probe and md_valid()
have the same shape.

Patch 1 makes those probing lookups leave the queue as they found it
(ERR_set_mark/ERR_pop_to_mark, with a wolfSSL fallback in
openssl_compat.h). Patch 2 is the earlier CRL-side change, kept as
hardening: the EOF test now looks at the error PEM_read just raised
rather than the oldest queued one, so no other leftover can produce the
warning either.

Validated on an aarch64 Ubuntu 26.04 server (DCO) with UDP, TCP and
CHACHA20-POLY1305 clients: the queue is empty at multi_create_instance()
and at backend_tls_ctx_reload_crl() entry, three CRL replacements give
three clean reloads (unpatched: three warnings), and a garbage CRL still
fails with "loaded 0 CRLs" / "VERIFY ERROR: CRL not loaded".

Not compile-tested against wolfSSL; the shim is two static inlines.

Drew Blokzyl (2):
  Drop the OpenSSL errors a failed cipher/digest lookup leaves behind
  Make CRL reload EOF detection independent of stale error queue entries

 src/openvpn/crypto_openssl.c | 16 +++++++++++++++-
 src/openvpn/openssl_compat.h | 18 ++++++++++++++++++
 src/openvpn/ssl_openssl.c    | 13 +++++++++++--
 3 files changed, 44 insertions(+), 3 deletions(-)