http://secnight.connpass.com/event/30672/ http://togetter.com/li/974201 シャノン技術ブログ http://shanon-tech.blogspot.jp/

1. 通信の安全を守るためにエンジニアが
できること
株式会社シャノン
藤倉 和明

2. 自己紹介
藤倉 和明 （ふじくら かずあき）
株式会社シャノン 所属
インフラチームマネージャー
兼 情報セキュリティ管理者
兼 情報システム部門長的な何か
共著ですが本書いたことも有ります
@fujya
2

3. 本日はこれについて
3

4. こういうの出てくると
サイトに繋がら
ないんですけど
API連携エラー
が出てるけど何
があったの？
今すぐなん
とかしろ！
ツライですよね・・・
フィッシングサイ
トですか？
4

5. そもそも何のためにあるの？
User
Internet
WebServer
盗聴
改ざん
インターネット上での通信は盗聴や
改ざんのリスクが常に伴う
5

6. そもそも何のためにあるの？
User
Internet
WebServer
盗聴
改ざん
暗号化通信する事で悪意のある第
三者からの盗聴、改ざんを防止
6

7. そもそも何のためにあるの？
User
Internet
WebServer
正規のサイト実在証明
フィッシング
サイト
7

8. SSLはインターネット上で大事な情報を守るための必要な仕組み
「盗聴」
「改ざん」
「なりすまし」
あなたの大事なデータを守る大事な仕組み
SSLで防ぐ３つのリスク
8

10. 大事な仕組み
でも色々と苦労はつきまとう
10

11. あらためて今日話す事
ここ10年ぐらいのSSL関連のツラミ
どう対応してきたか
これからどうしていくのか
11
実装の問題（openssl等）
認証局の問題は今回は対象外

12. 暗号アルゴリズムにおける2010年問題
https://jp.globalsign.com/service/ssl/knowledge/1024bit.html より
2005年頃にNISTが発表したガイドライン
SSLでよく使われているRSA(鍵長1024bit)も対象に含まれている
12

13. どうやって乗り越えていったか
証明局
2048bitのルート証明書の配布
後方互換の為のクロスルート証明書の配布
1024bit -> 2048bitへの無償アップグレード
マイクロソフト社をはじめとする各社
OS/ライブラリのアップデート時に2048bitのルート証明書のインストール
2013年ごろに1024bit証明書の接続拒否の対応
サービスベンダ（シャノン）
2010～2011年以降「特別な理由がない限り」2048bitの証明書を推奨
クロスルート証明書の設置、検証
ユーザへの根気強い説明

14. 5年間という期間をかけてゆるやかな移行ができた
業界一丸となってWebの安全を守った
翌年以降はどうだったか？
年次ごとにインシデントを見ていきましょう
14

15. 2011年

16. 人々を混乱に陥れたBEAST
2011年頃では多く使われていたSSL3.0/TLS1.0が対象
ブロック暗号のCBCモードに対して選択平文攻撃を行うことでブラウザ内の
Cookieを入手するツールが公開された
対策
サーバサイド
1. SSL3.0/TLS1.0を利用せずTLS1.1/TLS1.2を利用する
2. ブロック暗号ではなく、ストリーム暗号（RC4）を利用する
クライアントサイド
1. ブラウザのアップグレード
2. 信頼できるネットワークを利用する（MITMの回避）
16

17. 選択平文攻撃？
攻撃者が選択したある平文を何らかの方法で正規のユーザー
に暗号化させ、元の平文と得られた暗号文から暗号鍵を推測
し、同じ暗号鍵を用いて作られた暗号を解読しようとすること
BEAST攻撃では、暗号鍵の推測が目的ではなく、暗号文から
平文を推測する。つまりCookieの取得が目的になります。
CBCモードで16byte毎に区切られる（解読不能）
解読する対象を1byteに絞り 256パターンで解読できるようにする
1byte毎解読していきCookieを取得する

18. BEAST攻撃が流行っていた時のあるある
御社のサービスはBEAST攻撃に対し
て脆弱性があるので対応してください
TLS1.1～1.2のみにすると9割ぐらい
のブラウザ繋がらなくなります。
RC4はRC4で強度が低い問題が・・・
御社は脆弱性を放置するのですか？
TLS1.2 onlyにすると9割ぐらいのクラ
イアントが繋がらなくなる可能性があり
ますが・・・・
それは困る！みんなが繋がるように脆
弱性の対応してください！ 無理ゲー・・・
18

19. ・対応するリスク
・対応しないリスク
どちらのリスクを『受容』するか顧客に促す
BEASTについては対応しないリスクを説明し『受容』してもらう
根気よく説明、リスクの『受容』を促す
BEASTはかなり限定的な条件、ブラウザの不具合・脆弱性を組み合わせ
て実現できる攻撃手法であり、通常の環境で成功する事は難しい
ブラウザの対応は早く、アップデートしていればリスクはかなり下げられた
プロトコルのバージョンアップは繋がらなくなるリスクもある
19

20. 2012年

21. BEASTの後継者か？
BEASTと攻撃対象は似ていて中間者攻撃が可能な状態、Cookie等の秘
密情報を狙って取得使用しようとする攻撃
BEASTと異る点はCBCモードやストリーム暗号のRC4でも攻撃が可能
SSL圧縮で使われるdeflateが脆弱
対策
サーバサイド/クライアントサイド
1. SSL/TLS compressionの無効化、SPDYの圧縮機能の無効化
TLS1.3(ドラフト）では、これを受けて圧縮機能を廃止予定
21

22. 2013年
https://www.rc4nomore.com/
22

23. 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

24. パディングオラクル攻撃？
詳細は下記を参照
https://www.iacr.org/archive/eurocrypt2002/23320530/cbc
02_e02d.pdf

25. 2014年

26. SSL3.0が死んだ日
Lucky 13では限定的な環境でしかパディングオラクル攻撃の実証ができな
かったが、POODLEについては、SSL3.0が有効になっている環境で容易に
実現できるという報告
中間者攻撃が可能な状況かつ、SSL3.0が有効な場合にパディングオラク
ル攻撃が可能。これまでの脆弱性と違い、容易にパケットの改ざん、盗聴が
可能。TLS1.xを優先にしていてもダウングレード攻撃された場合に無力
対策
サーバサイド/クライアントサイド
1. SSL3.0を無効化する
やったね！IE6がこれで完全に無くせるよ！
と、思いきや・・・
26

27. POODLE発表後・・・（2014年10月発表）
SSL3.0で接続してきてるクライアントが一部居る・・・
切る？切らない？
一部顧客からしばらく待って欲しいとの問い合わせが
切る？切られる？
本音としては今すぐ切りたい。切るべきだと思う。
でも、ビジネス上それがすぐに出来ない。
地道な努力・啓蒙活動
この時できる事
27

28. POODLEの時どうしたか
早い段階でのdeveloper環境でのSSL3.0無効化
ブラウザ側でのSSL3.0無効化の案内
本番環境でのSSL3.0接続状況のデイリー監視
接続数が0.1%を切ったらスケジュールを繰り上げる想定
接続元IPから顧客を割り出し、個別に移行の案内
顧客への繰り返しの説明と暫定対応について相談
proxy環境立てる提案
結果として移行スケジュール早められた
ビジネス上すぐに対応できない場合は、
地道な活動をバランスよく行う必要があった
28

29. 2015年

30. FREAKそして、Logjam
FREAK、Logjamともに中間者攻撃が行われている環境において、輸出グレ
ード暗号にダウングレードしてデータの盗聴、改ざんが可能な状態にする攻
撃
FREAKは対策が容易：輸出グレード暗号については、暗号スイートの中
でも脆弱として位置付け、輸出グレード暗号を無効化すればOK
LogjamはDH鍵交換の脆弱性。512bitは完全にアウトで無効化しやす
いが、1024bitがグレーゾーンで議論が分かれる。
1. 大学研究機関規模の計算リソースがあれば 768bit
2. 国家規模の計算リソースがあれば 1024bit
現実的な計算可能範囲として指摘されている
AWSとか使えば国家規模の計算リソースも
実現できるのかな・・・
30

31. 実際にこんなお問い合わせも
国家規模のコンピュータリソース使われたら
個人情報が漏洩するから
2048bit以上に今すぐ対応してください！
31

32. 迫られる対応
DH2048bit対応すると起きる問題
DHを優先的に接続しようとするクライアントでは、1024bitまでしか対応
していないものもある（例えばJava6はかなり上位）
レガシーな環境で開発されたAPIクライアントはJava6で作られてるもの
は多い（推奨はしてない）
移行を促すのは促すとして、いきなり繋がらなくなるのはマズい
ECDHEの有効化とDHの無効化
レガシークライアントはECDHEそもそもスイートに無いのでスキップされる
等価安全性の考え方からECDHE 256bitはDHの2048bit以上の強度
32

33. ECDH 『E』のメリット ～ Perfect forward secrecy～
過去の通信の安全は保障されてますか？
エドワード・スノーデン/NSA情報漏洩事件
Heartbleedによる秘密鍵漏洩のリスク
秘密鍵が漏洩した場合、過去の通信も解読出来てしまう可能性が
Ephemeral ： 一時的な鍵交換手法
セッションごとに一時的な鍵を生成し利用する
証明書の秘密鍵は、一時的な鍵に対しての署名に利用
秘密鍵が漏洩したとしても過去に遡って通信データ漏洩する事は無い
但しsession ticketの問題残る・・
やはりTLS1.3に期待か？
33

34. ここからが本題
SSLって『安全』に通信するための仕組みなのに
なんだか脆弱性がたくさん報告されて怖いですよね。
これから先、『安全』を守れますか？
34

35. 2011年以降何が変わった？
2010年まで
ムーアの法則 vs 暗号強度の話
対応の期限は予め決められていて猶予はあった
2011年以降
SSLの仕組みに脆弱性が見つかった
期限は『今すぐやるべき』ものばかり
35

36. どうしてこうなった？
SSLは相互接続性を優先してきていた
1995年に作られたSSL3.0も2014年まで現役で生き続けた
1. 1995年はInternet Explorer 2が公開された年
相互接続性は安全性とのトレードオフ
レガシーなプロトコルもサポート「できてしまう」
弱い暗号もレガシー環境のため・ユーザのための一声でサポートできる
36

37. 相互接続性優先の考えは脆弱である
いくら強い暗号スイートを優先的に利用できるようにしていても
中間者攻撃、ダウングレード攻撃に対して無力
弱い暗号アルゴリズムの選択、バージョンダウンができてしまう
これから先、安心して通信をサポートするためには
安全性の高いプロトコルバージョン、暗号スイート
に限定する必要がある
37

38. 技術者が変えていかなければいけない
どうやって？

39. これからどうするべきか
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

40. 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

41. エンジニアが正しい情報を伝達する
引用：http://www.jnsa.org/seminar/2013/0607/data/2E-3_pki_suga.pdf
ここで止めてはいけない！
この辺がレガシー要求してくる
可能性有り
41
マスメディア

42. サイクルを作りましょう
検証環
境を作る
移行を
促す
問題点
を洗い
出す
顧客に
説明す
る
課題を
解決す
る
本番環
境に適
用する
新しい問題
ここで諦めない
ここでも諦めない
42

43. 通信の安全を守るために私達ができること
通信の安全を守るためにレガシーな環境は捨てていく
新しい問題への対処として変化に対応する
これらの事を顧客まで正しい情報として届ける
43
例えばAWSを使うとか良い案

44. 強い気持ちを持って未来を変えていきましょう！
ご清聴ありがとうございました
44