クライアント/サーバーランダムがない場合のSSLリプレイ攻撃
SSLプロトコルを勉強していると、サーバーのnonceが欠落している場合、誰かがどのようにしてリプレイ攻撃を行うことができるのでしょうか。私が見つけたすべての資料はノンスがそれを防ぐと述べていますが、理由または方法を指定する例はありません
サーバーが以前のハンドシェイクと同じノンス（ SSL/TLS仕様 では「server_random」と呼ばれます）と同じセッションIDを使用している場合、攻撃者は、クライアントが前のセッション中に送信したもの、およびサーバーがすべてを受け入れます。少なくとも、サーバーがRSA鍵交換暗号スイートを使用している場合（これが最も一般的なケースです）。
これは、さまざまな暗号要素がどのように計算されるかをたどることで簡単に確認できます。 ClientKeyExchangeメッセージには、サーバーの公開鍵で暗号化されたpre-master-secretが含まれています。そのパケットは再生でき、同じプレマスターシークレットの適切に暗号化されたバージョンです。次に、暗号化とMACキーは、決定論的であるSSL/TLS "PRF"を介して、プリマスターシークレットclient_randomおよびserver_randomから派生します。したがって、ランダムが変更されていない場合（つまり、サーバーが以前と同じserver_randomを使用しており、攻撃者が前のセッション中と同じClientHelloメッセージを送信した場合）、事前マスターシークレットはまた、変更されていない場合、サーバーは同じ対称鍵を推測し、キャプチャされた暗号化されたパケットを本物であるものとして受け入れます。
攻撃者がリプレイを実行しても、アプリケーションデータがどのように見えるかについて、追加の洞察は得られません。攻撃は復号化攻撃ではありません。しかし、サーバーの観点からは、これは2番目の正規の自発的な接続のように見えます。 HTTPS接続で使用されるSSL接続の場合POSTクレジットカード支払いのリクエストの場合、これは二重支払いを意味します。
幸いにも、常に同じサーバーランダムで同じセッションIDを使用するSSLサーバーを実現するには、非標準的な大きさの能力がありません。決して起こらないとは言っていません。まれにしか起こりません。特に、TLS仕様では、client_randomとserver_randomの最初の4バイトは現在の日時を1秒の精度でエンコードする必要があると主張しています。クロック、これだけでも、ひどく欠陥のあるRNGを持つサーバーが1秒後も異なるserver_randomを使用することが保証されます。