LockWire

Secure by default.
Not secure by expertise.

LockWire is batteries-included security infrastructure for Rust: TLS with no warnings, PKI, passkeys, signed updates, and tamper-evident audit — wired correctly out of the box, with fail-loud guards that turn an insecure setup into a build-time error.

Get started — five minutes Which traps am I in?

main.rs — the Easy Button
// HTTPS on localhost and your LAN — no browser warnings, no openssl incantations.
let server = lockwire::serve(app)
    .https_easy_button()   // trusted local CA, auto-renewal, revocation checked
    .await?;

LockWire is in pre-release development: the repositories and crates go public as each tier reaches release, and every snippet on this site is then compiled against the published crates in CI.

Start from what you're building

A web server

Serve HTTPS that browsers trust, on loopback or the LAN, with mTLS when you need it.

The tutorial ladder →

A desktop app

Call remote services from macOS, Windows, or Linux with pinned, revocation-checked TLS.

The tutorial ladder →

Login & identity

Passkeys and OIDC without rolling your own auth — the most common way apps get hurt.

The tutorial ladder →

Something airgapped

Your own DNS, time, CA, and timestamping when there is no internet to lean on.

The tutorial ladder →

The traps

Most apps don't get broken by clever attacks. They get broken by defaults — the ten shortcuts every codebase falls into, and how to make each one impossible.

Trap #3 — “It works if I turn off certificate checking”

One flag silences the warning and hands every connection to whoever is on the network. Here is what that flag actually does:

Trap #3 — disabled certificate verification Your app, with certificate verification turned off, connects across an untrusted network. Flow 1: the app says hello to whoever answers, and anyone on the network can read and rewrite the traffic. Flow 2: that party may or may not forward the connection to the real service, which is never consulted about who it is talking to. The green line beneath shows the fix: full chain verification with revocation, in one line of code. Your app verify: OFF UNTRUSTED NETWORK Anyone reads · rewrites Real service never consulted 1 “hello, anyone” 2 maybe forwarded, maybe not The fix: .https_easy_button() — full chain verification + revocation, one line, no warnings to silence

Reading the diagrams: ink boxes are your components, hatched zones are attacker positions, and green is the defended path. Flow 1 is your app greeting whoever answered; flow 2 is the attacker deciding whether the real service ever hears from you. The same grammar is used on every page.

About the Traps series →

Evidence, not adjectives

Threat models

Authored, versioned, and shipped in every repository — read them before you trust us.

SSDL, self-audited

An IEC 62443-4-1–based development process, audited in the open — not a certification we claim.

Traceability

Every security requirement links to the code that satisfies it and the test that proves it.

SBOMs, per release

A software bill of materials ships with every release — audit the whole dependency set, not just our code.

FIPS-only crypto

Routed through AWS-LC FIPS. No home-rolled primitives, no curve step-downs.

Apache-2.0 core

The security tier is permanently open source, and every tier is published through crates.io, not behind a portal.

Read the evidence →

Building with an AI agent?

This site treats agents as first-class readers. Its machine surface — a markdown twin of every page, a curated /llms.txt map, and the lockwire-mcp server that answers “what should this app be doing about security?” inside your coding session — is part of the design and is landing with the site itself.

What agents can use today →