#1 楼
SSL / TLS通道本身使用MAC（消息身份验证代码）进行保护，以防止重放攻击，该MAC使用MAC机密和序列号进行计算。 （MAC机制可确保TLS通信的完整性）。请参阅TLS 1.1规范附录F.2：为了防止消息重播或修改攻击，请从MAC机密，序列号，消息长度，
消息的内容和两个固定的字符串。
编辑：正如@CodesInChaos所指出的，握手也必须考虑在内，否则整个TLS连接可能是重播（不仅仅是一些记录，这是MAC和序列号可以防止的记录）。如果攻击者重播了相同的
Client Hello消息，则服务器将返回带有不同服务器随机值的Server Hello，从而更改其余的密钥交换。另外，在RSA密钥交换模式下，只有最初的合法客户端才知道它已加密的主密码。在DHE密钥交换模式下，客户端和服务器随机变量在服务器密钥交换消息中签名在一起（因此，在那里也需要良好的随机数）。 （此问题中有关这两种模式的内容还有很多。）从您的问题尚不清楚，您正在尝试防止重放攻击的方法。通常，这是一条在SSL / TLS层上方发送的消息，供您的应用程序使用。
SSL / TLS提供的加密功能肯定会阻止窃听者看到该应用程序请求，从而无法重放该请求。拥有自己的独立SSL / TLS连接。
但是，SSL / TLS本身并不一定会阻止合法的初始用户重播请求。需要此附加保护级别的协议和应用程序倾向于在应用程序级别具有基于随机数的机制来解决此问题（尽管防止窃听会有所帮助，但它独立于SSL / TLS）。
评论
虽然TLS可以防止重放攻击是正确的，但您的解释对我而言并不十分令人信服。我知道您所提到的所有协议都仍然存在，并且仍然遭受重放攻击（至少在天真的实现时）。
– CodesInChaos
2012-09-12 18:52
@CodesInChaos，您是在谈论TLS消息本身受保护的方式还是在应用程序级别？对于TLS，我认为基于序列号的良好MAC应该足以防止重播，不是吗？您只是不会两次处理具有相同序列号的消息。
–布鲁诺
2012-09-12 18:57
握手的细节也很重要，否则攻击者可以简单地重播整个连接。
– CodesInChaos
2012年9月12日19:02
作为参考，此处的MAC表示“消息认证代码”。搜寻“ TLS MAC”将为您提供有关Macintosh和第2层媒体访问控制地址的大量结果
–培根片
16年6月3日在19:42
@Abraham不，我的意思是TLS规范中定义的序列号（这是该规范的引号）。
–布鲁诺
19年1月13日，0：18
评论
根据您在此处发布的问题security.stackexchange.com/questions/23607/…，该问题被标记为重复-只是要指出，中间一个人可能利用代理对数据包进行解密。 br />不知道您想告诉我们什么。重播和MitM无关。 MitM（带代理或其他方式）仅在客户端未正确验证服务器证书的情况下起作用。
我认为这很明显。我通知“我们”时不要假设SSL不能被中间的人解密。
但是1）这个问题与MitM无关，与重播攻击有关。 2）如果正确使用SSL，则无法使用MitM。
您实际上读过另一篇文章吗？该方案引用了一个代理服务器，该服务器由某人控制，也就是中间的人。