SSL如何工作？

SSL如何工作？

客户端（或浏览器？）和服务器（或Web服务器？）上安装的证书在哪里？

当您将URLinput浏览器并从服务器获取页面时，信任/encryption/authentication过程如何启动？

HTTPS协议如何识别证书？ 为什么不能在证书完成所有信任/encryption/authentication工作的情况下使用证书？

Answer 1

注：我原来的回答很匆忙，但是从那时起，这已经变成了一个相当受欢迎的问题/答案，所以我把它扩大了一点，使之更加精确。

TLSfunction

“SSL”是最常用来指这个协议的名称，但是SSL特指在90年代中期由Netscapedevise的专有协议。 “TLS”是基于SSL的IETF标准，所以我将在我的答案中使用TLS。 现在，几乎所有的networking安全连接都使用TLS，而不是SSL。

TLS有几个function：

1. encryption您的应用程序层数据。 （在你的情况下，应用层协议是HTTP。）
2. validation服务器到客户端。
3. validation客户端到服务器。

＃1和＃2是非常普遍的。 ＃3不太常见。 你似乎把重点放在＃2，所以我会解释这一部分。

authentication

服务器使用证书向客户端身份validation。 证书是包含有关网站信息的数据块[1]：

• 域名
• 公钥
• 拥有它的公司
• 当它被发布
• 当它到期
• 谁发布的
• 等等。

您可以通过使用证书中包含的公钥来实现机密性（上述＃1）来encryption只能由相应的私钥解密的消息，该私钥应该安全地存储在该服务器上[2]。 我们称这个密钥对为KP1，这样我们就不会在以后感到困惑。 您也可以validation证书上的域名是否与您访问的网站（上面的＃2）匹配。

但是如果攻击者可以修改发送到服务器和从服务器发送的数据包，以及如果攻击者修改了提交给您的证书并插入了自己的公钥或更改了其他重要细节呢？ 如果发生这种情况，攻击者可以拦截并修改您认为被安全encryption的任何消息。

为了防止这种非常严重的攻击，证书由其他人的私钥进行encryption签名，这样签名可以由任何具有相应公钥的人来validation。 我们称这个密钥对为KP2，以清楚地表明它们与服务器使用的密钥不同。

证书颁发机构

那么谁创造了KP2？ 谁签了证书？

简单地说， 证书颁发机构创buildKP2，并出售使用其私钥为其他组织签发证书的服务。 例如，我创build了一个证书，然后付给像Verisign这样的公司用他们的私钥签名。[3] 由于除Verisign之外没有人可以访问这个私钥，所以我们都不能伪造这个签名。

那么为了validation签名，我将如何亲自获得KP2中的公钥？

那么我们已经看到证书可以拥有公钥 – 而计算机科学家喜欢recursion – 那么为什么不把KP2的公钥放入证书中并以这种方式分发呢？ 起初听起来有点疯狂，但事实上，这正是它的工作原理。 继续使用Verisign示例，Verisign会生成一个证书，其中包含有关他们的身份，允许签名的types（其他证书）以及公钥的信息。

现在，如果我拥有Verisign证书的副本，则可以使用它来validation我想访问的网站的服务器证书上的签名。 简单，对吗？

那么，不是那么快。 我必须从某处获得Verisign证书。 如果有人欺骗Verisign证书，并把自己的公钥放在那里呢？ 然后他们可以伪造服务器证书上的签名，我们马上回到了我们开始的地方：一个中间人攻击。

证书链

继续recursion思考，我们当然可以引入第三个证书和第三个密钥对（KP3），并使用它来签署Verisign证书。 我们称之为证书链：链中的每个证书都用于validation下一个证书。 希望你已经可以看到这个recursion方法只是乌龟/证书。 它停在哪里？

由于我们无法创build无限数量的证书，因此证书链显然必须停止在某个位置 ，这是通过在自签名的链中包含一个证书来完成的。

我会暂停一会儿，当你从头部爆炸的时候拿起脑部的物质。 自签名？

是的，在证书链（也就是“根”）的最后，会有一个使用自己的密钥对自己签名的证书。 这消除了无限recursion问题，但它不能解决authentication问题。 任何人都可以创build一个自签名证书，上面写着任何东西，就像我可以创build一个假的普林斯顿文凭，说我在政治学，理论物理学和应用对接踢三重专业，然后在底部签署我自己的名字。

这个问题的解决方法就是挑选一些你明确信任的自签名证书。 例如，我可能会说，“我相信这个Verisign自签名证书。”

有了这个明确的信任，现在我可以validation整个证书链。 无论链中有多less个证书，我都可以validation每个签名一直到根。 当我到达根目录时，我可以检查该根证书是否是我明确信任的证书。 如果是这样，那么我可以信任整个链条。

授予信任

TLS中的身份validation使用授予的信任系统。 如果我想聘请汽车修理工，我可能不会相信我find的随机机械师。 但是也许我的朋友担保某个机械师。 既然我相信我的朋友，那么我可以相信那个机械师。

当你购买一台电脑或下载一个浏览器时，它会附带几百个明确信任的根证书。[4] 拥有并运营这些证书的公司可以通过签署证书将这种信任授予其他组织。

这远非完美的系统。 有时CA可能错误地颁发证书。 在这些情况下，证书可能需要被撤销。 撤销是棘手的，因为发行的证书总是密码正确的; 需要一个带外协议来找出哪些先前有效的证书已被撤销。 实际上，其中一些协议并不是很安全，许多浏览器也不检查它们。

有时整个CA都会受到影响。 例如，如果您打算进入Verisign并窃取根签名密钥，那么您可以欺骗世界上的任何证书。 请注意，这不仅影响Verisign客户：即使我的证书由Thawte（Verisign的竞争对手）签署，也没关系。 我的证书仍然可以使用Verisign中的妥协签名密钥伪造。

这不仅仅是理论上的。 它发生在野外。 DigiNotar被黑客入侵 ，随后破产。 科摩多也遭到了黑客攻击 ，但是直到今天，他们仍然无法正常工作。

即使CA没有直接受到威胁，这个系统还有其他的威胁。 例如，政府使用法律强制迫使CA签署伪造的证书。 您的雇主可以在您的员工电脑上安装自己的CA证书。 在这些不同情况下，您希望“安全”的stream量对控制该证书的组织实际上是完全可见/可修改的。

已经提出了一些替代scheme，包括Convergence ， TACK和DANE 。

尾注

[1] TLS证书数据根据X.509标准格式化。 X.509基于ASN.1 （“抽象语法表示法＃1”），这意味着它不是二进制数据格式。 因此，X.509必须编码为二进制格式。 DER和PEM是我所知道的两种最常见的编码。

[2]在实践中，协议实际上切换到对称密码，但这是一个与您的问题无关的细节。

[3]可假设的，CA在签署证书之前实际validation你是谁。 如果他们不这样做，那么我可以为google.com创build一个证书，并要求CA签名。 有了这个certificate，我可以在中间任何“安全”的连接到google.com。 因此，validation步骤是CA操作中非常重要的一个因素。 不幸的是，这个validation过程在世界各地的数百个CA中有多严格并不是很清楚。

[4]请参阅Mozilla的可信CA列表 。

Answer 2

HTTPS是HTTP和SSL（安全套接字层）的组合，用于在客户端（浏览器）和Web服务器（应用程序位于此处）之间提供encryption通信。

为什么需要？

HTTPSencryption通过networking从浏览器传输到服务器的数据。 所以在传输过程中没有人能够嗅探到数据。

浏览器和Web服务器之间如何build立HTTPS连接？

1. 浏览器尝试连接到https://payment.com 。
2. payment.com服务器向浏览器发送证书。 这个证书包含了payment.com服务器的公钥，还有一些证据表明这个公钥实际上属于payment.com。
3. 浏览器validation证书以确认它具有用于payment.com的正确公钥。
4. 浏览器select一个随机的新对称密钥K用于连接到payment.com服务器。 它使用payment.com公钥对K进行encryption。
5. payment.com使用其私钥解密K. 现在，浏览器和付款服务器都知道K，但是没有其他人。
6. 任何时候浏览器都想要发送一些东西给payment.com，它会在K下encryption; payment.com服务器在收到后将其解密。 在任何时候，payment.com服务器都要发送一些东西给你的浏览器，它会在K下进行encryption。

这个stream程可以用下图来表示：

Answer 3

我写了一个小博客文章，简要讨论了这个过程。 请随时来看看。

SSL握手

同样的小片段如下：

“客户端通过HTTPS向服务器发出请求，服务器发送SSL证书+公钥的副本，在用本地信任的CA存储validation服务器的身份后，客户端生成一个秘密会话密钥，使用服务器的公共密钥对其进行encryption密钥并发送，服务器使用其私钥对秘密会话密钥进行解密，并向客户端发送确认，build立安全通道。

Answer 4

Mehaase已经详细解释了它。 我会把我的2美分添加到这个系列。 我有许多围绕SSL握手和证书的博客post。 虽然这些大部分都是围绕IIS Web服务器进行的，但这个post仍然与SSL / TLS握手相关。 这里有几个供您参考：

• SSL握手和IIS
• SSL握手中的客户端证书身份validation

不要将CERTIFICATES和SSL作为一个主题。 把他们当作两个不同的话题，然后试着看看他们一起工作的人。 这将帮助你回答这个问题。

通过证书库build立通信双方之间的信任

SSL / TLS通信完全基于信任。 互联网上的每台计算机（客户端/服务器）都有一个它所维护的根CA和中间CA的列表。 这些定期更新。 在SSL握手期间，这被用作build立信任的参考。 例如，在SSL握手期间，当客户端向服务器提供证书时。 服务器将尝试提交颁发证书的CA是否存在于CA的列表中。 当它不能这样做时，它声明它不能进行证书链validation。 （这是答案的一部分，它也看AIA ）客户端也对Server Hello收到的服务器证书进行类似的validation。 在Windows上，您可以通过PowerShell查看客户端和服务器的证书存储。 从PowerShell控制台执行以下步骤。

PS Cert：> ls Location：CurrentUser StoreNames：{TrustedPublisher，ClientAuthIssuer，Root，UserDS …}

位置：LocalMachine StoreNames：{TrustedPublisher，ClientAuthIssuer，Remote Desktop，Root …}

像Firefox和Opera这样的浏览器并不依赖底层操作系统进行证书pipe理。 他们维护他们自己的独立的证书商店

SSL握手使用对称密钥和公钥密码。 服务器authentication默认情况下发生 客户端身份validation是可选的，取决于服务器端点是否configuration为validation客户端。 参考我的博客文章，我已经详细解释了这一点。

最后这个问题

HTTPS协议如何识别证书？ 为什么不能在证书完成所有信任/encryption/authentication工作的情况下使用证书？

证书只是一个格式由X.509标准定义的文件。 这是一个certificate通信方身份的电子文件。 HTTPS = HTTP + SSL是一个协议，它定义了两方如何相互通信的指导原则。

更多信息

• 为了理解证书，您将必须了解什么证书，并阅读有关证书pipe理。 这些很重要。
• 一旦理解了这一点，就继续进行TLS / SSL握手。 你可以参考这个RFC。 但是它们是定义指南的骨架。 有几个博客包括我的详细解释这个。

如果上述活动已经完成，那么您将对证书和SSL有一个公正的理解。