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

Web over HTTPS

Jxck
October 09, 2016

Web over HTTPS

Web over HTTPS
DevFest Tokyo 2016
#devfest16 2016/10/0

Jxck

October 09, 2016
Tweet

More Decks by Jxck

Other Decks in Programming

Transcript

  1. 3

  2. 5 何からどう安全か? • 安全ってどういうこと? • そもそも危険なの? • 悪いのはだれなの? • その手段が

    HTTPS でいいの? • HTTPS にしないと悪者扱いなの? • このサイト、パスワードもカードも使わないんだけど? • なんで Google に Insecure とか言われないといけないの? • え、検索ランク下がるの? • なんで Service Worker 使えないの? • 急に言われたって無理だよ。。
  3. 7

  4. 秘情報 13 • パスワード • cookie • クレジットカード番号 • 住所、電話番号

    • メールアドレス • DM • 個人的な写真 漏れたら一大事
  5. 15 MITM Client Server Middle Box 中間にあるネットワーク 機器なら簡単に覗ける (*犯罪です、だめ絶対 )

    見るだけじゃなく 書き換えたり、なりすましたりも (MITM 前提の攻撃もよくある )
  6. 17 大事なところだけ HTTPS ? redirect login index list cart check

    redirect 秘情報が無ければ 平文でいい?
  7. http でもいい? • ドキュメントとかはいいよね • ニュースとかはいいよね • 漫画だしいいよね • 秘情報ないからいいよね

    • 見られたとしても別にね • メリットが無いしね • めんどく(ry 18 何が知られたくない かなんて人によって 違う
  8. もしも平文だったら • 検索エンジン • 書籍の検索 • 新聞やニュース系サイト • 画像・動画サイト 19

    つぶさに盗聴すると 主義/思想、趣味/趣向なども 浮かび上がるかも
  9. 前提の変化 28 • Web はもっと殺伐としていた ◦ 通信は見られている ◦ 秘情報かは関係無い ◦

    もう何も信じられない • 暗号化という対抗手段 ◦ 秘情報を隠すため ◦ 攻撃されてないため ◦ 監視されてないため ◦ 片手間な設定じゃだめ Web ユーザ の自由を守 るため
  10. 30

  11. 正しく HTTPS • TLS ◦ RSA key size ? ◦

    Ciphersuites ? ◦ TLS version ? ◦ TLS curve ? ◦ perfect foward security ? ◦ session resumpsion ? ◦ ocsp stapling ? • https://wiki.mozilla.org/Security/Server_Side_TLS • https://www.ssllabs.com/ 32 正しい理解と 適切な設定を わからなければ mozilla の推奨設定 sslabs でチェック
  12. PFS • Perfect Forward Secrecy • TLS セッションごとに鍵を変える • 秘密鍵が漏洩しても過去に遡って解読できない

    • Ephemeral の付く鍵交換を利用 (ECDHE) 33 ごっそり記録されても 秘密鍵を要求されても だいじょーぶ
  13. HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 35
  14. HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 36
  15. EV 証明書 • EV 証明書 ◦ まともにビジネスをやるなら EV を買うべき ◦

    一番簡単に見える、信頼できる組織の証 ◦ URL バーに堂々と組織名を 38 お金で買える信用ほど 安いものはない
  16. Let’s Encrypt • 無料の DV 証明書 ◦ 基本は非営利や個人サイト向け ◦ EveryWhere

    のうちビジネス用途以外を担うイメージ ◦ wildcard の無い EV の補完 (ex microservices) • ACME プロトコル ◦ 証明書管理自動化プロトコル ◦ certbot (client) + boulder (server) ◦ 自社 DC や開発用 CA としても応用可能 ◦ 他の CA サービスにも広まることを期待 39
  17. HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 40
  18. URL 変更 • http:// の URL が広まっている ◦ http:// はすべて残したまま

    ◦ http:// をすべて https:// にリダイレクト • HSTS ◦ 毎回リダイレクトだと遅い ◦ 最初のリダイレクトでブラウザに覚えてもらう ◦ http:// へのリクエストが https:// に読み替えられる ◦ ブラウザに preload することで最初から HSTS に ◦ Full HTTPS 化の 1 つの指標 41
  19. HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 42
  20. Mixed Contents • HTTPS ページに HTTP のサブリソース ◦ 警告になるものと読み込まれないものがある ◦

    広告が表示されない問題 ◦ iframe 許す CGM での問題 43 https://labs.jxck.io/mixed/
  21. Mixed Contents 対策 • Upgrade Insecure Request ◦ 埋め込まれた http://

    のリクエストを https:// にする ◦ 読み込む先が https 対応している必要 • CSP report ◦ mixed contents の情報を集める ◦ 地道に潰す ◦ 可視化することで対応を加速 • HSTS Priming (draft) ◦ mixed contents が HSTS だったら upgrade 44
  22. HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 45
  23. HTTPS でしかできないこと • HTTP2 • Service Worker • WebRTC(gUM) •

    Geolocation • Add to Home Screen • Credential Management • etc 49 MITM 成立時の影響が大 きいという理由も。 逆に今後出る低レベル API もHTTPS前提となっ ていく。
  24. その他、よく聞く問題 • ノウハウがない。。 • 遅くなっちゃった。。 • CPU リソースが。。 • 古いガラケーが。。

    51 自分達でなんとかできる問題 (問題ではなく課題) 自分達でどうにもできない問題 (買い替えを待つしか無い)
  25. HTTPS を狙う人々 55 • HTTPS の重要性が高まった • そこを狙うメリットも増えた • 実際に関連インシデントが目立つようになった

    • 今後はもっと増えるかも • 標的 ◦ OpenSSL ◦ CA ◦ メジャーブラウザ ◦ TLS プロトコルそのもの TLS + PKI に乗っかるからこそ、 そこで起こる事件には注意と迅速 な対応が必須
  26. post quantum 57 • 量子コンピュータが普及すると ◦ 素因数分解の実行時間などに依存した暗号は ◦ 一瞬で解けるかもしれない ◦

    暗号になってない、ヤバイ • 耐量子コンピュータ暗号方式 ◦ CECPQ1 が Chrome に実装され始める ◦ Google Play Store などですでに使われている 結城先生!次の改訂でぜひ!!
  27. 日和見暗号 58 • Opportunistic Encryption • TLS = 相手の保証 +

    暗号化 • 暗号化だけなら証明書はいらない • http:// だけど経路暗号化だけしよう • Firefox が先行実装
  28. 足りてないもの 62 • 大規模な移行事例の共有がもう少し欲しい ◦ 表に出にくい? ◦ 内部の都合が占める部分がでかい? • HTTPS

    前提の開発がまだ確立してない ◦ HTTPS を前提とするノウハウ ◦ HTTPS を前提とする開発環境 ◦ HTTPS を前提としたフレームワーク ◦ HTTPS を前提としたアプリ設計 ◦ HTTPS を前提としたインフラ設計 エコシステム の力が重要
  29. 64 • Google が言ったから? • SEO で勝ちたいから? • Service Worker

    使いたいから? • やってないと恥ずかしいから? • Web ユーザの自由を守るため? あなたはどれ?