Web over HTTPS

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

Transcript

1. Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/09
2. Jack
4. 4 安全とは？ 全ての HTTP サイト は危険なの？
5. 5 何からどう安全か？ • 安全ってどういうこと？ • そもそも危険なの？ • 悪いのはだれなの？ • その手段が HTTPS でいいの？ • HTTPS にしないと悪者扱いなの？ • このサイト、パスワードもカードも使わないんだけど？ • なんで Google に Insecure とか言われないといけないの？ • え、検索ランク下がるの？ • なんで Service Worker 使えないの？ • 急に言われたって無理だよ。。
6. 何が起こっているのか？ 6
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 にしない理由 の説明を求められる時代
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