社内勉強会資料

1. プロフェッショナルSSL/TLS
7章
2017/8/21
光成滋生

2. • 歴史
• 1999年 TLS1.0の標準化
• 2006年, 2008年TLS1.1, TLS1.2がリリース
• しかしTLS1.0が使い続けられる
• 2009年安全でない再ネゴシエーション
• 2011年BEAST
• 2012年CRIME, Lucky13, RC4, TIME
• 2013年BREACH
• 2014年トリプルハンドシェイク, POODLE
プロトコルに対する攻撃
2 / 16

3. • サーバが相手を検証していないのでMITM攻撃可能
p.183 図7.1
安全でない再ネゴシエーション
クライアント 攻撃者 サーバ
ハンドシェイクを
リクエスト
停止
ハンドシェイクをリクエスト
完了
攻撃HTTPリクエスト
GET /attacked.jsp HTTP/1.0
Dummy:
中身はそのまま
ハンドシェイク再開
GET /index.jsp HTTP/1.0
Cookie: ...
HTTPリクエスト
GET /attacked.jsp HTTP/1.0
Cookie: ...
改竄されたリクエストに対する
HTTPレスポンス
+
=
3 / 16

4. • 多くのサーバはクライアントによる
再ネゴシエーションを許容していた
• クライアント証明書に対応しているサイト
再ネゴシエーションを引き起こす
4 / 16

5. • 犠牲者の認証情報（クレデンシャル）を利用
• CSRFに似ているので多くのサイトは対策済みだった
• 重要性を見過ごす
任意のGETリクエストの実行
GET /path/to/resource HTTP/1.0
X-Ignore: GET /index.html HTTP/1.0
Cookie: JSESSIONID=...
5 / 16

6. • 犠牲者のtweetを自分のtweetとして送信
クレデンシャル泥棒
POST /statuses/update.xml HTTP.10
Authorization: Basic [攻撃者のクレデンシャル]
Content-Type: application/x-www-form-urlencoded
Content-Length: [適当な長さ]
status=POST /statutses/update.xml HTTP/1.1
Authorizaiotn: Basic [犠牲者のクレデンシャル]
...
6 / 16

7. • 標的サイトにリダイレクト対応リソースがあると
• オープンリダイレクト：任意のURLにリダイレクト
• これがあるとtarget.comをmytarget.comに誘導できる
• 平文HTTPにダウングレードさせる
• 307を返すリダイレクト（一時的リダイレクト）
• POSTはPOSTのままリダイレクト
• 攻撃者が暗号化されたデータを取得できる
• 標的サイトのアカウントを持たなくても攻撃可能
• その他の影響
• 概念実証ツールは結構ある
• 犠牲者が、あるサーバを攻撃しているように見せかける
リダイレクト
7 / 16

8. • 時間軸（p.190 図7.2）
• プロトコルの修正6カ月
• ライブラリとOSの修正12カ月
• みながパッチを適用24カ月
修正にかかる時間
2009 2010 2011
最初の発見
RFCドラフト
Opera
OpenSSL
RedHat
NSS
Mozilla/GnuTLS
Microsoft
JRE
Ubuntu
Debian
8 / 16

9. • 予測可能なIVの安全性
• 1995年Rogaway：IVが攻撃者に予測不能であることは不可欠
• 2006年TLS1.1で無作為なIVを利用
• 2011年Duong, Rizzo
• IVが予測可能なときCBCはECBなみに弱くなる
• HTTPのセッション情報はCookie:のうしろにある短いバイト列
• 15byteの平文と1byteの機微情報を1ブロックにできるなら256
回のテストで推測可能
BEAST
9 / 16

10. • 秘密データを圧縮するときのデータサイズを利用
• 2002年Kelsey：ブラウザ向けの現実的ではない攻撃
• 2012年CRIME
• 2013年TIME, BREACH
• パディングオラクル攻撃
• 2001年Vaudenay
• 2003年Canvel OpenSSLへの攻撃
• 2013年Lucky13
• RC4への攻撃, POODLE
• 既にやったので省略
圧縮サイドチャネル攻撃
10 / 16

11. • 安全でなかった再ネゴシエーションの修正版
• ハンドシェイクのFinishedにverify_dataを入れる
• 再ネゴシエーション時にその値をチェックする
• TLSの2個の弱点を利用してこの方式を攻撃
• 要件
• クライアント証明書を使っているサイト
• 悪意あるサーバに犠牲者を呼び込む
• 対策
• 再ネゴシエーションを無効にする
• ECDHEのみを利用する
トリプルハンドシェイク攻撃（2014年）
11 / 16

12. • TLSのマスターシークレット𝑚𝑠𝑘の生成手順
• clientがプリマスター鍵𝑘 𝑝𝑚と乱数𝑟𝑐を生成しserverに送信
• serverの公開鍵を使って暗号化する
• serverは乱数𝑟𝑠を生成しclientに送信
• client, serveが(𝑘 𝑝𝑚, 𝑟𝑐, 𝑟𝑠)から𝑚𝑠𝑘を生成
• ここにMITMで介在する
鍵生成手順
12 / 16

13. • 悪意あるサーバに犠牲者を誘導する(p.224図7.8)
未知の鍵の共有
ClientHello
クライアント 攻撃者 サーバ
ClientHello
ServerHello
Certificate
Certificate
ServerHelloDone
ClientKeyExchange
ClientKeyExchange
ChangeCipherSpec
Finished
Finished
ChangeCipherSpec
Finished
Finished
𝑝𝑚𝑘を自分の秘密鍵で
復号してserverに転送
serverの乱数を受信し
clientに転送
同じパラメータのTLS
接続が2個できる
13 / 16

14. • ステップ2 完全同期
• 現状
• 鍵パラメータは同じ
• サーバ証明書が異なるのでverify_dataが異なる
• セッションリザンプション
• フルハンドシェイクは重たいので出来るだけ省略したい
• SessionIDを用いて再開
• セッション再開時には認証がない
• 接続再開時に共有した鍵パラメータを使うことで
ハンドシェイク完了時に両接続のFinishedメッセージが同じ
• ステップ3 なりすまし
• 攻撃者は2個の接続を完全に制御可能
続き
14 / 16

15. • 原因
• CBCブロックのパディング部分が保護されない
• SSL3.0ではパディングに何が入っていてもよかった
• 暗号化されているので直接解読はできないがパディングの長
さがたまたまあうように攻撃し続ければよかった
• TLS1.0では固定された
POODLE
H e l l o w o r l d ! ? ? ? 3
H e l l o w o r l d ! 3 3 3 3
SSL3.0
TLS1.0
パディング 長さ
15 / 16

16. • 擬似乱数生成アルゴリズム
• 2007年NSAによるバックドアの可能性が指摘される
• 2012年NISTは非推奨に
• 2014年再度バックドアの可能性が指摘される
• 証拠はない
Dual EC DRBG
16 / 16