Protocol for Web 2018

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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事件

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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/

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Protocol for Web 2018

Protocol for Web 2018

Hiroki Suezawa (@rung)

More Decks by Hiroki Suezawa (@rung)

Other Decks in Technology

Featured

Transcript