Cameleering
simoomsimoom / Use cases / Audited builds
Supply-chain-sensitive and audited environments
An HTTP server with nothing to vet but itself
A bank, a medical device maker or a defence supplier has to review every third-party dependency it ships and track each one for vulnerabilities. Every crate is a vendor. simoom has none: no crates.io dependencies at all, not even for tests. The TLS stack, QUIC, HTTP/2, HTTP/3, the compression codecs and the event loops are all in one repository, under one licence.
What "zero dependencies" means here
The workspace's dependency tree is simoom's own crates and the Rust standard library. Calls into the operating system go through extern declarations in simoom-sys; SIMD goes through core::arch with runtime detection and a scalar fallback.
In the repository
- TLS 1.3 and its cryptography: X25519, P-256, RSA, AES-GCM; P-384, Ed25519 and ChaCha20-Poly1305 as an option.
- QUIC v1, HTTP/3 and QPACK; HTTP/2 and HPACK; HTTP/1.1.
- DEFLATE, gzip, Brotli and zstd codecs.
- Event loops for epoll, io_uring, IOCP and kqueue.
Rules the build enforces
- Every crate except
simoom-sysstarts with#![forbid(unsafe_code)]. - Zero warnings from
cargo build --workspace --all-targets. - Tests are hermetic: loopback only, never the internet.
- Certificate verification can't be turned off.
The only exception is the competitor programs under bench/competitors/: separate projects outside the workspace, with their own lock files, that exist only to be benchmarked against. The cryptography is planned to move into ksar, a shared crypto family for Cameleering projects; today it lives in simoom-tls.
What has been tested
Parsing follows RFC 9110, 9112, 9113, 9114 and 9204 strictly: a request whose framing is ambiguous is refused, and every limit has a default.
| check | result |
|---|---|
| h2spec 2.6.0 | 146/146, in 30 consecutive runs |
| HTTP Garden, as an origin next to nginx, Apache httpd, h2o, hyper, gunicorn and Go | 0 desyncs, 0 dangerous discrepancies |
| Request-smuggling test behind nginx 1.24 and haproxy 2.8 | 165 streams, 0 desyncs; accepted 0 requests that both refused |
| QUIC Interop Runner against ngtcp2, quiche and quic-go clients | 54 of 58 supported pairs (failures: 0-RTT, refused by design; ECN, not implemented) |
| testssl.sh 3.2.1 | no vulnerabilities found |
| TLS interop: OpenSSL, curl with OpenSSL, Python ssl, gnutls-cli, Schannel | 28/28, 31/31, 3/3 |
| Fuzzing | std-only mutation fuzzing of every parser for 2 h 40 min; coverage-guided fuzzing of HTTP/1.1 |
| Test suite | 777 tests on Windows, 791 on Linux (WSL2), zero warnings |
Versions, commands and details: security. Limits and defaults: limits and security.
What has not been done
No independent audit yet
All of the testing above was done by the project itself. The TLS stack and its cryptography have not had an independent security audit. If your policy requires audited TLS, rustls has had independent audits.
A young project
simoom is at version 0.1.0 and the API can still change. It has one maintainer. Vulnerabilities are reported privately through GitHub security advisories; the process is in security.
Common questions
Is there a Rust web server with zero dependencies?
Yes. simoom's workspace has no crates.io dependencies, not even dev-dependencies. HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS 1.3, compression and the event loops are all in its repository.
Does simoom use OpenSSL, ring or rustls?
No. It has its own TLS 1.3 and cryptography written with only the Rust standard library, so there is no C code and no third-party crypto crate in the build.
Where is the unsafe code?
Only in simoom-sys, which holds the operating-system calls, SIMD scanning and crypto intrinsics. Every unsafe block there has a SAFETY comment. Every other crate forbids unsafe code.
Has simoom been independently audited?
Not yet. It passes h2spec, HTTP Garden, a request-smuggling test, the QUIC Interop Runner and testssl.sh, and its parsers are fuzzed, but all of that was done by the project itself.
Is the HTTP server safe against request smuggling?
Parsing is strict per RFC 9112 and 9113, ambiguous framing is refused and the connection is closed after a framing error. Behind nginx and haproxy, 165 test streams gave 0 desyncs, and HTTP Garden found 0 desyncs.
Read it before you ship it
The source, the security model and the test results are all public.