Open OHTTP Relay for easy dev testing
Spin up or point to an open, configurable OHTTP relay to quickly try OHTTP (RFC 9458). It helps you decouple client identity (IP) from request content and gives developers a simple, configurable starting point for local and staging environments.
What is OHTTP?
Oblivious HTTP splits a request path into Client → Relay → Gateway. The client encrypts payloads to the gateway’s key; the relay forwards blind, unlinkable blobs; the gateway decrypts and forwards to the target. The relay never sees plaintext; the gateway never sees client IPs.
Two-hop design
Client sends HPKE-encrypted blobs to the Relay; Relay forwards to Gateway; responses flow back symmetrically.
End-to-end payload secrecy
Relay operates on ciphertext only. Payload integrity and confidentiality are enforced by HPKE and the OHTTP spec.
Request–identity unlinkability
Gateway learns request content but not client IP; Relay sees IP but never plaintext content.
A narrow, high-performance forwarder
The Relay’s sole job is to accept OHTTP encapsulated requests from clients and forward them to the configured Gateway, preserving unlinkability and avoiding state beyond what’s required for forwarding and accounting.
No plaintext access
Relay never decrypts payloads; it can enforce basic limits without breaking privacy.
Routing and policy
Map incoming relay endpoints to gateways; apply rate limits, DoS protections, and observability that don’t reveal user content.
Operational simplicity
Stateless-by-design; scale horizontally behind a load balancer; cache minimal metadata only when necessary.
Why OHTTP improves privacy
OHTTP enforces role separation: relays see source addresses, gateways see decrypted content, and neither party can link the two.
- Network-layer anonymity: Gateway can’t attribute requests to client IPs when the relay is independent.
- Application-layer secrecy: Relay can’t read or modify request bodies or headers protected by HPKE.
- Reduced tracking surface: Eliminates straightforward IP–content correlation; logs at relay and gateway are unlinkable by design.
- Defense in depth: Even compromised relays don’t expose plaintext; compromised gateways don’t learn client IPs.
Request flow in 4 steps
- 1) Client encapsulatesClient obtains the Gateway’s config (key, suite), then HPKE-encrypts the HTTP request into an OHTTP message.
- 2) Send to RelayThe encrypted blob is POSTed to the Relay endpoint. The Relay performs validation and forwards it to the Gateway.
- 3) Gateway decapsulatesThe Gateway decrypts, executes the HTTP request to the target origin, and encapsulates the response.
- 4) Relay returns responseThe Relay forwards the encrypted response back to the Client. The Client decapsulates locally.
Quick start with Echo Gateway
We provide a public Echo Gateway for testing. It mirrors your decoded payload and headers back to you via OHTTP.
https://echo.alpetest.com// 1) Fetch gateway config (includes HPKE public key)
const gwConfig = await fetch('https://echo.alpetest.com/.well-known/ohttp-configs');
// 2) Encapsulate request to the gateway using OHTTP
const encReq = ohttp.encapsulate({
method: 'POST',
url: 'https://echo.alpetest.com/',
body: '{"msg":"hello echo"}',
config: gwConfig
});
// 3) Send to relay (targeting the echo gateway)
const res = await fetch('https://your-relay.example.com/ohttp-relay', {
method: 'POST',
body: encReq,
headers: { 'Content-Type': 'message/ohttp-req' }
});
// 4) Decapsulate response locally
const dec = ohttp.decapsulate(await res.arrayBuffer());
console.log(dec.body); // "{"msg":"hello echo"}"FAQ
It’s trusted for availability and policy enforcement, not for confidentiality or integrity of payloads. Those are provided by OHTTP’s cryptography.
Not via IP addresses when the relay is independent. Side channels outside OHTTP (e.g. cookies at the target) still require standard mitigations.
Read the specification: RFC 9458.