社内勉強会用に作成した資料 HTTP2/TLS1.3などを始めとしたプロトコルの変化および、セキュリティへの影響について

1. Protocol 2018
2018.12
Securityベンダ 社内勉強会資料
Hiroki Suezawa (@rung)

2. 伝えたいこと
● Protocol(or標準化)を見ることでWebの流れが分かってくること
● 世界観の共有
○ Webはここ10年で一気に変化が進んでいること
○ End to End暗号化に対する強い意志
○ Privacyの要素を頭に入れておくと変化を追いやすいこと

3. State of the Web
ReferenceHTTPSの利用は急増

4. State of the Web
based on Alexa’s list of the most popular sites in the world.
https://www.ssllabs.com/ssl-pulse/
TLS1.3の登場 多くのHTTP/2サポート

5. 2000 - 2020
〜2000 2005 2010 2015 2020
HTTP/2
SPDY by Google
IEの時代
ActiveX, Flash
Google
Maps, Ajax
Chrome
リリース
HTTP/3TLS1.2
TLS1.3
Web
socket
WebRTC
Mozzila Suiteの死.
Firefoxリリース
(Java|ECMA)Scriptの時代
Snowden事件

6. Webにおける力関係の変化
● Microsoft IEの時代が2005年に終わり始める
● 2005- (Java|ECMA)Scriptの時代
○ Ajax: Webでリッチなコンテンツを作っていく動き
○ Webにおける標準化の促進
■ WHATWG/W3C/TC39..
● 2008- Chromeの誕生
○ Webを主戦場にする企業による、実験出来るブラウザの誕生
● Web = インターネットに
○ クラウド+CDNがインターネットの基盤になる
■ AWS/Azure/GCP/Akamai/Fastly/Cloudflare
● Protocolを変える土壌が整う
○ クライアントサイドと、サーバサイドの両方に大きなプラットフォーマー
■ クライアント=Chrome/Firefox。
■ サーバサイド=CDN

7. プロトコルを作る目的
● Webを
● 便利にする
● 速くする
● セキュアにする
● セキュア: 攻撃耐性 + Privacy
● 特にSnowden事件以降は、Privacyの要素は最重要視される要素

8. httpbis: IETFのワーキンググループ
● Chairs(2018)
○ Mark Nottingham(Fastly/元Akamai)
○ Patrick McManus(Fastly/元Mozzila)
○ Tommy Pauly(Apple)
■ (Chairsが2人ともFastlyになったことから最近 Chairに追加)
● ブラウザベンダ or CDNベンダがWebを変化させる人たちを雇っている

9. Javascriptの進化に伴うプロトコルの変化
● Javascript経由で利用する機能
● XHR(XML HTTP Request)
● Javascript経由で、クライアントに通信を発生させられる
● 双方向性がない
● Chatの実装: 定期的なポーリングなどが必要
○ Websocket(2011)
■ 双方向性がある
■ バイナリフレーミング
■ Web上で効率的に双方向の通信が可能になる
https://hpbn.co/xmlhttprequest/

10. Javascriptの進化に伴うプロトコルの変化
○ WebRTC(2012)
■ “標準的に”ビデオストリーミングなどで P2P通信を可能にしたい
■ 過去: Skype
● 独自プロトコル。P2Pに失敗し、サーバ経由でやりとりすることも多かった
■ 例: Google Duo
● ビデオ通信などでP2Pを利用する際にWebRTCを利用
● P2P失敗時の通信方式も現在は標準化されている (NAT超え対応など)

11. 通信プロトコルの課題
● 実感に反する問題: 帯域幅(Bandwidth)を増やしてもWebは早くならない
○ プロトコルに問題がある
● レイテンシを速くすると、それだけWebは速くなる
○ CDNにより解決できる
Reference

12. HTTP/1.1
● 問題点
● Head of line blocking
■ 多重化されておらず、次の通信を始めるためには、レスポンスを待つ必要あり
■ ブラウザによる”1ドメイン6TCPセッション制限”を回避するため、ドメインシャーディングの実施
がベストプラクティス
■ 重要な通信と重要でない通信を分けられない
● 画像ファイルはなくても Web描写を開始できる
https://www.slideshare.net/hustwj/http-20-tokyo
https://developers.google.com/web/fundamentals/performance/critical-rend
ering-path/render-tree-construction

13. HTTP/2
● 特徴
○ バイナリフレーム
■ TCP 1コネクション。通信をフレームで区切る
■ Stream(通信単位)/Message(Header全体/Data全体など)/Frame(フレーム単位)
○ ヘッダ圧縮
■ HTTP/1.1ではヘッダは圧縮できない
■ 単純な圧縮ではセキュリティホールを生むので独自圧縮方式 (HPACK)
○ 優先度制御
■ DOM構築に必要な
html/js/cssを優先的に取得
※プロトコルとWebブラウザ描写の問題は密接
に結びついている
https://developers.google.com/web/fundamentals/performance/http2/?hl=ja#_3

14. HTTP/2
● SPDY実験
○ Chromeが2009年ごろからHTTP/2の前身となるSPDYプロトコルを実験
■ その最終的な成果が HTTP/2
● RFC著者
○ M. Belshe(元GoogleでSPDY実施)
○ R. Peon(Google)
○ M. Thomson, Ed.(Mozilla)
○ その他CDN/Microsoft従事者などに謝辞

15. TLS1.2 -> 1.3
● TLS1.3: TLSのシンプル化
○ 2RTT -> 1RTT: 速くする
○ 暗号選択をシンプル +強く
■ AEAD(認証付き暗号) : AES-GCM/ChaCha20-Poly1305
■ CipherSuiteの選択肢がほとんどない (OpenSSLでCipher suitesを気にする必要が減る )
○ PFSの必須化
■ 鍵交換にRSAが使用できない = 通信経路を監視しても復号できないように
○ 不要な機能の削除
■ TLS圧縮/SHA1…
○ ただしSNIは暗号化できない
■ どのドメインに通信
するかは仲介者に見える
https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
TLS1.2 TLS1.3

16. TLS1.3策定時に起きた重要な議論
● DC内復号
○ 仲介者が通信を復号できる仕組みを作ろうという提案
■ TLSを復号できるように、セッションシークレットを公開鍵で暗号化して埋め込む
■ 秘密鍵を持っている人が通信を復号可能にする
■ https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/?include_text=1
○ IETFにて炎上
■ TLSを弱める機能を入れる理由はない
■ Snowden事件の反省が生かされていない
● Snowden事件ではPGP暗号化メールが秘密鍵により復号された
○ ポイント: Privacyは市民にとって最重要視されるべき事項であるという認識が Protocol策定者間では
共通認識になっている。

17. TCP
● 問題点
○ Head of line blocking
■ 先行パケットが落ちると、後ろのパケットが詰まる
● 全体が遅れる
■ TCP slow start
● ウインドウサイズを少しずつ上げていく
● パケットロス時に安全すぎる輻輳回避
https://hpbn.co/building-blocks-of-tcp/

18. HTTP/3 (QUIC)
● 現在策定中
● UDPを使用
○ TCP/UDPに変わるL4プロトコルを作ることは実質不可能
■ UDP上に再送制御などを実装。 UDPより上のレイヤは全て暗号化
■ 制御はユーザランドで全て実装出来るので Kernelに依存しないで済む
● Kernelの更新には時間がかかる
■ 事実上のTCP2
● 通信プロトコル上にTLSレイヤが乗る
● Chromeによる実験
○ gQUICと呼ばれるGoogle専用のQUICプロトコル
○ ブラウザ上でたくさんの実験および概念実証
https://datatracker.ietf.org/meeting/98/materials/slides-98-edu-sessf-quic-tutorial/

19. その先
● End to End暗号化に対する強い意志: Privacy
○ Snowden事件からの変えられない流れ
○ TLS証明書発行も自動化が進んでいる
■ ACMEプロトコル(Let’s encrypt)
● 通信全体を秘匿する流れ
○ DNS/TLS/HTTPどのレイヤにも介入が難しくなっていく
■ DNS Over HTTPS
■ Encrypted SNI
■ QUIC..
https://speakerdeck.com/kazuho/security-privacy-performance-of-next-generation-transport-protocols?slide=4

20. [セキュリティベンダとして] 社内セキュリティどうする？
● 社内からの通信に対する、MITM ProxyによるSSL Inspection
○ 出来なくなる可能性もある (OS側でのルート証明書管理の厳格化 )
● → EDRなどを基本としたProxyでない管理手法が求められる
● マルウェア対策の流れの変化?
○ 旧: 自由な端末(Mac/Windows)
○ 新: セキュアな端末の登場 (iPhone/Android/Chromebook/Windows 10 S)
■ そもそもおかしなコードを実行できない環境への変化
■ アンチウイルスからホワイトリスティングという考え方もある？
● https://www.theregister.co.uk/2016/11/17/google_hacker_pleads_try_whitelists_not_just_
bunk_antivirus_ids/

21. 付録: メール(SMTP)
● 古いプロトコル
○ Webと違い、変えるコストが大きい (MTAサーバが世界中に多数存在している /アップデートが難しい)
● 小さな動き: SMTP-STS
○ SMTP-STS: SMTP over TLSの強制化仕様
○ ただしサーバ間暗号化でしかない
● 現在の大きな問題
○ メールはEnd To Endで認証できない/暗号化できない
○ なりすましが容易
○ E2E認証/暗号化できるだけで、なりすましによるフィッシング攻撃は一気に難しくなるはず・・・
○ 理想のイメージ: 会社間でもLINEでやりとりするような世界

22. 付録: メール(SMTP)
● ただし、”メッセージング”は大きく変化している
● 会社内ではSlack/Teamsが基本に
● 既に個人間通信はEnd to End暗号化されている
■ Signal Protocolを各社採用.Whatsapp/Hangoutなど
■ LINEもLINE sealing機能でE2E暗号化
● プラットフォーマーが会社/サービス間メッセージングの暗号化に本気になるとき
■ どこかのタイミングで E2E暗号化プロトコルが標準化される？ (実質上のSMTP2?)