inductor's blog

nothing but self note :)

Builderscon 2018 Tokyo 次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス by @kazuho

この記事について

Builderscon 2018 Tokyoに参加してきた(記事書いてる時点ではまだしてる)のでそのアウトプットです。

とにかく速度最優先で書いたので間違ってるところがあればご指摘お待ちしております！

資料

↓kazuhoさんのスライド

なお、QUICやHTTP、TLSに関して全くわからないという方は下記スライドをざっくり見てみるといいかもしれません（宣伝）

主な内容

パフォーマンスの話は時間の都合上用意できなかったということで、主にTLS1.3やQUICの仕様の概要や、仕様策定の裏側に関する話だった。

1. 暗号化技術が今なぜ変わろうとしているのか

エドワード・スノーデンが暴露した話を皮切りにして、クライアント(または、ユーザー)とサーバーの間であるネットワーク経路上において、大規模な監視が行われている実態についていろいろな事実、憶測が飛び交うこととなった。

e.g.) そのネットワークは信用できるのか？→監視、パブリックWiFiの普及に伴いセキュリティの需要高

その結果、TLS Everywhereなどといった完全なるネットワークの暗号化を目指した動きが目立つようになった。

そのような中で、現状における暗号化通信で主要なTLSプロトコルには以下のものをはじめとしていくつかの問題が存在している

  • ハンドシェイクによるRTT(Round Trip Time)が長い
  • ハンドシェイクが平文で通信され、証明書の中身が見えてしまう

2. TLS 1.3

TLS1.3の主な概要

  • TLS1.3では0-1 RTTハンドシェイクになった
  • TLS1.3ではAEAD ciphersを使う。
  • handshakeが0-1RTTになった
  • forward securityが要件として入った
  • セッションチケットを使い回さないようになった(セッションチケット切り替わったタイミングとかも読み取られるとまずいので)

0-1 RTTハンドシェイクについて

TLS1.2ではClient Helloを起点にパラメーター交換をはじめ、鍵の交換等を行う。

交換が終わったら公開鍵を使って計算しデータの交換を始める。この方式だと実際の暗号チャンネル確率までに2回の通信が発生する。

これに起因する現状の問題として、どこと通信しているかは暗号化されていないというのがある。例)iOSの通知などはデバイスごとにユニークなナンバーとIPアドレスがバレてしまう。

TLS1.3では最初のClient Helloから公開鍵暗号を使って暗号化されているので、その瞬間から暗号化が始まる。

TLS1.3において発生した過去の問題

Confidentiality Integrity Availability

  • 従来のTLSではConfidentiality Integrityは提供されていたがAvailabilityはTCPが提供している

On-path Attack / Man-on-the-side attack / Off-path attack

  • 現状のTLSではman-on-the-side attackが容易にできてしまう(DTLSちやIPsecなどは耐性がある)

3. QUIC

QUICの大きな特徴

  • TLS1.3を使った暗号化通信
  • 1RTハンドシェイク
  • 複数のストリームを1コネクションにまとめる
    • html/js/cssまとめてとか
  • HTTP2の問題であるパケットの順番が保証されていないと読み込めない配信方式が改善されて高速な通信が見込める
    • パケロスの多い無線通信やモバイルで強い
    • QUICではIPアドレスに依存しないコネクションが確保されるのでモバイル/Wi-Fi等で接続情報が変わっても大丈夫

QUIC開発において発生したTLS 1.3への変更要求

  • TLSとQUICで二重に暗号化されてしまう部分があった
    • TLSのレイヤでやっていたTLSをQUICのパケットに載せ替えた

この変更から、TLSが提供するAPIにも仕様変更を要求

  • TLSは認証と鍵を提供するのみで、実際の暗号化はQUICが行うようになった

その他の暗号化

QUICではパケットの番号も暗号化されている。

パケット番号はそれぞれの送信されるパケットごとにユニークである。そのため、クライアントへのデータをトラックすることができてしまう。

コネクションIDが切り替わった瞬間のパケット番号がわかるとその瞬間がバレてしまう

  • QUICではIPが変わった瞬間にコネクションIDが変わるような仕様になっているため

4. まとめ

  • TLSでハンドシェイク→QUICで実際の暗号化を行う。
  • ほとんどの全てのデータが暗号化される。
  • 明示的に決められた情報だけが平文で通信される。
  • 暗号化は可用性を確保されるためにも使われるし、プロトコルの硬直化を防ぐためにも使われるようになってきた。

5. 自分がした質問

  • QUICの仕様として、今まではG QUICとIETF QUICがあったと思いますが、Googleが自身の開発していたG QUICからIETF QUICへ寄せていく発表をしました。IETF QUICの普及も国内についてもこれから少しずつ進んでいくかと思いますが、Fastlyさんでは実際どのくらい使用されているのか公開できる範囲で教えて欲しいです。

    • 現状FastlyでQUICは使っていない。が、IETFの策定に伴いH2OのQUIC対応を現在必死にやっている。

  • 個人的にH2OがNginxよりも好きなのですが、QUIC自体を基本機能として組み込む予定が近々ありそうなのか知りたいです。

    • 上記の通りだが、もともとは8末までの予定だった。ここ1、2ヶ月で対応できるよう頑張りたい。

  • お話の中でTLS1.3の仕様策定に時間がかかった理由としてNW機器がQUICをブロックしてしまったという話がありましたが、ChromebookとBluecoatの事件の話か、もし他の話であればどの事件だったのか知りたい

    • そのとおり

感想

質問を3つもしてしまってかなり満足しました。 特に、H2OがいつQUICに対応するのかという点については心待ちにしている部分もあるので、可及的速やかにリリースされることを超期待しています（煽りではなく）