O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
425 Too Early
HTTP/Tokyo
@flano_yuki
@flano_yuki
- プロトコルの人 (@flano_yuki)
- 標準化とかに興味がある
- HTTP, HTTP/3, QUIC, TLS
WebTransport, Masque, WebPackaging…
- Blog: AS...
425 Too Early
知ってますかー?
RFC 8470 「Using Early Data in HTTP」
で定義されるステータスコード
RFC 8470 「Using Early Data in HTTP」
で定義されるステータスコード
?
Early Dataを説明するため
一旦 TLS1.3 の話をします
TLS1.3 (RFC8446)
通信の暗号化を行うプロトコル。HTTPSとかで使われる
暗号化された通信を開始する前に、TLSハンドシェイクという準備を
行う(暗号アルゴリズム・パラメータ、証明書など)。
準備が整ったら、アプリケーションプロ...
TLSハンドシェイク
ハンドシェイクには種類がある (正式なフローはRFC見てね)
Client Server
ClientHello
ServerHello (etc...)
HTTP Request
HTTP Response
フルハンドシ...
TLSハンドシェイク
ハンドシェイクには種類がある (正式なフローはRFC見てね)
ClientHello
Client Server
ClientHello
ServerHello (etc...)
HTTP Response
0-RTTハン...
TLSハンドシェイク
ハンドシェイクには種類がある (正式なフローはRFC見てね)
ClientHello
Client Server
ClientHello
ServerHello (etc...)
HTTP Response
0-RTTハン...
Early Dataとリプレイ攻撃
Early Dataは暗号化されているがリプレイ攻撃の危険がある
経路上の観測者はリクエストの中身はわからないが複製できる。
Client Server
HTTP Request
attacker
Clien...
Early Dataとリプレイ攻撃
サーバはHTTPリクエストを見て、冪等なリクエストでない場合は拒
否するという選択もできる
(ハンドシェイク後に送り直される)
Client Serverattacker
ClientHelloHTTP Re...
RFC 8470 「Using Early Data in HTTP」
で定義されるステータスコード
!
Using Early Data in HTTP
HTTPの場合に、安全にEarly Dataを扱えるようにする仕様
ProxyやCDNでHTTPSを一旦終端する構成でも
ちゃんとEarly Data使えるようにしたい
Client Proxy...
Using Early Data in HTTP
HTTPの場合に、安全にEarly Dataを扱えるようにする仕様
ProxyやCDNでHTTPSを一旦終端する構成でも
ちゃんとEarly Data使えるようにしたい
Client Proxy...
Using Early Data in HTTP
この問題を解決するために、以下の2つを新しく定義する
- ProxyがOriginにEarly Dataを中継する際
Early-Data リクエストヘッダを追加する
- Originは、リクエ...
Early-Dataヘッダと425 Too Early
Client Server
HTTP Request
Proxy
HTTP Request
- Early-Data:1
HTTP Response
- status: 425HTTP R...
動作確認
簡易的な構成で実験する
- Firefoxで、https://asnokaze.com/ につなぐ(HTTP/1.1)
- コネクションを切断する
- 続けて、0-RTTで https://asnokaze.com/425 につなぐ(...
サーバ側
log_format main '$remote_addr - $remote_user "$request" ‘
'$status $body_bytes_sent "$http_referer" '
'$ssl_protocol ...
動作確認
簡易的な構成で実験する
Client Origin
https://asnokaze.com/
https://asnokaze.com/425
10.123.xxx.xxx - - "GET / HTTP/1.1"200 323 "...
Wireshark
0-RTTで /425 にリクエストしたときに何が起こったか。
Wireshark
0-RTTで /425 にリクエストしたときに何が起こったか。
0-RTT Early Data
(SeverHelloより早く投げて
いる)
425を受けて再接続
ハンドシェイク後に
リクエストを投げてる
Using Early Data in HTTP のまとめ
- TLS1.3 0-RTTハンドシェイクを使うと、より早いタイミングでアプ
リケーションを送信できる(Early Data)。
- しかしEarly Dataはリプレイ攻撃に対して脆...
おまけ
418 vs 425
(標準化の現場より)
425 vs 418
HTTPの仕様のメンテナンスと標準化はIETFのHTTP WGでやって
る。
Too Earlyのステータスコードを策定してる際、425にするか418にす
るか議論になった。
番号空間はIANAによって管理されているが、H...
https://www.google.com/teapot
議論
ステータスコード 418 I’m a tea potは、エイプリルフールに発行され
たジョークRFCであるRFC2324「Hyper Text Coffee Pot Control
Protocol」 で定義されているステータスコード。
...
議論ののち
■ HTTPセマンティクスの仕様が現在改定作業中
HTTP/1.1シンタックスとセマンティクスを分離し、HTTP/3などからセマ
ンティクスの仕様として参照出来るようになる
(H/2やH/3はHTTPメッセージのやりとりを効率よくや...
9.5.19. 418 (Unused)
[RFC2324] was an April 1 RFC that lampooned the various ways
HTTP was abused; one such abuse was the ...
おわり
おまけのおまけ
Other Topic
Other Topics
2019年にブログで取り上げたトピック
● HTTP/2 ORIGINフレームのセキュリティを改善する提案仕様 - ASnoKaze blog 

● Delegated Credentials for TLS につい...
● QUICにおいてNAT検出を行う拡張フレームの提案仕様 - ASnoKaze blog 

● WiresharkでのQUICの復号(decrypt) - ASnoKaze blog 

● 中間証明書を要求しないTLSフラグ拡張 - AS...
● HTTPSで接続するための追加情報を格納するHTTPSSVCレコード - ASnoKaze blog 

● 複数TLSコネクションの署名処理をまとめて行うBatch Signing - ASnoKaze blog 

● 動画上にコメント...
● ブラウザでIPマルチキャストを受信するMulticastReceiver API - ASnoKaze blog 

● QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog 

● Do...
Status 425 HTTP/Tokyo
Próximos SlideShares
Carregando em…5
×

Status 425 HTTP/Tokyo

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

  • Seja o primeiro a comentar

Status 425 HTTP/Tokyo

  1. 1. 425 Too Early HTTP/Tokyo @flano_yuki
  2. 2. @flano_yuki - プロトコルの人 (@flano_yuki) - 標準化とかに興味がある - HTTP, HTTP/3, QUIC, TLS WebTransport, Masque, WebPackaging… - Blog: ASnoKaze - https://asnokaze.hatenablog.com/
  3. 3. 425 Too Early 知ってますかー?
  4. 4. RFC 8470 「Using Early Data in HTTP」 で定義されるステータスコード
  5. 5. RFC 8470 「Using Early Data in HTTP」 で定義されるステータスコード ?
  6. 6. Early Dataを説明するため 一旦 TLS1.3 の話をします
  7. 7. TLS1.3 (RFC8446) 通信の暗号化を行うプロトコル。HTTPSとかで使われる 暗号化された通信を開始する前に、TLSハンドシェイクという準備を 行う(暗号アルゴリズム・パラメータ、証明書など)。 準備が整ったら、アプリケーションプロトコルのデータを暗号化してや りとりをする。 TLS 1.3ってやつが新しいやつ
  8. 8. TLSハンドシェイク ハンドシェイクには種類がある (正式なフローはRFC見てね) Client Server ClientHello ServerHello (etc...) HTTP Request HTTP Response フルハンドシェイク Client Server ClientHello ServerHello (etc...) HTTP Response 0-RTTハンドシェイク HTTP Request Fin Fin
  9. 9. TLSハンドシェイク ハンドシェイクには種類がある (正式なフローはRFC見てね) ClientHello Client Server ClientHello ServerHello (etc...) HTTP Response 0-RTTハンドシェイク HTTP Request Early Data Fin
  10. 10. TLSハンドシェイク ハンドシェイクには種類がある (正式なフローはRFC見てね) ClientHello Client Server ClientHello ServerHello (etc...) HTTP Response 0-RTTハンドシェイク HTTP Request Early Data Handshake中にアプリケーションデー タを送信する。早い。 もちろん暗号化される (事前に共有された鍵を使用する) Fin
  11. 11. Early Dataとリプレイ攻撃 Early Dataは暗号化されているがリプレイ攻撃の危険がある 経路上の観測者はリクエストの中身はわからないが複製できる。 Client Server HTTP Request attacker ClientHelloHTTP Request リプレイ攻撃 ClientHello
  12. 12. Early Dataとリプレイ攻撃 サーバはHTTPリクエストを見て、冪等なリクエストでない場合は拒 否するという選択もできる (ハンドシェイク後に送り直される) Client Serverattacker ClientHelloHTTP Request そのEarly-Dataの リクエストは冪等じゃ ないから処理しないよ ClientHelloHTTP Request https://tools.ietf.org/html/rfc8446#section-4.2.10
  13. 13. RFC 8470 「Using Early Data in HTTP」 で定義されるステータスコード !
  14. 14. Using Early Data in HTTP HTTPの場合に、安全にEarly Dataを扱えるようにする仕様 ProxyやCDNでHTTPSを一旦終端する構成でも ちゃんとEarly Data使えるようにしたい Client Proxy/CDN Origin TLS Hnadshake TLS Hnadshake Plain HTTP Origin
  15. 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 ProxyはEarly Dataの リクエストが冪等か 判断できない もともとのリクエストが Early Dataで送られた かわからない
  16. 16. Using Early Data in HTTP この問題を解決するために、以下の2つを新しく定義する - ProxyがOriginにEarly Dataを中継する際 Early-Data リクエストヘッダを追加する - Originは、リクエストが冪等でない場合は ステータス425 Too Early を返して、Early Dataで送信されたリ クエストとを拒否したことを示す
  17. 17. Early-Dataヘッダと425 Too Early Client Server HTTP Request Proxy HTTP Request - Early-Data:1 HTTP Response - status: 425HTTP Response - status: 425 ClientHello (Handshake...) そのリクエストは冪 等じゃないから、拒 否します 送り直します
  18. 18. 動作確認 簡易的な構成で実験する - Firefoxで、https://asnokaze.com/ につなぐ(HTTP/1.1) - コネクションを切断する - 続けて、0-RTTで https://asnokaze.com/425 につなぐ(425) Client Origin https://asnokaze.com/ https://asnokaze.com/425
  19. 19. サーバ側 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だったか出す
  20. 20. 動作確認 簡易的な構成で実験する 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が 来ても今度は無視)
  21. 21. Wireshark 0-RTTで /425 にリクエストしたときに何が起こったか。
  22. 22. Wireshark 0-RTTで /425 にリクエストしたときに何が起こったか。 0-RTT Early Data (SeverHelloより早く投げて いる) 425を受けて再接続 ハンドシェイク後に リクエストを投げてる
  23. 23. Using Early Data in HTTP のまとめ - TLS1.3 0-RTTハンドシェイクを使うと、より早いタイミングでアプ リケーションを送信できる(Early Data)。 - しかしEarly Dataはリプレイ攻撃に対して脆弱。サーバ側の判断 で拒否する - 425ステータスコード(Too Early)と、Early-Dataヘッダを使って、 HTTPでもEarly Dataを安全に使えるようになった
  24. 24. おまけ
  25. 25. 418 vs 425 (標準化の現場より)
  26. 26. 425 vs 418 HTTPの仕様のメンテナンスと標準化はIETFのHTTP WGでやって る。 Too Earlyのステータスコードを策定してる際、425にするか418にす るか議論になった。 番号空間はIANAによって管理されているが、HTTP の 418は使わ れていなかった。
  27. 27. https://www.google.com/teapot
  28. 28. 議論 ステータスコード 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...)
  29. 29. 議論ののち ■ 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がどうなったかというと...
  30. 30. 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.
  31. 31. おわり
  32. 32. おまけのおまけ Other Topic
  33. 33. 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 

  34. 34. ● 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 

  35. 35. ● 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 

  36. 36. ● ブラウザで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で試してみた)

×