Web over HTTPS - Speaker Deck

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Jack

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 何からどう安全か？ ● 安全ってどういうこと？ ● そもそも危険なの？ ● 悪いのはだれなの？ ● その手段が HTTPS でいいの？ ● HTTPS にしないと悪者扱いなの？ ● このサイト、パスワードもカードも使わないんだけど？ ● なんで Google に Insecure とか言われないといけないの？ ● え、検索ランク下がるの？ ● なんで Service Worker 使えないの？ ● 急に言われたって無理だよ。。

Slide 6

Slide 6 text

何が起こっているのか？ 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 平文 HTTP パケット request response

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

サイトからシステムへ 10

Slide 11

Slide 11 text

ID とセッション管理 11

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

秘情報 13 ● パスワード ● cookie ● クレジットカード番号 ● 住所、電話番号 ● メールアドレス ● DM ● 個人的な写真漏れたら一大事

Slide 14

Slide 14 text

14 MITM Client Server Middle Box

Slide 15

Slide 15 text

15 MITM Client Server Middle Box 中間にあるネットワーク機器なら簡単に覗ける (＊犯罪です、だめ絶対 ) 見るだけじゃなく書き換えたり、なりすましたりも (MITM 前提の攻撃もよくある )

Slide 16

Slide 16 text

16 TLS 暗号化 (盗聴・改ざん・なりすまし防止) https - http over tls

Slide 17

Slide 17 text

17 大事なところだけ HTTPS ? redirect login index list cart check redirect 秘情報が無ければ平文でいい？

Slide 18

Slide 18 text

http でもいい？ ● ドキュメントとかはいいよね ● ニュースとかはいいよね ● 漫画だしいいよね ● 秘情報ないからいいよね ● 見られたとしても別にね ● メリットが無いしね ● めんどく(ry 18 何が知られたくないかなんて人によって違う

Slide 19

Slide 19 text

もしも平文だったら ● 検索エンジン ● 書籍の検索 ● 新聞やニュース系サイト ● 画像・動画サイト 19 つぶさに盗聴すると主義/思想、趣味/趣向なども浮かび上がるかも

Slide 20

Slide 20 text

技術的にはそうだけどそんなことやるやついないよね 20

Slide 21

Slide 21 text

21 Edward Joseph Snowden と、思うじゃん？

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 言論の自由!!

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

牧歌的時代の終焉 27

Slide 28

Slide 28 text

前提の変化 28 ● Web はもっと殺伐としていた ○ 通信は見られている ○ 秘情報かは関係無い ○ もう何も信じられない ● 暗号化という対抗手段 ○ 秘情報を隠すため ○ 攻撃されてないため ○ 監視されてないため ○ 片手間な設定じゃだめ Web ユーザの自由を守るため

Slide 29

Slide 29 text

29 HTTPS にする理由ではなく HTTPS にしない理由の説明を求められる時代

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

正しく 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 でチェック

Slide 33

Slide 33 text

PFS ● Perfect Forward Secrecy ● TLS セッションごとに鍵を変える ● 秘密鍵が漏洩しても過去に遡って解読できない ● Ephemeral の付く鍵交換を利用 (ECDHE) 33 ごっそり記録されても秘密鍵を要求されてもだいじょーぶ

Slide 34

Slide 34 text

本当に大変なのは設定じゃない 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

証明書買え 37

Slide 38

Slide 38 text

EV 証明書 ● EV 証明書 ○ まともにビジネスをやるなら EV を買うべき ○ 一番簡単に見える、信頼できる組織の証 ○ URL バーに堂々と組織名を 38 お金で買える信用ほど安いものはない

Slide 39

Slide 39 text

Let’s Encrypt ● 無料の DV 証明書 ○ 基本は非営利や個人サイト向け ○ EveryWhere のうちビジネス用途以外を担うイメージ ○ wildcard の無い EV の補完 (ex microservices) ● ACME プロトコル ○ 証明書管理自動化プロトコル ○ certbot (client) + boulder (server) ○ 自社 DC や開発用 CA としても応用可能 ○ 他の CA サービスにも広まることを期待 39

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

URL 変更 ● http:// の URL が広まっている ○ http:// はすべて残したまま ○ http:// をすべて https:// にリダイレクト ● HSTS ○ 毎回リダイレクトだと遅い ○ 最初のリダイレクトでブラウザに覚えてもらう ○ http:// へのリクエストが https:// に読み替えられる ○ ブラウザに preload することで最初から HSTS に ○ Full HTTPS 化の 1 つの指標 41

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Mixed Contents ● HTTPS ページに HTTP のサブリソース ○ 警告になるものと読み込まれないものがある ○ 広告が表示されない問題 ○ iframe 許す CGM での問題 43 https://labs.jxck.io/mixed/

Slide 44

Slide 44 text

Mixed Contents 対策 ● Upgrade Insecure Request ○ 埋め込まれた http:// のリクエストを https:// にする ○ 読み込む先が https 対応している必要 ● CSP report ○ mixed contents の情報を集める ○ 地道に潰す ○ 可視化することで対応を加速 ● HSTS Priming (draft) ○ mixed contents が HSTS だったら upgrade 44

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

ビジネスメリット ● 「Web の自由のため」では金は出ない ● 啓蒙の限界 ● 別の強制力も必要 ● ブラウザやプラットフォーマの圧力 46 大人のやり方

Slide 47

Slide 47 text

● Google Search Rank ● URL Bar 47

Slide 48

Slide 48 text

● Google Search Rank ● URL Bar 48 説明不要の絶大な効果最初の記事の話 (そのうち insecure って表示するよ)

Slide 49

Slide 49 text

HTTPS でしかできないこと ● HTTP2 ● Service Worker ● WebRTC(gUM) ● Geolocation ● Add to Home Screen ● Credential Management ● etc 49 MITM 成立時の影響が大きいという理由も。逆に今後出る低レベル API もHTTPS前提となっていく。

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

その他、よく聞く問題 ● ノウハウがない。。 ● 遅くなっちゃった。。 ● CPU リソースが。。 ● 古いガラケーが。。 51 自分達でなんとかできる問題 (問題ではなく課題) 自分達でどうにもできない問題 (買い替えを待つしか無い)

Slide 52

Slide 52 text

現状 ● 牧歌的な時代は終わってしまった ● 議論はあるが HTTPS 化は避けられない ● する理由ではなく、しない理由を探すフェーズ ● そして、しない理由を潰していく ● 遅れるほど辛くなる 52

Slide 53

Slide 53 text

これからどうなっていくか 53

Slide 54

Slide 54 text

LTS 関連インシデント 54

Slide 55

Slide 55 text

HTTPS を狙う人々 55 ● HTTPS の重要性が高まった ● そこを狙うメリットも増えた ● 実際に関連インシデントが目立つようになった ● 今後はもっと増えるかも ● 標的 ○ OpenSSL ○ CA ○ メジャーブラウザ ○ TLS プロトコルそのもの TLS + PKI に乗っかるからこそ、そこで起こる事件には注意と迅速な対応が必須

Slide 56

Slide 56 text

プロトコルの改善 56

Slide 57

Slide 57 text

post quantum 57 ● 量子コンピュータが普及すると ○ 素因数分解の実行時間などに依存した暗号は ○ 一瞬で解けるかもしれない ○ 暗号になってない、ヤバイ ● 耐量子コンピュータ暗号方式 ○ CECPQ1 が Chrome に実装され始める ○ Google Play Store などですでに使われている結城先生！次の改訂でぜひ！！

Slide 58

Slide 58 text

日和見暗号 58 ● Opportunistic Encryption ● TLS = 相手の保証 + 暗号化 ● 暗号化だけなら証明書はいらない ● http:// だけど経路暗号化だけしよう ● Firefox が先行実装

Slide 59

Slide 59 text

TLS1.3 59 ● TLS1.2 も色々限界(技術的負債) ● もっとセキュアに(危殆化暗号、平文通信削減) ● もっと速く(ハンドシェイクをできればなくす) ● もっと綺麗に(使われない機能、項目をなくす) ● その他色々 ● RFC も近そう？

Slide 60

Slide 60 text

HTTPS 化 60

Slide 61

Slide 61 text

それでも進みつつある HTTPS 化 61 ● それでもインターネット全体では進んでる ● (日本は少し遅れているというデータも) ● 新規開発で HTTPS にしていく ● 既存資産もなんとかしてく ● 徐々に進みそう

Slide 62

Slide 62 text

足りてないもの 62 ● 大規模な移行事例の共有がもう少し欲しい ○ 表に出にくい？ ○ 内部の都合が占める部分がでかい？ ● HTTPS 前提の開発がまだ確立してない ○ HTTPS を前提とするノウハウ ○ HTTPS を前提とする開発環境 ○ HTTPS を前提としたフレームワーク ○ HTTPS を前提としたアプリ設計 ○ HTTPS を前提としたインフラ設計エコシステムの力が重要

Slide 63

Slide 63 text

HTTPS 化する理由 63

Slide 64

Slide 64 text

64 ● Google が言ったから？ ● SEO で勝ちたいから？ ● Service Worker 使いたいから？ ● やってないと恥ずかしいから？ ● Web ユーザの自由を守るため？あなたはどれ？

Slide 65

Slide 65 text

HTTPS 化に本当に必要なもの 65

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

67 本当に必要なもの ● それが必要だという意識 ● それを行う正しい知識と技術 ● そして少々のお金それを広めるのがコミュニティの責務それを整備するのがエコシステムの責務それが揃ったときにすぐに動けるようにするのがエンジニアの責務