第 91 题：介绍下 HTTPS 中间人攻击

[yygmind]

No description provided.

[nunuji123]

先占个座

[lvwxx]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述

中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

[104gogo]

@lvwxx 再来个证书的中间人攻击方式讲解

[Val-istar-Guo]

CA得保证不泄漏自己的私钥，否则中间人又可以连CA做的的签名都伪造了

[sailei1]

charles https 代理 是不是根据这个原理 实现的？

[gyf940349398]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述

中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

步骤6至8，攻击者已经将真秘钥保存下来了，所以完全可以把真秘钥发给服务端，没有必要再生成一个假密钥，后续客户端与服务端之间以共享密钥加密方式通信时，攻击者就可以用它保存的真秘钥解密了，不知道这样理解对不对

[feiying-tf]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述
中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

步骤6至8，攻击者已经将真秘钥保存下来了，所以完全可以把真秘钥发给服务端，没有必要再生成一个假密钥，后续客户端与服务端之间以共享密钥加密方式通信时，攻击者就可以用它保存的真秘钥解密了，不知道这样理解对不对

不对，因为服务端解密的东西必须是自己的公钥加密的文件，攻击者只能通过这个服务器的公钥重新生成密文才能被服务端正确解析。如果没有6-8步，那么服务端就无法进行解密。

[gyf940349398]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述
中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

步骤6至8，攻击者已经将真秘钥保存下来了，所以完全可以把真秘钥发给服务端，没有必要再生成一个假密钥，后续客户端与服务端之间以共享密钥加密方式通信时，攻击者就可以用它保存的真秘钥解密了，不知道这样理解对不对

不对，因为服务端解密的东西必须是自己的公钥加密的文件，攻击者只能通过这个服务器的公钥重新生成密文才能被服务端正确解析。如果没有6-8步，那么服务端就无法进行解密。

其实我的问题是：在步骤6中，攻击者为什么要再造一个假的hash值给服务端，而不是那个从客户端得来的真hash值，毕竟无论是客户端还是服务端它们都不知道已经泄露了这个密钥，所以后续攻击者完全可以只用这个密钥就可以解密通信中的数据包了

[SiyuanHu]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述
中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

步骤6至8，攻击者已经将真秘钥保存下来了，所以完全可以把真秘钥发给服务端，没有必要再生成一个假密钥，后续客户端与服务端之间以共享密钥加密方式通信时，攻击者就可以用它保存的真秘钥解密了，不知道这样理解对不对

不对，因为服务端解密的东西必须是自己的公钥加密的文件，攻击者只能通过这个服务器的公钥重新生成密文才能被服务端正确解析。如果没有6-8步，那么服务端就无法进行解密。

其实我的问题是：在步骤6中，攻击者为什么要再造一个假的hash值给服务端，而不是那个从客户端得来的真hash值，毕竟无论是客户端还是服务端它们都不知道已经泄露了这个密钥，所以后续攻击者完全可以只用这个密钥就可以解密通信中的数据包了

如果将客户端的hash值直接返回给服务端，服务端不能解密。因为客户端是用假的公钥加密的，服务器不能用真的私钥解密。所以攻击者一定要用自己的假私钥将客户端的hash值解密得到真秘钥。但攻击者是再伪造一个假秘钥，还是直接用真秘钥，我个人觉得都可以。最后通过真公钥对这个真或者假的秘钥进行加密，发给服务端。这是我的个人理解，不知道对不对。

[lzxxxxx]

charles https 代理 是不是根据这个原理 实现的？

charles 想拦截 https 先要信任他的证书，印象中 charles 确实是用中间人的方式实现的拦截

[lostvita]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述

中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

1. 首先纠正一点：https中，是CA证书中包含了非对称加密的公钥，而不是在公钥中加入证书。
2. 在第五点，不好意思，你拿到的并不是真密钥，你劫持的只是客户端生成的一个随机数，并不是后续用于对称加密的密钥（但这个随机数是用于生成密钥的，可以去了解下tls的三个随机数）；
3. https中用于对称加密的密钥是在客/服户端分别生成的，它在握手过程并不在网络间传输。至此，中间人劫持失败。

https本就有CA认证过程，这个就是用来防止劫持，退一万步讲，就算你伪造CA成功，你也拿不到我的对称密钥，除非客户端主动泄漏，我实在不理解HTTPS如何能进行中间人攻击。我觉得这个问题应该改成http的中间人攻击？

[lanOrage]

from baidu~~
假设爱丽丝（Alice）希望与鲍伯（Bob）通信。同时，马洛里（Mallory）希望拦截窃会话以进行窃听并可能在某些时候传送给鲍伯一个虚假的消息。
首先，爱丽丝会向鲍勃索取他的公钥。如果Bob将他的公钥发送给Alice，并且此时马洛里能够拦截到这个公钥，就可以实施中间人攻击。马洛里发送给爱丽丝一个伪造的消息，声称自己是鲍伯，并且附上了马洛里自己的公钥（而不是鲍伯的）。
爱丽丝收到公钥后相信这个公钥是鲍伯的，于是爱丽丝将她的消息用马洛里的公钥（爱丽丝以为是鲍伯的）加密，并将加密后的消息回给鲍伯。马洛里再次截获爱丽丝回给鲍伯的消息，并使用马洛里自己的私钥对消息进行解密，如果马洛里愿意，她也可以对消息进行修改，然后马洛里使用鲍伯原先发给爱丽丝的公钥对消息再次加密。当鲍伯收到新加密后的消息时，他会相信这是从爱丽丝那里发来的消息。
1.爱丽丝发送给鲍伯一条消息，却被马洛里截获：
爱丽丝“嗨，鲍勃，我是爱丽丝。给我你的公钥”-->马洛里鲍勃
2.马洛里将这条截获的消息转送给鲍伯；此时鲍伯并无法分辨这条消息是否从真的爱丽丝那里发来的：
爱丽丝马洛里“嗨，鲍勃，我是爱丽丝。给我你的公钥”-->鲍伯
3.鲍伯回应爱丽丝的消息，并附上了他的公钥：
爱丽丝马洛里<--[鲍伯的公钥]--鲍伯
4.马洛里用自己的公钥替换了消息中鲍伯的公钥，并将消息转发给爱丽丝，声称这是鲍伯的公钥：
爱丽丝<--[马洛里的公钥]--马洛里鲍勃
5.爱丽丝用她以为是鲍伯的公钥加密了她的消息，以为只有鲍伯才能读到它：
爱丽丝“我们在公共汽车站见面！”--[使用马洛里的公钥加密]-->马洛里鲍勃
6.然而，由于这个消息实际上是用马洛里的公钥加密的，所以马洛里可以解密它，阅读它，并在愿意的时候修改它。他使用鲍伯的公钥重新加密，并将重新加密后的消息转发给鲍伯：
爱丽丝马洛里“在家等我！”--[使用鲍伯的公钥加密]-->鲍伯
7.鲍勃认为，这条消息是经由安全的传输通道从爱丽丝那里传来的。

[evenjxr]

1，浏览器�和服务器分别保有运营商的公钥秘钥。
2，浏览器请求服务器，会拿运营商的公钥解密获取服务器自己的公钥。
3，能正确解密，验证服务器是目标服务器，再拿新获取的公钥跟服务器通信。
4，所以https 往复9次才开始传输信息。
5，除非自愿泄露，不然没办法劫持。

[JiangMengLei]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述
中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

步骤6至8，攻击者已经将真秘钥保存下来了，所以完全可以把真秘钥发给服务端，没有必要再生成一个假密钥，后续客户端与服务端之间以共享密钥加密方式通信时，攻击者就可以用它保存的真秘钥解密了，不知道这样理解对不对

不对，因为服务端解密的东西必须是自己的公钥加密的文件，攻击者只能通过这个服务器的公钥重新生成密文才能被服务端正确解析。如果没有6-8步，那么服务端就无法进行解密。

其实我的问题是：在步骤6中，攻击者为什么要再造一个假的hash值给服务端，而不是那个从客户端得来的真hash值，毕竟无论是客户端还是服务端它们都不知道已经泄露了这个密钥，所以后续攻击者完全可以只用这个密钥就可以解密通信中的数据包了

你可能弄混了秘钥和hash，攻击者一定是要再造一个假的hash值给服务端的，否则服务端无法解密。至于这个假hash的本体是真秘钥还是假秘钥，这个无所谓的。

[divasatanica]

所以实际上所谓 https 的中间人攻击是客户端主动泄密（信任了中间人的证书）的结果，也就是说只能抓你自己的客户端和服务端之间的包，抓不了别人的客户端和服务端通信的包，因为别人的客户端不会信任你的证书。
是这样吗？

[ron0115]

所以实际上所谓 https 的中间人攻击是客户端主动泄密（信任了中间人的证书）的结果，也就是说只能抓你自己的客户端和服务端之间的包，抓不了别人的客户端和服务端通信的包，因为别人的客户端不会信任你的证书。
是这样吗？

我也是这么理解的，不知道对不对。所谓的中间人攻击，只不过就是中间人代替了客户端与服务端进行传输，前提是客户端还要信任这个中间人的证书。

[wang-qiqi]

个人理解中间人攻击利用的是客户端和服务端认证阶段syn等泄露，伪装成客户端和服务端进行身份认证，从而拿到了服务端的公钥。同时为了持续保持劫持客户端的状态，需要将服务端的报文解密之后，混淆自己的类似广告等信息到新报文（如果不返回部分服务端内容的报文很容易被客户端识别出来网站可能是被劫持了），因此需要伪装成服务端生成一个公钥和客户端持续地通信，通过两头骗的方式，将自己的报文神不知鬼不觉地推送到了客户端。（如有理解偏差，劳烦指点，谢谢）

[yuluhuang]

总结：以charles为例实现中间人攻击过程如下：

• 客户端请求服务器证书
• charles拦截后 1.向客户端发送自己的伪证书，2.正常向服务端发送请求，3.拦截服务端返回的证书及公钥
• 客户端通过伪证书加密数据+随机数后 发送给服务端（被中间人拦截）。
• 中间人解密获得客户端数据和随机数，用正确的证书重新加密发送给服务端
• 服务端返回数据，被中间人拦截，用随机数解密，用伪证书加密后发送给客户端
• 在两端无感知的情况下获取到所有数据

[hyden-tan]

https协议由 http + ssl 协议构成，具体的链接过程可参考SSL或TLS握手的概述
中间人攻击过程如下：

1. 服务器向客户端发送公钥。
2. 攻击者截获公钥，保留在自己手上。
3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
5. 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
6. 同时生成假的加密hash值，发给服务器。
7. 服务器用私钥解密获得假秘钥。
8. 服务器用加秘钥加密传输信息

防范方法：

1. 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性

步骤6至8，攻击者已经将真秘钥保存下来了，所以完全可以把真秘钥发给服务端，没有必要再生成一个假密钥，后续客户端与服务端之间以共享密钥加密方式通信时，攻击者就可以用它保存的真秘钥解密了，不知道这样理解对不对

首先要说明一点，后续数据传输进行对称加密的密钥是算出来的，客户端和服务器端会生成两对值，k1,p1, k2,p2, 他们分别把自己的p给对方，这样客户端基于k1, p2, 服务器端基于k2, p1生成一个相同的密钥来加解密，而这个k是服务器端和客户端自己持有的，不会发送给对方，所以中间人是获取不到的，自然也就无法得到对称加密的密钥，同时，因为中间人没有服务器的私钥，所以握手过程当中，是无法解密客户端的数据的。 个人理解，如有不对，欢迎指正

[zizifn]

https不存在中间人攻击。除非你自己忽略浏览器的不安全提醒，或者自己http client禁用证书校验。但是这都是使用者的错，和https没有关系。

[sourcema]

如果中间人也申请一个正常的CA证书和客户端进行通信呢？

[yuluhuang]

您好，邮件已收到，尽快给您回复。