Web over HTTPS

1ff811939fd0923df8321ec6d8bf9d4b?s=47 Jxck
October 09, 2016

Web over HTTPS

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

1ff811939fd0923df8321ec6d8bf9d4b?s=128

Jxck

October 09, 2016
Tweet

Transcript

  1. Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/09

  2. Jack

  3. 3

  4. 4 安全とは? 全ての HTTP サイト は危険なの?

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

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

  7. 7

  8. 8 平文 HTTP パケット request response

  9. 最初の Web の役割 9 • ドキュメント(論文)共有のプラットフォーム • ごく限られたユーザ(研究者など) • パケットが見えたところで

    • 平文で問題なかった
  10. サイトからシステムへ 10

  11. ID とセッション管理 11

  12. 12 req res password 丸見え cookie 丸見え 平文だと

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

    • メールアドレス • DM • 個人的な写真 漏れたら一大事
  14. 14 MITM Client Server Middle Box

  15. 15 MITM Client Server Middle Box 中間にあるネットワーク 機器なら簡単に覗ける (*犯罪です、だめ絶対 )

    見るだけじゃなく 書き換えたり、なりすましたりも (MITM 前提の攻撃もよくある )
  16. 16 TLS 暗号化 (盗聴・改ざん・なりすまし防止) https - http over tls

  17. 17 大事なところだけ HTTPS ? redirect login index list cart check

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

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

    つぶさに盗聴すると 主義/思想、趣味/趣向なども 浮かび上がるかも
  20. 技術的にはそうだけど そんなことやるやついないよね 20

  21. 21 Edward Joseph Snowden と、思うじゃ ん?

  22. PRISM 計画 22 • 国民の通信バッチリ記録 • 企業と組んでバックドア • それらを国防(テロ対策)の名の下正当化 らりるれろ

  23. 23 言論の自由!!

  24. じゃ、じゃあとりあえず HTTPS にすればいいよね。。 24

  25. 25 ロシア亡命中 そんな HTTPS で大丈夫か?

  26. 国が本気出すとデキるらしいこと 26 • HTTPS でもとにかく記録しておく ◦ 法律で殴りまくって秘密鍵の提出要求 ◦ 物理で殴りまくって素因数分解 スケールが違うの

    だよスケールが
  27. 牧歌的時代の終焉 27

  28. 前提の変化 28 • Web はもっと殺伐としていた ◦ 通信は見られている ◦ 秘情報かは関係無い ◦

    もう何も信じられない • 暗号化という対抗手段 ◦ 秘情報を隠すため ◦ 攻撃されてないため ◦ 監視されてないため ◦ 片手間な設定じゃだめ Web ユーザ の自由を守 るため
  29. 29 HTTPS にする理由 ではなく HTTPS にしない理由 の説明を求められる時代

  30. 30

  31. 適切な HTTPS 設定できますか? 31

  32. 正しく 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 でチェック
  33. PFS • Perfect Forward Secrecy • TLS セッションごとに鍵を変える • 秘密鍵が漏洩しても過去に遡って解読できない

    • Ephemeral の付く鍵交換を利用 (ECDHE) 33 ごっそり記録されても 秘密鍵を要求されても だいじょーぶ
  34. 本当に大変なのは 設定じゃない 34

  35. HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents

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

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 36
  37. 証明書 買え 37

  38. EV 証明書 • EV 証明書 ◦ まともにビジネスをやるなら EV を買うべき ◦

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

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

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

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

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

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

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

    • ビジネスメリット • CPU リソース • ガラケーの存在 • etc 45
  46. ビジネスメリット • 「Web の自由のため」では金は出ない • 啓蒙の限界 • 別の強制力も必要 • ブラウザやプラットフォーマの圧力

    46 大人のやり方
  47. • Google Search Rank • URL Bar 47

  48. • Google Search Rank • URL Bar 48 説明不要の絶大な効果 最初の記事の話

    (そのうち insecure って表示するよ)
  49. HTTPS でしかできないこと • HTTP2 • Service Worker • WebRTC(gUM) •

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

    50
  51. その他、よく聞く問題 • ノウハウがない。。 • 遅くなっちゃった。。 • CPU リソースが。。 • 古いガラケーが。。

    51 自分達でなんとかできる問題 (問題ではなく課題) 自分達でどうにもできない問題 (買い替えを待つしか無い)
  52. 現状 • 牧歌的な時代は終わってしまった • 議論はあるが HTTPS 化は避けられない • する理由ではなく、しない理由を探すフェーズ •

    そして、しない理由を潰していく • 遅れるほど辛くなる 52
  53. これからどうなっていくか 53

  54. LTS 関連インシデント 54

  55. HTTPS を狙う人々 55 • HTTPS の重要性が高まった • そこを狙うメリットも増えた • 実際に関連インシデントが目立つようになった

    • 今後はもっと増えるかも • 標的 ◦ OpenSSL ◦ CA ◦ メジャーブラウザ ◦ TLS プロトコルそのもの TLS + PKI に乗っかるからこそ、 そこで起こる事件には注意と迅速 な対応が必須
  56. プロトコルの改善 56

  57. post quantum 57 • 量子コンピュータが普及すると ◦ 素因数分解の実行時間などに依存した暗号は ◦ 一瞬で解けるかもしれない ◦

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

    暗号化 • 暗号化だけなら証明書はいらない • http:// だけど経路暗号化だけしよう • Firefox が先行実装
  59. TLS1.3 59 • TLS1.2 も色々限界(技術的負債) • もっとセキュアに(危殆化暗号、平文通信削減) • もっと速く(ハンドシェイクをできればなくす) •

    もっと綺麗に(使われない機能、項目をなくす) • その他色々 • RFC も近そう?
  60. HTTPS 化 60

  61. それでも進みつつある HTTPS 化 61 • それでもインターネット全体では進んでる • (日本は少し遅れているというデータも) • 新規開発で

    HTTPS にしていく • 既存資産もなんとかしてく • 徐々に進みそう
  62. 足りてないもの 62 • 大規模な移行事例の共有がもう少し欲しい ◦ 表に出にくい? ◦ 内部の都合が占める部分がでかい? • HTTPS

    前提の開発がまだ確立してない ◦ HTTPS を前提とするノウハウ ◦ HTTPS を前提とする開発環境 ◦ HTTPS を前提としたフレームワーク ◦ HTTPS を前提としたアプリ設計 ◦ HTTPS を前提としたインフラ設計 エコシステム の力が重要
  63. HTTPS 化する理由 63

  64. 64 • Google が言ったから? • SEO で勝ちたいから? • Service Worker

    使いたいから? • やってないと恥ずかしいから? • Web ユーザの自由を守るため? あなたはどれ?
  65. HTTPS 化に 本当に必要なもの 65

  66. 66 本当に必要なもの • それが必要だという意識 • それを行う正しい知識と技術 • そして少々のお金

  67. 67 本当に必要なもの • それが必要だという意識 • それを行う正しい知識と技術 • そして少々のお金 それを広めるのがコミュニティの責務 それを整備するのがエコシステムの責務

    それが揃ったときにすぐに動けるようにするの がエンジニアの責務
  68. May the Free & Safe be with Web 68

  69. Jack