Commit 82733d90b5 for openssl.org
commit 82733d90b5bc58b8d064ed49c282aa028664a1ed
Author: Jakub Zelenka <jakub.zelenka@openssl.foundation>
Date: Tue Sep 1 19:16:02 2026 +0200
test: tolerate DTLS peer change with fragment data
In the DTLS variant of the TLS 1.3 HRR tests a large key share can
split the server's flight across two datagrams, leaving the proxy
with an incomplete message fragment when the client rejects the
ServerHello and its alert arrives first. The proxy treated any peer
change with pending fragment data as fatal and died, aborting the
whole test recipe. This made the no-ec run-checker build fail
intermittently, since only the ffdhe key shares are large enough to
force the fragmentation.
A DTLS peer may legitimately abort mid-flight, so discard the stale
fragment data and carry on instead. TLS keeps the strict behaviour.
Assisted-by: Claude:claude-fable-5
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
Merge-date: Fri Sep 4 17:40:52 2026
Merged-from: https://github.com/openssl/openssl/pull/32630
diff --git a/util/perl/TLSProxy/Message.pm b/util/perl/TLSProxy/Message.pm
index 1826616ef1..6c11609aef 100644
--- a/util/perl/TLSProxy/Message.pm
+++ b/util/perl/TLSProxy/Message.pm
@@ -204,7 +204,21 @@ sub get_messages
@message_frag_lens = ();
if ($serverin != $server && length($payload) != 0) {
- die "Changed peer, but we still have fragment data\n";
+ if ($isdtls) {
+ # A DTLS peer can abort mid-flight, e.g. with an alert rejecting
+ # the ServerHello, while a message fragment from the interrupted
+ # flight is still incomplete. Discard the stale fragment data.
+ print "Changed peer with incomplete fragment data, discarding\n";
+ $payload = "";
+ $messlen = -1;
+ $messseq = -1;
+ $messfraglen = -1;
+ $messfragoffs = -1;
+ $startoffset = -1;
+ @message_rec_list = ();
+ } else {
+ die "Changed peer, but we still have fragment data\n";
+ }
}
$server = $serverin;