15. Using Early Data in HTTP
HTTPの場合に、安全にEarly Dataを扱えるようにする仕様
ProxyやCDNでHTTPSを一旦終端する構成でも
ちゃんとEarly Data使えるようにしたい
Client Proxy/CDN
Origin
TLS Hnadshake
TLS Hnadshake
Plain HTTP Origin
16. Using Early Data in HTTP
HTTPの場合に、安全にEarly Dataを扱えるようにする仕様
ProxyやCDNでHTTPSを一旦終端する構成でも
ちゃんとEarly Data使えるようにしたい
Client Proxy/CDN
Origin
TLS Hnadshake
TLS Hnadshake
Plain HTTP Origin
ProxyはEarly Dataの
リクエストが冪等か
判断できない
もともとのリクエストが
Early Dataで送られた
かわからない
17. Using Early Data in HTTP
この問題を解決するために、以下の2つを新しく定義する
- ProxyがOriginにEarly Dataを中継する際
Early-Data リクエストヘッダを追加する
- Originは、リクエストが冪等でない場合は
ステータス425 Too Early を返して、Early Dataで送信されたリ
クエストとを拒否したことを示す
18. Early-Dataヘッダと425 Too Early
Client Server
HTTP Request
Proxy
HTTP Request
- Early-Data:1
HTTP Response
- status: 425HTTP Response
- status: 425
ClientHello
(Handshake...) そのリクエストは冪
等じゃないから、拒
否します
送り直します
29. 議論
ステータスコード 418 I’m a tea potは、エイプリルフールに発行され
たジョークRFCであるRFC2324「Hyper Text Coffee Pot Control
Protocol」 で定義されているステータスコード。
418 I’m a tea potはHyper Text Coffee Pot Control Protocolのス
テータスコードであり、HTTPのステータスコードではない
しかし、あちこちに実装されている (golang, nodejs...)
31. 9.5.19. 418 (Unused)
[RFC2324] was an April 1 RFC that lampooned the various ways
HTTP was abused; one such abuse was the definition of an
application-specific 418 status code. In the intervening years,
this status code has been widely implemented as an "Easter
Egg", and therefore is effectively consumed by this use.
34. Other Topics
2019年にブログで取り上げたトピック
● HTTP/2 ORIGINフレームのセキュリティを改善する提案仕様 - ASnoKaze blog
● Delegated Credentials for TLS について - ASnoKaze blog
● Signed Exchange Reporting for distributors について - ASnoKaze blog
● Fetch Metadataリクエストヘッダについて (Sec-Fetch-*) - ASnoKaze blog
● Fake SNIという提案仕様について - ASnoKaze blog
● リバースプロキシのエラーを示す Proxy-Statusヘッダの提案仕様 - ASnoKaze blog
● HTTP/3で接続してVPNとして使うMASQUEプロトコルの提案仕様 - ASnoKaze blog
● DigiCertによるプライベートアドレスの逆引き名の証明書誤発行 - ASnoKaze blog
● Secondary Certificate Authentication in HTTP/2 という仕様について - ASnoKaze blog
● HTTP/2をバイトストリームトランスポートとして利用する提案仕様 - ASnoKaze blog
35. ● QUICにおいてNAT検出を行う拡張フレームの提案仕様 - ASnoKaze blog
● WiresharkでのQUICの復号(decrypt) - ASnoKaze blog
● 中間証明書を要求しないTLSフラグ拡張 - ASnoKaze blog
● HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog
● 「Address-bound Token for QUIC」が面白い - ASnoKaze blog
● HTTP/2においてTLS1.3のpost-handshake authenticationの禁止 - ASnoKaze blog
● QUICの暗号化と鍵の導出について - ASnoKaze blog
● 新しいWebの双方向通信 "WebTransport" について - ASnoKaze blog
● Cross-Origin-Opener-Policyについて - ASnoKaze blog
● Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog
● サービスやリソースの廃止時間を示すSunset HTTP ヘッダ (RFC8594) - ASnoKaze blog
● 安全なコンテンツを要求するPrefer:safeヘッダ (RFC8674) - ASnoKaze blog
● Cross-Origin-Embedder-Policyヘッダについて - ASnoKaze blog
● 処理中のPOSTリクエストを別のサーバで引き継ぐPartial POST Replayについて blog
● QUICのAckとロスリカバリについて - ASnoKaze blog
● 提案仕様「HTTP Transport Authentication」について - ASnoKaze blog
● TCP Slow Startを改善する HyStart++について - ASnoKaze blog
36. ● HTTPSで接続するための追加情報を格納するHTTPSSVCレコード - ASnoKaze blog
● 複数TLSコネクションの署名処理をまとめて行うBatch Signing - ASnoKaze blog
● 動画上にコメントを表示する"弾幕"の仕様 - ASnoKaze blog
● curlのHTTP/3実験実装を触ってみる - ASnoKaze blog
● TCP/QUIC相互変換のポートフォワードツールを書いた - ASnoKaze blog
● Double-keyed HTTP cache に関するメモ - ASnoKaze blog
● Mixed Content Level 2の仕様について - ASnoKaze blog
● HTTPリクエストのレートリミットを示すRateLimitレスポンスヘッダの提案仕様 blog
● QUICのコネクションマイグレーションについて - ASnoKaze blog
● ChromeのHTTP/3(ドラフト版)対応 - ASnoKaze blog
● WebTransport over QUIC について - ASnoKaze blog
● NginxでHTTP/3が動いた (Cloudflareパッチ) - ASnoKaze blog
● 「Binary Structured HTTP Headers」について - ASnoKaze blog
● キャッシュ情報を示す、Cache-Status レスポンスヘッダ - ASnoKaze blog
● HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog
37. ● ブラウザでIPマルチキャストを受信するMulticastReceiver API - ASnoKaze blog
● QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog
● DoHを利用しないように指示するCanary domainの仕組み - ASnoKaze blog
● ネットワークメトリクスを示すTransport-Info HTTPレスポンスヘッダ - ASnoKaze blog
● HTTPで部分的アップロードを可能にする Partial Uploadsという提案仕様 - ASnoKaze blog
● HTTPヘッダに構造定義を与える Structured Headers の提案仕様 (draft-14) CookieのPriority属性の
仕様 - ASnoKaze blog
● Crash/Deprecation/Intervention Reporting について - ASnoKaze blog
● HTTP/3をUDPロードバランサで分散するときの問題点 (AWS NLBで試してみた)