HTTP2ことはじめ

Eaab8f0f3d5df0227e59441262e9ba1a?s=47 Secure Sky Technology
October 02, 2018
320

 HTTP2ことはじめ

HTTP2ことはじめ

Eaab8f0f3d5df0227e59441262e9ba1a?s=128

Secure Sky Technology

October 02, 2018
Tweet

Transcript

  1. HTTP/2 ことはじめ 2018年9月29日 株式会社セキュアスカイ・テクノロジー 技術開発部 岩間湧 越智郁

  2. 2 資料は以下のURLに置いてあります。 https://github.com/SecureSkyTechnology/http2-lab

  3. おしらせ 本セッションは「セミナー」「デモ形式」で進行します。 環境などは後日改めて展開いたします。 正確さは努めましたが、誤り等ありましたらご指摘ください。 3

  4. もくじ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 4
  5. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 5
  6. 1. はじめに -自己紹介- 岩間 湧 越智 郁 ・診断員として1月に入社 ・たまにCTF ・最近アニメ貪ってます

    ・9月に入ってから  緩やかに体重増加中 ・新卒入社2年目の診断員 ・北九州高専出身(制情) ・9月に入ってから  楽器をはじめたけど  さっそく休会中 6
  7. 1. はじめに -      の紹介- Webセキュリティ専門企業です! 防御サービス WAF「Scutum」 脆弱性を無害化します 教育・支援サービス 脆弱性を作らないよう

    支援します 脆弱性診断サービス 脆弱性を見つけます 開発・運用の各フェーズに対応 7
  8. カンファレンス聴講 1. はじめに -テーマ選定- 「学習時間」制度 「未来研」制度 Tech blog デモベース 診断員視点

    セキュリティ考察 「HTTP/2」に挑戦しよう! 8
  9. 1. はじめに -テーマについて- 私たちの生活で身近なプロトコル、HTTP。 HTTP/1.1のパフォーマンス上の問題の改善を目的として、2015年 にHTTP/2が発表されています。 同じ名前のプロトコルですが、バージョンが2になると様々な部分に 変化があることがわかりました。 一緒にHTTP/2をことはじめしてみましょう。 9

  10. 1. はじめに -テーマについて- https://dictionary.goo.ne.jp/jn/80682/meaning/m0u/ https://dictionary.goo.ne.jp/jn/80682/meaning/m0u/ 10

  11. 1. はじめに - 本セッションの目的 - 本講演でみなさんと目指すGOAL • HTTP/2のことを知る • HTTP/2の性能を知る

    • 検証方法の紹介 わたしたちのGOAL • 診断員目線でセキュリティ面を考察する(私見) 11
  12. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 12
  13. 2. HTTP/2がうまれた背景 90年代HTTP誕生→変化なし NW ビジネス リソース 変化  サービス提供者は  通信品質を制御できない 13

  14. 2. HTTP/2がうまれた背景 90年代HTTP誕生→変化なし NW ビジネス リソース 変化  サービス提供者は  通信品質を制御できない アプリケーション

    様々な(泥臭い)工夫 HTTP/1.1 根本的に 合理化したい! 14
  15. 2. HTTP/2がうまれた背景 90年代HTTP誕生→変化なし NW ビジネス リソース 変化  サービス提供者は  通信品質を制御できない アプリケーション

    HTTP/2 プロトコル レベルで… 15
  16. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 16
  17. 3. 本セッションの提案 -再確認- • HTTP/2のことを知る →4章「ことはじめ」 • HTTP/2の性能を知る →5章パフォーマンス • 検証方法の紹介

    →随時!(全体構成だけ今から先に) • 診断員目線でセキュリティ面考察 →7章  セッション中に  HTTP/2 を「h2」  HTTP/1.1を「h1」  と呼ぶことがあります 17
  18. 3. 本セッションの提案 -環境構成- HostOS (WIndows) GuestOS(Ubuntu16.04) enp0s8 docker0 (bridge) VirtualBox

    Host-Only Network network adapter PHP eth0 Apache2 eth0 H2O eth0 Nginx eth0 vethxxx vethxxx vethxxx vethxxx :443 :443 :443 :9000 :8443 :9443 Port Forward Protocol :443 ➡ Nginx :443 h2 :1443 ➡ H2O :443 h2 :2443 ➡ Apache2 :443 h2 :8443 ➡ Nginx :8443 h1 :9443 ➡ Nginx :9443 h2(tlsv1.1) 172.16.1.0/24 .10 .1 Docker Networks Container #1 Container #2 Container #3 Container #4 h2load nghttp 18
  19. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 19
  20. 4. HTTP/2のキーワード Client Server HTTP/2 TLS TCP/IP Connection Stream H

    H D Server Push HPACK ALPN e.t.c. negotiation Framing (Binary) 20 いろいろ あるっちゃん
  21. 4. HTTP/2のキーワード ポイントは Performance の向上 変わらないもの 「リクエスト」「レスポンス」の仕組み 変わるもの「伝え方」 h2で全く別のものに なったのではない

    Framing (Binary) HPACK stream Server Push negotiation 21
  22. 4. セマンティクスの維持 セマンティクス: その機能に求められる「意図」 Client (Browser) Server 変更 なし Web

    app h1相当の メッセージ ・メソッド ・ヘッダ ・ボディ ・ステータスコード ・ボディ h2形式の リクエスト h2形式の レスポンス 22
  23.  DEMO 1  セマンティクスの維持 HTTP/1.1とHTTP/2を 見比べてみる 23

  24. HTTP1.1 HTTP/2 4. セマンティクスの維持 ヘッダ メソッド ステータス コード ボディ ・h1は改行の後

    ・h2はDATAフレーム 24
  25. 4. HTTP/2のキーワード Client Server HTTP/2 TLS TCP/IP Connection Stream H

    H D Server Push HPACK ALPN e.t.c. negotiation Framing (Binary) 25
  26. 26 HPACK 同じヘッダ、また送るの? このデータ重 …続きはまだ? Stream 構成 決まってる 解釈楽 ~!

    終わりは どこ? バイナリ フレーム 4. HTTP/2のキーワード index.html ramen.jpg どうせ使うよね 一緒にどうぞ Server Push
  27. 27 HPACK 同じヘッダ、また送るの? このデータ重 …続きはまだ? Stream 構成 決まってる 解釈楽 ~!

    終わりは どこ? バイナリ フレーム 4. HTTP/2のキーワード index.html ramen.jpg どうせ使うよね 一緒にどうぞ Server Push
  28. 4. バイナリフレーム Client Server HTTP/2 TLS TCP/IP Connection Stream H

    H D Server Push HPACK ALPN negotiation Framing (Binary) 28
  29. 4. バイナリフレーム POST /upload HTTP1.1 Host:www.example.org Content-Type: application/json Content-Length:15 {“msg”:”hello”}

    HEADERSフレーム DATAフレーム H H D HTTP/2における通信の最小単位が「フレーム」 HTTP/1.1 HTTP/2 29
  30. 4. バイナリフレーム HEADERSフレーム = フレームヘッダ + HEADERSフレームペイロード DATAフレーム = フレームヘッダ

    + DATAフレームペイロード H H D HTTP/2における通信の最小単位 HTTP/2 30
  31. 4. バイナリフレーム 31

  32. 4. バイナリフレーム Length(24) Type(8): 01はHEADERSフレーム Flags(8) R(1) StreanIdentifier(31) weight(8) Stream

    Dependency(31) フレームヘッダ (bit) 32
  33. 33 HPACK 同じヘッダ、また送るの? このデータ重 …続きはまだ? Stream 構成 決まってる 解釈楽 ~!

    終わりは どこ? バイナリ フレーム 4. HTTP/2のキーワード index.html ramen.jpg どうせ使うよね 一緒にどうぞ Server Push
  34. 4. HPACK HTTP/2 のパフォーマンス改善のコア技術 HTTPヘッダには決まった名前や結果が良く出現 → 外部辞書を用意し参照すれば、ヘッダサイズが減少 34

  35. 4. HPACK 2つの辞書 • 静的テーブル • 動的テーブル 35 INDEX 1

    ・ ・ ・ 61 静的テーブル 62 ・ ・ ・ 動的テーブル
  36. 4. HPACK 具体的にどんな辞書(テーブル)を利用しているのか 36 フレームヘッダ

  37. 4. HPACK 82 1 0 0 0 0 0 1

    0 RFC7541 「インデックスヘッダフィールド表現」 静的テーブルまたは動的テーブルのエントリを識別 インデックス(=2) 37 RFC 7541 付録A
  38. 38 HPACK 同じヘッダ、また送るの? このデータ重 …続きはまだ? Stream 構成 決まってる 解釈楽 ~!

    終わりは どこ? バイナリ フレーム 4. HTTP/2のキーワード index.html ramen.jpg どうせ使うよね 一緒にどうぞ Server Push
  39. 4. Stream Client Server HTTP/2 TLS TCP/IP Connection Stream Server

    Push HPACK ALPN negotiation H H D 39
  40. 4. Stream Stream H H D Connection HTTP/2における通信を管理する単位で、多重化能力のコア技術 [1] [2]

    [0] リクエスト レスポンス 1ストリーム Client→Serverの場合 Stream ID は奇数 フレームの フラグで開閉 stream ID 40 Server→Clientの場合 Stream ID は偶数 (Server Push)
  41. 4. Stream HEADERS[5] DATA[1] HEADERS[3] DATA[3] 実体は無いので、同じStream IDを持つ一連のフレームが 受信時にグループ化される 41

  42. 4. Streamが多重化能力のコアとは? Connection HTTP/1.1の場合 HoLブロッキング TCP接続の非効率な利用 Connection HTTP/2の場合 Stream Stream

    42
  43. 4. Streamが多重化能力のコアとは? Connection HTTP/1.1の場合 43 … 最大6コネクションまで 1つ目のリクエストが完了しな いと後続のリクエストが送れ ない

    (Head of Line Blocking) 待機中…( ˘ω˘ ) 待機中…( ˘ω˘ )
  44. 4. Streamが多重化能力のコアとは? 44 … Stream HTTP/2の場合 1つ目のリクエストが完了して いなくても、後続のリクエスト を送ることができる。

  45.  DEMO 2-1  streamの中身を見る 45

  46. 4. HEADERSフレーム フラグ Stream ID (クライアントからなので奇数の 13) Header Block Fragment

    非圧縮のヘッダーの中身 46
  47. 4. DATAフレーム フラグ Stream ID (Reponse Body) Data WiresharkによるData解析内容 47

  48.  DEMO 2-2  HTTP/1.1のconnection HTTP/2のstream を見比べてみる 48

  49. 4. h1の場合(connection) 49

  50. 4. h1の場合(connection) 最大で6並列 1つコネクションが空いたので次 の通信が始まる 50

  51. 4. h2の場合(stream) 51

  52. 4. h2の場合(stream) 並列に6以上通信が走っている 52

  53. 53 HPACK 同じヘッダ、また送るの? このデータ重 …続きはまだ? Stream 構成 決まってる 解釈楽 ~!

    終わりは どこ? バイナリ フレーム 4. HTTP/2のキーワード index.html ramen.jpg どうせ使うよね 一緒にどうぞ Server Push
  54. 4. Server Push Client Server HTTP/2 TLS TCP/IP Connection Stream

    H H D Server Push HPACK ALPN negotiation 54
  55. 4. Server Push Connection Stream H H D ALPN 1:

    予想 (次はramen.jpg) 2: index.htmlをリクエスト index.html ramen.jpg 3: index.htmlをレスポンス 3: ramen.jpgをプッシュ 4: キャッシュとして  ramen.jpgを保存 5: 通常のHTTPの  仕組み同様  キャッシュを利用する 55
  56. 4. Server Push Promised-Stream-ID プッシュするデータを 送信するために予約するストリーム サーバからの通信のためIDは偶数の2 Header Block Fragment

    予想するHTTPリクエストのヘッダ。 サーバはこのリクエストを受け取ったと想定して HTTPレスポンスを返す 56
  57. 4. negotiation Client Server HTTP/2 TLS TCP/IP Connection Stream H

    H D Server Push HPACK ALPN negotiation 57
  58. 4. negotiation http:// は 80ポート https:// は 443ポート https://www.example.com/index.html 通信開始前に相手がh2とh1のどちらに対応しているか確認する

    h2? h1? ・ALPN (Application Layer Protocol Negotiation) ・HTTP/1.1で接続してからアップグレード ・HTTP/2に対応していることが事前にわかっている 3つの方法 58
  59. 4. ALPN (Application Layer Negotiation protocol) Client Hello ALPN 拡張

    プロトコルリスト h2? 59
  60. 4. ALPN (Application Layer Negotiation protocol) Server Hello ALPN 拡張

    プロトコル選択 h2! 60
  61. 4. negotiation HTTP/2 ALPN PRI*HTTP/2.0\r\n\r\nSM\r\n\r\n 「コネクションプリフェイス」を利用してHTTP/2のレイヤーでも確認 サーバーがh2を話せないとき、 明示的にエラーを引き起こす文字列 見た目はh1のメッセージ →h1だけのサーバーが受け取ると、エラーを

    返す 61
  62. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 62
  63. 5. パフォーマンス 検証内容 • 複数の画像リクエスト時のパフォーマンス検証 • レイテンシ(通信遅延)も考慮した検証も実施 • HPACKによるヘッダー圧縮率の検証 63

  64. 5. パフォーマンス 複数の画像リクエスト時のパフォーマンス検証 1枚の画像を分割して複数リクエストを送るページを用意 レイテンシはChrome Developer Toolsを利用 64

  65. 5. Chromeにおけるレイテンシ設定方法 1. [Network]タブ→[Online ▼]をクリック 2. [Add…]をクリック 65

  66. 5. Chromeにおけるレイテンシ設定方法 3. [Add custom profile…]をクリック 設定したレイテンシ 10 ms 100

    ms 500 ms 66
  67. 測定方法 • レイテンシを設定し、複数の画像をリクエスト 測定対象 • ページロード時間 5. パフォーマンス - ロード時間測定-

    67
  68. 5. パフォーマンス - ロード時間測定- 68

  69. 5. パフォーマンス - ロード時間測定- 69 遅延&リクエスト数増 (通信回線が不安定) h2のメリットが出る

  70. 5. HPACK検証 70 h2load Nginx H2O Apache h2 hello_world.phpのレスポンスのHEADERSフレームの圧縮率比較 H

    H H Nginx(h1)
  71. 5. パフォーマンス HPACKの圧縮比率 圧縮前ヘッダサイズ (KB) 圧縮後ヘッダサイズ (KB) 圧縮比率 h1 14.84

    14.84 0.00% Nginx h2 11.53 7.33 36.43% H2O h2 11.50 0.57 95.04% Apache2 h2 14.11 0.61 95.67% 71
  72. 5. パフォーマンス nginxの圧縮率が低い理由 • HPACK(RFC7541)の完全なサポートが完了していない Cloudflare社がPatchを公開している。このPatchの適用と ./configure実行時に--with-http_v2_hpack_encオプションを 指定してビルドすることで速くなるとのこと。 • https://github.com/cloudflare/sslconfig/tree/master/patches

    • ※本検証では実施していません 72
  73. 5. パフォーマンス 今回の条件ではApache2が最も圧縮比率が高い • ただし、圧縮前のヘッダサイズが14.11と他より高い • 実質H2Oが一番圧縮率が良いといえる ※Apache2で圧縮前のヘッダサイズが他より高いのかは詳細未確認。 73

  74. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 74
  75. 6. デバッグ • Chrome Developer Tools & Net Internals •

    Nghttp2 tools(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 75
  76. 6. デバッグ • Chrome Developer Tools & Net Internals •

    Nghttp2 tools(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 76
  77. 6. Chrome Developer Tools Chrome Developer Tools Network タブ (右クリックで追加できる)

    77
  78. 6. Chrome Developer Tools Chrome Developer Tools Network タブ 通信プロトコルの確認

    サーバプッシュの利用 78
  79. 6. デバッグ Chromeのアドレスバーに以下を入 力 「chrome://net-internals/#http2」 別タブでh2通信を行うとテーブルが 表示される。 79

  80. 6. デバッグ IDのリンクをクリックする。 80

  81. 6. デバッグ 通信の行をクリック 詳細が右画面に表示 81

  82. 6. デバッグ • Chrome Developer Tools & Net Internals •

    nghttp2 library(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 82
  83. 6. デバッグ nghttp2 HTTP/2とHPACKを実装したライブラリ。 次のツールが同梱されている。 83

  84. 6. デバッグ ツール名 内容 nghttp CLIで動作するクライアントソフト nghttpd サーバ nghttpx プロキシサーバ

    h2load パフォーマンス測定ツール (★今回使用) inflatehd HPACKで圧縮されたヘッダ文字列を json形式で解凍(decompress) deflatehd json形式のヘッダをHPACK形式の文字列に圧縮 84
  85. 6. デバッグ • Chrome Developer Tools & Net Internals •

    Nghttp2 tools(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 85
  86. 6. デバッグ curl CLIコマンドでHTTPリクエストを送る定番ツール。 `--http2`オプションを指定することでh2通信が行える。 86

  87. 6. デバッグ ALPNでh2をネゴシエーション h2を採用 (中略) h2通信を指定 87

  88. 6. デバッグ • Chrome Developer Tools & Net Internals •

    Nghttp2 tools(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 88
  89. 6. デバッグ h2i インタラクティブにh2通信が行えるCLIコマンド go言語で作成されている https://github.com/bradfitz/http2/tree/master/h2i 89

  90. 6. デバッグ インストール方法(golang含む) # apt-get install -y golang-1.10 # ln

    -s /usr/lib/go-1.10/bin/* /usr/bin/ # go get github.com/bradfitz/http2/h2i # ln -s $(go env GOPATH)/bin/h2i /usr/bin/h2i 90
  91. 6. デバッグ pingフレームの実施 リクエストヘッダの作成 レスポンスヘッダ 91

  92. 6. デバッグ • Chrome Developer Tools & Net Internals •

    Nghttp2 tools(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 92
  93. 6. デバッグ Wireshark 定番のキャプチャソフト。 ブラウザとサーバ間のh2通信を復号するには、PreMasterSecretの 設定が必要。 93

  94. 6. デバッグ • Chrome Developer Tools & Net Internals •

    Nghttp2 tools(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 94
  95. 6. デバッグ ローカルプロキシ 脆弱性診断士には必需品なツール • Burp Suite • Fiddler •

    OWASP ZAP etc... 95
  96. 6. デバッグ ローカルプロキシ 脆弱性診断士には必需品なツール • Burp Suite • Fiddler •

    OWASP ZAP etc... HTTP/2 Not Supported  96
  97. 6. デバッグ なんで実装してくれないの? • Webクライアント、サーバともh1,h2両方をサポートしてるから • HTTP/2用のライブラリがそれほど多く公開されてない など、コストに対してメリットが薄いため(と思われる)。 97

  98. 6. デバッグ 98 .Net Core 2.2のpreview版で HTTP/2サポートしてたから そのうちFiddlerも HTTP/2 対応するんじゃない?

    しらんけど 弊社の某Fiddler
  99. 6. デバッグ その他のクライアントやサーバ、プロキシなどの実装状況 https://github.com/http2/http2-spec/wiki/Implementations 99

  100. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 100
  101. おやくそく 悪用はもちろん禁止です。 Webアプリケーション脆弱性診断の観点でお話します。 (※ h2 の実装に不備はないという前提) 101

  102. 7. 擬似HTTPヘッダインジェクション考察  h2から実装された擬似ヘッダ(pseudo header)に対して  インジェクション等の攻撃を行う シナリオ 102

  103. 7. 擬似HTTPヘッダインジェクション考察  h2から実装された擬似ヘッダ(pseudo header)に対して  インジェクション等の攻撃を行う シナリオ  今回の検証範囲では、擬似ヘッダを取得できなかった。  擬似ヘッダは名前の通りHTTPヘッダではない。  Webアプリが擬似ヘッダを利用することはできなそう。 結論

    103
  104. 7. HTTPヘッダインジェクション考察 h2でも改行コードを利用したHTTPヘッダインジェクションができるので はないだろうか? シナリオ 104

  105. 7. HTTPヘッダインジェクション考察 h2でも改行コードを利用したHTTPヘッダインジェクションができるので はないだろうか? シナリオ 今回の検証範囲では確認できなかった。 h1のHTTPヘッダ終端文字はCRLFだったが、h2ではHEADERSフ レームになっており、終端文字CRLFは利用されていないからかも… 結論 105

  106. 7. HTTPヘッダインジェクション考察 HTTP/1.1 /%0d%0aX-bad:badvalue%0d%0afoo.json /foo.json 106

  107. 7. HTTPヘッダインジェクション考察 HTTP/2.0 /%0d%0aX-bad:badvalue%0d%0afoo.json 107

  108. 7. その他  h2であれはTLS利用にあたり制限があるようだ。もう気にしなくてよさ そう? シナリオ 108

  109. 7. その他 • HTTP/2ではTLSの利用にあたり条件がある ◦ TLS1.2以上にする ◦ SNI拡張に対応する ◦ TLSでの圧縮を無効にする

    ◦ HTTP/2通信が始まって以降の再ネゴシエーションを無効にする ◦ HTTP/2仕様中で禁止された暗号スイートの使用しない 109
  110. 7. その他 条件を満たさないときは接続できない “INADEQUATE_TRANSPORT_SECURITY” エラー 110

  111. 7. その他 111

  112. 7. その他 112

  113. 7. その他  h2であれはTLS利用にあたり制限があるようだ。もうアレコレ気にし なくてよさそう? シナリオ  そんなことはなさそう… ・h1とh2両方話すサーバーの場合がほとんどだから従来通り気を配る必要がある 結論 113

  114. 7. その他の従来の攻撃 プロトコルが変わってもh1と互換性があるなら従来の攻撃も通用する のでは? シナリオ 114

  115. 7. その他の従来の攻撃 プロトコルが変わってもh1と互換性があるなら従来の攻撃も通用する のでは? シナリオ 通用する ・クライアントサイドの攻撃 (XSS等) ・セッションに関連する攻撃  等、webアプリ開発で作り出した脆弱性のほとんどがh2でも有効

    結論 115
  116. いまからはここ 1. はじめに・目的 2. HTTP/2が生まれた背景 3. 本セッションの提案 4. HTTP/2 詳細(ことはじめ)

    5. HTTP/2 パフォーマンス考察 6. デバッグ 7. (診断員目線の)HTTP/2 セキュリティ考察 8. まとめ 9. おわりに 116
  117. 8. まとめ 本講演でみなさんと目指すGOAL ☑ HTTP/2のことを知る ☑ HTTP/2の性能を知る ☑ 検証方法の紹介 われわれのGOAL

    ☑ 診断員目線でセキュリティを考察する 117
  118. more detail…? 今日話せなかったこと • Flow Control • Priority • 他のフレーム

    • 他のネゴシエーション etc... 関連知識 • QUIC • TLSv1.3 • websocket over HTTP/2(RFC 8441) etc... 118
  119. 9. おわりに 119 ブログで紹介します 懇親会で意見交換 できたらうれしい…

  120. 9. おわりに -      のこともう少し- Fukuoka Tokyo !! 120

  121. 9. おわりに -      のこともう少し- Fukuoka !! Fukuoka 121

  122. HTTP/2 ことはじめ 2018年9月29日 株式会社セキュアスカイ・テクノロジー 技術開発部 岩間湧 越智郁

  123. 参考・引用資料

  124. 参考・引用資料 • Learning HTTP/2 A Practical Guide for Beginners ◦

    Stephen Ludin, Javier Garza • Real World HTTP -歴史とコードに学ぶインターネットとウェブ技術 ◦ 渋川よしき • ハイパフォーマンスブラウザネットワーキング ◦ Ilya Grigorik ほか • Software Design 2015 11月号 • Nghttp2: HTTP/2 C Library ◦ https://nghttp2.org/ • HTTP/2 wg github ◦ https://http2.github.io/ • H2O ◦ https://h2o.examp1e.net/ 124