HTTP2ことはじめ

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

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

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

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

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

1. はじめに -自己紹介- 岩間湧越智郁・診断員として1月に入社・たまにCTF ・最近アニメ貪ってます
・9月に入ってから　緩やかに体重増加中 ・新卒入社2年目の診断員・北九州高専出身（制情）・9月に入ってから　楽器をはじめたけど　さっそく休会中 6

1. はじめに -　　　　　の紹介- Webセキュリティ専門企業です！防御サービス WAF「Scutum」脆弱性を無害化します教育・支援サービス脆弱性を作らないよう
支援します脆弱性診断サービス脆弱性を見つけます開発・運用の各フェーズに対応 7

カンファレンス聴講 1. はじめに -テーマ選定- 「学習時間」制度「未来研」制度 Tech blog デモベース診断員視点
セキュリティ考察「HTTP/2」に挑戦しよう！ 8

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

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

1. はじめに - 本セッションの目的 - 本講演でみなさんと目指すGOAL • HTTP/2のことを知る • HTTP/2の性能を知る
• 検証方法の紹介わたしたちのGOAL • 診断員目線でセキュリティ面を考察する（私見） 11

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

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

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

3. 本セッションの提案　-再確認- • HTTP/2のことを知る →4章「ことはじめ」 • HTTP/2の性能を知る →5章パフォーマンス • 検証方法の紹介
→随時！（全体構成だけ今から先に） • 診断員目線でセキュリティ面考察 →7章　セッション中に　HTTP/2 を「h2」　HTTP/1.1を「h1」　と呼ぶことがあります 17

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

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 いろいろあるっちゃん

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

4. セマンティクスの維持セマンティクス: その機能に求められる「意図」 Client (Browser) Server 変更なし Web
app h1相当のメッセージ・メソッド・ヘッダ・ボディ・ステータスコード・ボディ h2形式のリクエスト h2形式のレスポンス 22

 DEMO 1  セマンティクスの維持 HTTP/1.1とHTTP/2を見比べてみる 23

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

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

4. バイナリフレーム Client Server HTTP/2 TLS TCP/IP Connection Stream H
H D Server Push HPACK ALPN negotiation Framing (Binary) 28

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

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

4. バイナリフレーム 31

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

4. HPACK HTTP/2 のパフォーマンス改善のコア技術 HTTPヘッダには決まった名前や結果が良く出現 → 外部辞書を用意し参照すれば、ヘッダサイズが減少 34

4. HPACK ２つの辞書 • 静的テーブル • 動的テーブル 35 INDEX 1
・・・ 61 静的テーブル 62 ・・・動的テーブル

4. HPACK 具体的にどんな辞書（テーブル）を利用しているのか 36 フレームヘッダ

4. HPACK 82 1 0 0 0 0 0 1
0 RFC7541 「インデックスヘッダフィールド表現」静的テーブルまたは動的テーブルのエントリを識別インデックス(=2) 37 RFC 7541 付録A

4. Stream Client Server HTTP/2 TLS TCP/IP Connection Stream Server
Push HPACK ALPN negotiation H H D 39

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)

4. Stream HEADERS[5] DATA[1] HEADERS[3] DATA[3] 実体は無いので、同じStream IDを持つ一連のフレームが受信時にグループ化される 41

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

4. Streamが多重化能力のコアとは？ Connection HTTP/1.1の場合 43 … 最大6コネクションまで 1つ目のリクエストが完了しないと後続のリクエストが送れない
(Head of Line Blocking) 待機中…( ˘ω˘ ) 待機中…( ˘ω˘ )

4. Streamが多重化能力のコアとは？ 44 … Stream HTTP/2の場合 1つ目のリクエストが完了していなくても、後続のリクエストを送ることができる。

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

4. HEADERSフレームフラグ Stream ID (クライアントからなので奇数の 13) Header Block Fragment
非圧縮のヘッダーの中身 46

4. DATAフレームフラグ Stream ID (Reponse Body) Data WiresharkによるData解析内容 47

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

4. h1の場合(connection) 49

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

4. h2の場合(stream) 51

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

4. Server Push Client Server HTTP/2 TLS TCP/IP Connection Stream
H H D Server Push HPACK ALPN negotiation 54

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

4. Server Push Promised-Stream-ID プッシュするデータを送信するために予約するストリームサーバからの通信のためIDは偶数の2 Header Block Fragment
予想するHTTPリクエストのヘッダ。サーバはこのリクエストを受け取ったと想定して HTTPレスポンスを返す 56

4. negotiation Client Server HTTP/2 TLS TCP/IP Connection Stream H
H D Server Push HPACK ALPN negotiation 57

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に対応していることが事前にわかっている３つの方法 58

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

4. ALPN (Application Layer Negotiation protocol) Server Hello ALPN 拡張
プロトコル選択 h2! 60

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

5. パフォーマンス検証内容 • 複数の画像リクエスト時のパフォーマンス検証 • レイテンシ(通信遅延)も考慮した検証も実施 • HPACKによるヘッダー圧縮率の検証 63

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

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

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

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

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

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

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

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

5. パフォーマンス nginxの圧縮率が低い理由 • HPACK(RFC7541)の完全なサポートが完了していない Cloudflare社がPatchを公開している。このPatchの適用と ./configure実行時に--with-http_v2_hpack_encオプションを指定してビルドすることで速くなるとのこと。 • https://github.com/cloudflare/sslconfig/tree/master/patches
• ※本検証では実施していません 72

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

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

6. Chrome Developer Tools Chrome Developer Tools Network タブ（右クリックで追加できる）
77

6. Chrome Developer Tools Chrome Developer Tools Network タブ通信プロトコルの確認
サーバプッシュの利用 78

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

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

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

nghttp2 library(nghttp, nghttpx, h2load, inflatehd,deflatehd) • curl • h2i • Wireshark • ローカルプロキシ • その他実装状況 82

6. デバッグ nghttp2 HTTP/2とHPACKを実装したライブラリ。次のツールが同梱されている。 83

6. デバッグツール名内容 nghttp CLIで動作するクライアントソフト nghttpd サーバ nghttpx プロキシサーバ
h2load パフォーマンス測定ツール　（★今回使用） inflatehd HPACKで圧縮されたヘッダ文字列を json形式で解凍(decompress) deflatehd json形式のヘッダをHPACK形式の文字列に圧縮 84

6. デバッグ curl CLIコマンドでHTTPリクエストを送る定番ツール。 `--http2`オプションを指定することでh2通信が行える。 86

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

6. デバッグ h2i インタラクティブにh2通信が行えるCLIコマンド go言語で作成されている https://github.com/bradfitz/http2/tree/master/h2i 89

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

6. デバッグ pingフレームの実施リクエストヘッダの作成レスポンスヘッダ 91

6. デバッグ Wireshark 定番のキャプチャソフト。ブラウザとサーバ間のh2通信を復号するには、PreMasterSecretの設定が必要。 93

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

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

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

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

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

おやくそく悪用はもちろん禁止です。 Webアプリケーション脆弱性診断の観点でお話します。（※ h2 の実装に不備はないという前提） 101

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

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

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

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

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

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

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

7. その他 • HTTP/2ではTLSの利用にあたり条件がある ◦ TLS1.2以上にする ◦ SNI拡張に対応する ◦ TLSでの圧縮を無効にする
◦ HTTP/2通信が始まって以降の再ネゴシエーションを無効にする ◦ HTTP/2仕様中で禁止された暗号スイートの使用しない 109

7. その他条件を満たさないときは接続できない “INADEQUATE_TRANSPORT_SECURITY” エラー 110

7. その他 111

7. その他 112

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

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

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

8. まとめ本講演でみなさんと目指すGOAL ☑ HTTP/2のことを知る ☑ HTTP/2の性能を知る ☑ 検証方法の紹介われわれのGOAL
☑ 診断員目線でセキュリティを考察する 117

more detail…? 今日話せなかったこと • Flow Control • Priority • 他のフレーム
• 他のネゴシエーション etc... 関連知識 • QUIC • TLSv1.3 • websocket over HTTP/2(RFC 8441) etc... 118

9. おわりに 119 ブログで紹介します懇親会で意見交換できたらうれしい…

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

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

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

参考・引用資料

参考・引用資料 • 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

HTTP2ことはじめ

HTTP2ことはじめ

More Decks by Secure Sky Technology

Featured

Transcript