Web over HTTPS

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