Securityベンダで行った社内勉強会資料 Webに関わるプロトコルの変化を追うことで、現在のWebの状況および、Snowden事件以降のPrivacyの重視などの10年間の変遷を說明した
Protocol for Web 20182018.12Securityベンダ 社内勉強会資料Hiroki Suezawa (@rung)
View Slide
伝えたいこと●Protocol(or標準化)を見ることでWebの流れが分かってくること● 世界観の共有○Webはここ10年で一気に変化が進んでいること○End to End暗号化に対する強い意志○Privacyの要素を頭に入れておくと変化を追いやすいこと
State of the WebReferenceHTTPSの利用は急増
State of the Webbased 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 2020HTTP/2SPDY by GoogleIEの時代ActiveX, FlashGoogleMaps, AjaxChromeリリースHTTP/3TLS1.2TLS1.3WebsocketWebRTCMozzila 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-tokyohttps://developers.google.com/web/fundamentals/performance/critical-rendering-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?)