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

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

State of the Web Reference HTTPSの利用は急増

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サポート

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

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

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

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

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

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

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

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

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

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

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

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

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

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/

その先 ● 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

[セキュリティベンダとして] 社内セキュリティどうする？ ● 社内からの通信に対する、 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/

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

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