Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Web over HTTPS
Search
Jxck
October 09, 2016
Programming
71
10k
Web over HTTPS
Web over HTTPS
DevFest Tokyo 2016
#devfest16 2016/10/0
Jxck
October 09, 2016
Tweet
Share
More Decks by Jxck
See All by Jxck
IE Graduation (IE の功績を讃える)
jxck
22
15k
IE Graduation Certificate
jxck
6
6k
RFC 9111: HTTP Caching
jxck
0
600
tc39_study_2
jxck
1
4.4k
IETF における ABNF とプロトコルパーサの話 / ABNF for Protocol Parser @ IETF
jxck
2
980
Web Components 元年 v3 / Web Components first year v3
jxck
1
950
Periodic Background Sync
jxck
0
510
Podcast over PWA
jxck
0
220
Yearly Web 2019
jxck
0
140
Other Decks in Programming
See All in Programming
Vue.js学習の振り返り
hiro_xre
2
130
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
katty0324
5
3.6k
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
590
Dev ContainersとGitHub Codespacesの素敵な関係
ymd65536
1
130
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
0
150
Honoの来た道とこれから
yusukebe
19
3k
Golang と Erlang
taiyow
8
1.9k
Tuning GraphQL on Rails
pyama86
2
1k
macOS でできる リアルタイム動画像処理
biacco42
7
1.8k
2万ページのSSG運用における工夫と注意点 / Vue Fes Japan 2024
chinen
3
1.3k
Server Driven Compose With Firebase
skydoves
0
400
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
7
2.8k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
How GitHub (no longer) Works
holman
311
140k
Faster Mobile Websites
deanohume
304
30k
Writing Fast Ruby
sferik
626
61k
Designing for humans not robots
tammielis
249
25k
Why Our Code Smells
bkeepers
PRO
334
57k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Teambox: Starting and Learning
jrom
132
8.7k
How to Ace a Technical Interview
jacobian
275
23k
Transcript
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/09
Jack
3
4 安全とは? 全ての HTTP サイト は危険なの?
5 何からどう安全か? • 安全ってどういうこと? • そもそも危険なの? • 悪いのはだれなの? • その手段が
HTTPS でいいの? • HTTPS にしないと悪者扱いなの? • このサイト、パスワードもカードも使わないんだけど? • なんで Google に Insecure とか言われないといけないの? • え、検索ランク下がるの? • なんで Service Worker 使えないの? • 急に言われたって無理だよ。。
何が起こっているのか? 6
7
8 平文 HTTP パケット request response
最初の Web の役割 9 • ドキュメント(論文)共有のプラットフォーム • ごく限られたユーザ(研究者など) • パケットが見えたところで
• 平文で問題なかった
サイトからシステムへ 10
ID とセッション管理 11
12 req res password 丸見え cookie 丸見え 平文だと
秘情報 13 • パスワード • cookie • クレジットカード番号 • 住所、電話番号
• メールアドレス • DM • 個人的な写真 漏れたら一大事
14 MITM Client Server Middle Box
15 MITM Client Server Middle Box 中間にあるネットワーク 機器なら簡単に覗ける (*犯罪です、だめ絶対 )
見るだけじゃなく 書き換えたり、なりすましたりも (MITM 前提の攻撃もよくある )
16 TLS 暗号化 (盗聴・改ざん・なりすまし防止) https - http over tls
17 大事なところだけ HTTPS ? redirect login index list cart check
redirect 秘情報が無ければ 平文でいい?
http でもいい? • ドキュメントとかはいいよね • ニュースとかはいいよね • 漫画だしいいよね • 秘情報ないからいいよね
• 見られたとしても別にね • メリットが無いしね • めんどく(ry 18 何が知られたくない かなんて人によって 違う
もしも平文だったら • 検索エンジン • 書籍の検索 • 新聞やニュース系サイト • 画像・動画サイト 19
つぶさに盗聴すると 主義/思想、趣味/趣向なども 浮かび上がるかも
技術的にはそうだけど そんなことやるやついないよね 20
21 Edward Joseph Snowden と、思うじゃ ん?
PRISM 計画 22 • 国民の通信バッチリ記録 • 企業と組んでバックドア • それらを国防(テロ対策)の名の下正当化 らりるれろ
23 言論の自由!!
じゃ、じゃあとりあえず HTTPS にすればいいよね。。 24
25 ロシア亡命中 そんな HTTPS で大丈夫か?
国が本気出すとデキるらしいこと 26 • HTTPS でもとにかく記録しておく ◦ 法律で殴りまくって秘密鍵の提出要求 ◦ 物理で殴りまくって素因数分解 スケールが違うの
だよスケールが
牧歌的時代の終焉 27
前提の変化 28 • Web はもっと殺伐としていた ◦ 通信は見られている ◦ 秘情報かは関係無い ◦
もう何も信じられない • 暗号化という対抗手段 ◦ 秘情報を隠すため ◦ 攻撃されてないため ◦ 監視されてないため ◦ 片手間な設定じゃだめ Web ユーザ の自由を守 るため
29 HTTPS にする理由 ではなく HTTPS にしない理由 の説明を求められる時代
30
適切な HTTPS 設定できますか? 31
正しく 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 でチェック
PFS • Perfect Forward Secrecy • TLS セッションごとに鍵を変える • 秘密鍵が漏洩しても過去に遡って解読できない
• Ephemeral の付く鍵交換を利用 (ECDHE) 33 ごっそり記録されても 秘密鍵を要求されても だいじょーぶ
本当に大変なのは 設定じゃない 34
HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents
• ビジネスメリット • CPU リソース • ガラケーの存在 • etc 35
HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents
• ビジネスメリット • CPU リソース • ガラケーの存在 • etc 36
証明書 買え 37
EV 証明書 • EV 証明書 ◦ まともにビジネスをやるなら EV を買うべき ◦
一番簡単に見える、信頼できる組織の証 ◦ URL バーに堂々と組織名を 38 お金で買える信用ほど 安いものはない
Let’s Encrypt • 無料の DV 証明書 ◦ 基本は非営利や個人サイト向け ◦ EveryWhere
のうちビジネス用途以外を担うイメージ ◦ wildcard の無い EV の補完 (ex microservices) • ACME プロトコル ◦ 証明書管理自動化プロトコル ◦ certbot (client) + boulder (server) ◦ 自社 DC や開発用 CA としても応用可能 ◦ 他の CA サービスにも広まることを期待 39
HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents
• ビジネスメリット • CPU リソース • ガラケーの存在 • etc 40
URL 変更 • http:// の URL が広まっている ◦ http:// はすべて残したまま
◦ http:// をすべて https:// にリダイレクト • HSTS ◦ 毎回リダイレクトだと遅い ◦ 最初のリダイレクトでブラウザに覚えてもらう ◦ http:// へのリクエストが https:// に読み替えられる ◦ ブラウザに preload することで最初から HSTS に ◦ Full HTTPS 化の 1 つの指標 41
HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents
• ビジネスメリット • CPU リソース • ガラケーの存在 • etc 42
Mixed Contents • HTTPS ページに HTTP のサブリソース ◦ 警告になるものと読み込まれないものがある ◦
広告が表示されない問題 ◦ iframe 許す CGM での問題 43 https://labs.jxck.io/mixed/
Mixed Contents 対策 • Upgrade Insecure Request ◦ 埋め込まれた http://
のリクエストを https:// にする ◦ 読み込む先が https 対応している必要 • CSP report ◦ mixed contents の情報を集める ◦ 地道に潰す ◦ 可視化することで対応を加速 • HSTS Priming (draft) ◦ mixed contents が HSTS だったら upgrade 44
HTTPS 化を妨げる要因 • 証明書 • URL の変更 • Mixed Contents
• ビジネスメリット • CPU リソース • ガラケーの存在 • etc 45
ビジネスメリット • 「Web の自由のため」では金は出ない • 啓蒙の限界 • 別の強制力も必要 • ブラウザやプラットフォーマの圧力
46 大人のやり方
• Google Search Rank • URL Bar 47
• Google Search Rank • URL Bar 48 説明不要の絶大な効果 最初の記事の話
(そのうち insecure って表示するよ)
HTTPS でしかできないこと • HTTP2 • Service Worker • WebRTC(gUM) •
Geolocation • Add to Home Screen • Credential Management • etc 49 MITM 成立時の影響が大 きいという理由も。 逆に今後出る低レベル API もHTTPS前提となっ ていく。
その他、よく聞く問題 • ノウハウがない。。 • 遅くなっちゃった。。 • CPU リソースが。。 • 古いガラケーが。。
50
その他、よく聞く問題 • ノウハウがない。。 • 遅くなっちゃった。。 • CPU リソースが。。 • 古いガラケーが。。
51 自分達でなんとかできる問題 (問題ではなく課題) 自分達でどうにもできない問題 (買い替えを待つしか無い)
現状 • 牧歌的な時代は終わってしまった • 議論はあるが HTTPS 化は避けられない • する理由ではなく、しない理由を探すフェーズ •
そして、しない理由を潰していく • 遅れるほど辛くなる 52
これからどうなっていくか 53
LTS 関連インシデント 54
HTTPS を狙う人々 55 • HTTPS の重要性が高まった • そこを狙うメリットも増えた • 実際に関連インシデントが目立つようになった
• 今後はもっと増えるかも • 標的 ◦ OpenSSL ◦ CA ◦ メジャーブラウザ ◦ TLS プロトコルそのもの TLS + PKI に乗っかるからこそ、 そこで起こる事件には注意と迅速 な対応が必須
プロトコルの改善 56
post quantum 57 • 量子コンピュータが普及すると ◦ 素因数分解の実行時間などに依存した暗号は ◦ 一瞬で解けるかもしれない ◦
暗号になってない、ヤバイ • 耐量子コンピュータ暗号方式 ◦ CECPQ1 が Chrome に実装され始める ◦ Google Play Store などですでに使われている 結城先生!次の改訂でぜひ!!
日和見暗号 58 • Opportunistic Encryption • TLS = 相手の保証 +
暗号化 • 暗号化だけなら証明書はいらない • http:// だけど経路暗号化だけしよう • Firefox が先行実装
TLS1.3 59 • TLS1.2 も色々限界(技術的負債) • もっとセキュアに(危殆化暗号、平文通信削減) • もっと速く(ハンドシェイクをできればなくす) •
もっと綺麗に(使われない機能、項目をなくす) • その他色々 • RFC も近そう?
HTTPS 化 60
それでも進みつつある HTTPS 化 61 • それでもインターネット全体では進んでる • (日本は少し遅れているというデータも) • 新規開発で
HTTPS にしていく • 既存資産もなんとかしてく • 徐々に進みそう
足りてないもの 62 • 大規模な移行事例の共有がもう少し欲しい ◦ 表に出にくい? ◦ 内部の都合が占める部分がでかい? • HTTPS
前提の開発がまだ確立してない ◦ HTTPS を前提とするノウハウ ◦ HTTPS を前提とする開発環境 ◦ HTTPS を前提としたフレームワーク ◦ HTTPS を前提としたアプリ設計 ◦ HTTPS を前提としたインフラ設計 エコシステム の力が重要
HTTPS 化する理由 63
64 • Google が言ったから? • SEO で勝ちたいから? • Service Worker
使いたいから? • やってないと恥ずかしいから? • Web ユーザの自由を守るため? あなたはどれ?
HTTPS 化に 本当に必要なもの 65
66 本当に必要なもの • それが必要だという意識 • それを行う正しい知識と技術 • そして少々のお金
67 本当に必要なもの • それが必要だという意識 • それを行う正しい知識と技術 • そして少々のお金 それを広めるのがコミュニティの責務 それを整備するのがエコシステムの責務
それが揃ったときにすぐに動けるようにするの がエンジニアの責務
May the Free & Safe be with Web 68
Jack