]> git.kaiwu.me - haproxy.git/commit
BUG/MEDIUM: ssl: enforce tune.ssl.lifetime across TLS1.3 session renewals
authorWilliam Lallemand <wlallemand@haproxy.com>
Tue, 18 Aug 2026 11:27:17 +0000 (13:27 +0200)
committerWilliam Lallemand <wlallemand@haproxy.com>
Tue, 18 Aug 2026 11:37:54 +0000 (13:37 +0200)
commit9f1d590999c2e881d0deb6d5fe8a38415a7f461a
treea5803ca62ea869d1fd72d76b46a6fe66765bea81
parente80bcb3eacbec961c90cd471fda9ce610d769a07
BUG/MEDIUM: ssl: enforce tune.ssl.lifetime across TLS1.3 session renewals

On TLS 1.3, OpenSSL (and most derivatives) hands out a new session
ticket on every resumption, bumping that session's creation time to
"now" while leaving its timeout untouched. Each renewal therefore gets
a fresh, full "tune.ssl.lifetime" window instead of inheriting what's
left of the original one, so a client resuming just before each
ticket's window closes can keep a session alive indefinitely, well past
its original full handshake's deadline and past any point where a
client certificate would need to be re-verified for expiration or
revocation.

Fix this in ssl_sock_infocbk()'s SSL_CB_ACCEPT_LOOP handler: once per
handshake, clamp the session's remaining budget to what's actually left
of its ORIGINAL lifetime, by rewriting its creation time to "now" and
shrinking its timeout by however much real time has elapsed since it
was created (capped to the currently configured "tune.ssl.lifetime", in
case it was lowered since the session was first issued). Since
OpenSSL's own per-hop duplication only touches the creation time and
leaves whatever timeout is already on the object alone, the shrunk
timeout carries forward from hop to hop instead of resetting, so the
chain still eventually hits its original deadline.

This fix does not carry over to BoringSSL/AWS-LC: on those libs,
it need a different fix instead, handled separately.

Must be backported in every stable branches.
include/haproxy/ssl_sock-t.h
src/ssl_sock.c