SSL和中间人攻击的误解
SSL和中间人攻击的误解
我已经阅读了大量与这个问题相关的文档, 但是我仍然不能把所有的内容整合在一起, 因此我想要问一些问题。
- 首先, 我将简要描述一下认证过程, 因为我可能在这方面有所错误: 客户端启动连接, 服务器响应使用公钥、一些元数据和可信任机构的数字签名的组合。然后客户端决定是否信任服务器, 用公钥加密某些随机会话密钥并发送回服务器。这个会话密钥只能用服务器上存储的私钥解密。服务器这样做, 然后HTTPS会话开始。
- 因此, 如果我以上所述正确, 那么问题是如何在这种情况下发生中间人攻击？我的意思是, 即使有人拦截了服务器 (例如www.server.com) 带有公钥的响应并有某种方法让我认为他是www.server.com, 他仍然无法在没有私钥的情况下解密我的会话密钥。
- 谈到双向认证, 它是否完全取决于服务器对客户端身份的信任？我的意思是, 客户端已经能够确定自己正在与正确的服务器通信, 但现在服务器想要找出客户端是谁, 对吗？
- 最后一个问题是关于双向认证的替代方案。如果我作为一个描述的情况下的客户端, 我如果在SSL会话建立之后在HTTP头中发送登录/密码, 那怎么办？在我看来, 这个信息无法被拦截, 因为连接已经被保护, 服务器可以依赖它来确定我的身份。我错了吗？与双向认证相比, 这种方法的缺陷是什么 (只有安全问题很重要, 而不是实现复杂性)？
更新 2022
由于证书透明度，本回答现已过时。
原始答案
在客户端和服务器之间的任何人都可以对https进行中间人攻击。如果你认为这是不可能的或罕见的，请考虑到有商业产品系统地解密、扫描和重新加密互联网网关上的所有ssl流量。他们通过向客户端发送实时创建的ssl证书，并将细节从“真正”的ssl证书复制过来，但使用不同的证书链进行签名来工作。如果此链以任何浏览器信任的CA为结束，则这个中间人攻击对用户来说将是不可见的。这些产品主要销售给公司来“保护”（监管）公司网络，并应该在用户的知情和同意下使用。但从技术上讲，没有任何阻止ISP或任何其他网络运营商使用这些产品。（可以毫不安全地假设NSA 拥有至少一个受信任的根CA签名密钥。）
如果你正在服务一个页面，你可以包含一个HTTP头部指示页面应该使用什么公钥进行签名。这可能有助于提醒用户其“安全”连接可能存在中间人攻击，但这是一种基于信任的技术。如果Bob没有“真正”的公钥个记录，Mallory只需重写文档中的pkp头部。使用此技术（HPKP）的网站清单非常短。其中包括谷歌和Dropbox，这是他们的信誉。通常，一个https拦截网关将放行少数几个使用HPKP的大型信任网站的页面。如果你在不希望看到HPKP错误时看到了，需要小心。
关于密码，在https连接中，除了需要明文路由请求的域名外，https中的所有内容都是安全的。一般来说，不建议将密码放在查询字符串中，因为这些信息可能会留在日志、书签等中。但是，如果https被破坏，查询字符串是不可见的。
SSL的中间人攻击只有当SSL的前提条件被破坏时才可能发生，下面是一些例子：\n\n- 服务器密钥被盗 - 意味着攻击者可以冒充服务器，而客户端无法知道。\n- 客户端信任不可信的CA (或者一个根密钥被盗的CA) - 持有受信任的CA密钥的人可以生成一个证书来假装是服务器，而客户端将信任它。由于今天浏览器中预先存在的CA数量非常多，这可能是一个真正的问题。这意味着服务器证书会变成另一个有效的证书，这是大多数客户端会隐藏的。\n- 客户端没有正确验证证书是否匹配其受信任的CA列表 - 任何人都可以创建CA。如果没有验证，“Ben\'s Cars and Certificates”看起来和Verisign一样有效。\n- 客户端已遭受攻击，并注入了一个伪造的CA到其受信任的根机构中 - 允许攻击者生成他想要的任何证书，并且客户端将信任它。恶意软件往往会这样做，例如将您重定向到虚假的银行站点。\n\n特别是＃2非常恶劣，即使您为高度信任的证书付费，您的网站也不会以任何方式锁定到该证书，您必须信任客户端浏览器中的所有CA，因为它们中的任何一个都可以为您的网站生成一个虚假的证书，而这个证书是完全有效的。它也不需要访问服务器或客户端。