Oblivious HTTP Explained: How Relays and Gateways Hide Your IP

It can link the two, so a private question gets a return address. An IP address plus a timestamp can narrow a request down to one home network or one mobile connection.

This happens without anyone planning it. nginx, a popular web server, writes the client IP address and the local time into its access log by default.

Picture a common setup. A health app lets people type a symptom without logging in and get advice, about 2 lakh (200,000) searches a day. The setup is made up, but the problem is real.

One night someone searches for "chest pain after climbing stairs". The next morning that search sits in the server log, right beside the user's IP address and the exact time. Nobody meant to collect it.

The team wants to answer every search without learning who sent it. Oblivious HTTP, a standard from the IETF (the Internet Engineering Task Force, which writes internet protocols), is built for exactly this. The rest of this guide follows that one app.

You need eight words. RFC 9458 uses longer names for the four parties, shown in brackets.

• Client: the app that seals and sends the request, here on the user's phone.
• Relay (Oblivious Relay Resource): a middle server that passes sealed requests along. It sees who connects but cannot read what they send.
• Gateway (Oblivious Gateway Resource): the server that opens a sealed request, sends it on as normal HTTP and seals the answer.
• Target (Target Resource): the real API that answers. It may not even know Oblivious HTTP is in use.
• Operator: the organisation that runs a server and can read its logs.
• HPKE (Hybrid Public Key Encryption, RFC 9180): a published recipe for encrypting a message that only one private key can open.
• Key configuration: the gateway's public record of a key ID, its algorithms and its public key.
• Binary HTTP (RFC 9292): a compact byte format for a whole HTTP request or response.

Oblivious HTTP is a standard way to send an HTTP request through two separate servers. The relay knows the sender, and the gateway knows the question. Neither one learns both.

Think of a sealed letter sent by courier. The courier knows your address but cannot open the envelope. The reader opens the letter, but it arrives from the courier's depot, not your house.

Map the parts: the courier is the relay, the envelope is HPKE encryption, and the reader is the gateway. The depot's return address is the relay's IP address, the only one the gateway sees.

Where the picture breaks: a courier could steam open an envelope, but HPKE ciphertext needs the gateway's private key. That holds as long as the app has the gateway's real public key. And unlike a letter, the answer travels back sealed through the same courier.

The diagram follows one search, one box per message.

RFC 9458 says a relay must not add information that might identify the client when it forwards a request. It names the Via and Forwarded headers, which record earlier hops, as the kind of thing generic proxies add. So the gateway sees a request from the relay, not from the user's phone.

Cloudflare opened a closed beta of a self-serve OHTTP Gateway on 2 October 2026. Before that, its OHTTP product covered only the relay side.

That 2022 relay product, Privacy Gateway, is now renamed Cloudflare OHTTP Relay. The new gateway will be sold as a paid add-on to a customer's domain. As of 19 October 2026, no price is published.

Clients send sealed requests to the fixed path /.well-known/ohttp-gateway on the customer's domain. A GET request to that path returns the public keys, which Cloudflare manages. The gateway decrypts each request and makes an ordinary request to the customer's own server.

The detail that drew attention is a refusal. The gateway will not decrypt requests sent from Cloudflare Workers, its serverless code platform, or from websites that route their traffic through Cloudflare. Cloudflare says this ensures it never sees both who sent a request and what it says. InfoQ reported the refusal on 13 October 2026.

Two things the announcement does not say, as of 19 October 2026: which HPKE algorithms the gateway uses, and how often its keys rotate. Read both from the key configuration your gateway serves, and recheck after the beta.

The relay sees the client's IP address and the time and size of each sealed message. The gateway sees the full request but only the relay's address.

In the example, the health app runs both the gateway and the target. RFC 9458 allows that and says it does not affect client privacy. Only the relay and the gateway must have different operators.

Timing and size still leak a little. RFC 9458 warns that a malicious relay can study message sizes and timing, called traffic analysis. It suggests padding, meaning filler bytes, to make that harder.

Pause and predict: the relay holds half the story and the gateway holds the other half. What happens if one company runs both?

Because one operator running both could join the two logs by time and put a user's IP next to their search. RFC 9458 says the relay cannot be operated by the same entity as the gateway.

Back to the courier: if the courier and the reader are one company, the envelope protects nothing.

This is why Cloudflare's gateway refuses traffic from its own Workers and proxied hosts. Its post says the relay and app server must be run by separate, non-colluding parties, and suggests a third-party relay.

The gateway can also check that requests come from the agreed relay. Cloudflare Access, its product that checks every caller's identity before letting it in, runs before decryption, with options such as mutual TLS, where both sides show certificates.

It is the wrong tool when the request itself identifies the user, or when requests must be linked, as with a login. RFC 9458 says plainly that it has limited applicability.

• Logged-in features. RFC 9458 calls cookies the most obvious feature that can link requests, and login credentials do the same.
• Identifiers in the body. Cloudflare warns that it is up to you not to send things like an email address or username inside the request.
• General browsing. Each service needs its own gateway and an agreed relay, so it suits a few chosen APIs rather than whole websites.
• Tiny user bases. With only a handful of users behind a relay, each one has little cover. RFC 9458 likewise warns against small groups of clients sharing one setup.

The symptom app fits well, since its searches need no login and are independent. RFC 9458 lists similar uses: DNS queries, telemetry, anonymous surveys, search queries and map tiles.

Beginners can stop here: you now know the four parties, what each one sees, why two operators matter and when to skip Oblivious HTTP. The sections below are for engineers.

The app encrypts the request to the gateway's public key using HPKE. It puts a 7-byte header in front saying which key and algorithms it used. Only the gateway's private key can open it.

The key configuration comes first

Each key configuration has a 1-byte key ID, a 2-byte KEM ID, the public key and the algorithm pairs the gateway accepts. A KEM, or key encapsulation mechanism, creates a fresh shared secret that only the private key holder can recover.

RFC 9458 does not define how the app gets this record. Cloudflare suggests fetching keys over a different IP address from the one used for requests, for stronger privacy.

Sealing the request, step by step

1. 1

   Pack the request

   The app turns the search into a Binary HTTP message.

2. 2

   Build the header

   It writes 7 bytes: the key ID, then the KEM, KDF (key derivation) and AEAD (encryption) algorithm IDs.

3. 3

   Build the info string

   It joins the text "message/bhttp request", one zero byte and the header, tying the encryption to this purpose and key.

4. 4

   Set up HPKE

   HPKE setup in base mode needs only the gateway's public key. It gives an encapsulated key, called enc, and a sending context.

5. 5

   Seal and send

   It encrypts the Binary HTTP bytes into ciphertext, then sends header, enc and ciphertext to the relay as one POST body.

The Python below builds the header and info string for the example key, using algorithm IDs from RFC 9180. Real sealing then needs an HPKE library.

import struct

# The gateway's key configuration (key ID 1, as in RFC 9458 Appendix A)
KEY_ID = 1
KEM_X25519 = 0x0020    # DHKEM(X25519, HKDF-SHA256)
KDF_SHA256 = 0x0001    # HKDF-SHA256
AEAD_AES128 = 0x0001   # AES-128-GCM

def request_header(key_id, kem_id, kdf_id, aead_id):
    # one 8-bit number, then three 16-bit numbers, big-endian
    return struct.pack("!BHHH", key_id, kem_id, kdf_id, aead_id)

hdr = request_header(KEY_ID, KEM_X25519, KDF_SHA256, AEAD_AES128)
info = b"message/bhttp request" + b"\x00" + hdr

print(hdr.hex())   # 01002000010001
print(len(info))   # 21 label bytes + 1 zero byte + 7 header bytes = 29

What just happened? In struct.pack, the format "!BHHH" means big-endian order: one 1-byte number, then three 2-byte numbers. Run it with Python 3 and you should see 01002000010001 and 29. A different hex string means the byte order is wrong.

A gateway rejects a key ID or algorithm it does not know. RFC 9458 says it can answer an unknown key ID with HTTP 422 (Unprocessable Content). The app cannot rely on a clear error, because that error reply cannot be encrypted and may not reach it.

Sealing the answer

For the reply, the gateway exports a secret from the same HPKE session, using the label "message/bhttp response". It adds a random nonce, a number used once (16 bytes with AES-128-GCM), and derives a fresh key from that secret, the request's enc and the nonce. The relay cannot open the answer. The app can, and so can anyone who later steals the gateway's private key.

With X25519, HKDF-SHA256 and AES-128-GCM, the algorithms in RFC 9458's own example, a sealed request is 55 bytes bigger than the Binary HTTP message inside it. A sealed response is 32 bytes bigger.

We checked these numbers across two separate implementations on 19 October 2026. A Python gateway built on pyhpke 0.6.5 opened a request sealed by ohttp-ts 0.6.1, a TypeScript OHTTP library. ohttp-ts then opened the Python gateway's sealed reply.

A 44-byte payload became a 99-byte sealed request, and a 17-byte answer became a 49-byte sealed response. Other algorithms change these numbers, so recompute them for your key configuration.

Padding changes the real size

ohttp-ts 0.6.1 pads by default. Its Request helper pads the Binary HTTP message to at least 1,024 bytes, so short searches all look the same size to the relay.

In our run, a 5-character and a 32-character search both became 1,079-byte sealed requests. A 2,000-character body became 2,231 bytes. With padding switched off, the 5-character search was 138 bytes.

So padding costs about 1 KB per short request and hides its length. The time cost is one extra network hop plus the encryption work at each end. Measure that on your own traffic.

A gateway can track users by handing each one a different key, and an attacker can resend an old sealed request. HPKE alone stops neither.

Unique keys can tag users

If the gateway gave one user their own key ID, every request with that ID would point to them. RFC 9458 calls preventing unique client configurations critical, because each active configuration splits users into smaller groups.

The check is easy to state: every key configuration in use must be shared by many users, never handed to one user.

Replays and the HTTP Date header

Someone who copies a sealed request can send it again. In our test, both pyhpke 0.6.5 and ohttp-ts 0.6.1 opened the same sealed request twice without complaint. RFC 9458 makes the gateway and the application responsible: reject replays, or make sure a replay does no harm.

RFC 9458 says clients should put a Date header inside the sealed request. The gateway can reject a request whose date falls outside its time window, or one it has already answered in that window.

The gateway can answer with a 400-series error that carries its own date. The client may then retry once, with a corrected date and a fresh HPKE context.

A leaked key opens old requests

RFC 9458 gives no forward secrecy for requests or answers during a key configuration's lifetime. Forward secrecy would keep old messages safe if a key leaked later. In our test, the gateway's private key alone opened a request captured earlier, and the answer to it.

RFC 9458 suggests rotating keys and deleting old ones as a partial fix. Give each new key to all users, not a few at a time, so the rotation does not create small groups.

Chunked Oblivious HTTP is a proposed variant that seals a message in pieces, and it is not a standard yet. As of 19 October 2026 it is draft-ietf-ohai-chunked-ohttp-08, dated 18 February 2026.

Plain Oblivious HTTP seals each message as one block, so the receiver must get all of it before it can check and open it. The chunked version encrypts each piece on its own and marks the final piece.

The draft sits in the RFC Editor queue, marked as waiting for a reference that is not yet published. Cloudflare says its new gateway supports chunked OHTTP, and ohttp-ts 0.6.1 implements version 08. Treat it as coming, not settled.

Start with the threat, draw four boxes, then say what each box can and cannot see.

1. 1

   Name the threat

   One server seeing both the IP address and the request can link a person to a sensitive question.

2. 2

   Draw the four parties

   Client, relay, gateway and target. The relay forwards sealed bytes, and the gateway decrypts them.

3. 3

   Explain the sealing

   The client encrypts with HPKE to the gateway's public key from a key configuration shared by many users.

4. 4

   Insist on separate operators

   Different, non-colluding organisations run the relay and gateway, and the gateway can authenticate the relay.

5. 5

   Cover the attacks

   Per-user keys as tracking tags, replays limited with a Date window and a duplicate check, and size and timing analysis at the relay.

6. 6

   State the costs and limits

   One extra hop, 55 bytes per request before padding, no logins or identifiers inside, and independent requests only.

Rough numbers help. 2 lakh searches a day is about 2.3 requests a second on average, each 55 bytes bigger before padding. The traffic is made up; the overhead is measured.