2013-08-02 135 views
1

我一直在寻找关于SSL证书和加密协议的信息。我得到了很好的答案,特别是在这个网站上。SSL证书和身份验证

只有一件事我没有得到。如果我得到了这个权利,身份验证(我的意思是验证服务器身份,而不是证书身份)是使用非对称密码术进行的。

这意味着步骤将是(阻止我,如果我错了):

  • 客户端使用验证公钥加密的随机挑战字符串,并将其发送给服务器。
  • 服务器使用其私钥解密并将其发送回客户端。
  • 客户端检查服务器的响应是否与刚刚发送的随机质询字符串匹配。

什么防止假冒服务器做这样的,一个真正的证书,比如说,www.example.com但不具有私有密钥?

  • 客户端使用经过验证的公钥对随机挑战字符串进行加密并将其发送到服务器。
  • 假服务器将加密的随机挑战字符串发送到www.example.com,作为客户端希望检查其身份。
  • www.example.com将解密后的随机挑战字符串发送回假服务器。
  • 假服务器将其发送回客户端。
  • 身份确认?

回答

2

客户端使用验证的公钥对随机挑战字符串 进行加密并将其发送到服务器。

客户端用服务器的公钥加密某些东西的密钥交换模式是RSA密钥交换模式。在section F.1.1.2 of the TLS specification中有完整的描述。

实质上,客户端生成预主密钥,使用服务器的公钥(在服务器发送的服务器证书中找到)对其进行加密,然后将其发送到服务器(在客户端密钥交换消息中)。而已。只有具有匹配私钥的服务器才能解密它。服务器不会将任何破译的版本发送回客户端,因此无法要求第三方执行您似乎想到的任何操作。

-2

这只是一个稻草人的论点。您列出的步骤完全是虚构的。该实际步骤是:

  1. 服务器发送其证书作为TLS握手的一部分。
  2. 服务器通过其证书和其他由其私钥签名的握手消息发送数字签名。
  3. 客户端使用证书中的公钥来验证数字签名。

只有拥有与证书中公钥对应的私钥的服务器才能成功。

我建议你做一些阅读,而不是在互联网上随机贴子:尽量规范参考:RFC 2246

+0

@BabuSrinivasan你错了。 #2没有错。您将发行方签名的证书中包含的签名与TLS握手协议期间交换的签名混淆,该协议在整个握手过程中计算,包括证书在内。否则,客户端不可能认证服务器实际拥有该证书。坦率地说,你似乎对此一无所知。我也建议您阅读RFC 2246。你显然还没有听说过自签证书。 – EJP

+0

@downvoter我的奖杯内阁的另一个downvoted正确的答案。这种滥用投票系统只会降低本网站的实用性。 – EJP

+0

您的“规范性参考”链接已关闭以及您的帖子 – user1855153