Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Protocol for Web 2018

Protocol for Web 2018

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

Hiroki Suezawa (@rung)

December 28, 2018
Tweet

More Decks by Hiroki Suezawa (@rung)

Other Decks in Technology

Transcript

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

    View Slide

  2. 伝えたいこと

    Protocol(or
    標準化
    )
    を見ることで
    Web
    の流れが分かってくること
    ● 世界観の共有

    Web
    はここ
    10
    年で一気に変化が進んでいること

    End to End
    暗号化に対する強い意志

    Privacy
    の要素を頭に入れておくと変化を追いやすいこと

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  7. プロトコルを作る目的

    Web

    ● 便利にする
    ● 速くする
    ● セキュアにする
    ● セキュア
    :
    攻撃耐性
    + Privacy
    ● 特に
    Snowden
    事件以降は、
    Privacy
    の要素は最重要視される要素

    View Slide

  8. httpbis: IETFのワーキンググループ

    Chairs(2018)

    Mark Nottingham(Fastly/

    Akamai)

    Patrick McManus(Fastly/

    Mozzila)

    Tommy Pauly(Apple)

    (Chairs

    2
    人とも
    Fastly
    になったことから最近
    Chair
    に追加
    )
    ● ブラウザベンダ
    or CDN
    ベンダが
    Web
    を変化させる人たちを雇っている

    View Slide

  9. Javascriptの進化に伴うプロトコルの変化

    Javascript
    経由で利用する機能

    XHR(XML HTTP Request)

    Javascript
    経由で、クライアントに通信を発生させられる
    ● 双方向性がない

    Chat
    の実装
    :
    定期的なポーリングなどが必要

    Websocket(2011)
    ■ 双方向性がある
    ■ バイナリフレーミング

    Web
    上で効率的に双方向の通信が可能になる
    https://hpbn.co/xmlhttprequest/

    View Slide

  10. Javascriptの進化に伴うプロトコルの変化

    WebRTC(2012)


    標準的に

    ビデオストリーミングなどで
    P2P
    通信を可能にしたい
    ■ 過去
    : Skype
    ● 独自プロトコル。
    P2P
    に失敗し、サーバ経由でやりとりすることも多かった
    ■ 例
    : Google Duo
    ● ビデオ通信などで
    P2P
    を利用する際に
    WebRTC
    を利用

    P2P
    失敗時の通信方式も現在は標準化されている
    (NAT
    超え対応など
    )

    View Slide

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

    CDN
    により解決できる
    Reference

    View Slide

  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

    View Slide

  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

    View Slide

  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
    従事者などに謝辞

    View Slide

  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

    View Slide

  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
    策定者間では
    共通認識になっている。

    View Slide

  17. TCP
    ● 問題点

    Head of line blocking
    ■ 先行パケットが落ちると、後ろのパケットが詰まる
    ● 全体が遅れる

    TCP slow start
    ● ウインドウサイズを少しずつ上げていく
    ● パケットロス時に安全すぎる輻輳回避
    https://hpbn.co/building-blocks-of-tcp/

    View Slide

  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/

    View Slide

  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

    View Slide

  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/

    View Slide

  21. 付録: メール(SMTP)
    ● 古いプロトコル

    Web
    と違い、変えるコストが大きい
    (MTA
    サーバが世界中に多数存在している
    /
    アップデートが難しい
    )
    ● 小さな動き
    : SMTP-STS

    SMTP-STS: SMTP over TLS
    の強制化仕様
    ○ ただしサーバ間暗号化でしかない
    ● 現在の大きな問題
    ○ メールは
    End To End
    で認証できない
    /
    暗号化できない
    ○ なりすましが容易

    E2E
    認証
    /
    暗号化できるだけで、なりすましによるフィッシング攻撃は一気に難しくなるはず・・・
    ○ 理想のイメージ
    :
    会社間でも
    LINE
    でやりとりするような世界

    View Slide

  22. 付録: メール(SMTP)
    ● ただし、

    メッセージング

    は大きく変化している
    ● 会社内では
    Slack/Teams
    が基本に
    ● 既に個人間通信は
    End to End
    暗号化されている

    Signal Protocol
    を各社採用
    .Whatsapp/Hangout
    など

    LINE

    LINE sealing
    機能で
    E2E
    暗号化
    ● プラットフォーマーが会社
    /
    サービス間メッセージングの暗号化に本気になるとき
    ■ どこかのタイミングで
    E2E
    暗号化プロトコルが標準化される?
    (
    実質上の
    SMTP2?)

    View Slide