Protocol for Web 2018

Securityベンダで行った社内勉強会資料
Webに関わるプロトコルの変化を追うことで、現在のWebの状況および、Snowden事件以降のPrivacyの重視などの10年間の変遷を說明した

Transcript

1. Protocol for Web 2018 2018.12 Security ベンダ 社内勉強会資料 Hiroki Suezawa (@rung)
2. 伝えたいこと • Protocol(or 標準化 ) を見ることで Web の流れが分かってくること • 世界観の共有 ◦ Web はここ 10 年で一気に変化が進んでいること ◦ End to End 暗号化に対する強い意志 ◦ Privacy の要素を頭に入れておくと変化を追いやすいこと
3. State of the Web Reference HTTPSの利用は急増
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/3 TLS1.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?)