StreamSec Tools 4.1.5.362 was released on 2026-10-26 and is in the Download Area now. Security support for this release runs until 2031-10-26. Its change log, CHANGES_4.1.5.362.txt, and its SBOM are attached to this post.

The headline of this release is QUIC and HTTP/3.

A COMPLETELY INDEPENDENT QUIC IMPLEMENTATION

The QUIC transport in 4.1.5 (RFC 9000) is our own, written for the library from the RFCs. It contains no code from MsQuic, OpenSSL, quiche or any other QUIC stack, and it does not call into one. Packet protection, loss recovery, congestion control, pacing, connection migration and ECN are all Object Pascal, built on the same TLS 1.3 handshake and the same cryptographic code as the rest of StreamSec Tools. The SBOM lists no third-party QUIC component, because there is none.

It is cross-platform in the same way as the rest of the library. The QUIC components compile for every platform the library targets - Windows 32- and 64-bit, macOS, Linux, iOS and Android - with Delphi XE3 through 13 Florence (Linux from 10.3 Rio, iOS and Android from 10.4 Sydney). They run on each system's own event mechanism: I/O completion ports on Windows, epoll on Linux, kqueue on macOS. We test them on Windows, Linux and macOS.

On top of it:
- HTTP/3 (RFC 9114) with QPACK. TsmAsyncQUICServer and its TsmHTTPSv3 plugin serve HTTP/3 from the same request router as HTTP/1.1 and HTTP/2, so a handler you already have answers HTTP/3 unchanged.
- TsmHTTPSClient speaks HTTP/3 when you enable it, and finds a server's HTTP/3 endpoint through Alt-Svc.
- The SNIF remoting framework runs over QUIC, as well as over SSH and TLS.
- Retry address validation, bounded per-connection input, and 0-RTT early data only as an explicit opt-in.

PERFORMANCE IN THE SAME CLASS AS MsQUIC AND OPENSSL

We benchmarked our stack against Microsoft's MsQuic 2.6.3 and OpenSSL 3.5.9 on two Windows PCs connected over Wi-Fi: each library sending bulk data to each library, in both directions, eight interleaved rounds per combination. Sending to a StreamSec or an MsQuic receiver, the median throughput was 35.3 to 41.0 MiB/s for StreamSec, 41.0 to 46.0 MiB/s for MsQuic and 22.5 to 31.8 MiB/s for OpenSSL.

So our stack sent faster than OpenSSL in all four of those combinations, and reached 82 to 95 percent of MsQuic's throughput. In CPU time per transferred gigabyte it was close to OpenSSL, 11 to 16 CPU-seconds against OpenSSL's 9 to 15; MsQuic was the most frugal of the three, at about 3.

A BUG IN OPENSSL'S QUIC, FOUND IN INTEROPERABILITY TESTING

We test QUIC and HTTP/3 against implementations we did not write: aioquic, a client built on MsQuic, and OpenSSL. That testing turned up a bug in OpenSSL's QUIC implementation.

An OpenSSL endpoint that receives on a stream extends the sender's credit with MAX_STREAM_DATA frames. If the packet carrying the latest of those is lost, and that packet carried no data for the stream, OpenSSL never sends the update again - although RFC 9000, section 13.3, requires it to. The sender then waits for credit that never comes, and the stream stalls for good. A client that sends a short request and reads a long response is exactly that case.

We found it because the OpenSSL client stalled in every one of 32 benchmark runs against our server, which under load discards incoming datagrams it cannot queue, as any UDP server may. With OpenSSL at both ends, over a path that loses 5 percent of the client's packets, unpatched OpenSSL 3.5.9 stalled in 6 of 13 runs; with a fix in two places it completed all 13. We reproduced the stall with 3.5.7 and 3.5.9 and reported it to the OpenSSL project on 2026-10-24, with a reproducer and the fix: openssl/openssl issue 33373. OpenSSL has triaged it as a bug on its 3.5, 3.6, 4.0 and 4.1 branches and on master. The OpenSSL figures above were measured with that fix applied.

ALSO IN THIS RELEASE

- SSH: the sntrup761x25519-sha512 post-quantum hybrid key exchange (RFC 9941), which OpenSSH also offers.
- HTTP/2 brought in line with the MUST-level rules of RFC 9113 and RFC 9110.
- The embedded CCADB root set is refreshed: the three emSign roots that Mozilla no longer lists for websites are removed.

There are some 150 entries in all. Ten are marked BEHAVIOUR CHANGE, the root set among them; please read those before you upgrade.

Evaluation builds for Delphi XE3 to 13 are on the download page, and the HTTP stack, HTTP/3 included, is described here