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.
プロフェッショナルSSL/TLS
7章
2017/8/21
光成滋生
• 歴史
• 1999年 TLS1.0の標準化
• 2006年, 2008年TLS1.1, TLS1.2がリリース
• しかしTLS1.0が使い続けられる
• 2009年安全でない再ネゴシエーション
• 2011年BEAST
• 2012年CR...
• サーバが相手を検証していないのでMITM攻撃可能
p.183 図7.1
安全でない再ネゴシエーション
クライアント 攻撃者 サーバ
ハンドシェイクを
リクエスト
停止
ハンドシェイクをリクエスト
完了
攻撃HTTPリクエスト
GET /at...
• 多くのサーバはクライアントによる
再ネゴシエーションを許容していた
• クライアント証明書に対応しているサイト
再ネゴシエーションを引き起こす
4 / 16
• 犠牲者の認証情報(クレデンシャル)を利用
• CSRFに似ているので多くのサイトは対策済みだった
• 重要性を見過ごす
任意のGETリクエストの実行
GET /path/to/resource HTTP/1.0
X-Ignore: GET ...
• 犠牲者のtweetを自分のtweetとして送信
クレデンシャル泥棒
POST /statuses/update.xml HTTP.10
Authorization: Basic [攻撃者のクレデンシャル]
Content-Type: app...
• 標的サイトにリダイレクト対応リソースがあると
• オープンリダイレクト:任意のURLにリダイレクト
• これがあるとtarget.comをmytarget.comに誘導できる
• 平文HTTPにダウングレードさせる
• 307を返すリダイレ...
• 時間軸(p.190 図7.2)
• プロトコルの修正6カ月
• ライブラリとOSの修正12カ月
• みながパッチを適用24カ月
修正にかかる時間
2009 2010 2011
最初の発見
RFCドラフト
Opera
OpenSSL
RedH...
• 予測可能なIVの安全性
• 1995年Rogaway:IVが攻撃者に予測不能であることは不可欠
• 2006年TLS1.1で無作為なIVを利用
• 2011年Duong, Rizzo
• IVが予測可能なときCBCはECBなみに弱くなる
•...
• 秘密データを圧縮するときのデータサイズを利用
• 2002年Kelsey:ブラウザ向けの現実的ではない攻撃
• 2012年CRIME
• 2013年TIME, BREACH
• パディングオラクル攻撃
• 2001年Vaudenay
• 2...
• 安全でなかった再ネゴシエーションの修正版
• ハンドシェイクのFinishedにverify_dataを入れる
• 再ネゴシエーション時にその値をチェックする
• TLSの2個の弱点を利用してこの方式を攻撃
• 要件
• クライアント証明書...
• TLSのマスターシークレット𝑚𝑠𝑘の生成手順
• clientがプリマスター鍵𝑘 𝑝𝑚と乱数𝑟𝑐を生成しserverに送信
• serverの公開鍵を使って暗号化する
• serverは乱数𝑟𝑠を生成しclientに送信
• client,...
• 悪意あるサーバに犠牲者を誘導する(p.224図7.8)
未知の鍵の共有
ClientHello
クライアント 攻撃者 サーバ
ClientHello
ServerHello
Certificate
Certificate
ServerHel...
• ステップ2 完全同期
• 現状
• 鍵パラメータは同じ
• サーバ証明書が異なるのでverify_dataが異なる
• セッションリザンプション
• フルハンドシェイクは重たいので出来るだけ省略したい
• SessionIDを用いて再開
•...
• 原因
• CBCブロックのパディング部分が保護されない
• SSL3.0ではパディングに何が入っていてもよかった
• 暗号化されているので直接解読はできないがパディングの長
さがたまたまあうように攻撃し続ければよかった
• TLS1.0では...
• 擬似乱数生成アルゴリズム
• 2007年NSAによるバックドアの可能性が指摘される
• 2012年NISTは非推奨に
• 2014年再度バックドアの可能性が指摘される
• 証拠はない
Dual EC DRBG
16 / 16
Upcoming SlideShare
Loading in …5
×

プロフェッショナルSSL/TLS 7章

976 views

Published on

社内勉強会資料

Published in: Technology
  • Be the first to comment

プロフェッショナルSSL/TLS 7章

  1. 1. プロフェッショナルSSL/TLS 7章 2017/8/21 光成滋生
  2. 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. 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. • 多くのサーバはクライアントによる 再ネゴシエーションを許容していた • クライアント証明書に対応しているサイト 再ネゴシエーションを引き起こす 4 / 16
  5. 5. • 犠牲者の認証情報(クレデンシャル)を利用 • CSRFに似ているので多くのサイトは対策済みだった • 重要性を見過ごす 任意のGETリクエストの実行 GET /path/to/resource HTTP/1.0 X-Ignore: GET /index.html HTTP/1.0 Cookie: JSESSIONID=... 5 / 16
  6. 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. 7. • 標的サイトにリダイレクト対応リソースがあると • オープンリダイレクト:任意のURLにリダイレクト • これがあるとtarget.comをmytarget.comに誘導できる • 平文HTTPにダウングレードさせる • 307を返すリダイレクト(一時的リダイレクト) • POSTはPOSTのままリダイレクト • 攻撃者が暗号化されたデータを取得できる • 標的サイトのアカウントを持たなくても攻撃可能 • その他の影響 • 概念実証ツールは結構ある • 犠牲者が、あるサーバを攻撃しているように見せかける リダイレクト 7 / 16
  8. 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. 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. 10. • 秘密データを圧縮するときのデータサイズを利用 • 2002年Kelsey:ブラウザ向けの現実的ではない攻撃 • 2012年CRIME • 2013年TIME, BREACH • パディングオラクル攻撃 • 2001年Vaudenay • 2003年Canvel OpenSSLへの攻撃 • 2013年Lucky13 • RC4への攻撃, POODLE • 既にやったので省略 圧縮サイドチャネル攻撃 10 / 16
  11. 11. • 安全でなかった再ネゴシエーションの修正版 • ハンドシェイクのFinishedにverify_dataを入れる • 再ネゴシエーション時にその値をチェックする • TLSの2個の弱点を利用してこの方式を攻撃 • 要件 • クライアント証明書を使っているサイト • 悪意あるサーバに犠牲者を呼び込む • 対策 • 再ネゴシエーションを無効にする • ECDHEのみを利用する トリプルハンドシェイク攻撃(2014年) 11 / 16
  12. 12. • TLSのマスターシークレット𝑚𝑠𝑘の生成手順 • clientがプリマスター鍵𝑘 𝑝𝑚と乱数𝑟𝑐を生成しserverに送信 • serverの公開鍵を使って暗号化する • serverは乱数𝑟𝑠を生成しclientに送信 • client, serveが(𝑘 𝑝𝑚, 𝑟𝑐, 𝑟𝑠)から𝑚𝑠𝑘を生成 • ここにMITMで介在する 鍵生成手順 12 / 16
  13. 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. 14. • ステップ2 完全同期 • 現状 • 鍵パラメータは同じ • サーバ証明書が異なるのでverify_dataが異なる • セッションリザンプション • フルハンドシェイクは重たいので出来るだけ省略したい • SessionIDを用いて再開 • セッション再開時には認証がない • 接続再開時に共有した鍵パラメータを使うことで ハンドシェイク完了時に両接続のFinishedメッセージが同じ • ステップ3 なりすまし • 攻撃者は2個の接続を完全に制御可能 続き 14 / 16
  15. 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. 16. • 擬似乱数生成アルゴリズム • 2007年NSAによるバックドアの可能性が指摘される • 2012年NISTは非推奨に • 2014年再度バックドアの可能性が指摘される • 証拠はない Dual EC DRBG 16 / 16

×