From: 许云 <xuyun018@gmail.com>
Subject: [BUG] LibreSSL/OpenSSL client fails to decrypt large back-to-back TLS records
To: tech@openbsd.org
Date: Sat, 19 Jul 2025 09:59:48 +0800

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.

Best regards,
xuyun018