Small surface
Support the environment and protocols nxTLS actually needs. Compatibility is not a goal by itself.
project 03 · 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: upstream baseline established.
Pinned BoringSSL builds and passes its full upstream test suite.
Pinned nginx builds unmodified against it through the nxTLS top-level CMake orchestration.
Pinned BoringSSL builds and passes its full upstream test suite.
Pinned nginx builds unmodified against it through the nxTLS top-level CMake orchestration.
nginx 1.31.6 · BoringSSL b75f405… · Clang 21.1.8
Debian Testing · amd64 · current state 2026-09-29
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.
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 pinned commit builds unmodified with Clang, libc++, LLD, CMake and Ninja. The complete upstream BoringSSL test suite passed.
verified
nginx + BoringSSL
nginx 1.31.6 builds unmodified against the pinned BoringSSL. BoringSSL is linked statically; the resulting binary has no dynamic system libssl.so or libcrypto.so dependency.
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.6
BoringSSL pinb75f405cde1c…
compilerClang 21.1.8
build targetnxtls-baseline
Next engineering step: turn the manual baseline evidence into project-owned automated runners for build verification, static HTTP, TLS 1.3 and the first configuration-profile contracts — without letting runner work decide unresolved artifact architecture by accident.
05 / 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
06 / 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.
07 / 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.
08 / 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
active
Automated upstream baseline
Add project-owned runners for baseline verification, static HTTP and TLS 1.3 behavior.
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.
Phase 5
later
Hardening + release quality
Sanitizer modes, fuzz targets, hardening profile and a verified offline/reproducible Debian source build.