Oblivious HTTP (OHTTP)
Oblivious HTTP (OHTTP) とは何ですか?
Oblivious HTTP (OHTTP)An IETF-standardized HTTP-over-HPKE relay protocol (RFC 9458) that decouples client identity from request content by splitting trust between a relay (sees IP, not content) and a gateway (sees content, not IP).
Oblivious HTTP (OHTTP), specified in RFC 9458 (2024), is a privacy-preserving relay protocol for HTTP requests. The client encrypts the inner request with HPKE (Hybrid Public-Key Encryption, RFC 9180) using the gateway server's public key, then sends the encrypted payload over a normal TLS connection to a separate relay server. The relay decrypts only the outer envelope, sees the client's IP but not the request, and forwards the encrypted payload to the gateway; the gateway decrypts and processes the request, sees the request and response, but never sees the client's IP. This split-trust model means no single party knows both 'who' and 'what'. Use cases include Apple Private Relay-style web access, DNS over Oblivious HTTP, telemetry pipelines (Mozilla, Cloudflare), 'private prefetch proxy' deployments, and certificate-revocation lookups. The companion 'oblivious DoH' (ODoH, RFC 9230) is an OHTTP-style relay specific to DNS resolution. OHTTP requires the client to trust that the relay and gateway are run by non-colluding parties, which is the central operational assumption.
● 例
- 01
An operating system fetches certificate-revocation status via OHTTP so that revocation lookups cannot be tied to user IPs by either the CA or the network operator alone.
- 02
A telemetry pipeline ships product-usage events through OHTTP, routing through a Fastly relay to a vendor's gateway, ensuring the vendor cannot tie events to client IPs.
● よくある質問
Oblivious HTTP (OHTTP) とは何ですか?
An IETF-standardized HTTP-over-HPKE relay protocol (RFC 9458) that decouples client identity from request content by splitting trust between a relay (sees IP, not content) and a gateway (sees content, not IP). サイバーセキュリティの ネットワークセキュリティ カテゴリに属します。
Oblivious HTTP (OHTTP) とはどういう意味ですか?
An IETF-standardized HTTP-over-HPKE relay protocol (RFC 9458) that decouples client identity from request content by splitting trust between a relay (sees IP, not content) and a gateway (sees content, not IP).
Oblivious HTTP (OHTTP) はどのように機能しますか?
Oblivious HTTP (OHTTP), specified in RFC 9458 (2024), is a privacy-preserving relay protocol for HTTP requests. The client encrypts the inner request with HPKE (Hybrid Public-Key Encryption, RFC 9180) using the gateway server's public key, then sends the encrypted payload over a normal TLS connection to a separate relay server. The relay decrypts only the outer envelope, sees the client's IP but not the request, and forwards the encrypted payload to the gateway; the gateway decrypts and processes the request, sees the request and response, but never sees the client's IP. This split-trust model means no single party knows both 'who' and 'what'. Use cases include Apple Private Relay-style web access, DNS over Oblivious HTTP, telemetry pipelines (Mozilla, Cloudflare), 'private prefetch proxy' deployments, and certificate-revocation lookups. The companion 'oblivious DoH' (ODoH, RFC 9230) is an OHTTP-style relay specific to DNS resolution. OHTTP requires the client to trust that the relay and gateway are run by non-colluding parties, which is the central operational assumption.
Oblivious HTTP (OHTTP) からどのように防御しますか?
Oblivious HTTP (OHTTP) に対する防御は通常、上記の定義で述べたとおり、技術的統制と運用上の実践を組み合わせます。
Oblivious HTTP (OHTTP) の別名は何ですか?
一般的な別名: OHTTP, RFC 9458。
● 関連用語
- network-security№ 374
DNS over HTTPS (DoH)
DNS クエリを HTTPS の中に載せて暗号化する仕組みで、経路上の観察者による盗聴や改ざんを防ぐ。
- network-security№ 376
DNS over TLS (DoT)
専用の TLS セッション内で DNS クエリを暗号化し、ネットワーク上での盗聴や改ざんを防ぐプロトコル。
- network-security№ 375
DNS over QUIC (DoQ)
A DNS transport (RFC 9250, 2022) that runs DNS queries over QUIC, providing the confidentiality and integrity of DoT/DoH with lower handshake latency, better connection migration, and head-of-line blocking immunity from QUIC.
- network-security№ 557
HTTPS
TLS で保護された接続上で HTTP を伝送することで、Web 通信に機密性・完全性・サーバー認証を提供するプロトコル。
- privacy№ 960
Privacy Sandbox
Google's umbrella initiative for replacing third-party cookies and cross-site identifiers with privacy-preserving alternatives — Topics, Protected Audience (FLEDGE), Attribution Reporting, and on-device APIs — under heavy regulatory and competitor scrutiny.
- network-security№ 1279
TLS(トランスポート層セキュリティ)
IETF が標準化した暗号プロトコルで、ネットワーク上の 2 つのアプリケーション間の通信に機密性・完全性・認証を提供する。