SSL/TLSチャネル自体は、MACシークレットとシーケンス番号を使用して計算されたMAC（メッセージ認証コード）を使用して、リプレイ攻撃から保護されています。 （MACメカニズムは、TLS通信の整合性を保証するものです）。 TLS 1.1仕様の付録F.2 を参照してください。
メッセージの再生や変更攻撃を防ぐために、MACシークレット、シーケンス番号、メッセージの長さ、メッセージの内容、2つの固定文字列からMACが計算されます。
EDIT：@CodesInChaosが指摘するように、ハンドシェイクも考慮する必要があります。そうしないと、TLS接続全体を再生できます（一部のレコードだけでなく、 MACとシーケンス番号が保護する対象です）。攻撃者が同じClient Helloメッセージを再生した場合、サーバーは別のサーバーランダム値を含むServer Helloを返し 、残りのキー交換が変更されます 。さらに、RSA鍵交換モードでは、最初の正規のクライアントだけが暗号化した事前マスターシークレットを知っています。 DHE鍵交換モードでは、クライアントとサーバーの乱数はサーバーの鍵交換メッセージで一緒に署名されます（したがって、そこにも適切な乱数が重要です）。 （ この質問 のこれら2つのモードについてもう少しあります。）
リプレイ攻撃から何を保護しようとしているのかは、質問から明らかではありません。通常、これはSSL/TLSレイヤーの上に送信されるメッセージで、アプリケーションによって使用されます。
SSL/TLSによって提供される暗号化は、盗聴者がそのアプリケーション要求を見るのを確実に防ぎ、したがって、独自の個別のSSL/TLS接続でそれを再生することを防ぎます。
ただし、SSL/TLS自体は、正当な初期ユーザーがリクエストを再生することを必ずしも妨げるものではありません。この追加レベルの保護を必要とするプロトコルとアプリケーションは、この問題に対処するためにアプリケーションレベルでnonceベースのメカニズムを持っている傾向があります（これは、盗聴の防止には役立ちますが、SSL/TLSからはかなり独立しています）。