SSL・EV SSL サーバー証明書 サポート

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に依存するプロトコルに影響を与えます。

SSL Plus/1年あたり64,790円から
DigiCert(デジサート)企業認証SSL/TLS スマホ対応 リーズナブルな価格でご提供

背景

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

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

  1. Helloメッセージ

    • Hello Request
      サーバーからクライアントにClient Helloを送るように要求
    • Client Hello
      クライアントは自分が利用可能なTLS/SSLのバージョン、暗号方式やデータの圧縮方式のリストなどのデータを送信。再ネゴシエーション(renegotiation)の場合は直前のセッションIDも送付
    • Server Hello
      サーバーはクライアントが利用可能なTLS/SSLのバージョン、暗号方式、データの圧縮方式から利用する方式を決定し通知。再ネゴシエーション(renegotiation)の場合は直前のセッションIDも送付
  2. Server Certificateメッセージ
    サーバーは自分のSSLサーバ証明書、中間証明書情報をクライアントに通知
  3. Server Hello Done
    サーバーは必要なデータの送信が終わったことを通知
  4. Client Key Exchange
    クライアントは、サーバ証明書を検証し目的の通信相手であることが確認できると、サーバーの公開鍵で暗号化した乱数(プリマスターシークレット)を送信
  5. ChangeCipherSpec
    以降の通信で使用する共通鍵、MAC鍵等をクライアント、サーバー間で交換
  6. Finished
    以上の過程の記録をクライアント、サーバ間で交換。改竄やなりすましがないことを確認

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

EV SSL Plus/1年あたり135,630円から
緑のアドレスバーでサイトの信頼性向上 DigiCert(デジサート) EV SSL/TLS リーズナブルな価格でご提供

対策

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

既存のTLS/SSLの仕様

ClientHelloに含まれる不明な情報を無視するようになっています。

RFC5746のTLS/SSLの仕様

ClientHelloでは、renegotiation_info拡張が空であるか、TLS_EMPTY_RENEGOTIATION_INFO_SCSVとしてSignaling Cipher Suite Value (SCSV)を指定しなければなりません。

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

RFC5746で指定された安全な再ネゴシエーション(renegotiation)がサポートされているとわかった場合

クライアントはTLS再ネゴシエーションのために、renegotiation_info拡張を送信することができます。

サーバーがRFC5746に対応していない場合

クライアントは再ネゴシエーションハンドシェイクを中止しなければなりません。

サーバーもクライアントもRFC5746に対応していない場合

再ネゴシエーションハンドシェイクを中止しなければなりません。

サーバーもクライアントもrenegotiation_infoに対応している場合

双方がハンドシェイクで安全に共有した情報を保存しておき、再ネゴシエーションを行う際に、両者しか知りえない情報をrenegotiation_info拡張で交換し、それまで接続していた通信相手であることを確認します。

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

WildCard Plus/1年あたり162,910円から
複数のサブドメインを1枚の証明書でカバー DigiCert(デジサート)企業認証SSL/TLS リーズナブルな価格でご提供

DigiCertがお勧めする対策

SSL version 2を利用しないこと

SSL version 2は、セッションネゴシエーションハンドシェイクの安全性を確保する手段を持っていません。
これは、中間者攻撃をサーバーとクライアントの接続中のどの時点にも潜り込ませることが可能だということを意味しています。

例:SSL version 2でセッションネゴシエーションハンドシェイクを行った場合

偽の終了メッセージをSSLセッションに潜り込ませながら、サーバーとクライアントの双方に対して「接続は依然として安全である」と思わせるような中間者攻撃ができてしまいます。

弱い暗号化アルゴリズムの組合せ(CipherSuite)を使用しないこと

弱い暗号化アルゴリズムの組合せを使うと、安全性を確保できません。128bit未満の暗号化は危険です。現在最低とされる128bitの場合、2の64乗の異なった暗号が作成されます。
国際版IE3とNetscapeは40bitしかない暗号化を使っていましたが、すでにSSL2.0や、40bit、56bitを使っているブラウザはないので、サーバーでもこれらには対応しない設定にしてください。
こうした環境をそのままにしておくと、さまざまな攻撃を受ける可能性があります。

マルチドメイン証明書/1年あたり85,690円から
Windowsサーバーにおすすめ 最大25ホスト名まで対応 DigiCert(デジサート) 企業認証SSL/TLS リーズナブルな価格でご提供

RMS

・SSLサーバー証明書

・コードサイニング
その他証明書

・バウチャ(クーポン)

お見積依頼

Copyright © cybervision Hosting. All rights reserved.