Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

httpbis interim@チューリッヒ レポート

  1. 1. httpbis interim@チューリッヒ レポート IIJ 大津 繁樹 2014年1月28日 HTTP2勉強会#3
  2. 2. HTTP/2 これまでの歩み 年月 2012年1月 トピック IETF httpbis WGでHTTP/2.0の仕様検討開始することを決定 2012年11月 3つの候補案からSPDY仕様をベースにすることを決定 draft-00(SPDY/3仕様をそのまま)リリース 2013年1月 第1回中間会議(東京) draft-01リリース(HTTPからのUpgrade方法を追加) 2013年4月 draft-02リリース(フレームフォーマット・タイプの大幅な変更) 2013年6月 第2回中間会議(サンフランシスコ) 新ヘッダ圧縮仕様の採用を決定 2013年7月 draft-04リリース(最初の実装ドラフト) 2013年8月 第3回中間会議(ハンブルグ) 最初のHTTP/2.0相互接続試験を実施 draft-06リリース(実装ドラフト) 2013年10月 第4回中間会議(シアトル) 2回目の相互接続試験を実施 2013年12月 draft-09リリース(実装ドラフト) 2014年1月 第5回中間会議(チューリッヒ) 開催 今ココ
  3. 3. 第5回 httpbis interim@チューリッヒ 2014 1/22~24 スイスは 物価高過ぎ! 名物チーズ フォンデュ 私は、 • • • • Cisco Systems がホスト ではありませんよ。 20数名が集まる (F5など新参組も) 最終日は TLS WG と Joint (WG chairも参加) Application/Security AD達が集まる豪勢なinterim
  4. 4. HTTP-draft-09/2.0 interop? 僕らスイス来る前に もう済んじゃったから あらっ! 分科会で議論している から勝手にやっていて Firefoxのバグ1つ 見つけてやったぞ 教訓:宿題はすぐ済ませましょう。
  5. 5. 現状を一言で表すと、 HTTP/2は第4コーナーに入りました! でもまだコーナー抜けてません。 最終かどうかも???
  6. 6. チューリッヒ interim 概要 • issue の議論と方針決め • Priority Leveling 仕様の議論 (最後の大物) • Security Discussion (一応スコープ外で決着)
  7. 7. issue議論の結果 draft10の変更点(見た目編) • Editorが転職 (MS Open Tech→Mozilla) • マイナーバージョンの廃止 (HTTP/2, ALPNではh2) – 2.0←→2.1といった互換通信をしない。 – 次は HTTP/3 にすぐ取り掛かる。(短期にバージョンアップ) • GOAWAY→GTFO(General Termination of Future Operations) – Google の Hasan と Editor の Martin によるシャレ → 1/29に revert • FrameType、エラーコード、SETTINGSのリナンバー – LastCall に向けた準備 • SETTINGSフレーム構造の変更. 5(1+4)バイト毎に
  8. 8. もうチョイ深いdraft10変更点(その1) • FlowControl停止設定の廃止 – どっちみち DoS対策でフロー制御が必要だよね。 – 最大値(31bit)に設定すればいいじゃん。 • DATAフレームにEND_MESSAGEフラグの新設(*) – この後にWebSocketを入れられるようにしようか。 – hybiとジョイント WGをしてWSの検討しよう。 • 負荷分散について記述追加(*) – TCP張りっぱなしだから負荷分散がしにくい – Alt-Svcヘッダ使って分散する方法の記述を検討 (*) 1/28時点まだ未修整
  9. 9. もうチョイ深いdraft10変更点(その2) • 拡張(FrameType/SETTINGS)を認めない – DoSの温床、TCP拡張の様にフィルターされるのは嫌だ – やるなら別ALPN名でやる。 – Google は DNS/Cert. Pushなんかの拡張試験をやるよ。 • TLSの利用条件を厳しく – TLS1.2必須、圧縮不可、 ephemeral cipher suites (DHE,ECDHE) に制限、エラーコードの新設、BCP参照 • CRIME/BEAST BREACH対策(Padding付加) – BODYはDATAフレームに2種類のPADDINGフラグ (1or2byte)を追加してペイロードの先頭にpaddingを付加。 – HPACKは本当に必要かThreatModel検証が要必要 (*) (*) 1/28時点まだ未修整
  10. 10. HPACK-06の変更点 • Request/Response の Huffman Tableの共通化(*) – チョット最適化が悪くなるがそれほどでもない – コンテキストで共通化,サーバプッシュにメリット • cookie/set-cookie用の Huffman Tableの新設(*) – base64エンコードにして最適化を進めよう • エンコーダー側からのTableSize指定 – index:0を使おう。reference set消去とかぶるよ(涙) – FrameHeader Flagじゃあかん。bit flag を変更しようか(*) – SETTINGS-ACKとは独立。問題があるならエラーに。 • draftはHTTP/2と別々に進めよう。先にセキュリティレ ビューなどしてもらってもいいし。 (*) 1/28時点まだ未修整
  11. 11. 最後の大物 Priority Dependency ユースケースの例 • ダウンロード順が決められてるもの – jQueryロードしてから、JS実行コード – 分割ビデオやオーディオファイル(1章、2章…) • DOM Parseに影響するもの – document.write はDOM Parseをブロックするので早く取得 • ユーザ行動 – タブ切り替え、ViewPort変更(優先度変更) • Server Pushのヒント – 依存性で次にリクエストするファイルが分かるのでプッ シュに有用(そもそもサーバ側が情報持っているジャン) ユーザ視点の高速化に大きく利点、SPDY時代からの課題だが 複雑過ぎてGoogleがこれまで取り組めなかった。
  12. 12. Googleの提案 優先度 or ストリームの依存+順番を指定 END_STREAM Dependency Listを同期 END_STREAM_ACK index.html 状態の同期は 複雑すぎる! a.js 優先度:X a.js b.js b.js a.jpg index.html 優先度:X b.jpg dependency list(client) a.jpg b.jpg dependency list(server)
  13. 13. Weighted Dependency Group Priority Group ID: 1234(24bit), Weight: 255(8bit) X 0 A F B C D E G 木構造に しないよ ストリーム Priority Group(24) Weight(8) Stream Dependency(31) • Priority用のGroupを新設 • Group内で0を頂点としたスト リーム依存性を定義 • グループ間はWeight比でリ ソース割り当て • default はID下24bit, 重み16, stream_id:0に依存 これから議論、検証です。
  14. 14. Security Discussionの前に。 インターネットの脅威 • • • • PRISM: 情報収集・通信監視 (写真出典 wikipedia) Quantum: バックボーンMITM Fox Acid: 脆弱性攻撃 MUSCULAR: データセンター内通信傍受 IESG/IAB要請が出る見込み: IETFの技術仕様は Pervasive Surveillance 対策の検討必須
  15. 15. Security Discussion • HTTP/2 を TLS に限定する提案 – 従来通り HTTP でも利用できるようにする。 • Explicit Proxy(PolicyFilter、VirusScan , etc.用途 ) – HTTP/2のスコープ外にして、継続議論 • http:// の opportunistic(日和見)暗号化 – HTTP/2の進捗に影響ない範囲で検討継続 • コネクション集約 – Client証明書、 subjectAltName対応など問題あり
  16. 16. Security Discussion 結論:HTTP/2 はTLSに限定しない • HTTP/2は仕様的に、http/https両方使える。 • どう対応するかはマーケットに任せる。 • Firefox/Chrome は httpsのみ、IEは http もサポー トするといったちぐはぐが起こる。 ユーザ側のHTTP/2対応に混乱、問題は生じない か? 個人情報を扱うサイトは、HSTS/Key pinning などで フルHTTPS化推進へ
  17. 17. Security Discussion HTTP/2の http:// に日和見暗号を! • そもそも必要、不要? (このまま何もしないわけにはい かない) • サーバ認証は? – する(httpsと実質同じ) – しない(Active MITMには無力) – 別の仕組み(DNSSECを使うDANE、TLS拡張を使うTACK 等々) • 切り替え方法は? (対ダウングレードアタック) – ALPNみたいなヒント交換、 DNSレコード、HTTP/2フ レーム内で暗号化ハンドシェイク、既存の443ポート を使ってSETTINGSで交換
  18. 18. 今後の予定 • 2/7 (最悪2/14)までに draft10 をリリース – みんな仕事速い!ほとんど修正済 • IETF London(3/2-7)翌日3/8にhttpbisの非公式 interimを開催(正式な interopはやらない) • 6月上旬米国東海岸で第6回interimを開催 まだまだあきらめまへん • 4月 HTTP/2 の WG Last Call • 8月 IETF Last Call を目指す。

×