HTTP/2からQUICへ続く Webプロトコルの進化

Transcription

1 HTTP/2からQUICへ 続 く Webプロトコルの 進 化 大 津 繁 樹 IIJ Technical WEEK 年 11 月 11 日

2 自 己 紹 介 大 津 繁 樹 株 式 会 社 インターネットイニシアティブ プロダクト 本 部 アプリケーション 開 発 部 サービス 開 発 2 課 NodeJS Technical Steering Committee メンバー ( 主 にTLS/CRYPTO/OpenSSLバインディングを 担 当 ) IETF httpbis WG で HTTP/2 相 互 接 続 試 験 等 仕 様 策 定 に 参 画

3 内 容 Webプロトコルの 進 化 とこれからについて 次 のフェーズ 毎 にその 概 要 と 見 通 しを 解 説 します 1. HTTP/1.1 からHTTP/2へ 2. HTTP/2 からQUIC へ 3. QUIC からTLS1.3(*) へ (* 注 意 ) 内 容 は2015 年 11 月 2 日 時 点 での TLS1.3 draft (*1)を 元 にしています 今 後 の 仕 様 策 定 作 業 で 本 プレゼンの 内 容 が 変 更 になる 場 合 がありますのでご 注 意 ください (*1 の master HEAD)

4 0. HTTP/1.1 の 時 代 (1999~) HTTP/1.1 TLS 1.0/1.1/1.2 TCP IP(v4/v6) Ethernet (* TLS ~, TLS ~)

5 1. HTTP/1.1からHTTP/2へ (2009~) HTTP/1.1 Semantics SPDY 2/3/3.1 TLS 1.0/1.1/1.2 TCP (2015~) TLS 1.2 HTTP/1.1 Semantics HTTP/2 TCP IP(v4/v6) IP(v4/v6) Ethernet Ethernet

6 2. HTTP/2からQUICへ (2013~) HTTP/1.1 Semantics HTTP/2 QUIC TLS 1.2 UDP TCP IP(v4/v6) Ethernet (* HTTP/2 2015~ )

7 3. QUICからTLS1.3へ (2016 or 2017?~) HTTP/1.1 Semantics HTTP/3? QUIC TLS1.3 TLS1.3 UDP TCP IP(v4/v6) Ethernet

8 HTTP/1.1からHTTP/2へ

9 HTTPプロトコルの 年 表 Webの 始 まり HTTP/0.9 HTTP/1.0 RFC1945 HTTP/1.1 RFC2068 HTTP/1.1 RFC2616 httpbis WG SPDY/2 HTTP/1.1 RFC HTTP-NG 中 止 暗 黒 の 時 代 SPDY/3 SPDY/3.1 HTTP/2 RFC7540 HPACK RFC7541

10 HTTP/2サポート 状 況 サーバ 側 は nghttp, jetty, h2o, nginx, apache2 等 続 々 登 場 中

11 HTTP 転 送 サイズとリクエスト 数 の 遷 移 (2012/7/1~2015/7/1) 3 年 で 転 送 サイズ: 96% 増 リクエスト 数 :20% 増 ( 単 一 Webサイトの 統 計 平 均 )

12 HTTP 経 由 のダウンロード 時 間 [ms] Make the Web Faster: Google の 試 験 回 線 帯 域 を 増 速 していくと ページの 表 示 時 間 は これ 以 上 短 縮 できない 回 線 帯 域 [MBps] More Bandwidth does nt matter よりデータ 引 用

13 HTTP 経 由 のダウンロード 時 間 [ms] Make the Web Faster: Google の 試 験 RTT(Round Trip Time)を 小 さくしていくと ちゃんと 下 がる RTT[ms] Webページの 表 示 速 度 を 速 くするには 回 線 速 度 増 強 よりRTT(の 影 響 )を 小 さくするかが 重 要 でも 物 理 的 な 制 限 で 難 しい More Bandwidth does nt matter よりデータ 引 用

14 SPDY(スピーディ)の 登 場 (2009 年 ) RTTの 影 響 をできるだけ 避 けるべくGoogleはSPDYを 開 発 した SPDYは Webページの 表 示 速 度 を 速 くするためのプロトコル として 当 初 社 内 プロジェクトから 生 まれた 既 に3 年 以 上 に 渡 りGoogleの 全 サービスで 利 用 され Twitterや Facebook LINEなど 大 規 模 なシステムに 導 入 されている Googleは2016 年 初 めにSPDYを 廃 止 する 予 定 ブラウザの 拡 張 プラグイ ン(SPDY Indicator)を 使 う とSPDYを 使 っているサ イトがわかる

15 HTTP/1.1の 問 題 点 のおさらい 1. HTTP Head of Line Blocking 2. ネットワーク 通 信 の 利 用 が 非 効 率 3. 曖 昧 でテキスト 処 理 が 煩 雑

16 1. HTTP Head of Line Blocking HTTP/1.1 1 本 のTCP 接 続 クライアント HTTP リクエスト サーバ 待 ち 時 間 HTTPレスポンス HTTP リクエスト

17 HTTP/1.1 ブラウザは 最 大 同 時 4~6TCP 接 続 に 制 限 最 大 同 時 並 列 6

18 HTTP/2 100 以 上 の 同 時 リクエストが 可 能 全 部 同 時

19 2. HTTP/1.1はネットワーク 通 信 の 利 用 が 非 効 率 TCP 接 続 TCP 接 続 TCP 接 続 TCP 接 続 クライアント TCP 接 続 サーバ TCP 接 続 それぞれのTCP 接 続 が 独 立 して 輻 輳 制 御 を 行 う

20 輻 輳 ウィンドウサイズ(mss) HTTP/1.1は 非 効 率 なプロトコル HTTP/1.1+SSLの 輻 輳 ウィンドウサイズの 変 遷 6 本 のTCPがバラバラに 輻 輳 制 御 帯 域 を 有 効 に 使 いきれてない SSL SSL2 SSL3 SSL4 SSL5 SSL 時 間 (sec)

21 輻 輳 ウィンドウサイズ(mss) HTTP/2(SPDY)は 効 率 的 なプロトコル 60 SPDY 利 用 時 の 輻 輳 ウィンドウサイズの 変 遷 本 のTCPで 最 高 速 まで 利 用 帯 域 を 最 大 限 に 効 率 的 に 使 っている SPDY 時 間 (sec)

22 3. HTTP/1.1は 処 理 が 煩 雑 なテキストプロトコル :の 後 に 空 白 を 許 可 Status-Lineは 一 行 目 ヘッダ 名 は 大 文 字 小 文 字 区 別 せず ヘッダ 領 域 の 区 切 り はCRLF 一 つ 続 くデータが123バイト であることを 宣 言 Trailヘッダ 空 白 は1つ HTTP/ OK Content-Type: image/jpeg Transfer-Encoding: chunked Trailer: Foo 123 {binary data} 0 Foo: bar chunk 終 了 合 図 のCRLF CRLFで 改 行 複 数 行 対 応 は 廃 止 一 番 最 後 にFooヘッダが 付 与 されることを 宣 言 データ 終 了 の 合 図 レスポンスデータがchunkedであ り サイズはまだ 不 定

23 HTTP/2はきっちりしたバイナリープロトコル データの 位 置 サイズ 型 が 明 確 HEADERS a c ff フレーム 長 :28バイト フレームタイプ:HEADERS, END_HEADERSフラグ ストリームID: 1 :status = 200 content-length = 123 content-type = image/jpeg trailer = Foo DATA b {binary data} フレーム 長 :123バイト フレームタイプ:DATA, フラグなし ストリームID: 1 (* 記 載 スペースの 都 合 上 Trailer HEADERSは 省 いています)

24 HTTP/2の 仕 組 み 概 要

25 HTTP/2の 技 術 的 な 特 徴 HTTP/1.1のセマンティックスを 変 えない サーバへのTCP 接 続 数 を1つに 限 定 TLSと 連 携 してプロトコルを 自 動 選 択 バイナリープロトコル(テキストデータの 曖 昧 さを 排 除 ) 全 2 重 多 重 化 通 信 フロー 制 御 優 先 度 指 定 サーバプッシュ 機 能

26 HTTP/2の 技 術 的 な 特 徴 SPDYのプロトコルアーキテクチャはそのまま 利 用 SPDYの 無 駄 なヘッダフィールドやフレームタイプを 統 廃 合 し 簡 略 化 SPDYの 実 運 用 で 明 らかとなったフロー 制 御 優 先 度 制 御 と いった 課 題 へ 対 応 する TLS 利 用 を 前 提 とするSPDYに 対 し 平 文 接 続 も 利 用 可 能 に する (ただしほとんどのブラウザーは 平 文 接 続 をサポートせず) ヘッダ 圧 縮 脆 弱 性 (CRIME) 対 策 として 新 しくHTTPに 特 化 し たヘッダ 送 受 信 仕 様 (HPACK)を 策 定 する

27 HTTP/2 初 期 ニゴシエーション 暗 号 化 通 信 現 状 のブラウザーは TLS 接 続 のみサポート (1) TLS + ALPN TLS 接 続 時 にALPN 拡 張 フィールドを 利 用 してHTTP/2に 接 続 を 行 う (2) HTTP Upgrade 平 文 通 信 HTTP/1.1の 接 続 後 Upgradeヘッダを 使 っ て HTTP/2 に 接 続 をアップグレードす る WebSocket と 一 緒 (3) 事 前 知 識 に よるDirect 接 続 あらかじめサーバがHTTP/2 対 応 とわかって いる 場 合 直 接 第 2 段 階 の 接 続 方 法 を 行 う (DNSレコードや HTTPヘッダによるリダイレ クト) 詳 細 仕 様 検 討 中 ALT-SVC

28 HTTP/2の 全 二 重 多 重 化 通 信 フレーム HTTP リクエスト フレーム レスポンス ストリーム(id:1) クライアント フレーム フレーム ストリーム(id:3) HTTP リクエスト レスポンス 1つの TCP 接 続 サーバ フレーム HTTP リクエスト フレーム レスポンス ストリーム(id:5) 仮 想 的 なストリームチャンネルを 生 成 して 多 重 化 を 実 現

29 HTTP/2のデータフレーム(binary) デフォルトは14bit(16K), 24bit(16M)まで 拡 張 可 フレームヘッダ 9バイト ペイロード 長 (24bit) タイプ(8bit) フラグ(8bit) X ストリームID(31bit) ペイロードデータ(ペイロード 長 bit) タイプ フレーム 種 類 タイプ フレーム 種 類 0x00 DATA 0x05 PUSH_PROMISE 0x01 HEADERS 0x06 PING 0x02 PRIORITY 0x07 GOAWAY 0x03 RST_STREAM 0x08 WINDOW_UPDATE 0x04 SETTINGS 0x09 CONTINUATION

30 HPACK HTTP/2で 用 いられるヘッダ 圧 縮 技 術 もともとSPDYでは gzipを 使 ったヘッダ 圧 縮 を 行 っていたが 暗 号 化 通 信 下 でも 情 報 が 漏 えい 可 能 となるCRIME 攻 撃 手 法 が 公 開 され クライアントからサーバへのヘッダ 圧 縮 が 無 効 になって いた そこでHTTP/2 専 用 でHTTPヘッダに 特 化 した 圧 縮 技 術 仕 様 HPACKの 開 発 を 行 った GET / HTTP/1.1 Host: User-Agent: Mozilla/5.0 XXXXX Accept: text/html,application/xhtml+xml,xxx Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive

31 HPACK 概 要 X 番 のエントリー(nameX, valuex) 送 信 します ヘッダテーブル 1. name1, value1 2. name2, value2 3. name3., value3 X 番 のエントリーのnameXを 使 うけど 値 は 別 の valuex'のヘッダを 送 信 します 後 で 使 うからテー ブルに 追 加 しておいて ヘッダテーブル 1. name1, value1 2. name2, value2 3. name3., value3 クライアント サーバ 両 者 でインデックス 番 号 が 付 いたヘッダ テーブルを 保 持 両 者 でヘッダテーブルのインデックスを 参 照 する 情 報 を 送 信 最 も 圧 縮 ができる 時 は 番 号 を 通 知 するだけでよい

32 フロー 制 御 Window Size を 増 加 させる クライアント AとBからのデータを バランスよく 返 す サーバA,B への ウィンドウサイ ズ 更 新 を 調 整 Reverse Proxy WINDOW_UPDATE 低 速 高 速 WINDOW_UPDATE サーバA サーバは Window Size が 0になったらデータ 送 信 を 停 止 サーバB TCPコネクション ストリーム 毎 にフロー 制 御 が 可 能

33 HTML プライオリティ weight:16 weight:16 コンテンツ HTML CSS JS 画 像 1 画 像 2 画 像 3 画 像 4 依 存 性 と 重 みを 指 定 クライアント Reverse Proxy CSS, js プライオリティのユースケース 画 像 ファイルタイプ(HTML/CSS/JS/ 画 像 )に 応 じた 返 答 順 序 の 指 定 タブ 切 り 替 えによる 重 みの 上 げ 下 げ 分 割 されたビデオデータなど 順 番 が 明 示 的 に 決 められている 場 合

34 サーバプッシュ 機 能 予 約 された 画 像 リクエスト はクライアントからサーバ に 送 らずに,クライアント はサーバ 側 からの 画 像 デー タの 送 付 を 待 つ コンテンツリクエスト 画 像 のHTTPリクエストを 予 約 サーバはコンテンツ の 中 身 を 判 断 し,あ らかじめコンテンツ に 含 まれている 画 像 のリクエストを 予 約 する. サーバから 送 信 され た 画 像 データは,ク ライアントのキャッ シュに 保 存 クライアント コンテンツのレスポンス サーバ キャッシュ 画 像 データ

35 デモ HTTP HoLの 有 無 によるHTTP/1.1(SSL)とHTTP/2の 見 え 方 の 違 い をデモします 少 数 の 画 像 vs 多 数 の 画 像 表 示 に 遅 延 あり vs 遅 延 なし 即 表 示 遅 延 ありの 場 合 リクエストの3 秒 後 に 表 示 されます

36 HTTP/2からQUICへ

37 TCPの 問 題 点 TCP Head of Line Blocking. 3 方 向 ハンドシェイクのコスト. initcwnd( 初 期 輻 輳 ウィンドウ)が 小 さくスロースタート パケットロスによる 大 きなバックオフ( 待 ち 時 間 ) カーネルのソケットバッファの 増 大 NATのタイムアウトとIPのローミング 経 路 途 中 のTCP Buffer Bloat TCP Fast Open TCP_NOT_SENT_LOWAT Random packet drop in router initcwnd10 TCP cubic 解 決 策 は 提 示 されているが OSや 中 継 機 の 機 能 追 加 が 必 要 これは 非 常 に 時 間 がかかる

38 TLSの 問 題 点 TLSのハンドシェイクネゴシエーションのコスト ChangeCipherSpecが 来 るまで 待 たないといけない 負 荷 分 散 のバグによるClientHelloのサイズ 制 限 Ballooning Extension サーバから 送 信 する 証 明 書 チェーンの 肥 大 再 接 続 や 再 ネゴシエーションはコストがかかり 最 適 化 できてな い TLS Ticket, Channel ID TLSのライブラリや 中 継 機 のバージョンアップが 必 要 TLS False Start

39 TCP HoLブロックとTCP+TLSハンドシェイク syn TCP SPDY SPDY SPDY SPDY syn+ack ack TCP ハンドシェイク SPDY ClientHello SPDY 7 SPDY 6 ロス! ServerHello Certificate ブロック! Server Key Exchange TLS ハンドシェイク Client Key Exchange Change Cipher Spec FInished Change Cipher Spec Finished Application Data

40 QUIC(Quic UDP Internet Connections) Googleが 独 自 に 開 発 しているプロト コル UDP 上 でTCP+TLS 相 当 +αの 機 能 を 実 装 最 短 0-RTTで 再 接 続 暗 号 通 信 を 必 須 化 TCPと 同 様 の 輻 輳 制 御 で 帯 域 の 公 平 化 独 自 の 誤 り 訂 正 と 再 送 機 能 でパケット ロスによるTCPのHead of Line Blocking を 回 避 HTTP/2のフレーム 制 御 機 能 を 取 り 込 み Googleの 全 サービスで 運 用 中 TCP TLS HTTP HTTP/2 暗 号 化 認 証 QUIC セッション 確 立 フロー 制 御 エラー 補 正, 輻 輳 制 御 UDP IP(IPv4/IPv6)

41 QUICによる 性 能 向 上 結 果 (Google 発 表 分 ) 92%でQUICが 利 用 できている(デスクトップ+モバイル 環 境 ) 平 均 5%のページ 読 み 込 み 時 間 の 短 縮 速 度 下 位 1%の 接 続 で1 秒 の 短 縮 ( 接 続 環 境 が 悪 い 程 効 果 が 高 い) 最 適 化 しているGoogle 検 索 ページでも 平 均 3%の 読 み 込 み 時 間 の 短 縮 Youtubeで rebuffer を30% 短 縮 (ビデオ 停 止 時 間 が 短 い) 75%が 0-RTTの 恩 恵 を 受 けている(QUICによる 性 能 向 上 効 果 の 半 分 が0-RTT) データ 参 照 先

42 ChromeでQUICを 確 認

43 QUICの 実 装 Chrome/GFE テスト 用 のサーバ クライアントが 付 随 最 近 急 速 にバージョンアップを 繰 り 返 し 現 在 QUIC_VERSION_30 Microsoftのプロトタイプ(*1) C++で3000 行 程 度 非 公 開 libquic, goquic goquic libquic:chromeの net/quic 以 下 を 外 部 依 存 を 覗 いてまとめたもの goquic: libquicとwrapper クラスを cgo でバインディングしたもの QUIC_VERSION_24までしか 対 応 してない forkして QUIC_VERSION_30まで 対 応 しました (*1 )

44 QUIC Wireフレーム 書 式 (Public Header) public flag (1) sequence num(1,4,6,8) connection id (0,1,4,8) version(0,1) Encrypted Payload by AEAD (Chcha20+Poly1395 or AES128+GCM12) public header は AEADで 保 護 クライアント 固 有 のConnectionIDベースでセッション 管 理 src ip/port が 変 更 されてもセッションが 継 続 できる

45 欠 損 フレームを 新 しいストリームで 再 送 STREAM_FRAME Lost id=9 id=10 id=11 ACK(largest_observed: 11, missing: [10]) ブロックしない id=12 id=13 をid=10として 再 送 id=10 がロストした ので 新 ストリームで 再 送 (id=13) 新 しいストリームとして 再 送

46 QuicストリームとHTTP/2バインディング QUIC Priority(64bit) 高 中 QUIC Priority(64bit) 低 CryptoStream stream_id = 1 HeadersStream stream_id = 3 HTTP/2 HEADERS DataStream stream_id = spdy s stream_id HTTP/2 DATA フロー 制 御 Stream 1 は 暗 号 化 ハンドシェイク 専 用 ストリーム Stream 3 は ヘッダ 情 報 のやりとり 専 用 ストリーム

47 QUICの 問 題 点 : HPACKによるQUICのHoLブロック 1~5までテー ブル 更 新 済 み QUIC Stream (id=3) HEADERS HEADERS HEADERS HEADERS ,3~5でテーブル 更 新 するとインデック スがずれちゃう ヘッダテーブル 1. name1, value1 2. name2, value2 3. name3., value を 再 送 ヘッダテーブル 1. name1, value1 2. name2, value2 3. name3., value3 HEADERフレームの 欠 損 によるヘッダテーブルの 不 一 致 を 防 ぐには 欠 損 した フレーム(6)が 届 くまでヘッダテーブルの 更 新 をブロックするしかない

48 QUICの 問 題 点 : HPACKによるQUICのHoLブロック 最 近 の Canary では chrome://histograms からHPACK HoLの 状 況 を 確 認 できます QUICのせいでWebの 閲 覧 速 度 が 遅 いという 感 じがするなら 一 度 この 値 を 確 認 してください

49 デモ TCP HoL 耐 性 デモ packet ロストで HTTP/2 vs QUIC の 通 信 がどう 変 わるかデモし ます HTTP/2の 方 は TCP HoLで 通 信 が 途 絶 えますが QUICは 独 自 再 送 機 能 で 通 信 は 継 続 されます 0-RTT 実 演 デモ ( 時 間 があれば) HTTP/2 over TLS, QUIC (0-RTTを disabled), QUIC(0-RTT)で 初 期 接 続 時 間 の 比 較 を 行 います

50 QUICからTLS1.3へ 注 意 : 内 容 は2015 年 11 月 2 日 時 点 での TLS1.3 draft (*)を 元 にしています 今 後 の 仕 様 策 定 作 業 で 本 プレゼンの 内 容 が 変 更 になる 場 合 がありますのでご 注 意 ください (* の master HEAD)

51 TLS1.3の 目 的 1. ハンドシェイクデータをできるだけ 暗 号 化 して 隠 匿 する 2. ハンドシェイクレイテンシーの 削 減 再 接 続 の 場 合 は 0-RTT フルハンドシェイクは 1-RTT 3. ハンドシェイクで 交 換 する 項 目 の 見 直 し 簡 素 化 4. レコード 層 暗 号 化 の 見 直 し(RC4 廃 止 CBC 不 採 用 等 )

52 TLS1.3の 特 徴 様 々な 機 能 項 目 を 見 直 し 廃 止 時 代 に 合 わなくなったもの より 効 率 的 な 仕 組 みに 変 更 修 正 されたも のなど TLS1.2の 機 能 項 目 を 数 多 く 廃 止 ( 後 述 ) よりセキュアに 平 文 通 信 が 必 要 な 部 分 を 極 力 少 なくして 情 報 を 隠 匿 AEAD 必 須 やパディング 等 将 来 的 な 攻 撃 に 備 える 性 能 向 上 QUICで 使 われているような 0-RTTの 接 続 をサポートし 接 続 レイテン シーを 下 げられるようにしている 将 来 的 にQUICはTLS1.3をサポート (*)する 方 向 (* QUICとTLSでフレームフォーマットが 異 なるので 全 く 同 一 にならない 可 能 性 があります )

53 TLS1.3の 廃 止 項 目 一 覧 とその 理 由 これまでの 機 能 の 必 要 性 を 全 面 的 に 見 直 し 機 能 Compression CRIME/TIME 等 の 圧 縮 タイミング 攻 撃 対 策 暗 号 署 名 方 式 Renegotiation SessionID resumption MD5, SHA-1, SHA-224 DSA non-aead(cbc, RC4) IVフィールド AEADのadditional data custom DHE ECDHE compress format anonymous DH Triple Handshake 等 Renegotiation 前 後 の 状 態 引 継 ぎの 不 備 を 対 策 廃 止 に 伴 いクライアント 認 証 とRekeyを 行 う 方 式 を 変 更 PSKと 同 一 方 法 で resumptionが 可 能 になったため 危 殆 化 低 強 度 対 策 利 用 用 途 の 減 少 RC4 危 殆 化 MtEを 狙 ったパディングオラクル 攻 撃 の 対 策 AEADのみになっため nonce は seq no から 生 成 要 検 証 なレコードヘッダ 部 はnonce/ 暗 号 データ 内 で 改 ざん 検 知 可 能 Cross-Protocol 対 策 で named groupに 統 一 uncompress 書 式 だけで 利 用 用 途 が 十 分 raw public key (RFC7250)を 使 うか 証 明 書 の 検 証 をしない

54 TLS1.3での 廃 止 項 目 一 覧 とその 理 由 cont'd ハンド シェイ ク 書 式 record layerのバージョン random 中 のgmt unix time PFS/PSK 以 外 の 鍵 交 換 SSL2.0/3.0のサポート 実 質 的 に 利 用 用 途 がないため 後 方 互 換 だけのために 残 されている 乱 数 生 成 が 高 度 化 され 利 用 用 途 がなくなったため 秘 密 鍵 の 危 殆 化 対 策 危 殆 化 プロトコルのサポート 廃 止 不 要 タイプの 削 除 ChangeCipherSpec,HelloRequest,Sever/ClientKeyExchange 等 ( 後 述 ) 拡 張 max_fragment_length 最 大 値 は2^14 に 固 定 truncated_hmac srp PSKに 置 き 換 え? encrypt_then_mac extended_master_secret SessionTicket renegotiation_info AEADに 利 用 できないし 安 全 でないため AEAD 利 用 のため TLS1.3 仕 様 に 取 り 込 み Resumption/PSKで 利 用 するTicketに 置 き 換 えるため Renegotiationを 禁 止

55 TLS1.3 ハンドシェイク (full handshake) ClientHello + KeyShare Finished Application Data Application Data ここで 即 暗 号 化 ServerHello + KeyShare EncryptedExtensions ServerConfigration Certificate CertificateVerify Finished 0-RTT 再 接 続 用 のsemistatic DH keyを 通 知 Application Data 注 意 : 内 容 は2015 年 11 月 2 日 時 点 での TLS1.3 draftを 元 にしています 1-RTT ( 赤 文 字 は 暗 号 化 されているデータ)

56 TLS1.3 ハンドシェイク (0-RTT 再 接 続 ) フライイングで アプリデータ 暗 号 化 して 送 る semi-static server DH key 以 前 の 接 続 で 保 持 ClientHello + KeyShare + EarlyDataIndication EncryptedExtensions ApplicationData Finished Application Data ServerHello + KeyShare + EarlyDataIndication EncryptedExtensions ServerConfigration Certificate CertificateVerify Finished 本 来 必 要 ないがロジック の 簡 略 化 のため 常 時 署 名 Application Data 注 意 : 内 容 は2015 年 11 月 2 日 時 点 での TLS1.3 draftを 元 にしています 0-RTT ( 赤 文 字 は 暗 号 化 されているデータ)

57 TLS1.3の 新 たな 鍵 交 換 方 式 と 鍵 スケジュール (OPTLSの 採 用 ) signature based handshake DH based handshake にする 提 案 当 初 DH 証 明 書 と 公 開 鍵 の offline signature( 後 述 )の 利 用 を 想 定 していたため 反 対 意 見 が 多 かった プロトコルロジックや 鍵 生 成 が 簡 略 化 され PSKの 導 入 もしや すくなるのでTLS1.3に 採 用 する 方 針 となった しかし offline signature 機 能 を 外 し online 署 名 された semistatic DH 鍵 を 利 用 することにした (offline 署 名 については 後 述 )

58 TLS1.3の 鍵 交 換 (0-RTT) g xs で 暗 号 化 g s を 保 持 以 前 の 接 続 で 保 持 ClientHello + KeyShare g x + EarlyDataIndication EncryptedExtensions ApplicationData Finished Application Data ServerHello + KeyShare g y + EarlyDataIndication EncryptedExtensions ServerConfigration Certificate CertificateVerify Finished Application Data g xy で 暗 号 化 g x : クライアント 一 時 鍵 g y : サーバ 一 時 鍵 g s : サーバ semi-static 鍵 ( 赤 文 字 は 暗 号 化 されているデータ) 注 意 : 内 容 は2015 年 11 月 2 日 時 点 での TLS1.3 draftを 元 にしています

59 TLS1.3 鍵 スケジュール(0-RTT) クライアント 一 時 鍵 x サーバ 一 時 鍵 g xy 0 クライアント 一 時 鍵 0 x サーバsemi-static 鍵 HKDF-Extract g xs HKDF-Extract xes xss セッション ハッシュ HKDF-Expand セッション ハッシュ HKDF-Expand ハンドシェ イク 用 鍵 mes mss HKDF-Extract early data 用 鍵 Finished 用 鍵 セッション ハッシュ master secret HKDF-Expand 0-RTTで 送 るア プリデータは この 鍵 を 使 う resumption 用 鍵 アプリデータ 用 鍵 exporter 用 鍵 参 考 The OPTLS Protocol and TLS 1.3 Hugo Krawczyk, Hoeteck Wee 2015

60 0-RTTでは4 種 類 の 鍵 を 利 用 early data 用 鍵 で 暗 号 化 g s を 保 持 以 前 の 接 続 で 保 持 ClientHello + KeyShare + EarlyDataIndication EncryptedExtensions ApplicationData Finished Application Data g x ServerHello ハンドシェイク 用 + KeyShare g y 鍵 で 暗 号 化 + EarlyDataIndication EncryptedExtensions ServerConfigration Certificate CertificateVerify Finished Application Data Finished 用 鍵 でセッショ ンハッシュのMACを 計 算 g x : クライアント 一 時 鍵 g y : サーバ 一 時 鍵 g s : サーバ semi-static 鍵 アプリデータ 用 鍵 で 暗 号 化

61 TLS1.3 0-RTTの 問 題 点 0-RTT ApplicationData POST / HTTP/1.1 xxxx Reply 攻 撃 更 新 クラスタリング 厳 密 な 同 期 は 不 可 能 0-RTT ApplicationData POST / HTTP/1.1 xxxx 更 新 Reply 攻 撃 に 弱 いため 最 初 のデータは 冪 等 性 のあるリク エストのみに 制 限 しなければならない

62 TLS1.3のその 先 (offline signature) ClientHello + KeyShare Finished Application Data Application Data g x 0-RTT 用 g s を 保 存 再 接 続 セッションに 関 わらず 利 用 可 能 定 期 的 に 更 新 するだけ ServerHello + KeyShare g y EncryptedExtensions ServerConfigration Certificate CertificateVerify Finished Application Data g s g s はあらかじめ 有 効 期 限 と 共 にサーバ 証 明 書 で 署 名 TLS1.3の 採 用 は 見 送 られたが 並 行 して 拡 張 仕 様 として 検 討 を 進 める 方 向 に

63 まとめ HTTP/2, QUIC は Web 閲 覧 の 高 速 化 を 図 る 新 しいプロトコルです HTTP/2は HTTP/1.1の HoLブロックの 解 消 を 実 現 しました QUICは TCPの HoLブロックの 解 消 し 暗 号 化 ハンドシェイクの 0-RTTを 実 現 しました TLS1.3は 古 くて 無 駄 な 項 目 を 数 多 く 廃 止 し よりセキュアな 暗 号 通 信 を 実 現 します また0-RTTで 接 続 レイテンシーの 向 上 を 目 指 します 常 時 TLS 接 続 の 世 界 が 予 想 される 中 将 来 的 にTLS1.3の 元 で HTTP/2や 次 のバージョン QUIC 等 のWebプロトコルが 実 現 され るでしょう