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 full-size slide

  2. 伝えたいこと

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

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

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

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    Web

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

    View full-size 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 full-size slide

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

    Javascript
    経由で利用する機能

    XHR(XML HTTP Request)

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

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

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

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

    View full-size slide

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

    WebRTC(2012)


    標準的に

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

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

    View full-size slide

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

    CDN
    により解決できる
    Reference

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  17. TCP
    ● 問題点

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

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

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

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

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

    View full-size slide

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

    メッセージング

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

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

    LINE

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

    View full-size slide