IM消息是通过tcp传输，是有自定义协议，base64编码传输，还需要进行哈希校验传输吗？会很不安全吗？如果不做哈希校验

引用：JackJiang 发表于 2021-09-08 10:41
这篇有没有去读一下：《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》，这篇在安全性和实用性上 ...

ok马上学习去

引用：登至必极 发表于 2021-09-08 08:04
其实第一步服务器传递pk1至客户端，存在中间人攻击，黑客可以此时可以将自己的公钥pk"传给客户端，然后客户 ...

这篇有没有去读一下：《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》，这篇在安全性和实用性上，比较不错

其实第一步服务器传递pk1至客户端，存在中间人攻击，黑客可以此时可以将自己的公钥pk"传给客户端，然后客户端用pk"加密pk11,此时黑客截获此密文用自己的公钥解开即可。因此最后的终极通信安全 ，如果再加上CA认证机制，确定服务器公钥的真实性就完美了。

http://www.52im.net/thread-2866-1-1.html   上面忘了贴链接地址

上面几位反馈的，方案7中的“为什么要对客户端发送的公钥进行加密”，我想应该是为了防止“中间人攻击”。黑客若明文的客户端公钥，那么可以在client和server之间伪造通信，client端无法发现。可以看看这篇文章的第6节，差不多的意思

通俗易懂，学习了！

3次握手好理解，但是如何保障第一次请求服务器时，服务器是合法的没有伪造，比如说DNS拦截，伪造服务端。

引用：Da.du.M_s28iT 发表于 2018-10-30 16:50
我想了一下，是不是如下更简洁一点：
1客户端生成公私钥，并把公钥传给服务端；
2服务端生成自己的公私 ...

你第一步就错了，从理论上来讲，客户端发起的东西都有可能是黑客伪造过的，所以肯定不能由以客户端为主发起整个过程。

引用：JackJiang 发表于 2018-01-04 15:16
其实是多重加密

我想了一下，是不是如下更简洁一点：
1客户端生成公私钥，并把公钥传给服务端；
2服务端生成自己的公私钥，并用客户公钥加密自己公钥，返回密文；
3.客户端用自己的私钥解密密文，得到服务公钥；
4.以后的请求数据，直接用解密的服务公钥加密传输
这样不就少了一个回路么？好像也没啥风险

引用：mw-im 发表于 2018-01-04 14:00
x每次连接都不同，模拟client拿到也没有用，不会造成伤害

拿到X不就相当于已经被破解了么，7这整个过程不就是为了让X不被泄露么，为什么不会造成伤害

引用：JackJiang 发表于 2018-01-04 15:16
其实是多重加密

为什么加密客户端的公钥呢，公钥被黑客获取有什么问题吗，为什么要多重加密？

引用：mw-im 发表于 2018-01-04 14:05
7 当中的

客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk11，通过pk1加密，传给服务端：
( ...

其实是多重加密

最后一种，如果黑客模拟Client,生成自己的pk11 pk12，那不就能获取X了么

确实通俗易懂 学习了

学习了

引用：。面向阳光. 发表于 2017-08-25 15:26
感谢分享。一直在关注！辛苦！

引用：JackJiang 发表于 2017-08-25 15:19
多谢勘误，已订正，抱歉！

感谢分享。一直在关注！辛苦！

引用：。面向阳光. 发表于 2017-08-25 15:13
文章中：
7、终级通信安全，描述的三次握手过程中有笔误
第2步：客户端随机生成公私钥对(公钥pk11，私钥p ...

多谢勘误，已订正，抱歉！

文章中：
7、终级通信安全，描述的三次握手过程中有笔误
第2步：客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk22，通过pk1加密，传给服务端：
应该是客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk11，通过pk1加密，传给服务端：