我一直在互联网上阅读一些关于SSL如何工作的网站，但我不明白它究竟是如何确保安全的。可能是因为我完全不了解它的工作原理。
让我先从SSL的核心思想开始。它用于加密HTTP连接，但是对于客户端和服务器与加密数据通信，肯定需要共享加密密钥。如果有人在窃听您的连接，他们是否只能抓住此密钥并在解密数据时继续收听？如果我们谈论的是长期连接，我可以想象这种技术会起作用，但HTTP请求通常会在半秒内完成。
让我们假设这是以某种方式照顾的。 SSL的另一个用途是验证服务器是否与它所说的完全一致。是什么阻止了恶意服务器伪造由根证书提供者签名的证书？在我读过的所有描述中，浏览器实际上都联系了其中一个权限来验证证书。我们假设证书是由根证书颁发机构用私钥加密的，浏览器如何在不知道解密密钥的情况下验证此证书中的数据？或者解密密钥是否与加密密钥不同？
我可以想象的一个解决方案是，如果证书和密钥只发送一次，并与浏览器中的域和IP地址一起存储。
感谢您提前解释。
答案 0 :(得分：9)
首先，关于公钥加密的一些基本概念：
要确保您与正确的实体进行通信，您需要将身份绑定到密钥对。这是证书进入的地方。公钥证书是包含主题标识（名称）和主题公钥的签名文档。
例如，www.google.com的证书包含其公钥和名称www.google.com。它已使用证书颁发机构的私钥（在本例中为Thawte）进行签名。在X.509术语（用于HTTPS的证书的通用标准）中，CA是证书的颁发者，它还将其名称与主题的名称，主题的公钥（以及其他属性）一起放在证书中。 。发行人的目的是验证他们为谁颁发证书的身份。
您不一定看到浏览器从CA获取信息的原因是许多商业（或政府）CA证书与您的浏览器或操作系统捆绑在一起。你默认信任他们。这可以被视为一种“信仰的飞跃”，但任何信任机制都需要这种起点。
您可能想要了解有关TLS handshake的更多信息，但简而言之：
要使SSL / TLS安全，您至少需要3分：
（这是绝大多数SSL / TLS（特别是HTTPS）使用的情况，但也可以使用除TLS的X.509证书之外的其他机制，例如OpenPGP证书或Kerberos密码套件。据我所知，这种情况并不常见。）
答案 1 :(得分：2)
为了加密连接，您必须同意某些共享密钥。这可以使用diffie-hellman完成。为了防止中间人攻击，所以你还需要一个证书机制。
对于加密或签名（证书），您可以使用异步密钥。这意味着您有两个不同的密钥（公钥和私钥）来加密/解密。通常，您使用公钥加密数据，有人可以使用私钥对其进行解密。使用您的私钥进行签名，其他人可以使用公钥进行签名。
所以你看，伪造证书并不容易，因为你没有来自根证书提供者的私钥。
答案 2 :(得分：1)
当然需要共享加密密钥。如果有人在窃听您的连接，他们就不能抓住这个密钥
没有。密钥永远不会传输。它通过密钥协商算法独立地在两端计算。
是什么阻止了恶意服务器伪造由根证书提供者签名的证书？
证书与其使用私钥进行的数字签名一起发送，并由对等方通过证书自己的公钥进行验证。服务器需要它所欺骗的服务器的私钥。
答案 3 :(得分：0)
当使用诸如Diffie-Hellman key exchange之类的协议时，通信的双方各自生成一个随机数，以某种方式对其进行转换，并将转换后的版本发送给另一方。该变换使得将第一数字与第二数字的变换版本组合将产生与将第二数字与第一数字的变换版本组合相同的结果。然而，只有变换后的数字的对手无法找到任何一个未转换的版本，也无法计算如果将一个数字的（不可用）未转换版本与（另一个的转换版本。
Diffie-Hellman密钥交换本身足以防止所有形式的被动攻击或历史攻击（这意味着如果攻击者在通信发生之前没有采取措施拦截通信，则以后不能进行泄密。执行一些计算，这些计算不能像今天的技术那样，在任何远程可行的时间内计算出来。它的问题在于它不能很好地防止攻击者（例如Z）可以拦截参与者之间的所有通信（例如X和Y）并替换他自己的情况。在那种情况下，X会与Z建立联系 - 由Y认为他 - 除了他和Z之外没人能解码。 Z然后 - 假装是X - 与Y建立连接。
如果X和Y有任何预先存在的相互共享信息的方式，它们可以比Z更快地解码它，即使它不是非常安全，这可能足以防止上述人在中间的攻击。所有需要发生的事情都是让X和Y互相询问他们正在使用的密钥。如果Z能够识别出这个问题并替换自己的答案，那么它就能够继续这个问题。另一方面，如果问题是这样的，即合法的一方能够比冒名顶替者更快地作出回应，那么Z可能会被难倒。例如，如果为每个参与者显示关于协商密钥的语音电话应用程序，并且一方要求另一方“读取密钥的数字12到18，给Elmer Fudd留下最好的印象”（选择，在一个合法的参与者能够立即作出回应，但是攻击者需要时间来制作一个如所示的那个人说话的虚假记录。