As OpenHTTPA is a security-first protocol involving Trusted Execution Environments (TEEs) and Post-Quantum Cryptography, we take security vulnerabilities extremely seriously.

If you discover a potential security issue, please do NOT open a public issue. Instead, follow these steps:

1. Email us: Send a detailed report to security@openhttpa.org.

2. Include Details: Please provide a detailed description of the vulnerability, including steps to reproduce, potential impact, and any suggested remediation.

3. PGP Encryption: For highly sensitive reports, please encrypt with our public PGP key:

   [!CAUTION] D-01 RELEASE GATE — PGP Key Not Yet Provisioned

   A dedicated PGP key for security@openhttpa.org MUST be generated and published before the first GA release. Until then, send reports via plaintext email to security@openhttpa.org with the subject line [SECURITY] <short description>.

   Key Generation Checklist (for maintainers):

   1. Generate an Ed25519 or RSA-4096 PGP key for security@openhttpa.org.
   2. Publish the key to keys.openpgp.org and verify the email address.
   3. Replace this block with the actual Key ID, Fingerprint, and Key Server URL.
   4. Cross-sign the key with at least two core maintainer keys.
   5. Add the public key armored block to docs/pgp/security-at-openhttpa.asc.
   6. Remove this caution block and replace with the key details.

• Acknowledgement: We will acknowledge receipt of your report within 24 hours.
• Resolution: We aim to provide a resolution or a timeline for a fix within 5 business days.
• Credit: We will credit the researcher in our security advisories, unless anonymity is requested.

The OpenHTTPA project is built with a "Zero-Warning" policy and undergoes continuous formal verification using ProVerif and Tamarin.

• Secrecy: All payload data is AEAD-encrypted with hardware-rooted keys.
• Integrity: Message-level authentication prevents modification by any party, including the host OS.
• Authenticity: Every session is bound to a TEE attestation quote, proving the identity and integrity of the remote enclave.
• ZK Prover Isolation: The zero-knowledge proof generation (risc0-zkvm) has been decoupled from openhttpa-attestation into openhttpa-zk, significantly reducing the attestation verifier's dependency footprint and attack surface (See ADR-003).
• Replay Attack Prevention: The protocol implements hardened replay protection using deterministic nonces and HMACs bound to the Attest-Ticket. Our internal middleware strictly rejects reused and unauthorized MAC/nonce pairs.
• Memory Safety & Zeroization: OpenHTTPA enforces PQC strictness by heavily utilizing the zeroize crate (ZeroizeOnDrop) across all cryptographic buffers, ensuring deterministic erasure of keys to eliminate cross-request leakage.
• Metadata Protection: Handshake configuration metadata (such as version constraints and cipher suite preferences) is shielded using Encrypted Client Hello structures via ML-KEM Hybrid Public Key Encryption (HPKE).

All CI pipelines run on self-hosted GitHub Actions runners defined in the openhttpa-runners repository. The following properties are enforced:

• Isolation: Each runner executes in an ephemeral environment (clean working directory, no shared mutable state between jobs).
• Pinned toolchains: rust-toolchain.toml pins the exact Rust toolchain version; all tool versions are locked in Cargo.lock / pnpm-lock.yaml.
• TEE attestation (planned): Runner nodes are intended to run inside a hardware TEE (TDX or SEV-SNP) so that the build environment itself can be attested. Until that work lands, runners MUST NOT be shared with untrusted workloads on the same host.
• Audit log: All runner registrations and de-registrations are logged and reviewed by a maintainer. The registration token is rotated after each use.
• No secrets in runner environment: Production signing keys and deployment credentials are stored in GitHub Actions secrets and injected only into the specific jobs that require them; runner environment variables are not exported to pull-request workflows from forks.

Operators deploying private instances of OpenHTTPA are encouraged to run their own self-hosted runners inside a TEE and to attest the build environment using the openhttpa-tee crate before trusting any produced artifacts.

The AtHsHandlerState.challenge_key (and the matching field in PreflightHandlerState) is a 32-byte HMAC-SHA-256 key used to sign and verify freshness challenges issued during the preflight phase.

Initialization

let mut key_bytes = [0u8; 32];
getrandom::getrandom(&mut key_bytes).expect("RNG failure");
let challenge_key = openhttpa_server::ChallengeKey::new(key_bytes);

Never use an all-zero key in production. Generate the key from a cryptographically secure RNG at server startup.

Rotation

ChallengeKey::rotate(new_key) atomically replaces the key without restarting the server. Challenges issued with the old key expire after their 5-minute freshness window; no explicit revocation of in-flight challenges is required.

Rotate the key:

• On a regular schedule (recommended: every 24 hours).
• Immediately after a suspected key compromise.
• After any deployment that changes the set of active Preflight nodes if they share the same key.

Threat model note: The challenge prevents replay of old ATTEST requests. A compromised challenge_key allows an attacker to forge valid challenges, but does NOT break session key secrecy (the session keys are bound to the ECDH/KEM transcript, not to the challenge).

The OpenHTTPA Foundation (openhttpa.org)