SSL 到底是如何工作的？
SSL 是如何工作的？
证书安装在客户端（或浏览器？）和服务器（或Web服务器？）的哪里？
当您在浏览器中输入 URL 并从服务器获取页面时，信任/加密/身份验证过程如何启动？
HTTPS协议如何识别证书？ 当证书完成所有信任/加密/身份验证工作时，为什么 HTTP 不能使用证书？
How does SSL work?
Where is the certificate installed on the client (or browser?) and the server (or web server?)?
How does the trust/encryption/authentication process start when you enter the URL into the browser and get the page from the server?
How does the HTTPS protocol recognize the certificate? Why can't HTTP work with certificates when it is the certificates which do all the trust/encryption/authentication work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
TLS 功能
“SSL”是最常用于指代该协议的名称，但 SSL 特指由 Netscape 在 90 年代中期设计的专有协议。 “TLS”是基于 SSL 的 IETF 标准，因此我将在答案中使用 TLS。 如今，几乎所有网络安全连接实际上都使用 TLS，而不是 SSL。
TLS 具有多种功能：
#1 和 #2 很常见。 #3 不太常见。 您似乎专注于#2，所以我将解释该部分。
身份验证
服务器使用证书向客户端验证自身身份。 证书是一团数据[1]，其中包含有关网站的信息：
您可以通过使用以下方式实现机密性（上面的#1）：证书中包含的公钥用于加密只能由相应私钥解密的消息，该私钥应安全地存储在该服务器上。 [2] 我们将这个密钥对称为KP1，这样以后就不会混淆了。 您还可以验证证书上的域名是否与您正在访问的网站匹配（上面#2）。
但是，如果对手可以修改发送到服务器和从服务器发送的数据包，并且如果该对手修改了向您提供的证书并插入了他们自己的公钥或更改了任何其他重要细节，该怎么办？ 如果发生这种情况，对手可以拦截并修改您认为已安全加密的任何消息。
为了防止这种攻击，证书由其他人的私钥进行加密签名，这样任何拥有相应公钥的人都可以验证该签名。 我们将此密钥对称为 KP2，以明确这些密钥与服务器使用的密钥不同。
证书颁发机构
那么谁创建了 KP2？ 谁签署了证书？
稍微简单一点，证书颁发机构创建 KP2，并且他们出售使用其私钥为其他组织签署证书的服务。 例如，我创建一个证书，然后向 Verisign 这样的公司付费，让其使用他们的私钥对其进行签名。[3] 由于除了 Verisign 之外没有人可以访问此私钥，因此我们没有人可以伪造此签名。
我个人如何获得 KP2 中的公钥来验证该签名？
好吧，我们已经看到证书可以保存公钥 - 并且计算机科学家喜欢递归 - 那么为什么不将 KP2 公钥放入证书中并以这种方式分发呢？ 乍一听起来有点疯狂，但事实上它就是这样运作的。 继续使用 Verisign 示例，Verisign 生成一个证书，其中包含有关他们是谁、允许他们签署什么类型的内容（其他证书）以及他们的公钥的信息。
现在，如果我有该 Verisign 证书的副本，我可以使用它来验证我要访问的网站的服务器证书上的签名。 容易，对吧？！
嗯，没那么快。 我必须从某个地方获取威瑞信证书。 如果有人欺骗 Verisign 证书并将自己的公钥放入其中怎么办？ 然后他们可以伪造服务器证书上的签名，我们就回到了开始的地方：中间人攻击。
证书链
继续递归思考，我们当然可以引入第三个证书和第三个密钥对 (KP3)，并使用它来签署 Verisign 证书。 我们将其称为证书链：链中的每个证书都用于验证下一个证书。 希望您已经看到这种递归方法只是海龟/证书一直向下。 它在哪里停止？
由于我们无法创建无限数量的证书，因此证书链显然必须在某个地方停止，这是通过在链中包含自签名的证书来完成的。
是的，在证书链的末端（也称为“根”），将会有一个证书使用自己的密钥对来对自身进行签名。 这消除了无限递归问题，但并没有解决身份验证问题。 任何人都可以创建一个自签名证书，在上面写上任何内容，就像我可以创建一个假的普林斯顿大学文凭，上面写着我主修政治、理论物理和应用踢屁股，然后在底部签上我自己的名字。
这个问题的[有点不令人兴奋]的解决方案就是选择一组您明确信任的自签名证书。 例如，我可能会说，“我信任这个 Verisign 自签名证书。”
有了明确的信任，现在我可以验证整个证书链。 无论链中有多少个证书，我都可以验证每个签名一直到根。 当我到达根证书时，我可以检查该根证书是否是我明确信任的证书。 如果是这样，那么我可以信任整个链条。
TLS 中的授予信任
身份验证使用授予信任系统。 如果我想雇用一名汽车修理工，我可能不会相信我找到的任何随机修理工。 但也许我的朋友为某个特定的机械师提供担保。 既然我信任我的朋友，那么我就可以信任那个机械师。
当您购买计算机或下载浏览器时，它会附带数百个它明确信任的根证书。 [4] 拥有和运营这些证书的公司可以通过签署其证书来将该信任授予其他组织。
这远非一个完美的系统。 有时，CA 可能会错误地颁发证书。 在这些情况下，可能需要吊销证书。 撤销是很棘手的，因为颁发的证书在密码上始终是正确的； 需要使用带外协议来查明哪些先前有效的证书已被撤销。 实际上，其中一些协议不是很安全，许多浏览器无论如何也不会检查它们。
有时整个 CA 都会受到损害。 例如，如果您要闯入 Verisign 并窃取他们的根签名密钥，那么您可以欺骗世界上的任何证书。 请注意，这不仅会影响 Verisign 客户：即使我的证书是由 Thawte（Verisign 的竞争对手）签署的，也没关系。 我的证书仍然可以使用来自 Verisign 的受损签名密钥来伪造。
这不仅仅是理论上的。 它发生在野外。 DigiNotar 曾遭受黑客攻击，随后破产。 Comodo 也遭到黑客攻击，但令人费解的是，他们至今仍在营业。
即使 CA 没有直接受到损害，该系统中也存在其他威胁。 例如，政府使用法律强制手段迫使 CA 签署伪造的证书。 您的雇主可以在您的员工计算机上安装他们自己的 CA 证书。 在这些不同的情况下，您期望“安全”的流量实际上对于控制该证书的组织是完全可见/可修改的。
建议进行一些替代，包括Convergence、TACK 和 DANE< /a>.
尾注
[1] TLS 证书数据根据 X.509 标准进行格式化。 X.509 基于 ASN.1（“抽象语法表示法 #1”），这意味着它不是二进制数据格式。 因此，X.509 必须编码为二进制格式。 DER 和 PEM 是两种最常见的编码据我所知。
[2] 在实践中，协议实际上切换到对称密码，但这是一个与您的问题无关的细节。
[3] 据推测，CA 在签署您的证书之前实际上会验证您的身份。 如果他们不这样做，那么我可以为 google.com 创建一个证书并要求 CA 对其进行签名。 有了这个证书，我就可以通过中间人方式与 google.com 进行任何“安全”连接。 因此，验证步骤是CA运行中非常重要的因素。 遗憾的是，目前尚不清楚全球数百家 CA 的验证流程有多严格。
[4] 请参阅 Mozilla 的可信 CA 列表< /a>.
TLS Capabilities
"SSL" is the name that is most often used to refer to this protocol, but SSL specifically refers to the proprietary protocol designed by Netscape in the mid 90's. "TLS" is an IETF standard that is based on SSL, so I will use TLS in my answer. These days, the odds are that nearly all of your secure connections on the web are really using TLS, not SSL.
TLS has several capabilities:
#1 and #2 are very common. #3 is less common. You seem to be focusing on #2, so I'll explain that part.
Authentication
A server authenticates itself to a client using a certificate. A certificate is a blob of data[1] that contains information about a website:
You can achieve confidentiality (#1 above) by using the public key included in the certificate to encrypt messages that can only be decrypted by the corresponding private key, which should be stored safely on that server.[2] Let's call this key pair KP1, so that we won't get confused later on. You can also verify that the domain name on the certificate matches the site you're visiting (#2 above).
But what if an adversary could modify packets sent to and from the server, and what if that adversary modified the certificate you were presented with and inserted their own public key or changed any other important details? If that happened, the adversary could intercept and modify any messages that you thought were securely encrypted.
To prevent this very attack, the certificate is cryptographically signed by somebody else's private key in such a way that the signature can be verified by anybody who has the corresponding public key. Let's call this key pair KP2, to make it clear that these are not the same keys that the server is using.
Certificate Authorities
So who created KP2? Who signed the certificate?
Oversimplifying a bit, a certificate authority creates KP2, and they sell the service of using their private key to sign certificates for other organizations. For example, I create a certificate and I pay a company like Verisign to sign it with their private key.[3] Since nobody but Verisign has access to this private key, none of us can forge this signature.
And how would I personally get ahold of the public key in KP2 in order to verify that signature?
Well we've already seen that a certificate can hold a public key — and computer scientists love recursion — so why not put the KP2 public key into a certificate and distribute it that way? This sounds a little crazy at first, but in fact that's exactly how it works. Continuing with the Verisign example, Verisign produces a certificate that includes information about who they are, what types of things they are allowed to sign (other certificates), and their public key.
Now if I have a copy of that Verisign certificate, I can use that to validate the signature on the server certificate for the website I want to visit. Easy, right?!
Well, not so fast. I had to get the Verisign certificate from somewhere. What if somebody spoofs the Verisign certificate and puts their own public key in there? Then they can forge the signature on the server's certificate, and we're right back where we started: a man-in-the-middle attack.
Certificate Chains
Continuing to think recursively, we could of course introduce a third certificate and a third key pair (KP3) and use that to sign the Verisign certifcate. We call this a certificate chain: each certificate in the chain is used to verify the next certificate. Hopefully you can already see that this recursive approach is just turtles/certificates all the way down. Where does it stop?
Since we can't create an infinite number of certificates, the certificate chain obviously has to stop somewhere, and that's done by including a certificate in the chain that is self-signed.
Yes, at the end of the certificate chain (a.k.a. the "root"), there will be a certificate that uses it's own keypair to sign itself. This eliminates the infinite recursion problem, but it doesn't fix the authentication problem. Anybody can create a self-signed certificate that says anything on it, just like I can create a fake Princeton diploma that says I triple majored in politics, theoretical physics, and applied butt-kicking and then sign my own name at the bottom.
The [somewhat unexciting] solution to this problem is just to pick some set of self-signed certificates that you explicitly trust. For example, I might say, "I trust this Verisign self-signed certificate."
With that explicit trust in place, now I can validate the entire certificate chain. No matter how many certificates there are in the chain, I can validate each signature all the way down to the root. When I get to the root, I can check whether that root certificate is one that I explicitly trust. If so, then I can trust the entire chain.
Conferred Trust
Authentication in TLS uses a system of conferred trust. If I want to hire an auto mechanic, I may not trust any random mechanic that I find. But maybe my friend vouches for a particular mechanic. Since I trust my friend, then I can trust that mechanic.
When you buy a computer or download a browser, it comes with a few hundred root certificates that it explicitly trusts.[4] The companies that own and operate those certificates can confer that trust to other organizations by signing their certificates.
This is far from a perfect system. Some times a CA may issue a certificate erroneously. In those cases, the certificate may need to be revoked. Revocation is tricky since the issued certificate will always be cryptographically correct; an out-of-band protocol is necessary to find out which previously valid certificates have been revoked. In practice, some of these protocols aren't very secure, and many browsers don't check them anyway.
Sometimes an entire CA is compromised. For example, if you were to break into Verisign and steal their root signing key, then you could spoof any certificate in the world. Notice that this doesn't just affect Verisign customers: even if my certificate is signed by Thawte (a competitor to Verisign), that doesn't matter. My certificate can still be forged using the compromised signing key from Verisign.
This isn't just theoretical. It has happened in the wild. DigiNotar was famously hacked and subsequently went bankrupt. Comodo was also hacked, but inexplicably they remain in business to this day.
Even when CAs aren't directly compromised, there are other threats in this system. For example, a government use legal coercion to compel a CA to sign a forged certificate. Your employer may install their own CA certificate on your employee computer. In these various cases, traffic that you expect to be "secure" is actually completely visible/modifiable to the organization that controls that certificate.
Some replacements have been suggested, including Convergence, TACK, and DANE.
Endnotes
[1] TLS certificate data is formatted according to the X.509 standard. X.509 is based on ASN.1 ("Abstract Syntax Notation #1"), which means that it is not a binary data format. Therefore, X.509 must be encoded to a binary format. DER and PEM are the two most common encodings that I know of.
[2] In practice, the protocol actually switches over to a symmetric cipher, but that's a detail that's not relevant to your question.
[3] Presumable, the CA actually validates who you are before signing your certificate. If they didn't do that, then I could just create a certificate for google.com and ask a CA to sign it. With that certificiate, I could man-in-the-middle any "secure" connection to google.com. Therefore, the validation step is a very important factor in the operation of a CA. Unfortunately, it's not very clear how rigorous this validation process is at the hundreds of CAs around the world.
[4] See Mozilla's list of trusted CAs.
HTTPS 是HTTP 和SSL（安全套接字层） 的组合，用于在客户端（浏览器）和 Web 服务器（此处托管应用程序）之间提供加密通信。
为什么需要它？
HTTPS 对通过网络从浏览器传输到服务器的数据进行加密。 因此，没有人可以在传输过程中嗅探数据。
浏览器和Web服务器之间如何建立HTTPS连接？
该流程可以用下图表示：
HTTPS is combination of HTTP and SSL(Secure Socket Layer) to provide encrypted communication between client (browser) and web server (application is hosted here).
Why is it needed?
HTTPS encrypts data that is transmitted from browser to server over the network. So, no one can sniff the data during transmission.
How HTTPS connection is established between browser and web server?
This flow can be represented by the following diagram:
我写了一篇小博客文章，简要讨论了该过程。 请随意查看。
SSL 握手
一个小片段如下：
“客户端使通过 HTTPS 向服务器发送请求。服务器通过其本地可信 CA 存储验证服务器的身份后，生成一个秘密会话密钥，使用服务器的公钥对其进行加密并发送。服务器使用其私钥解密秘密会话密钥并向已建立的安全通道发送确认。”
I have written a small blog post which discusses the process briefly. Please feel free to take a look.
SSL Handshake
A small snippet from the same is as follows:
"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."
Mehaase已经详细解释过了。 我将在这个系列中添加我的 2 美分。 我有很多关于 SSL 握手和证书的博文。 虽然大部分内容都围绕 IIS Web 服务器，但该帖子总体上仍然与 SSL/TLS 握手相关。 以下是一些供您参考：
通过证书存储在通信双方之间建立信任
SSL/TLS 通信仅在信任的基础上进行。 互联网上的每台计算机（客户端/服务器）都有一个它维护的根 CA 和中间 CA 列表。 这些会定期更新。 在 SSL 握手期间，这用作建立信任的参考。 例如，在 SSL 握手期间，客户端向服务器提供证书。 服务器将尝试检查颁发证书的 CA 是否存在于其 CA 列表中。 当它不能做到这一点时，它声明它无法进行证书链验证。 （这是答案的一部分。它还查看AIA。）客户端还对其在 Server Hello 中收到的服务器证书进行类似的验证。
在 Windows 上，您可以看到客户端和客户端的证书存储区。 通过 PowerShell 的服务器。 从 PowerShell 控制台执行以下命令。
Firefox 和 Opera 等浏览器不依赖底层操作系统进行证书管理。 他们维护自己独立的证书存储。
SSL 握手同时使用对称和对称握手。 公钥密码学。 默认情况下会发生服务器身份验证。 客户端身份验证是可选的，取决于服务器端点是否配置为对客户端进行身份验证。 请参阅我的博客文章，因为我对此进行了详细解释。
终于回答这个问题了
证书只是一个文件，其格式由X.509 标准。 它是证明通信方身份的电子文件。
HTTPS = HTTP + SSL 是一种协议，它定义了两方应如何相互通信的准则。
更多信息
如果完成上述活动，那么您将对证书和 SSL 有一个大致的了解。
Mehaase has explained it in details already. I will add my 2 cents to this series. I have many blogposts revolving around SSL handshake and certificates. While most of this revolves around IIS web server, the post is still relevant to SSL/TLS handshake in general. Here are few for your reference:
Establishing trust between communicating parties via Certificate Store
SSL/TLS communication works solely on the basis of trust. Every computer (client/server) on the internet has a list of Root CA's and Intermediate CA's that it maintains. These are periodically updated. During SSL handshake this is used as a reference to establish trust. For exampe, during SSL handshake, when the client provides a certificate to the server. The server will try to cehck whether the CA who issued the cert is present in its list of CA's . When it cannot do this, it declares that it was unable to do the certificate chain verification. (This is a part of the answer. It also looks at AIA for this.) The client also does a similar verification for the server certificate which it receives in Server Hello.
On Windows, you can see the certificate stores for client & Server via PowerShell. Execute the below from a PowerShell console.
Browsers like Firefox and Opera don't rely on underlying OS for certificate management. They maintain their own separate certificate stores.
The SSL handshake uses both Symmetric & Public Key Cryptography. Server Authentication happens by default. Client Authentication is optional and depends if the Server endpoint is configured to authenticate the client or not. Refer my blog post as I have explained this in detail.
Finally for this question
Certificates is simply a file whose format is defined by X.509 standard. It is a electronic document which proves the identity of a communicating party.
HTTPS = HTTP + SSL is a protocol which defines the guidelines as to how 2 parties should communicate with each other.
MORE INFORMATION
If the above activity is done, then you will have a fair understanding of Certificates and SSL.