Small surface
Support the environment and protocols nxTLS actually needs. Compatibility is not a goal by itself.
project 02 · nxTLS · 2026 reboot
Small HTTPS stack.
Strong opinions.
Upstream stays upstream.
nxTLS is a deliberately small, modern HTTPS stack built from nginx, BoringSSL and strong opinions. It keeps the judgment behind nsb2 and TinX — narrow surface, current protocols, explicit crypto policy and first-class hardening — without inheriting their fork-heavy implementation model.
Current state · 18 October 2026: refreshed upstream pins, verified baseline.
nginx 1.31.7 + pinned BoringSSL build and pass the required checks.
BoringSSL: 24/24 native invocations and 11,076/11,076 protocol cases.
HPACK, QPACK, TLS-record and QUIC-reload smoke checks passed within scope.
nginx 1.31.7 + pinned BoringSSL build and pass the required checks.
BoringSSL: 24/24 native invocations and 11,076/11,076 protocol cases.
HPACK, QPACK, TLS-record and QUIC-reload smoke checks passed within scope.
nginx 1.31.7 · BoringSSL 594a442… · Clang 21.1.8
Debian Testing · amd64 · validated 2026-10-18
01 / INTENT
Keep the ideas. Drop the ownership tax.
nxTLS is a clean 2026 reboot, not a continuation of the old source trees. Historical code is evidence and engineering archaeology; current upstreams and current decisions define the implementation.
The ideas were worth keeping.
Owning the entire implementation was not.
nsb2 and TinX pushed hard on small surface area, TLS 1.3, X25519, post-quantum experimentation, Clang-first development, fuzzing and explicit policy. nxTLS keeps those instincts while changing the maintenance model: nginx remains recognisable nginx, BoringSSL remains recognisable BoringSSL, and project-owned code lives at the policy and integration boundary.
The philosophy survives. The fork debt does not.
Upstream first
Prefer maintained upstream behavior, then project-owned integration, then the smallest patch that is actually necessary.
Explicit policy
TLS, crypto, platform and build choices belong in visible project decisions rather than historical defaults.
Evidence first
Experiments answer questions. They do not silently become architecture decisions merely because they worked once.
02 / ARCHITECTURE
Own the boundary, not the universe.
The accepted direction is intentionally simple: pinned upstream components, a small nxTLS-owned policy/integration layer, minimal patches, and one primary Debian product. The exact final artifact boundaries are still being worked out.
BoringSSL
Pinned exact commit. Production cryptography comes from maintained implementations rather than a new project-owned crypto fork.
→
nxTLS policy
Integration, TLS/crypto policy, build logic, tests and the narrow code that makes the product intentionally smaller.
→
nginx
Pinned release, recognisable upstream source, with only narrowly scoped integration where a project requirement actually needs it.
→
nxTLS
One repository, one primary Debian package, modern HTTPS behavior and a deliberately reduced support surface.
accepted decisions
What is already fixed.
nginx and BoringSSL are pinned third-party upstreams. No global upstream renames. BoringSSL should remain unmodified whenever possible. Vendoring is explicit. The eventual release build must be offline-capable. The target is deliberately Debian Testing, amd64 and current Debian Clang/LLVM.
open design
What is deliberately not fixed yet.
Final artifact relationships, whether libnxtls.so belongs in the product architecture, BoringSSL symbol isolation, the nginx integration boundary, public/internal API boundaries, exact CLI scope and final runtime layout remain open questions.
03 / CONFIGURATION POLICY
nginx owns the language.
nxTLS owns the policy.
Upstream nginx sample configurations are reference material, not product defaults. nxTLS keeps familiar nginx semantics, but will ship its own small, tested configuration baselines built from the supported surface and operational lessons learned.
profile / compatibility edge
Compatibility gets a cage, not equal status.
HTTP/1.0 is rejected. HTTP/1.1 is a deliberately constrained compatibility lane with tighter connection, timeout and expensive-route budgets. HTTP/2 gets the normal modern TCP path. HTTP/3 is enabled as its own QUIC edge.
The profile exists for real production environments where selected legacy clients, provider callbacks or operational tools still need H1. Exceptions stay narrow and do not become trust.
profile / h3 first
HTTP/2 says hello. QUIC takes over when it can.
HTTP/1.x is outside the intended surface. HTTP/2 is the bootstrap and TCP fallback: establish the origin, advertise HTTP/3, and keep a working path when UDP is unavailable. HTTP/3 is the preferred steady-state transport.
This profile is for deliberately modern sites that do not need an H1 compatibility contract at all.
Project-owned defaults
Vendored nginx may still contain its upstream examples, but nxTLS does not install or inherit them as its product configuration baseline.
Shared invariants
Unknown hosts fail closed, protocol exposure is explicit, resource budgets are finite, TLS policy is inherited from nxTLS, and logging is sufficient to explain the resulting behavior.
Profiles, not brands
Real deployments provide the evidence. The shipped profiles describe reusable operational contracts rather than being named after a particular site or company.
Test the samples
A shipped configuration is part of the product contract. Automated runners should prove its positive and negative protocol behavior instead of treating it as passive documentation.
Hardening input, not copy-and-paste: the nginx edge-security field guide informs these profiles, but deployment-specific Lua policy, crawler classes and bypass-sensitive rules do not become universal nxTLS defaults.
Related research / a possible nxTLS add-on: Response-Aware Edge Security asks whether the nginx-to-backend handoff can carry a trustworthy enforcement context for request-caused execution, without restricting unrelated legitimate work. Native denial has been demonstrated; a request-to-operation binding has not. RAES remains a research question, with no production guarantee or selected mechanism. nxTLS's small HTTPS-stack scope is unchanged; R1–R4 are historical experiment archives.
04 / CURRENT BASELINE
Make the boring build work first.
Before pruning modules or inventing product abstractions, nxTLS established that the pinned upstreams build and work together cleanly on the intended toolchain.
verified
BoringSSL baseline
The refreshed pinned commit builds unmodified with Clang, libc++, LLD, CMake and Ninja. The upstream checks passed: 24/24 native invocations, 11,076/11,076 protocol cases, five Go packages and generated-file checks.
verified
nginx + BoringSSL
Official nginx 1.31.7 builds unmodified against the refreshed pinned BoringSSL. The baseline and isolated experiment binaries use static BoringSSL; no dynamic system libssl.so or libcrypto.so dependency was found.
accepted
Top-level CMake
The root CMake project is the canonical build entry point. It orchestrates BoringSSL through upstream CMake and nginx through upstream configure/make without replacing either build system.
experiment
Symbol-boundary spike
A focused experiment completed a TLS 1.3 HTTPS handshake through a test libnxtls.so with prefixed BoringSSL symbols. Useful evidence — explicitly not a final artifact decision.
nginx pin1.31.7
BoringSSL pin594a44291086…
compilerClang 21.1.8
build targetnxtls-baseline
2026-10-18 refresh: the official nginx 1.31.7 release and BoringSSL
594a44291086dcc7cef06cabec4c0b47afd674c0 passed the canonical build, TLS 1.3 runtime checks and focused regressions. This validates the updated pins; it does not imply a production release, a security audit or new feature adoption. See the regression summary.05 / EVIDENCE
Questions, measured.
nxTLS keeps the project overview here and the experimental detail in a separate evidence log. Historical clues become controlled questions against the pinned modern baseline; successful spikes remain evidence until a project decision adopts them.
HPACK · Gate C
The fix I never wrote down.
TinX left a real response-side HPACK encoder behind, but not a preserved browser A/B. The modern nxTLS spike independently reproduced persistent response reuse: a repeated test block fell from 204 to 107 bytes after the first response.
QPACK · Gate B
Same policy question, harder protocol.
Dynamic response reuse worked over HTTP/3: stock sections stayed at 202 bytes, while the experimental path produced 202 once and 104 thereafter. The known decoder disagreement was resolved on saved inputs using the fixed upstream pylsqpack PR #60 commit, without changing the nxTLS encoder. Production integration remains separate.
TLS records · transport-tested
Control the records, then measure the cost.
The first transport campaign rejected the tested adaptive 1k→16k policy. A 1,350-connection follow-up then separated nginx buffering from TLS record sizing: a 16 KiB nginx buffer plus a static 4096-byte BoringSSL fragment limit reproduced stock 4 KiB-buffer early delivery within 0.1 ms median across H1/H2 and all three paths. Static 4 KiB TLS records are the measured direction; the production integration boundary remains open.
QUIC reload · upstream
The fix stayed upstream.
The official nginx 1.31.7 release passed 48/48 fresh post-reload H3 probes and 4/4 established transfers across IPv4, IPv6 and stacked SIGHUP reloads. No nxTLS-specific reload patch was needed.
FIFTH EXPERIMENT · HTTP/2 PRIORITY
When does priority become delivery?
On nginx 1.31.7, 240 randomized HTTP/2 runs found earlier delivery of critical DATA with RFC 9218 urgency: paired median gains of 27.8 ms (simultaneous streams) and 29.1 ms (late critical request). Static 4 KiB TLS fragments added a smaller, workload-dependent gain at the cost of more records. A separate instrumented trace confirmed live PRIORITY_UPDATE state changes and already pending SSL/TCP output.
SIXTH EXPERIMENT · PRIORITY-AWARE EARLY FLUSH
The frame was ready. The record was not.
Experiment 6 traced an urgency-0 HTTP/2 DATA frame through nginx's SSL buffering and demonstrated selective early TLS-record delivery with a small G0A patch. The client decrypted a complete critical frame in a short record; subsequent bulk writes returned to 16 KiB. Phase 3E then forced a real BoringSSL WANT_WRITE in the selected prefix and recovered intact in four controlled cases, without modifying G0A. The native socket prefix condition and performance validation remain open.
SEVENTH EXPERIMENT · RESPONSE HPACK × EARLY FLUSH
Smaller headers. Earlier response?
EXP 07 combines response HPACK with G0A using four isolated HTTP/2 variants. The combined path preserved response integrity in the tested table-size, backpressure and stateful controls, and compression demonstrably changes the size of the early TLS write. The actual latency interaction is not yet measured. Server-side graceful GOAWAY, native selected-prefix retry and the E7-3 performance gate remain separate open questions.
Evidence does not silently become architecture. Four pin-refresh regressions passed in their respective scopes. Experiments 5 and 6 explored priority delivery and bounded output; Experiment 7 tests their interaction with response HPACK. Neither settles production encoder integration, default TLS record sizing, binary-upgrade behavior or general end-to-end performance.
HPACK repeated block204 → 107 B
QPACK repeated section202 → 104 B
TLS record sizing4 KiB records · integration open
QUIC reload48/48 · 4/4 inflight
Read the experiment log.
Seven experiments have individual reports, each distinguishing research results from product policy. EXP 07 now documents the combined HPACK/G0A behavior under bounded integrity and backpressure controls. Its latency interaction is unmeasured; server-side graceful GOAWAY and native prefix-retry validation remain open.
06 / CRYPTO POLICY
Policy is the product surface.
A primitive existing somewhere inside BoringSSL does not mean nxTLS exposes or uses it. The intended surface is explicit, narrow and allowed to exclude historical compatibility.
TLS 1.3 primary
TLS 1.3 is the intended production protocol. TLS 1.2 and older are intended to be excluded rather than carried as compatibility baggage.
X25519MLKEM768
The preferred candidate for hybrid post-quantum key establishment. Exact runtime ordering and fallback policy still need implementation and testing.
X25519
The current candidate for a conventional fallback. Whether, when and how that fallback is allowed remains an explicit open policy question.
Maintained crypto
Production cryptography should use maintained upstream implementations. Novel or experimental primitives stay isolated from the production TLS path.
Modern AEAD
AES-GCM and ChaCha20-Poly1305 are the expected production candidates. Exact TLS 1.3 cipher-suite policy is still to be defined against the implemented baseline.
Authentication + 0-RTT
Authentication policy remains undecided. 0-RTT is also TBD; the default direction is off until replay semantics are explicitly designed for.
TLS ≤ 1.2
RSA key exchange
classic/static DH
CBC TLS suites
3DES
RC4
renegotiation
TLS compression
07 / LINEAGE
A reboot with memory.
The old projects matter because they show where the instincts came from — not because their implementation choices automatically deserve to survive.
2016
TinX begins narrowing nginx.
Unused modules were removed, HTTP/2 became a core assumption, Clang/SafeStack entered release builds, and TLS was pushed behind a smaller project-specific boundary.
2017
TLS 1.3 before the standard was finished.
The surviving history records pre-standard TLS 1.3 work, including a final release using the draft-18 implementation, while the server and crypto projects evolved into TinX and nsb2.
2018–2019
Smaller surface, stronger policy, more experiments.
X25519 was implemented in TLS; the tree contained a generic KEM interface and NTRU KEM implementation. TinX also used SipHash-backed file-cache hashing and Argon2-based basic-auth password handling while fuzzing and hardening remained normal development modes.
2026
nxTLS starts over.
New Git history. Current pinned nginx and BoringSSL. Minimal upstream delta. One product. Modern C++ only where the project owns the code. Historical source stays reference material.
then / nsb2 + TinX
Own the forkLarge project-owned copies of upstream code accumulated maintenance cost.
Deep source transformationRenames, deletion and C++ conversion made upstream comparison harder.
Separate productsnsb2 and TinX became independently versioned and packaged components.
Experimental crypto in-treeNovel primitives and PQ experiments lived directly in the historical crypto tree.
now / nxTLS
Own the policyKeep upstream source recognisable and put nxTLS value in integration, policy and tests.
Narrow patchesPrefer wrappers and project-owned code; patch upstream only for concrete requirements.
One productOne repository and one primary Debian package; internal boundaries need not become public products.
Maintained production cryptoUse upstream implementations; keep experimental cryptography isolated.
Historical caution: the surviving archive proves X25519 TLS work, a generic KEM interface, an NTRU KEM implementation and explicit Kyber/PQ interest. It does not contain a surviving Kyber+X25519 hybrid TLS implementation, so nxTLS does not present that as established history.
08 / QUALITY
Hardening is a build mode.
Fuzzing, sanitizers and reproducibility are intended to be normal ways to develop nxTLS, not a release-week checklist bolted onto the side.
Sanitizers
ASan and UBSan are initial targets, with MSan and TSan evaluated where the current toolchain and dependency graph make them useful.
Fuzzing
Focus fuzz targets on code nxTLS actually owns: configuration parsing, TLS integration boundaries and any project-owned protocol glue.
Hardening
PIE, RELRO/NOW, LTO, stack protections and current Clang control-flow options are evaluated against the current stack rather than copied from 2019 flags.
Offline release
Vendoring may use the network. The eventual Debian source/release artifact must contain what it needs and build without network access.
09 / ROADMAP
Evidence, then integration.
The roadmap is intentionally short. The next stages should emerge from measured build and integration results rather than from a speculative platform plan.
Phase 0
complete
Bootstrap
Clean repository, project identity, history, upstream policy, pinning, vendoring and development workflow.
Phase 1
complete
Automated upstream baseline
Project-owned runners verify static HTTP and TLS 1.3 against the pinned upstream baseline.
Phase 2
next
Artifact + integration architecture
Resolve symbol isolation, final artifact relationships, nginx integration, CLI scope and runtime layout. The project-owned configuration baseline and profile model are already accepted; exact file layout and values remain to be defined.
Phase 3
later
nxTLS integration
Implement the project-owned policy boundary, configuration profiles, patch mechanism, reduced nginx surface, first integrated artifacts and Debian package.
Phase 4
later
Modern transport + PQ
HTTP/2, HTTP/3/QUIC and an X25519MLKEM768 hybrid baseline, including automated verification of compatibility-edge and h3-first transport behavior. Focused HPACK/QPACK experiments already exist; the complete product transport baseline still does not.
Phase 5
later
Hardening + release quality
Sanitizer modes, fuzz targets, hardening profile and a verified offline/reproducible Debian source build.