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

株式会社シャノン

藤倉 和明

自己紹介

藤倉 和明 （ふじくら かずあき）

株式会社シャノン 所属

インフラチームマネージャー

兼 情報セキュリティ管理者

兼 情報システム部門長的な何か

共著ですが本書いたことも有ります

@fujya

2

本日はこれについて

3

こういうの出てくると

サイトに繋がらないんですけど

API連携エラーが出てるけど何があったの？

今すぐなんとかしろ！

ツライですよね・・・

フィッシングサイトですか？

4

そもそも何のためにあるの？

User Internet

WebServer

盗聴

改ざん

インターネット上での通信は盗聴や改ざんのリスクが常に伴う

5

そもそも何のためにあるの？

User Internet

WebServer

盗聴

改ざん

暗号化通信する事で悪意のある第三者からの盗聴、改ざんを防止

6

そもそも何のためにあるの？

User Internet

WebServer

正規のサイト実在証明

フィッシングサイト

7

SSLはインターネット上で大事な情報を守るための必要な仕組み

「盗聴」

「改ざん」

「なりすまし」 あなたの大事なデータを守る大事な仕組み

SSLで防ぐ３つのリスク

8

大事な仕組み

でも色々と苦労はつきまとう

10

あらためて今日話す事

ここ10年ぐらいのSSL関連のツラミ

どう対応してきたか

これからどうしていくのか

11

実装の問題（openssl等） 認証局の問題は今回は対象外

暗号アルゴリズムにおける2010年問題

https://jp.globalsign.com/service/ssl/knowledge/1024bit.html より

2005年頃にNISTが発表したガイドライン

SSLでよく使われているRSA(鍵長1024bit)も対象に含まれている

12

どうやって乗り越えていったか

証明局

2048bitのルート証明書の配布

後方互換の為のクロスルート証明書の配布

1024bit -> 2048bitへの無償アップグレード

マイクロソフト社をはじめとする各社

OS/ライブラリのアップデート時に2048bitのルート証明書のインストール

2013年ごろに1024bit証明書の接続拒否の対応

サービスベンダ（シャノン）

2010～2011年以降「特別な理由がない限り」2048bitの証明書を推奨

クロスルート証明書の設置、検証

ユーザへの根気強い説明

5年間という期間をかけてゆるやかな移行ができた

業界一丸となってWebの安全を守った

翌年以降はどうだったか？

年次ごとにインシデントを見ていきましょう

14

2011年

人々を混乱に陥れたBEAST

2011年頃では多く使われていたSSL3.0/TLS1.0が対象

ブロック暗号のCBCモードに対して選択平文攻撃を行うことでブラウザ内のCookieを入手するツールが公開された

対策

サーバサイド

1. SSL3.0/TLS1.0を利用せずTLS1.1/TLS1.2を利用する

2. ブロック暗号ではなく、ストリーム暗号（RC4）を利用する

クライアントサイド

1. ブラウザのアップグレード

2. 信頼できるネットワークを利用する（MITMの回避）

16

選択平文攻撃？

攻撃者が選択したある平文を何らかの方法で正規のユーザーに暗号化させ、元の平文と得られた暗号文から暗号鍵を推測し、同じ暗号鍵を用いて作られた暗号を解読しようとすること

BEAST攻撃では、暗号鍵の推測が目的ではなく、暗号文から平文を推測する。つまりCookieの取得が目的になります。

CBCモードで16byte毎に区切られる（解読不能）

解読する対象を1byteに絞り 256パターンで解読できるようにする

1byte毎解読していきCookieを取得する

BEAST攻撃が流行っていた時のあるある

御社のサービスはBEAST攻撃に対して脆弱性があるので対応してください

TLS1.1～1.2のみにすると9割ぐらいのブラウザ繋がらなくなります。

RC4はRC4で強度が低い問題が・・・

御社は脆弱性を放置するのですか？

TLS1.2 onlyにすると9割ぐらいのクラ

イアントが繋がらなくなる可能性がありますが・・・・

それは困る！みんなが繋がるように脆弱性の対応してください！ 無理ゲー・・・

18

・対応するリスク

・対応しないリスク

どちらのリスクを『受容』するか顧客に促す

BEASTについては対応しないリスクを説明し『受容』してもらう

根気よく説明、リスクの『受容』を促す

BEASTはかなり限定的な条件、ブラウザの不具合・脆弱性を組み合わせ

て実現できる攻撃手法であり、通常の環境で成功する事は難しい

ブラウザの対応は早く、アップデートしていればリスクはかなり下げられた

プロトコルのバージョンアップは繋がらなくなるリスクもある

19

2012年

BEASTの後継者か？

BEASTと攻撃対象は似ていて中間者攻撃が可能な状態、Cookie等の秘密情報を狙って取得使用しようとする攻撃

BEASTと異る点はCBCモードやストリーム暗号のRC4でも攻撃が可能

SSL圧縮で使われるdeflateが脆弱

対策

サーバサイド/クライアントサイド

1. SSL/TLS compressionの無効化、SPDYの圧縮機能の無効化

TLS1.3(ドラフト）では、これを受けて圧縮機能を廃止予定

21

2013年

https://www.rc4nomore.com/

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

パディングオラクル攻撃？

詳細は下記を参照

https://www.iacr.org/archive/eurocrypt2002/23320530/cbc

02_e02d.pdf

2014年

SSL3.0が死んだ日

Lucky 13では限定的な環境でしかパディングオラクル攻撃の実証ができなかったが、POODLEについては、SSL3.0が有効になっている環境で容易に実現できるという報告

中間者攻撃が可能な状況かつ、SSL3.0が有効な場合にパディングオラクル攻撃が可能。これまでの脆弱性と違い、容易にパケットの改ざん、盗聴が可能。TLS1.xを優先にしていてもダウングレード攻撃された場合に無力

対策

サーバサイド/クライアントサイド

1. SSL3.0を無効化する

やったね！IE6がこれで完全に無くせるよ！

と、思いきや・・・

26

POODLE発表後・・・（2014年10月発表）

SSL3.0で接続してきてるクライアントが一部居る・・・

切る？切らない？

一部顧客からしばらく待って欲しいとの問い合わせが

切る？切られる？

本音としては今すぐ切りたい。切るべきだと思う。

でも、ビジネス上それがすぐに出来ない。

地道な努力・啓蒙活動

この時できる事

27

POODLEの時どうしたか

早い段階でのdeveloper環境でのSSL3.0無効化

ブラウザ側でのSSL3.0無効化の案内

本番環境でのSSL3.0接続状況のデイリー監視

接続数が0.1%を切ったらスケジュールを繰り上げる想定

接続元IPから顧客を割り出し、個別に移行の案内

顧客への繰り返しの説明と暫定対応について相談

proxy環境立てる提案

結果として移行スケジュール早められた

ビジネス上すぐに対応できない場合は、

地道な活動をバランスよく行う必要があった

28

2015年

FREAKそして、Logjam

FREAK、Logjamともに中間者攻撃が行われている環境において、輸出グレード暗号にダウングレードしてデータの盗聴、改ざんが可能な状態にする攻撃

FREAKは対策が容易：輸出グレード暗号については、暗号スイートの中でも脆弱として位置付け、輸出グレード暗号を無効化すればOK

LogjamはDH鍵交換の脆弱性。512bitは完全にアウトで無効化しやすいが、1024bitがグレーゾーンで議論が分かれる。

1. 大学研究機関規模の計算リソースがあれば 768bit

2. 国家規模の計算リソースがあれば 1024bit

現実的な計算可能範囲として指摘されている

AWSとか使えば国家規模の計算リソースも実現できるのかな・・・

30

実際にこんなお問い合わせも

国家規模のコンピュータリソース使われたら個人情報が漏洩するから

2048bit以上に今すぐ対応してください！

31

迫られる対応

DH2048bit対応すると起きる問題

DHを優先的に接続しようとするクライアントでは、1024bitまでしか対応していないものもある（例えばJava6はかなり上位）

レガシーな環境で開発されたAPIクライアントはJava6で作られてるものは多い（推奨はしてない）

移行を促すのは促すとして、いきなり繋がらなくなるのはマズい

ECDHEの有効化とDHの無効化

レガシークライアントはECDHEそもそもスイートに無いのでスキップされる

等価安全性の考え方からECDHE 256bitはDHの2048bit以上の強度

32

ECDH 『E』のメリット ～ Perfect forward secrecy～

過去の通信の安全は保障されてますか？

エドワード・スノーデン/NSA情報漏洩事件

Heartbleedによる秘密鍵漏洩のリスク

秘密鍵が漏洩した場合、過去の通信も解読出来てしまう可能性が

Ephemeral ： 一時的な鍵交換手法

セッションごとに一時的な鍵を生成し利用する

証明書の秘密鍵は、一時的な鍵に対しての署名に利用

秘密鍵が漏洩したとしても過去に遡って通信データ漏洩する事は無い

但しsession ticketの問題残る・・やはりTLS1.3に期待か？

33

ここからが本題

SSLって『安全』に通信するための仕組みなのに

なんだか脆弱性がたくさん報告されて怖いですよね。

これから先、『安全』を守れますか？

34

2011年以降何が変わった？

2010年まで

ムーアの法則 vs 暗号強度の話

対応の期限は予め決められていて猶予はあった

2011年以降

SSLの仕組みに脆弱性が見つかった

期限は『今すぐやるべき』ものばかり

35

どうしてこうなった？

SSLは相互接続性を優先してきていた

1995年に作られたSSL3.0も2014年まで現役で生き続けた

1. 1995年はInternet Explorer 2が公開された年

相互接続性は安全性とのトレードオフ

レガシーなプロトコルもサポート「できてしまう」

弱い暗号もレガシー環境のため・ユーザのための一声でサポートできる

36

相互接続性優先の考えは脆弱である

いくら強い暗号スイートを優先的に利用できるようにしていても

中間者攻撃、ダウングレード攻撃に対して無力

弱い暗号アルゴリズムの選択、バージョンダウンができてしまう

これから先、安心して通信をサポートするためには

安全性の高いプロトコルバージョン、暗号スイートに限定する必要がある

37

技術者が変えていかなければいけない

どうやって？

これからどうするべきか

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

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

エンジニアが正しい情報を伝達する

引用：http://www.jnsa.org/seminar/2013/0607/data/2E-3_pki_suga.pdf

ここで止めてはいけない！ この辺がレガシー要求してくる可能性有り

41

マスメディア

サイクルを作りましょう

検証環境を作る

移行を促す

問題点を洗い出す

顧客に説明する

課題を解決する

本番環境に適用する

新しい問題

ここで諦めない

ここでも諦めない

42

通信の安全を守るために私達ができること

通信の安全を守るためにレガシーな環境は捨てていく

新しい問題への対処として変化に対応する

これらの事を顧客まで正しい情報として届ける

43

例えばAWSを使うとか良い案

強い気持ちを持って未来を変えていきましょう！

ご清聴ありがとうございました

44