Summary

When receiving multiple consecutive TLS records from a TLS server (e.g., multiple 4MB chunks via SSL_write()), the OpenSSL or LibreSSL client frequently fails inside SSL_read() with:

error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt

This only happens when the records are sent without delay — for example, in a loop without sleep() or artificial throttling. If a sleep(2) is inserted between each chunk, the problem disappears.

In contrast, using wolfSSL as the client handles the exact same data stream without issue — no sleep() is needed, and all records are parsed correctly.

This suggests OpenSSL and LibreSSL are unable to correctly handle consecutive TLS records over a TCP stream unless the records arrive with time gaps. This may indicate a state machine robustness issue in SSL_read().

Reproduction Code

Client + Server demo:
https://github.com/xuyun018/openssl_bug_test

Tested combinations:

• wolfSSL client ✅ — works correctly
• OpenSSL client ❌ — fails unless sleep() is inserted
• LibreSSL client ❌ — same as OpenSSL

Suggested Behavior

Clients should not rely on delays to parse TLS records correctly. The TLS implementation should be able to handle concatenated records from a TCP stream, as TCP is inherently stream-oriented and record boundaries are not preserved.

This appears to be a robustness issue in how OpenSSL / LibreSSL process buffered input, and should ideally be fixed or documented clearly.