Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,176 views

Published on

Published in: Technology
  • Be the first to comment

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 を目指す。

×