More Related Content
What's hot
What's hot (20)
More from MITSUNARI Shigeo
More from MITSUNARI Shigeo (20)
Recently uploaded
Recently uploaded (9)
プロフェッショナルSSL/TLS 7章
- 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
- 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