Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
WeboverHTTPSDevFest Tokyo 2016#devfest16 2016/10/09
View Slide
Jack
3
4安全とは？全ての HTTP サイトは危険なの？
5何からどう安全か？● 安全ってどういうこと？● そもそも危険なの？● 悪いのはだれなの？● その手段が HTTPS でいいの？● HTTPS にしないと悪者扱いなの？● このサイト、パスワードもカードも使わないんだけど？● なんで Google に Insecure とか言われないといけないの？● え、検索ランク下がるの？● なんで Service Worker 使えないの？● 急に言われたって無理だよ。。
何が起こっているのか？6
7
8平文 HTTP パケットrequest response
最初の Web の役割9● ドキュメント(論文)共有のプラットフォーム● ごく限られたユーザ(研究者など)● パケットが見えたところで● 平文で問題なかった
サイトからシステムへ10
ID とセッション管理11
12reqrespassword丸見えcookie丸見え平文だと
秘情報13● パスワード● cookie● クレジットカード番号● 住所、電話番号● メールアドレス● DM● 個人的な写真漏れたら一大事
14MITMClient ServerMiddleBox
15MITMClient ServerMiddleBox中間にあるネットワーク機器なら簡単に覗ける(＊犯罪です、だめ絶対 )見るだけじゃなく書き換えたり、なりすましたりも(MITM 前提の攻撃もよくある )
16TLS 暗号化(盗聴・改ざん・なりすまし防止)https - http over tls
17大事なところだけ HTTPS ?redirectlogin index listcart checkredirect秘情報が無ければ平文でいい？
http でもいい？● ドキュメントとかはいいよね● ニュースとかはいいよね● 漫画だしいいよね● 秘情報ないからいいよね● 見られたとしても別にね● メリットが無いしね● めんどく(ry18何が知られたくないかなんて人によって違う
もしも平文だったら● 検索エンジン● 書籍の検索● 新聞やニュース系サイト● 画像・動画サイト19つぶさに盗聴すると主義/思想、趣味/趣向なども浮かび上がるかも
技術的にはそうだけどそんなことやるやついないよね20
21Edward Joseph Snowdenと、思うじゃん？
PRISM 計画22● 国民の通信バッチリ記録● 企業と組んでバックドア● それらを国防(テロ対策)の名の下正当化らりるれろ
23言論の自由!!
じゃ、じゃあとりあえずHTTPS にすればいいよね。。24
25ロシア亡命中そんなHTTPSで大丈夫か？
国が本気出すとデキるらしいこと26● HTTPS でもとにかく記録しておく○ 法律で殴りまくって秘密鍵の提出要求○ 物理で殴りまくって素因数分解スケールが違うのだよスケールが
牧歌的時代の終焉27
前提の変化28● Web はもっと殺伐としていた○ 通信は見られている○ 秘情報かは関係無い○ もう何も信じられない● 暗号化という対抗手段○ 秘情報を隠すため○ 攻撃されてないため○ 監視されてないため○ 片手間な設定じゃだめWeb ユーザの自由を守るため
29HTTPS にする理由ではなく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 リソース● ガラケーの存在● etc35
HTTPS 化を妨げる要因● 証明書● URL の変更● Mixed Contents● ビジネスメリット● CPU リソース● ガラケーの存在● etc36
証明書買え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 リソース● ガラケーの存在● etc40
URL 変更● http:// の URL が広まっている○ http:// はすべて残したまま○ http:// をすべて https:// にリダイレクト● HSTS○ 毎回リダイレクトだと遅い○ 最初のリダイレクトでブラウザに覚えてもらう○ http:// へのリクエストが https:// に読み替えられる○ ブラウザに preload することで最初から HSTS に○ Full HTTPS 化の 1 つの指標41
HTTPS 化を妨げる要因● 証明書● URL の変更● Mixed Contents● ビジネスメリット● CPU リソース● ガラケーの存在● etc42
Mixed Contents● HTTPS ページに HTTP のサブリソース○ 警告になるものと読み込まれないものがある○ 広告が表示されない問題○ iframe 許す CGM での問題43https://labs.jxck.io/mixed/
Mixed Contents 対策● Upgrade Insecure Request○ 埋め込まれた http:// のリクエストを https:// にする○ 読み込む先が https 対応している必要● CSP report○ mixed contents の情報を集める○ 地道に潰す○ 可視化することで対応を加速● HSTS Priming (draft)○ mixed contents が HSTS だったら upgrade44
HTTPS 化を妨げる要因● 証明書● URL の変更● Mixed Contents● ビジネスメリット● CPU リソース● ガラケーの存在● etc45
ビジネスメリット● 「Web の自由のため」では金は出ない● 啓蒙の限界● 別の強制力も必要● ブラウザやプラットフォーマの圧力46大人のやり方
● Google Search Rank● URL Bar47
● Google Search Rank● URL Bar48説明不要の絶大な効果最初の記事の話(そのうち insecure って表示するよ)
HTTPS でしかできないこと● HTTP2● Service Worker● WebRTC(gUM)● Geolocation● Add to Home Screen● Credential Management● etc49MITM 成立時の影響が大きいという理由も。逆に今後出る低レベルAPI もHTTPS前提となっていく。
その他、よく聞く問題● ノウハウがない。。● 遅くなっちゃった。。● CPU リソースが。。● 古いガラケーが。。50
その他、よく聞く問題● ノウハウがない。。● 遅くなっちゃった。。● CPU リソースが。。● 古いガラケーが。。51自分達でなんとかできる問題(問題ではなく課題)自分達でどうにもできない問題(買い替えを待つしか無い)
現状● 牧歌的な時代は終わってしまった● 議論はあるが HTTPS 化は避けられない● する理由ではなく、しない理由を探すフェーズ● そして、しない理由を潰していく● 遅れるほど辛くなる52
これからどうなっていくか53
LTS 関連インシデント54
HTTPS を狙う人々55● HTTPS の重要性が高まった● そこを狙うメリットも増えた● 実際に関連インシデントが目立つようになった● 今後はもっと増えるかも● 標的○ OpenSSL○ CA○ メジャーブラウザ○ TLS プロトコルそのものTLS + PKI に乗っかるからこそ、そこで起こる事件には注意と迅速な対応が必須
プロトコルの改善56
post quantum57● 量子コンピュータが普及すると○ 素因数分解の実行時間などに依存した暗号は○ 一瞬で解けるかもしれない○ 暗号になってない、ヤバイ● 耐量子コンピュータ暗号方式○ CECPQ1 が Chrome に実装され始める○ Google Play Store などですでに使われている結城先生！次の改訂でぜひ！！
日和見暗号58● Opportunistic Encryption● TLS = 相手の保証 + 暗号化● 暗号化だけなら証明書はいらない● http:// だけど経路暗号化だけしよう● Firefox が先行実装
TLS1.359● 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 theFree & Safebe with Web68
jxck
alli83
usamik26
makenowjust
mraible
mame
totto2727
cer
kinocoboy2
maimux2x
koba04
utgwkk
rinchsan
lauravandoore
62gerente
destraynor
eileencodes
iamctodd
philhawksworth
wjessup
akosma
morganepeng
gr2m
lara