重放攻击怎么产生的 重放攻击怎么产生的啊

SSH如何防御重放攻击？

看到答非所问，真是着急，下面是要点：

1、ssh或者https 都是使用TLS协议；

2、TLS 使用非对称密钥交换对称密钥，这个对称密钥是每个对话开始前随机生成的，每次都不一样，专业名词叫“前向安全”。

那么答案来了：ssh重放时，对端会要求重新协商对称密钥，很显然：失败！

看了下回答这个问题的人真少，估计大家可能经常用ssh,但是对ssh协议可能不是很了解。下面分享一下我对这个问题的看法：

第一，ssh协议中的传输协议会为为会话产生一个会话id，这个会话id可以被高层协议用于将数据和特定的会话绑定，防止之前会话数据的重放。

第二，本协议会为数据包计算mac或hmac，在计算时会将单增序号作为输入，可有效的防止重放，这也是防止重放的惯用手段。

第三，协议中的加密算法套件会使用cbc模式，cbc方式加密时，会传入iv。iv每次加密完成后均会改变，也可以起到防重放作用。

当然，防重放得措施不止这些，ssh协议主要用到了以上三种。

本人具有多年的java开发经验，熟悉多种框架，熟悉网络编程，熟悉java安全编程，熟悉大数据，熟悉多种安全协议，熟悉并发编程，有兴趣的同学可以互相关注，互相学习！！！

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）这两个协议，SSL 技术最初是由浏览器开发商网景通信公司率先倡导的，开发 过 SSL3.0 之前的版本。目前主导权已转移到 IETF（Internet Engineering Task Force，Internet 工程任务组）的手中。

IETF 以 SSL3.0 为基准，后又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 为原型开发的协议，有时会统一称该协议 为 SSL。当前主流的版本是 SSL3.0 和 TLS1.0。

SSL 和 TLS 实际上可以理解为 TLS 是 SSL 的升级版本，TLS 基于 SSL，至于两者的具体区别还是留给专业人士，这里顺便普及一下 SSL 和 TLS 的相关背景。

为什么不适用HTTPS

HTTPS 由于使用了 SSL(包括 TLS) 而变得安全可靠，但是 SSL 由于要进行加密处理会导致整个通信变慢，频繁的加密、解密会消耗服务端和客户端的硬件资源。

SSL 不仅会导致通信慢，还会由于大量消耗 CPU 和内存等资源，导致整个处理速度变慢，和 HTTP 相比，网络负载可能可能会变慢 2 到 100 倍，如下图所示：

为什么不使用HTTPS

如果使用了 HTTPS，那就意味着要增加硬件成本，此外从数字认证机构购买证书也是需要开销的。

SSH是一个什么样的存在？

SSH类似于TLS，站在TCP 端口22上，TLS站在TCP 端口443上。

所以，这两者是平起平坐的，都可以提供安全加密服务。对SSH不熟悉的同学，可以用TLS的知识来学习SSH。

网络安全有一个经典口号，不造轮子，只使用轮子！

什么意思呢？

私自造轮子，本来想提供安全的通信，可是考虑不周全，引入了更多的安全漏洞，得不偿失。

使用酒精考验的轮子，经历了全人类不断捶打的轮子，使用起来更放心！

所以，SSH和TLS尽管名称不同，安全的三要素是相同的套路。

• 认证对方
• 分发密钥
• 加密数据

SSH与TLS认证方式有一点区别，TLS采用第三方CA认证，而SSH为了简化，没有采用第三方的CA，而是采用双方互相认证。

SSH公钥认证

当客户端与服务器完成TCP三次握手，紧接着就是SSH双方开始了握手协商的过程。

服务器会将自己的公钥以明文的方式推送给客户端，为了避免被第三方篡改，公钥的尾部报文还附带服务器私钥的签名保护。

客户端获得服务器的公钥，用公钥解密签名，可以解开，说明公钥完好。解不开说明公钥被篡改。

这里有一个问题，客户端永远都不知道公钥是不是服务器的，对吗？

服务器出示一张名片，上面赫然写着“马云”，客户端就相信这个是马云了？

客户端尽管傻，但是设计SSH人并不傻，设计人员是这么想的。

假如客户端与服务器第一次通信，是在一个安全的局域网里，双方如同在一个小会议室见面，然后双方交换名片，以后双方即使在互联网上通信，依然只认在小会议室交换的名片，是不是就可以避免被第三方欺骗？

重放攻击

所谓重放攻击，就是第三方捕获了双方的历史通信报文，在合适的时间重新发送一次或多次不等。

如何防止重放攻击？

安全协议为了应对这个挑战，通常会在报文头里嵌入一个序列号，从0开始单向增长的整数，接收方维护着一个类似TCP滑动窗口，不在窗口以内的序列号统统抛弃。即使在窗口内，也要比较接收序列号与缓存的序列号是否相同，如果相同，一样抛弃处理！