◉ COOLJAPAN
← All posts
July 17, 2026 • 9 min read

OxiTLS 0.2.1 Released — RUSTSEC-2026-0104 Eliminated, OCSP Replay Bypass Closed, SCT Parsing Fixed

OxiTLS 0.2.1 eliminates RUSTSEC-2026-0104 by forking its Pure-Rust CryptoProvider into a webpki-free oxitls-rustcrypto-provider crate, closes an OCSP staple replay bypass, and fixes SCT parsing — 443 tests passing, the sovereign Pure Rust TLS layer for the COOLJAPAN ecosystem.

release oxitls pure-rust cooljapan noffi tls security networking cryptography

The fastest way to guarantee a CVE never reaches a downstream Cargo.lock is to remove the vulnerable dependency from the graph entirely — not patch around it, not pin a fixed version, remove it.

Today we released OxiTLS 0.2.1 — a security-hardening release for the COOLJAPAN Pure Rust TLS transport stack. It eliminates RUSTSEC-2026-0104 (a rustls-webpki CRL-parsing panic) from the dependency graph, closes a replay bypass in OCSP staple validation, and fixes a Certificate Transparency parsing bug that silently dropped every embedded SCT extension it was supposed to verify.

No OpenSSL. No native-tls. No ring. No FFI. No -sys crates on the path you actually ship. As of 0.2.1, no webpki or rustls-webpki either — the new in-workspace oxitls-rustcrypto-provider fork carries the same Pure-Rust CryptoProvider without them. Pure Rust, from the byte that hits the socket to the AEAD that protects it, compiling to a single static binary with no system libraries and no build-time C toolchain.

Why OxiTLS 0.2.1 is a game changer

Security releases are where “Pure Rust” either pays off or turns out to be marketing. 0.2.1 is a real test of the former:

OxiTLS 0.2.1 ends all of that.

Technical Deep Dive: the crypto engine, the trust stores, and where the fix lives

  1. The crypto engine (oxitls-core, oxitls-rustcrypto-provider, oxitls-adapter-rustls-rustcrypto). oxitls-core supplies the shared traits, types, and the OsRng adapter. oxitls-rustcrypto-provider is the new fork carrying the CVE fix: it supplies TLS 1.3 cipher suites (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305), optional TLS 1.2 ECDHE-ECDSA / ECDHE-RSA suites (tls12 feature, on by default), X25519 / secp256r1 / secp384r1 key exchange, ECDSA / Ed25519 / RSA (PKCS#1v1.5 + PSS) signing and verification, and an RFC 9001 §5.4 QUIC header-protection module. oxitls-adapter-rustls-rustcrypto sits unchanged on top, and is where the OCSP and SCT hardening in this release actually lives (verifier::ocsp_client, verifier::sct).
  2. Trust anchors (oxitls-webpki-roots, oxitls-native-certs). oxitls-webpki-roots stays Mozilla-roots-only — bundled WebPKI roots, an LRU intermediate-certificate cache, and expiring-roots support, all FFI-free. oxitls-native-certs is the dedicated quarantine crate for OS-native trust stores (Security.framework, SChannel, a PEM bundle on Linux) — opt-in, added directly only when you need it.
  3. Opt-in bounded FFI (oxitls-adapter-aws-lc, oxitls-adapter-pkcs11). The aws-lc-rs adapter (FIPS, high throughput) and the PKCS#11 adapter (HSM / TPM, tested against SoftHSM) are standalone crates with bounded FFI — never facade features, never in the default closure.
  4. The facade and its wings (oxitls, oxitls-h2, oxitls-rcgen). ClientBuilder / ServerBuilder are the ergonomic front door; oxitls-h2 adds HTTP/2 over TLS with a generic stream type; oxitls-rcgen generates Pure-Rust X.509 certificates. All three inherit the CVE fix automatically — none of them touch webpki directly.

The cryptographic primitives underneath all of it — AEAD, hash, MAC, signature, key exchange — come directly from RustCrypto’s own audited crates (aes-gcm, chacha20poly1305, p256/p384, ed25519-dalek, rsa, sha2), vendored inside oxitls-rustcrypto-provider — no external crypto-primitives crate in between.

Getting Started

cargo add oxitls

A minimal async TLS client — nothing about this snippet changes in 0.2.1, but the CryptoProvider wired in underneath ClientBuilder::new() is now the CVE-clean fork automatically:

use oxitls::{ClientBuilder, TlsError};

#[tokio::main]
async fn main() -> Result<(), TlsError> {
    let stream = ClientBuilder::new()
        .server_name("example.com")
        .connect("example.com:443")
        .await?;
    Ok(())
}

And the server side, with ALPN negotiation:

use oxitls::{ServerBuilder, TlsError};

#[tokio::main]
async fn main() -> Result<(), TlsError> {
    let acceptor = ServerBuilder::new()
        .with_cert_pem(cert_pem, key_pem)?
        .with_alpn(&["h2", "http/1.1"])
        .build()?;
    Ok(())
}

Need certificates for local development? Enable the rcgen feature and generate them in Pure Rust — this path runs through oxitls-rcgen untouched by the CVE fix, since it never depended on webpki in the first place:

use oxitls_rcgen::{generate_self_signed_ed25519, generate_ca, SigningAlgorithm};

let leaf = generate_self_signed_ed25519(&["localhost", "127.0.0.1"])?;
let ca = generate_ca("My Root CA", SigningAlgorithm::EcdsaP256)?;

What’s New in 0.2.1

Tips

This is the foundation

OxiTLS belongs to NoFFI — the COOLJAPAN initiative to replace every C / C++ / Fortran / -sys FFI dependency in the Rust ecosystem with a clean, memory-safe, 100% Pure Rust implementation. A release like 0.2.1, which removes a vulnerable dependency instead of merely papering over it, is that initiative working as intended.

OxiTLS sits underneath a growing list of sibling COOLJAPAN projects — all of them already pinned to oxitls = "0.2.1" (or one of its subcrates) at the time of this release: OxiHTTP, OxiQUIC, and OxiRPC carry it as their transport-security layer; OxiSQL depends on it directly, and its own Cargo.toml now notes that its CryptoProvider is supplied CVE-clean by this exact fork; OxiGDAL pulls in oxitls-core, oxitls-adapter-rustls-rustcrypto, and oxitls-webpki-roots individually; and OxiRS, CeleRS, MielinOS, and VoiRS round out the list. When a CVE fix lands in oxitls, it propagates to all of them on their next cargo update, with no code changes required on their side either.

Repository: https://github.com/cool-japan/oxitls

Star the repo if you want a TLS stack where a CVE gets removed from the dependency graph, not just patched around.

The era of shipping a vulnerable dependency because “we don’t hit that code path anyway” is over. Pure Rust TLS — sovereign, safe, and now provably free of RUSTSEC-2026-0104 — is here.

— KitaSan at COOLJAPAN OÜ July 17, 2026

↑ Back to all posts