From: Joel Sing <joel@sing.id.au>
Subject: Re: [BUG] LibreSSL/OpenSSL client fails to decrypt large back-to-back TLS records
To: ?????? <xuyun018@gmail.com>
Cc: tech@openbsd.org
Date: Tue, 22 Jul 2025 01:05:29 +1000

On 25-07-19 09:59:48, ?????? wrote:
> Hello LibreSSL developers,
> 
> I???d like to report a reproducible TLS bug involving LibreSSL or OpenSSL
> clients when receiving large encrypted records from a TLS 1.3 server.
> 
> ???? Description
> When the server sends multiple large SSL_write() calls back-to-back ??? each
> sending about 3MB of data ??? the client (LibreSSL or OpenSSL) fails to
> decrypt after receiving the first 2 or 3 records.
> 
> This happens only when the data is sent without delay.
> If a sleep(2) is added between writes, the issue disappears.
> 
> This suggests that the client fails to handle TCP coalesced (sticky)
> packets, where two TLS records arrive merged in one recv().
> 
> ??? Works with wolfSSL client
> Using a wolfSSL client, the same test works perfectly ??? no errors, even
> with high-throughput record streams and no delay between writes.
> 
> The issue only appears with LibreSSL or OpenSSL clients acting as receivers.
> 
> ???? Reproduction Project (OpenSSL-based)
> A test project is available here:
> ???? https://github.com/xuyun018/openssl_bug_linux
> 
> It includes:
> 
> A TLS client and server program (using OpenSSL APIs ??? LibreSSL compatible)
> 
> The server sends a large file (AA.bmp, >3MB) using multiple SSL_write()
> calls
> 
> No delay between writes
> 
> LibreSSL clients will fail after a few chunks.
> 
> ??? Test Instructions
> Place AA.bmp (size > 3MB), server-cert.pem, and server-key.pem in the same
> directory as the binary
> 
> Build with LibreSSL or OpenSSL
> 
> Run as:
> 
> Server:
> ./program <port> [server-cert.pem] [server-key.pem]
> Client:
> ./program <ip:port>
> With LibreSSL client, you???ll get a decryption error after receiving ~2???3
> records.
> 
> ???? Request
> It seems the TLS record layer in LibreSSL (and possibly OpenSSL) does not
> properly handle consecutive large records arriving in a single TCP packet.
> 
> I hope the LibreSSL team can take a look ??? happy to assist with more
> testing if needed.

TL;DR - the test code is buggy, not LibreSSL.

Unfortunately this is far from a minimal reproducer, however there are
plenty of bugs in the code, one in particular is triggering the problem
that you're seeing. Changing the BIO_new_bio_pair() call to:

  BIO_new_bio_pair(&b, 1<<20, &b1, 1<<20);

will "fix" the problem, but that is really just papering over the real
issue (hint: you should check all of the libssl/libcrypto function calls
that are made and ensure that the return values are actually checked and
handled correctly).