Security SSL和中间人误解

我已经阅读了大量与这个问题相关的文档，但是我仍然不能把所有的部分都整理好，所以我想问几个问题

首先，我将简要描述我所理解的身份验证过程，因为在这方面我可能会弄错：客户机启动连接，服务器使用公钥、一些元数据和可信机构的数字签名的组合来响应该连接。然后，客户机决定是否信任服务器，用公钥加密一些随机会话密钥并将其发回。此会话密钥只能使用存储在服务器上的私钥解密。服务器执行此操作，然后HTTPS会话开始

所以，如果我上面说的是对的，问题是在这种情况下，中间人攻击是如何发生的？我的意思是，即使有人用公钥截取服务器（例如www.server.com）的响应，并且有某种方法让我认为他是www.server.com，如果没有私钥，他仍然无法解密我的会话密钥

说到相互身份验证，这一切都是关于服务器对客户端身份的信心吗？我的意思是，客户机已经可以确定她正在与正确的服务器通信，但是现在服务器想知道客户机是谁，对吗

最后一个问题是关于相互认证的替代方案。如果我在所描述的情况下充当客户机，那么在建立SSL会话后，如果我在HTTP头中发送一个登录名/密码会怎么样？在我看来，无法截获此信息，因为连接已经安全，服务器可以依赖它来识别我。我错了吗？与相互认证相比，这种方法的缺点是什么（只有安全问题才重要，而不是实现的复杂性）

---

除了关于会话密钥的部分外，您所说的一切都是正确的。CAs的目的是击败中间人攻击——其他一切都由SSL本身完成。客户端身份验证是用户名和密码方案的替代方案

正确的

不太正确。在这种攻击中，iTerMedia服务器会收到您的请求，并代表您将其发送到目的地。然后回复你结果。实际上，是中间人服务器与您建立了安全连接，而不是您打算通信的实际服务器。这就是为什么您必须始终检查证书是否有效和可信

可能是正确的

如果您确信安全连接是可信的，那么发送用户名/密码是安全的

---

只有当SSL的前提条件之一被打破时，才有可能对SSL进行中间人攻击，下面是一些示例

• 服务器密钥已被盗-意味着攻击者可能看起来就是服务器，而客户端无法知道

• 客户机信任不可信的CA（或其根密钥被盗的CA）-任何持有可信CA密钥的人都可以生成一个假装是服务器的证书，客户机将信任它。现在浏览器中已有大量CA，这可能是一个真正的问题。这意味着服务器证书似乎会更改为另一个有效证书，这是大多数客户端对您隐藏的内容

• 客户端不需要根据其受信任的CA列表正确验证证书-任何人都可以创建CA。如果不进行验证，“Ben的汽车和证书”将与Verisign一样有效

• 客户端受到攻击，并且在其受信任的根权限中注入了一个伪造的CA-允许攻击者生成他喜欢的任何证书，客户端将信任它。恶意软件倾向于这样做，例如将你重定向到伪造的银行网站

特别是#2相当令人讨厌，即使您为高度信任的证书付费，您的站点也不会以任何方式锁定到该证书，您必须信任客户端浏览器中的所有CA，因为它们中的任何一个都可以为您的站点生成同样有效的假证书。它也不需要访问服务器或客户端

首先，我将简要描述我所理解的身份验证过程，也许我在这一步上弄错了。因此，客户端启动一个连接，服务器用公钥、一些元数据和可信机构的数字签名的组合来响应它

服务器使用一个X.509证书链和一个用自己的私钥签名的数字签名进行响应

然后，客户机决定是否信任服务器

对

用公钥加密一些随机会话密钥并将其发回

否。客户端和服务器参与了一个相互会话密钥生成过程，因此会话密钥本身根本不会被传输

此会话密钥只能使用存储在服务器上的私钥解密

没有

服务器就是这样做的

没有

然后HTTPS会话开始

TLS/SSL会话开始，但首先还有更多步骤

所以，如果我上面说的是对的，问题是在这种情况下，中间人攻击是如何发生的

通过伪装成服务器并充当SSL端点。客户端必须省略任何授权步骤。遗憾的是，大多数HTTPS会话中唯一的授权步骤是主机名检查

我的意思是，即使有人用公钥拦截服务器（例如www.server.com）的响应，然后用某种方法让我认为他是www.server.com，如果没有私钥，他仍然无法解密我的会话密钥

见上文。没有要解密的会话密钥。SSL连接本身是安全的，与您交谈的人可能不安全

说到相互认证，是不是都是关于服务器信任