TLS/SSL 再ネゴシエーション 脆弱性

再ネゴシエーション (renegotiation) による中間者攻撃脆弱性問題

概要

2009年に、TLS v.1、SSL v.3 のハンドシェイク過程での脆弱性が発見され、TLS/SSLプロトコル更新の RFC 5746 が 2010年2月にリリースされました。
以降、ほとんどの関連サービス提供者はこの問題対策のパッチを提供済みです。それにもかかわらず、2011年 6月時点で、インターネット上でのTLS/SSLを使用したシステムの約半分がこのセキュリティホール対策のパッチを実装していませんでした。
この脆弱性は、HTTP、IMAP、SMTPを初めとする多くのTLS/SSLに依存するプロトコルに影響を与えます。

背景

TLS/SSLではサーバー、クライアントの双方から暗号化のパラメーターを更新するために再ネゴシエーション (renegotiation) 要求を行うことができます。
この機能は多くの場合、通信者双方が現在のTLS/SSL接続をより安全な暗号パラメータに変更して、接続を再開するために使われます。
しかし最初のハンドシェイクと再ネゴシエーションのプロセスには、「第三者が”Client Hello”を送ることができるため、クライアントのTLS/SSLセッションに第三者のデータを紛れ込ませることが可能で、サーバとクライアントのTLS/SSL通信をインターセプトできてしまう」という欠陥がありました。

以下は、典型的なhttps（TLS / SSL）ハンドシェイクプロセスの簡略化した説明です。

再ネゴシエーションによる中間者攻撃の脆弱性を利用して、攻撃者は、例えばクライアントの接続要求に応答したマシンにクライアントよりも先にTLS接続を形成することも、攻撃を実施するためにセッションの再ネゴシエーションを利用することもできます。
サーバ証明書とクライアント証明書を利用した相互の証明書ベースのクライアント認証接続であっても、再ネゴシエーションによる中間者攻撃を防ぎきれません。

対策

RFC5746でのTLS/SSLの仕様改定は、最初のハンドシェイクおよびセッション再開ハンドシェイクの両方に適用されます。

クライアントがServerHelloメッセージを受信した場合、クライアントはサーバーがrenegotiation_info拡張に対応しているかどうかをチェックしなければなりません。

RFC5746対応クライアントは、下位互換性のために安全でない再ネゴシエーション（renegotiation）を許可するように設定することも、再ネゴシエーションを許可しないように設定することも可能です。しかし、再ネゴシエーションをサポートしていないTLSサーバーもあるので、移行期間中は問題の完全な解決は望めません。
サーバー側の対応では、サーバーがrenegotiation_info拡張もSCSVも受け取らなかった場合、RFC5746によってsecure_renegotiationフラッグがFALSEに設定されます。
以降の再ネゴシエーション要求は、renegotiation_info拡張が空であっても、SCSVが指定されていても承認されません。

DigiCertがお勧めする対策