Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
通信の安全を守るためにエンジニアが
できること
株式会社シャノン
藤倉 和明
自己紹介
藤倉 和明 (ふじくら かずあき)
株式会社シャノン 所属
インフラチームマネージャー
兼 情報セキュリティ管理者
兼 情報システム部門長的な何か
共著ですが本書いたことも有ります
@fujya
2
本日はこれについて
3
こういうの出てくると
サイトに繋がら
ないんですけど
API連携エラー
が出てるけど何
があったの?
今すぐなん
とかしろ!
ツライですよね・・・
フィッシングサイ
トですか?
4
そもそも何のためにあるの?
User
Internet
WebServer
盗聴
改ざん
インターネット上での通信は盗聴や
改ざんのリスクが常に伴う
5
そもそも何のためにあるの?
User
Internet
WebServer
盗聴
改ざん
暗号化通信する事で悪意のある第
三者からの盗聴、改ざんを防止
6
そもそも何のためにあるの?
User
Internet
WebServer
正規のサイト実在証明
フィッシング
サイト
7
SSLはインターネット上で大事な情報を守るための必要な仕組み
「盗聴」
「改ざん」
「なりすまし」
あなたの大事なデータを守る大事な仕組み
SSLで防ぐ3つのリスク
8
大事な仕組み
でも色々と苦労はつきまとう
10
あらためて今日話す事
ここ10年ぐらいのSSL関連のツラミ
どう対応してきたか
これからどうしていくのか
11
実装の問題(openssl等)
認証局の問題は今回は対象外
暗号アルゴリズムにおける2010年問題
https://jp.globalsign.com/service/ssl/knowledge/1024bit.html より
2005年頃にNISTが発表したガイドライン
SSLでよく使われているRSA...
どうやって乗り越えていったか
証明局
2048bitのルート証明書の配布
後方互換の為のクロスルート証明書の配布
1024bit -> 2048bitへの無償アップグレード
マイクロソフト社をはじめとする各社
OS/ライブラリのアップデート時に...
5年間という期間をかけてゆるやかな移行ができた
業界一丸となってWebの安全を守った
翌年以降はどうだったか?
年次ごとにインシデントを見ていきましょう
14
2011年
人々を混乱に陥れたBEAST
2011年頃では多く使われていたSSL3.0/TLS1.0が対象
ブロック暗号のCBCモードに対して選択平文攻撃を行うことでブラウザ内の
Cookieを入手するツールが公開された
対策
サーバサイド
1. SSL3...
選択平文攻撃?
攻撃者が選択したある平文を何らかの方法で正規のユーザー
に暗号化させ、元の平文と得られた暗号文から暗号鍵を推測
し、同じ暗号鍵を用いて作られた暗号を解読しようとすること
BEAST攻撃では、暗号鍵の推測が目的ではなく、暗号文から...
BEAST攻撃が流行っていた時のあるある
御社のサービスはBEAST攻撃に対し
て脆弱性があるので対応してください
TLS1.1~1.2のみにすると9割ぐらい
のブラウザ繋がらなくなります。
RC4はRC4で強度が低い問題が・・・
御社は脆弱性...
・対応するリスク
・対応しないリスク
どちらのリスクを『受容』するか顧客に促す
BEASTについては対応しないリスクを説明し『受容』してもらう
根気よく説明、リスクの『受容』を促す
BEASTはかなり限定的な条件、ブラウザの不具合・脆弱性を組み...
2012年
BEASTの後継者か?
BEASTと攻撃対象は似ていて中間者攻撃が可能な状態、Cookie等の秘
密情報を狙って取得使用しようとする攻撃
BEASTと異る点はCBCモードやストリーム暗号のRC4でも攻撃が可能
SSL圧縮で使われるdeflate...
2013年
https://www.rc4nomore.com/
22
RC4推奨のジレンマ、そしてLucky 13
以前よりRC4そのものに対する攻撃法は報告されていたが、SSLで使われ
るRC4は安全と言われていたが、2013年に効果的な攻撃が報告された
2015年には「解読に2000時間かかっていたものが、7...
パディングオラクル攻撃?
詳細は下記を参照
https://www.iacr.org/archive/eurocrypt2002/23320530/cbc
02_e02d.pdf
2014年
SSL3.0が死んだ日
Lucky 13では限定的な環境でしかパディングオラクル攻撃の実証ができな
かったが、POODLEについては、SSL3.0が有効になっている環境で容易に
実現できるという報告
中間者攻撃が可能な状況かつ、SSL3.0が有...
POODLE発表後・・・(2014年10月発表)
SSL3.0で接続してきてるクライアントが一部居る・・・
切る?切らない?
一部顧客からしばらく待って欲しいとの問い合わせが
切る?切られる?
本音としては今すぐ切りたい。切るべきだと思う。
で...
POODLEの時どうしたか
早い段階でのdeveloper環境でのSSL3.0無効化
ブラウザ側でのSSL3.0無効化の案内
本番環境でのSSL3.0接続状況のデイリー監視
接続数が0.1%を切ったらスケジュールを繰り上げる想定
接続元IPから...
2015年
FREAKそして、Logjam
FREAK、Logjamともに中間者攻撃が行われている環境において、輸出グレ
ード暗号にダウングレードしてデータの盗聴、改ざんが可能な状態にする攻
撃
FREAKは対策が容易:輸出グレード暗号については、暗号スイ...
実際にこんなお問い合わせも
国家規模のコンピュータリソース使われたら
個人情報が漏洩するから
2048bit以上に今すぐ対応してください!
31
迫られる対応
DH2048bit対応すると起きる問題
DHを優先的に接続しようとするクライアントでは、1024bitまでしか対応
していないものもある(例えばJava6はかなり上位)
レガシーな環境で開発されたAPIクライアントはJava6で作...
ECDH 『E』のメリット ~ Perfect forward secrecy~
過去の通信の安全は保障されてますか?
エドワード・スノーデン/NSA情報漏洩事件
Heartbleedによる秘密鍵漏洩のリスク
秘密鍵が漏洩した場合、過去の通信も...
ここからが本題
SSLって『安全』に通信するための仕組みなのに
なんだか脆弱性がたくさん報告されて怖いですよね。
これから先、『安全』を守れますか?
34
2011年以降何が変わった?
2010年まで
ムーアの法則 vs 暗号強度の話
対応の期限は予め決められていて猶予はあった
2011年以降
SSLの仕組みに脆弱性が見つかった
期限は『今すぐやるべき』ものばかり
35
どうしてこうなった?
SSLは相互接続性を優先してきていた
1995年に作られたSSL3.0も2014年まで現役で生き続けた
1. 1995年はInternet Explorer 2が公開された年
相互接続性は安全性とのトレードオフ
レガシーな...
相互接続性優先の考えは脆弱である
いくら強い暗号スイートを優先的に利用できるようにしていても
中間者攻撃、ダウングレード攻撃に対して無力
弱い暗号アルゴリズムの選択、バージョンダウンができてしまう
これから先、安心して通信をサポートするためには...
技術者が変えていかなければいけない
どうやって?
これからどうするべきか
TLS1.0はすでにレガシーなので捨てていかなければいけない
PCI-DSSもTLS1.0捨てろと言っている
TLS1.0は1999年に作られた
TLS1.2が現段階で最新版のプロトコルバージョン
常時httpsの時代へ...
TLS1.0捨てる?
以下のクライアントが繋がらなくなります
Android4.3以前
IE 6 - XP
IE 7 - Vista / IE8 -10 Win7(設定で繋がるようにする事はできる)
Safari 6.0.4 / OS X 10...
エンジニアが正しい情報を伝達する
引用:http://www.jnsa.org/seminar/2013/0607/data/2E-3_pki_suga.pdf
ここで止めてはいけない!
この辺がレガシー要求してくる
可能性有り
41
マスメデ...
サイクルを作りましょう
検証環
境を作る
移行を
促す
問題点
を洗い
出す
顧客に
説明す
る
課題を
解決す
る
本番環
境に適
用する
新しい問題
ここで諦めない
ここでも諦めない
42
通信の安全を守るために私達ができること
通信の安全を守るためにレガシーな環境は捨てていく
新しい問題への対処として変化に対応する
これらの事を顧客まで正しい情報として届ける
43
例えばAWSを使うとか良い案
強い気持ちを持って未来を変えていきましょう!
ご清聴ありがとうございました
44
通信の安全を守るためにエンジニアができること
Upcoming SlideShare
Loading in …5
×

通信の安全を守るためにエンジニアができること

21,186 views

Published on

http://secnight.connpass.com/event/30672/
http://togetter.com/li/974201


シャノン技術ブログ
http://shanon-tech.blogspot.jp/

Published in: Internet
  • Be the first to comment

通信の安全を守るためにエンジニアができること

  1. 1. 通信の安全を守るためにエンジニアが できること 株式会社シャノン 藤倉 和明
  2. 2. 自己紹介 藤倉 和明 (ふじくら かずあき) 株式会社シャノン 所属 インフラチームマネージャー 兼 情報セキュリティ管理者 兼 情報システム部門長的な何か 共著ですが本書いたことも有ります @fujya 2
  3. 3. 本日はこれについて 3
  4. 4. こういうの出てくると サイトに繋がら ないんですけど API連携エラー が出てるけど何 があったの? 今すぐなん とかしろ! ツライですよね・・・ フィッシングサイ トですか? 4
  5. 5. そもそも何のためにあるの? User Internet WebServer 盗聴 改ざん インターネット上での通信は盗聴や 改ざんのリスクが常に伴う 5
  6. 6. そもそも何のためにあるの? User Internet WebServer 盗聴 改ざん 暗号化通信する事で悪意のある第 三者からの盗聴、改ざんを防止 6
  7. 7. そもそも何のためにあるの? User Internet WebServer 正規のサイト実在証明 フィッシング サイト 7
  8. 8. SSLはインターネット上で大事な情報を守るための必要な仕組み 「盗聴」 「改ざん」 「なりすまし」 あなたの大事なデータを守る大事な仕組み SSLで防ぐ3つのリスク 8
  9. 9. 大事な仕組み でも色々と苦労はつきまとう 10
  10. 10. あらためて今日話す事 ここ10年ぐらいのSSL関連のツラミ どう対応してきたか これからどうしていくのか 11 実装の問題(openssl等) 認証局の問題は今回は対象外
  11. 11. 暗号アルゴリズムにおける2010年問題 https://jp.globalsign.com/service/ssl/knowledge/1024bit.html より 2005年頃にNISTが発表したガイドライン SSLでよく使われているRSA(鍵長1024bit)も対象に含まれている 12
  12. 12. どうやって乗り越えていったか 証明局 2048bitのルート証明書の配布 後方互換の為のクロスルート証明書の配布 1024bit -> 2048bitへの無償アップグレード マイクロソフト社をはじめとする各社 OS/ライブラリのアップデート時に2048bitのルート証明書のインストール 2013年ごろに1024bit証明書の接続拒否の対応 サービスベンダ(シャノン) 2010~2011年以降「特別な理由がない限り」2048bitの証明書を推奨 クロスルート証明書の設置、検証 ユーザへの根気強い説明
  13. 13. 5年間という期間をかけてゆるやかな移行ができた 業界一丸となってWebの安全を守った 翌年以降はどうだったか? 年次ごとにインシデントを見ていきましょう 14
  14. 14. 2011年
  15. 15. 人々を混乱に陥れたBEAST 2011年頃では多く使われていたSSL3.0/TLS1.0が対象 ブロック暗号のCBCモードに対して選択平文攻撃を行うことでブラウザ内の Cookieを入手するツールが公開された 対策 サーバサイド 1. SSL3.0/TLS1.0を利用せずTLS1.1/TLS1.2を利用する 2. ブロック暗号ではなく、ストリーム暗号(RC4)を利用する クライアントサイド 1. ブラウザのアップグレード 2. 信頼できるネットワークを利用する(MITMの回避) 16
  16. 16. 選択平文攻撃? 攻撃者が選択したある平文を何らかの方法で正規のユーザー に暗号化させ、元の平文と得られた暗号文から暗号鍵を推測 し、同じ暗号鍵を用いて作られた暗号を解読しようとすること BEAST攻撃では、暗号鍵の推測が目的ではなく、暗号文から 平文を推測する。つまりCookieの取得が目的になります。 CBCモードで16byte毎に区切られる(解読不能) 解読する対象を1byteに絞り 256パターンで解読できるようにする 1byte毎解読していきCookieを取得する
  17. 17. BEAST攻撃が流行っていた時のあるある 御社のサービスはBEAST攻撃に対し て脆弱性があるので対応してください TLS1.1~1.2のみにすると9割ぐらい のブラウザ繋がらなくなります。 RC4はRC4で強度が低い問題が・・・ 御社は脆弱性を放置するのですか? TLS1.2 onlyにすると9割ぐらいのクラ イアントが繋がらなくなる可能性があり ますが・・・・ それは困る!みんなが繋がるように脆 弱性の対応してください! 無理ゲー・・・ 18
  18. 18. ・対応するリスク ・対応しないリスク どちらのリスクを『受容』するか顧客に促す BEASTについては対応しないリスクを説明し『受容』してもらう 根気よく説明、リスクの『受容』を促す BEASTはかなり限定的な条件、ブラウザの不具合・脆弱性を組み合わせ て実現できる攻撃手法であり、通常の環境で成功する事は難しい ブラウザの対応は早く、アップデートしていればリスクはかなり下げられた プロトコルのバージョンアップは繋がらなくなるリスクもある 19
  19. 19. 2012年
  20. 20. BEASTの後継者か? BEASTと攻撃対象は似ていて中間者攻撃が可能な状態、Cookie等の秘 密情報を狙って取得使用しようとする攻撃 BEASTと異る点はCBCモードやストリーム暗号のRC4でも攻撃が可能 SSL圧縮で使われるdeflateが脆弱 対策 サーバサイド/クライアントサイド 1. SSL/TLS compressionの無効化、SPDYの圧縮機能の無効化 TLS1.3(ドラフト)では、これを受けて圧縮機能を廃止予定 21
  21. 21. 2013年 https://www.rc4nomore.com/ 22
  22. 22. RC4推奨のジレンマ、そしてLucky 13 以前よりRC4そのものに対する攻撃法は報告されていたが、SSLで使われ るRC4は安全と言われていたが、2013年に効果的な攻撃が報告された 2015年には「解読に2000時間かかっていたものが、75時間に短縮さ れた」と報告 Lucky 13はHMAC付きのCBCモードの脆弱性を利用した中間者攻撃。パデ ィングオラクル攻撃自体は2000年前後に示唆されていましたが、Lucky 13では実証に成功しました。(ただし、限定的な環境での実証) 対策 サーバサイド/クライアントサイド 1. RC4を無効化しCBCモードではなく、認証付き暗号利用モード(GCM/CCM)を利用 ただし、認証付き暗号利用モードはTLS1.2以降で実装 この辺りから雲行きが怪しくなってきた・・・ 23
  23. 23. パディングオラクル攻撃? 詳細は下記を参照 https://www.iacr.org/archive/eurocrypt2002/23320530/cbc 02_e02d.pdf
  24. 24. 2014年
  25. 25. SSL3.0が死んだ日 Lucky 13では限定的な環境でしかパディングオラクル攻撃の実証ができな かったが、POODLEについては、SSL3.0が有効になっている環境で容易に 実現できるという報告 中間者攻撃が可能な状況かつ、SSL3.0が有効な場合にパディングオラク ル攻撃が可能。これまでの脆弱性と違い、容易にパケットの改ざん、盗聴が 可能。TLS1.xを優先にしていてもダウングレード攻撃された場合に無力 対策 サーバサイド/クライアントサイド 1. SSL3.0を無効化する やったね!IE6がこれで完全に無くせるよ! と、思いきや・・・ 26
  26. 26. POODLE発表後・・・(2014年10月発表) SSL3.0で接続してきてるクライアントが一部居る・・・ 切る?切らない? 一部顧客からしばらく待って欲しいとの問い合わせが 切る?切られる? 本音としては今すぐ切りたい。切るべきだと思う。 でも、ビジネス上それがすぐに出来ない。 地道な努力・啓蒙活動 この時できる事 27
  27. 27. POODLEの時どうしたか 早い段階でのdeveloper環境でのSSL3.0無効化 ブラウザ側でのSSL3.0無効化の案内 本番環境でのSSL3.0接続状況のデイリー監視 接続数が0.1%を切ったらスケジュールを繰り上げる想定 接続元IPから顧客を割り出し、個別に移行の案内 顧客への繰り返しの説明と暫定対応について相談 proxy環境立てる提案 結果として移行スケジュール早められた ビジネス上すぐに対応できない場合は、 地道な活動をバランスよく行う必要があった 28
  28. 28. 2015年
  29. 29. FREAKそして、Logjam FREAK、Logjamともに中間者攻撃が行われている環境において、輸出グレ ード暗号にダウングレードしてデータの盗聴、改ざんが可能な状態にする攻 撃 FREAKは対策が容易:輸出グレード暗号については、暗号スイートの中 でも脆弱として位置付け、輸出グレード暗号を無効化すればOK LogjamはDH鍵交換の脆弱性。512bitは完全にアウトで無効化しやす いが、1024bitがグレーゾーンで議論が分かれる。 1. 大学研究機関規模の計算リソースがあれば 768bit 2. 国家規模の計算リソースがあれば 1024bit 現実的な計算可能範囲として指摘されている AWSとか使えば国家規模の計算リソースも 実現できるのかな・・・ 30
  30. 30. 実際にこんなお問い合わせも 国家規模のコンピュータリソース使われたら 個人情報が漏洩するから 2048bit以上に今すぐ対応してください! 31
  31. 31. 迫られる対応 DH2048bit対応すると起きる問題 DHを優先的に接続しようとするクライアントでは、1024bitまでしか対応 していないものもある(例えばJava6はかなり上位) レガシーな環境で開発されたAPIクライアントはJava6で作られてるもの は多い(推奨はしてない) 移行を促すのは促すとして、いきなり繋がらなくなるのはマズい ECDHEの有効化とDHの無効化 レガシークライアントはECDHEそもそもスイートに無いのでスキップされる 等価安全性の考え方からECDHE 256bitはDHの2048bit以上の強度 32
  32. 32. ECDH 『E』のメリット ~ Perfect forward secrecy~ 過去の通信の安全は保障されてますか? エドワード・スノーデン/NSA情報漏洩事件 Heartbleedによる秘密鍵漏洩のリスク 秘密鍵が漏洩した場合、過去の通信も解読出来てしまう可能性が Ephemeral : 一時的な鍵交換手法 セッションごとに一時的な鍵を生成し利用する 証明書の秘密鍵は、一時的な鍵に対しての署名に利用 秘密鍵が漏洩したとしても過去に遡って通信データ漏洩する事は無い 但しsession ticketの問題残る・・ やはりTLS1.3に期待か? 33
  33. 33. ここからが本題 SSLって『安全』に通信するための仕組みなのに なんだか脆弱性がたくさん報告されて怖いですよね。 これから先、『安全』を守れますか? 34
  34. 34. 2011年以降何が変わった? 2010年まで ムーアの法則 vs 暗号強度の話 対応の期限は予め決められていて猶予はあった 2011年以降 SSLの仕組みに脆弱性が見つかった 期限は『今すぐやるべき』ものばかり 35
  35. 35. どうしてこうなった? SSLは相互接続性を優先してきていた 1995年に作られたSSL3.0も2014年まで現役で生き続けた 1. 1995年はInternet Explorer 2が公開された年 相互接続性は安全性とのトレードオフ レガシーなプロトコルもサポート「できてしまう」 弱い暗号もレガシー環境のため・ユーザのための一声でサポートできる 36
  36. 36. 相互接続性優先の考えは脆弱である いくら強い暗号スイートを優先的に利用できるようにしていても 中間者攻撃、ダウングレード攻撃に対して無力 弱い暗号アルゴリズムの選択、バージョンダウンができてしまう これから先、安心して通信をサポートするためには 安全性の高いプロトコルバージョン、暗号スイート に限定する必要がある 37
  37. 37. 技術者が変えていかなければいけない どうやって?
  38. 38. これからどうするべきか TLS1.0はすでにレガシーなので捨てていかなければいけない PCI-DSSもTLS1.0捨てろと言っている TLS1.0は1999年に作られた TLS1.2が現段階で最新版のプロトコルバージョン 常時httpsの時代へ さらにSSLの重要性がましてくる 変化への対応が重要 1. TLS1.2も2008年に作られたもので結構限界がある 2. おそらく、もうすぐTLS1.2以前の問題点を解消したTLS1.3の仕様が固まる? 3. TLS1.3が出たらまた、TLS1.3への移行が推奨されると予測 39
  39. 39. TLS1.0捨てる? 以下のクライアントが繋がらなくなります Android4.3以前 IE 6 - XP IE 7 - Vista / IE8 -10 Win7(設定で繋がるようにする事はできる) Safari 6.0.4 / OS X 10.8.4 以前 Java6 Java7 OpenSSL 0.9.8 2018年6月30日までには、ほぼ確実に繋がらなくなる 40
  40. 40. エンジニアが正しい情報を伝達する 引用:http://www.jnsa.org/seminar/2013/0607/data/2E-3_pki_suga.pdf ここで止めてはいけない! この辺がレガシー要求してくる 可能性有り 41 マスメディア
  41. 41. サイクルを作りましょう 検証環 境を作る 移行を 促す 問題点 を洗い 出す 顧客に 説明す る 課題を 解決す る 本番環 境に適 用する 新しい問題 ここで諦めない ここでも諦めない 42
  42. 42. 通信の安全を守るために私達ができること 通信の安全を守るためにレガシーな環境は捨てていく 新しい問題への対処として変化に対応する これらの事を顧客まで正しい情報として届ける 43 例えばAWSを使うとか良い案
  43. 43. 強い気持ちを持って未来を変えていきましょう! ご清聴ありがとうございました 44

×