Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

第 91 题:介绍下 HTTPS 中间人攻击 #142

Open
yygmind opened this issue Jun 17, 2019 · 13 comments
Open

第 91 题:介绍下 HTTPS 中间人攻击 #142

yygmind opened this issue Jun 17, 2019 · 13 comments
Labels

Comments

@yygmind
Copy link
Contributor

@yygmind yygmind commented Jun 17, 2019

No description provided.

@nunuji123

This comment has been minimized.

Copy link

@nunuji123 nunuji123 commented Jun 18, 2019

先占个座

@lvwxx

This comment has been minimized.

Copy link

@lvwxx lvwxx commented Jun 18, 2019

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

中间人攻击过程如下:

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

防范方法:

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

This comment has been minimized.

Copy link

@104gogo 104gogo commented Jun 19, 2019

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

@Val-istar-Guo

This comment has been minimized.

Copy link

@Val-istar-Guo Val-istar-Guo commented Jul 15, 2019

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

@sailei1

This comment has been minimized.

Copy link

@sailei1 sailei1 commented Jul 18, 2019

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

@gyf940349398

This comment has been minimized.

Copy link

@gyf940349398 gyf940349398 commented Aug 21, 2019

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

中间人攻击过程如下:

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

防范方法:

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

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

@tfeng-use

This comment has been minimized.

Copy link

@tfeng-use tfeng-use commented Aug 21, 2019

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

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

防范方法:

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

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

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

@gyf940349398

This comment has been minimized.

Copy link

@gyf940349398 gyf940349398 commented Aug 21, 2019

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

This comment has been minimized.

Copy link

@SiyuanHu SiyuanHu commented Aug 28, 2019

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

This comment has been minimized.

Copy link

@lzxxxxx lzxxxxx commented Oct 10, 2019

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

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

@qiudongwei

This comment has been minimized.

Copy link

@qiudongwei qiudongwei commented Oct 23, 2019

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

This comment has been minimized.

Copy link

@lanOrage lanOrage commented Nov 30, 2019

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

@evenjxr

This comment has been minimized.

Copy link

@evenjxr evenjxr commented Dec 1, 2019

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

@yygmind yygmind added the 网络 label Dec 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.