SSL:如何保护证书免受中间人攻击?

发布于 2024-08-18 07:00:45 字数 929 浏览 4 评论 0原文

我的问题是关于 ssl 中的证书,但我认为这些问题应该适用于所有证书。为了清楚起见,我已经包含了 SSL 过程。

在SSL中,我理解的过程是:

1)客户端

  • 发送支持的加密算法
  • 发送客户端随机数
  1. 服务器
  • 选择(并发送)
  • 对称算法
  • 公钥算法
  • MAC算法
  • 发送其证书
  • 发送服务器随机数
  1. 客户端
  • 验证证书
  • 提取公钥
  • 生成预主密钥 (pms),
  • 使用服务器公钥加密,并向
  1. 客户端和服务器
  • 发送来自 PMS 的计算主密钥 (MS) 和随机数
  • PMS 切片以生成两个加密和密钥两个 mac 密钥
  1. 客户端
  • 发送所有握手的 mac(以确保它们之前未被修改)
  1. 服务器
  • 发送所有握手的 mac

问题

什么可以阻止第二步发生中间人攻击? trudy 说,为什么中间人不能捕获服务器发送的证书并更改其中的公钥(更改为它拥有私钥的内容)。

我假设证书以某种方式加密。

然而,服务器无法加密证书,因为客户端还没有公钥。当服务器从权威机构(例如 veri-sign)获取密钥时,是否会使用 verisign 的公钥对密钥进行预加密?我认为这应该可行,因为所有网络浏览器都应该拥有大多数权威机构的公钥。

My question is about certificates specifically in ssl but I think the questions should apply to all certificates. I have included the SSL procedure for the sake of clarity.

In SSL this is what I understand the procedure is:

1)Client

  • sends supported crypto algorithms
  • sends client nonce
  1. Server
  • chooses (and sends) a
  • symmetric algorithm
  • a public key algorithm
  • a MAC algorithm
  • sends it's certificate
  • sends server nonce
  1. Client
  • verifies certificate
  • Extracts public key
  • Generates a pre-master secret key (pms)
  • encrypts with servers public key and sends
  1. Client and Server
  • compute master secrete (MS) from PMS and nonces
  • PMS sliced to generate two encryption & two mac keys
  1. Client
  • sends a mac of all handshakes (to ensure they were not previously modifide)
  1. Server
  • sends a mac of all handshakes

Question

What stops a man in the middle attack from happening at step two? Why can't a man in the middle, say trudy, capture the certificate sent by the server and change the public key in it (to something it has the private key to).

I assume that the certificate is encrypted somehow.

However the server cannot encrypt the certificate because the client does not have the public key yet. When the server gets the key from an authority (like veri-sign) would the key be pre-encrypted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

往日 2024-08-25 07:00:45

不,证书未加密。但它是由认证机构(CA)签署的。由于这些检查证书中包含的信息(尤其是证书所属的 URL),因此给定 URL 不应该有第二个有效证书。

CA 的证书根据信任存储(例如在您的浏览器中)进行检查。如果此信任库遭到破坏,或者您信任无效的证书,则无法防范中间人攻击

No, the certificate is not encrypted. But it is signed by a certification authority (CA). Since those check the information included in the certificate (especially the URL to which the cert belongs), there shouldn't be a second valid certificate for a given URL.

The cert of the CA is checked against a trust store (e.g. in your browser). If this truststore is compromised, or if you trust not valid certificates, there is no protection against man in the middle attacks

温柔戏命师 2024-08-25 07:00:45

证书由一些受信任的机构签名,例如 Verisign

这些根权限的证书在您下载时直接内置到浏览器中。例如,您可以在 Firefox 中查看根证书,方法是转至工具-->选项-->高级-->加密-->查看证书-->颁发机构。

然而,如果这些根证书颁发机构中的任何一个受到损害,那么证书可能会被伪造,从而使中间人攻击成为可能,这是正确的。

Certificates are signed by some trusted authority, such as Verisign.

The certificates for these root authorities are built right into the browsers when you download them. You can view the root certificates in Firefox, for example, by going to tools-->options-->advanced-->encryption-->view certificates-->authorities.

If any one of these root-certificate authorities is compromised, however, you are right that a certificate could be forged, making a man-in-the-middle attack possible.

夕色琉璃 2024-08-25 07:00:45

您实际上指出了 PKI 的一个弱点。

假设 Trudy 位于您和您的银行 (bank.com) 中间。 Trudy 可以在步骤 2 中随意更改公钥,但证书签名将无效。所以 Trudy 必须找到一种方法来重新生成签名。可以肯定地说,受信任的 CA 不会为他这样做。所以他必须使用假的 CA 进行签名,而你的浏览器不信任该 CA。这理论上还是安全的。

然而,根据一些测试,大多数浏览器(尤其是 IE 6)都会显示模糊的安全警告,大多数人不理解并且只是忽略。

You actually pointed out a weak spot of PKI.

Say Trudy is in the middle of you and yourbank (bank.com). Trudy can change the public key at will at step 2 but the certificate's signature will be invalid. So Trudy has to find a way to generate the signature again. It's safe to say that the trusted CAs will not do this for him. So he has to sign with a fake CA, which is not trusted by your browser. This is still safe theoretically.

However, most browsers (especially IE 6) display a vague security warning and most people don't understand and just ignore, according to some tests.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文