RFC 9458

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.

Try the relay — Quick start View on GitHub Read RFC 9458

Overview

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.

Role of the Relay

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.

Privacy Benefits

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.

How it Works

Request flow in 4 steps

1) Client encapsulates
Client obtains the Gateway’s config (key, suite), then HPKE-encrypts the HTTP request into an OHTTP message.
2) Send to Relay
The encrypted blob is POSTed to the Relay endpoint. The Relay performs validation and forwards it to the Gateway.
3) Gateway decapsulates
The Gateway decrypts, executes the HTTP request to the target origin, and encapsulates the response.
4) Relay returns response
The Relay forwards the encrypted response back to the Client. The Client decapsulates locally.

Try it

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.

Echo Gateway URL

https://echo.alpetest.com

Resources

Note

For legal reasons, registration is required for custom gateways.

Example (ohttp-js):

import { Client, PublicKeyConfig } from 'ohttp-js';
import { CipherSuite, KemId, KdfId, AeadId } from 'hpke-js';

// 1) Create cipher suite and deserialize gateway's public key
const suite = new CipherSuite({
  kem: KemId.DhkemP256HkdfSha256,
  kdf: KdfId.HkdfSha256,
  aead: AeadId.Aes128Gcm
});
const publicKey = await suite.kem.deserializePublicKey(publicKeyBytes);

// 2) Create OHTTP client with gateway config
const config = new PublicKeyConfig(1, suite.kem.id, suite.kdf.id, suite.aead.id, publicKey);
const client = new Client(config);

// 3) Encapsulate request to the gateway
const request = new Request('https://echo.alpetest.com/', {
  method: 'POST',
  body: JSON.stringify({ msg: 'hello echo' })
});
const ctx = await client.encapsulateRequest(request);

// 4) Send to relay
const res = await fetch('https://your-relay.example.com/ohttp-relay', { 
  method: 'POST', 
  body: ctx.request.encode(),
  headers: { 'Content-Type': 'message/ohttp-req' }
});

// 5) Decapsulate response
const innerRes = await ctx.decapsulateResponse(res);
console.log(await innerRes.text()); // {"msg":"hello echo"}

FAQ

Is the relay trusted?

It’s trusted for availability and policy enforcement, not for confidentiality or integrity of payloads. Those are provided by OHTTP’s cryptography.

Can the gateway correlate requests to clients?

Not via IP addresses when the relay is independent. Side channels outside OHTTP (e.g. cookies at the target) still require standard mitigations.

Where can I learn more?

Read the specification: RFC 9458.

Does this relay provide anonymous access?

No. This service is designed as a developer tool to help you test and validate your OHTTP gateway implementations, not as a production anonymity service.

Why do you need my email address?

Your email address is encrypted and securely stored to link relay routes to a verified account holder, ensuring accountability and proper resource allocation.