HTTP Status Code 425とTLS1.3 0-RTTについて

1. 425 Too Early
HTTP/Tokyo
@flano_yuki

2. @flano_yuki
- プロトコルの人 (@flano_yuki)
- 標準化とかに興味がある
- HTTP, HTTP/3, QUIC, TLS
WebTransport, Masque, WebPackaging…
- Blog: ASnoKaze
- https://asnokaze.hatenablog.com/

3. 425 Too Early
知ってますかー？

4. RFC 8470 「Using Early Data in HTTP」
で定義されるステータスコード

5. RFC 8470 「Using Early Data in HTTP」
で定義されるステータスコード
？

6. Early Dataを説明するため
一旦 TLS1.3 の話をします

7. TLS1.3 (RFC8446)
通信の暗号化を行うプロトコル。HTTPSとかで使われる
暗号化された通信を開始する前に、TLSハンドシェイクという準備を
行う（暗号アルゴリズム・パラメータ、証明書など）。
準備が整ったら、アプリケーションプロトコルのデータを暗号化してや
りとりをする。
TLS 1.3ってやつが新しいやつ

9. TLSハンドシェイク
ハンドシェイクには種類がある (正式なフローはRFC見てね)
Client Server
ClientHello
ServerHello (etc...)
HTTP Request
HTTP Response
フルハンドシェイク
Client Server
ClientHello
ServerHello (etc...)
HTTP Response
0-RTTハンドシェイク
HTTP Request
Fin
Fin

10. TLSハンドシェイク
ハンドシェイクには種類がある (正式なフローはRFC見てね)
ClientHello
Client Server
ClientHello
ServerHello (etc...)
HTTP Response
0-RTTハンドシェイク
HTTP Request
Early Data
Fin

11. TLSハンドシェイク
ハンドシェイクには種類がある (正式なフローはRFC見てね)
ClientHello
Client Server
ClientHello
ServerHello (etc...)
HTTP Response
0-RTTハンドシェイク
HTTP Request
Early Data
Handshake中にアプリケーションデー
タを送信する。早い。
もちろん暗号化される
(事前に共有された鍵を使用する)
Fin

12. Early Dataとリプレイ攻撃
Early Dataは暗号化されているがリプレイ攻撃の危険がある
経路上の観測者はリクエストの中身はわからないが複製できる。
Client Server
HTTP Request
attacker
ClientHelloHTTP Request
リプレイ攻撃
ClientHello

13. Early Dataとリプレイ攻撃
サーバはHTTPリクエストを見て、冪等なリクエストでない場合は拒
否するという選択もできる
(ハンドシェイク後に送り直される)
Client Serverattacker
ClientHelloHTTP Request
そのEarly-Dataの
リクエストは冪等じゃ
ないから処理しないよ
ClientHelloHTTP Request
https://tools.ietf.org/html/rfc8446#section-4.2.10

14. RFC 8470 「Using Early Data in HTTP」
で定義されるステータスコード
！

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...) そのリクエストは冪
等じゃないから、拒
否します
送り直します

19. 動作確認
簡易的な構成で実験する
- Firefoxで、https://asnokaze.com/ につなぐ(HTTP/1.1)
- コネクションを切断する
- 続けて、0-RTTで https://asnokaze.com/425 につなぐ(425)
Client Origin
https://asnokaze.com/
https://asnokaze.com/425

20. サーバ側
log_format main '$remote_addr - $remote_user "$request" ‘
'$status $body_bytes_sent "$http_referer" '
'$ssl_protocol early=$ssl_early_data';
Nginxで
- /425 へのリクエスト対して、425を返すようにする
- 設定でssl_early_dataを有効にする
- ログにリクエストがEarly_Dataだったか出す

21. 動作確認
簡易的な構成で実験する
Client Origin
https://asnokaze.com/
https://asnokaze.com/425
10.123.xxx.xxx - - "GET / HTTP/1.1"200 323 "-" TLSv1.3 early=-
10.123.xxx.xxx - - "GET /425 HTTP/1.1"425 0 "-" TLSv1.3 early=1
10.123.xxx.xxx - - "GET /425 HTTP/1.1"425 0 "-" TLSv1.3 early=-
リクエストし直してる(425が
来ても今度は無視)

22. Wireshark
0-RTTで /425 にリクエストしたときに何が起こったか。

23. Wireshark
0-RTTで /425 にリクエストしたときに何が起こったか。
0-RTT Early Data
(SeverHelloより早く投げて
いる)
425を受けて再接続
ハンドシェイク後に
リクエストを投げてる

24. Using Early Data in HTTP のまとめ
- TLS1.3 0-RTTハンドシェイクを使うと、より早いタイミングでアプ
リケーションを送信できる(Early Data)。
- しかしEarly Dataはリプレイ攻撃に対して脆弱。サーバ側の判断
で拒否する
- 425ステータスコード(Too Early)と、Early-Dataヘッダを使って、
HTTPでもEarly Dataを安全に使えるようになった

25. おまけ

26. 418 vs 425
(標準化の現場より)

27. 425 vs 418
HTTPの仕様のメンテナンスと標準化はIETFのHTTP WGでやって
る。
Too Earlyのステータスコードを策定してる際、425にするか418にす
るか議論になった。
番号空間はIANAによって管理されているが、HTTP の 418は使わ
れていなかった。

28. https://www.google.com/teapot

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...)

30. 議論ののち
■ HTTPセマンティクスの仕様が現在改定作業中
HTTP/1.1シンタックスとセマンティクスを分離し、HTTP/3などからセマ
ンティクスの仕様として参照出来るようになる
（H/2やH/3はHTTPメッセージのやりとりを効率よくやる。HTTPのヘッダやステータスコードの意味は変わらな
い。）
■ いまのRFC 7230~37から以下の仕様に再改定される予定 (draft)
- HTTP Semantics (draft-ietf-httpbis-semantics)
- HTTP Caching (draft-ietf-httpbis-cache)
- HTTP/1.1 Messaging (draft-ietf-httpbis-messaging)
そこで418がどうなったかというと...

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.

32. おわり

33. おまけのおまけ
Other Topic

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で試してみた)