HTTPS是如何工作的[翻译]
原文链接
HTTPS is simply your standard HTTP protocol slathered with a generous layer of delicious SSL/TLS encryption goodness.
HTTPS其实只是具有SSL / TLS加密优势的标准HTTP协议
Unless something goes horribly wrong (and it can), it prevents people like the infamous Eve from viewing or modifying the requests that make up your browsing experience;
除非某些事情发生了非常严重的错误(这是有可能发生的),HTTPS协议能保护使用者免于遭受第三人(infamous eve)篡改或者监视你的浏览请求(http request)
it’s what keeps your passwords, communications and credit card details safe on the wire between your computer and the servers you want to send this data to.
HTTPS是使你的密码，通讯和信用卡信息在你的电脑与你想发送信息的服务器网线之间保持安全的东西。
Whilst the little green padlock and the letters “https” in your address bar don’t mean that there isn’t still ample rope for both you and the website you are viewing to hang yourselves elsewhere, they do at least help you communicate securely whilst you do so.
同时，在你浏览器地址栏上绿色的小锁和”https”的字样并不一定意味着没有办法欺骗你和你正在访问的网站，但HTTPS协议至少帮助你在与你访问的网站之间通信时能保持安全。
1. What is HTTPS and what does it do?
1. HTTPS 是什么以及它的功能
HTTPS takes the well-known and understood HTTP protocol, and simply layers a SSL/TLS (hereafter referred to simply as “SSL”) encryption layer on top of it. Servers and clients still speak exactly the same HTTP to each other, but over a secure SSL connection that encrypts and decrypts their requests and responses. The SSL layer has 2 main purposes:
HTTPS协议仍然使用众所周知的HTTP协议，只是简单地在其上层叠SSL / TLS（以下简称为“SSL”）加密层。服务器和客户端仍然使用HTTP互相交流，但是是通过一个SSL连接来加密解密通讯的请求与回应。
SSL层有两个主要的作用：
Verifying that you are talking directly to the server that you think you are talking to
Ensuring that only the server can read what you send it and only you can read what it sends back
验证你确实是在直接与你想要通讯的服务器通讯。
确保只有服务器能读取到你发送的信息，同时只有你能读取到服务器返回的信息。
The really, really clever part is that anyone can intercept every single one of the messages you exchange with a server, including the ones where you are agreeing on the key and encryption strategy to use, and still not be able to read any of the actual data you send.
这其中最聪明巧妙的部分就是即使所有人都可以拦截你与服务器通讯的每一个请求，甚至包括你与服务器交流使用的加密算法与密钥的请求，他们仍然无法知道你与服务器之间传递的真实数据(actual data)。(译者注:他们可以获取你与服务器的通信内容，却无法解密)
2. How an SSL connection is established
2. SSL连接是如何建立的
An SSL connection between a client and server is set up by a handshake, the goals of which are:
一个服务器与客户端的SSL连接是通过握手(handshake)建立的,握手的目的是:
- To satisfy the client that it is talking to the right server (and optionally visa versa)
- 确保客户端正在与正确的服务器通信（反之亦然）
- For the parties to have agreed on a “cipher suite”, which includes which encryption algorithm they will use to exchange data
- 各方“密码套件”达成一致，其中包括他们将用于交换数据的加密算法
- For the parties to have agreed on any necessary keys for this algorithm
- 双方就算法中使用到的任何密钥达成一致
Once the connection is established, both parties can use the agreed algorithm and keys to securely send messages to each other. We will break the handshake up into 3 main phases - Hello, Certificate Exchange and Key Exchange.
一旦连接成功建立，双方可以使用事先同意使用的算法和密钥来安全的通讯。接下来，我们会将握手(handshake)分成3个主要的阶段 - 打招呼(hello)，证书(certificate)交换，密钥(key)交换
Hello - The handshake begins with the client sending a ClientHello message. This contains all the information the server needs in order to connect to the client via SSL, including the various cipher suites and maximum SSL version that it supports. The server responds with a ServerHello, which contains similar information required by the client, including a decision based on the client’s preferences about which cipher suite and version of SSL will be used.
打招呼(Hello) - 握手以客户端发送一个问好信息(ClientHello message)开始.这个信息包含了所有服务器需要知道以通过ssl连接客户端的内容，包括”密码套件”和支持的最大SSL版本号。服务器返回一个回复信息(ServerHello)，这其中包括与之前客户端发送的类似的，客户端需要的信息，其中包括关于是否支持客户端使用的SSL和”密码套件”的决定。
Certificate Exchange - Now that contact has been established, the server has to prove its identity to the client.
This is achieved using its SSL certificate, which is a very tiny bit like its passport. An SSL certificate contains various pieces of data, including the name of the owner, the property (eg. domain) it is attached to, the certificate’s public key, the digital signature and information about the certificate’s validity dates.
证书交换 - 现在连接建立之后，服务器必需向客户端证明自己的身份。这是通过使用使用一个非常小的类似于密码的一个称为SSL证书的东西。一个SSL证书包含许多的信息，其中有证书拥有者的名字，证书附着的属性(比如服务器域名),证书的公钥，数字签名以及证书合法时间的信息。
The client checks that it either implicitly trusts the certificate, or that it is verified and trusted by one of several Certificate Authorities (CAs) that it also implicitly trusts. Much more about this shortly. Note that the server is also allowed to require a certificate to prove the client’s identity, but this typically only happens in very sensitive applications.
客户端检查客户端是否隐式的信任这个证书或者这个证书验证成功且被客户端隐式信任的众多证书机构(CA)之一信任。很快就会有更多这方面的内容。请注意服务器端同样可以要求客户端提供证书来证明客户端的身份，但这一般只在非常机密的应用中发生。
Key Exchange - The encryption of the actual message data exchanged by the client and server will be done using a symmetric algorithm, the exact nature of which was already agreed during the Hello phase. A symmetric algorithm uses a single key for both encryption and decryption, in contrast to asymmetric algorithms that require a public/private key pair. Both parties need to agree on this single, symmetric key, a process that is accomplished securely using asymmetric encryption and the server’s public/private keys.
密钥交换 - 客户端与服务器交流的数据将会由对称加密算法加密，这在打招呼阶段已经被一致同意。一个对称加密算法使用一个单一的密钥用于加密以及解密，而不对称加密算法需要一对公钥/密钥。双方需要就使用的密钥达成一致，这个过程是通过使用服务器的公/私钥安全的完成的。
The client generates a random key to be used for the main, symmetric algorithm. It encrypts it using an algorithm also agreed upon during the Hello phase, and the server’s public key (found on its SSL certificate).
客户端生成随机密钥用于主要的对称加密算法。客户端用之前双方同意的加密算法以及服务器的公钥(SSL证书上附着)来加密随机生成的密钥
It sends this encrypted key to the server, where it is decrypted using the server’s private key, and the interesting parts of the handshake are complete.
客户端将加密过的密钥发送给服务器，服务器使用私钥进行解密，这样握手就完成了。
The parties are sufficiently happy that they are talking to the right person, and have secretly agreed on a key to symmetrically encrypt the data that they are about to send each other.
这样双方就可以确认自己确实与正确的对象通讯，并且就用于对称加密双方通信数据的公钥达成一致。
HTTP requests and responses can now be sent by forming a plaintext message and then encrypting and sending it. The other party is the only one who knows how to decrypt this message, and so Man In The Middle Attackers are unable to read or modify any requests that they may intercept.
现在HTTP请求与响应可以使用明文信息构造，并用密钥加密后进行发送。而对方则是唯一知道如何解密的人，这样一来”中间人攻击”就无法修改或者读取它拦截的信息。
3. Certificates
3. 证书
3.1 Trust
3.1 信任
At its most basic level, an SSL certificate is simply a text file, and anyone with a text editor can create one. You can in fact trivially create a certificate claiming that you are Google Inc. and that you control the domain gmail.com.
在最基本的层面上，SSL证书只是一个文本文件，所有拥有一个文本编辑器的人都可以创建它。实际上，你可以轻松创建一个声明你是Google Inc.并且你控制gmail.com这个域名的证书。
If this were the whole story then SSL would be a joke; identity verification would essentially be the client asking the server “are you Google?”, the server replying “er, yeah totally, here’s a piece of paper with ‘I am Google’ written on it” and the client saying “OK great, here’s all my data.” The magic that prevents this farce is in the digital signature, which allows a party to verify that another party’s piece of paper really is legit.
如果这是整个故事，那么SSL将是一个笑话; 身份验证基本上是客户端询问服务器“你是谷歌吗？”，服务器回答“呃，是的，这是一张纸，上面写着’我是谷歌’”，客户说“好的，这里是我所有的数据。“防止这场闹剧的神奇之处在于数字签名，它允许一方确认另一方的纸张确实是合法的。
There are 2 sensible reasons why you might trust a certificate:
If it’s on a list of certificates that you trust implicitly
If it’s able to prove that it is trusted by the controller of one of the certificates on the above list
您可能因为两个明智的理由信任证书：
如果它位于您隐含信任的证书列表中
如果它能够证明上述列表中的一个证书的控制器信任它
The first criteria is easy to check. Your browser has a pre-installed list of trusted SSL certificates from Certificate Authorities (CAs) that you can view, add and remove from.
第一个标准很容易检查。 您的浏览器具有预安装的证书颁发机构（CA）证书列表，您可以查看，添加和删除。
These certificates are controlled by a centralised group of (in theory, and generally in practice) extremely secure, reliable and trustworthy organisations like Symantec, Comodo and GoDaddy.
这些证书由一组（理论上和通常在实践中）极其安全，可靠和值得信赖的组织（如Symantec，Comodo和GoDaddy）控制。
If a server presents a certificate from that list then you know you can trust them.
如果服务器提供该列表中的证书，那么您知道可以信任它们。
The second criteria is much harder. It’s easy for a server to say “er yeah, my name is er, Microsoft, you trust Symantec and er, they totally trust me, so it’s all cool.” A somewhat smart client might then go and ask Symantec “I’ve got a Microsoft here who say that you trust them, is this true?” But even if Symantec say “yep, we know them, Microsoft are legit”, you still don’t know whether the server claiming to be Microsoft actually is Microsoft or something much worse. This is where digital signatures come in.
第二个标准要困难得多。 服务器很容易说”是的，我的名字是，微软，你信任Symantec，他们完全信任我，所以这没有任何问题。”一个有点聪明的客户端可能会去问Symantec：”我有一个微软在这里说你信任他们，这是真的吗？”但即使Symantec说:”是的，我们知道他们，微软是合法的”，你仍然不知道声称是微软的服务器实际上是微软还是其他东西更糟糕。这就是数字签名的用武之地。
3.2 Digital signatures
3.2 数字签名
As already noted, SSL certificates have an associated public/private key pair.
如前所述，SSL证书具有与其关联的公钥/私钥对。
The public key is distributed as part of the certificate, and the private key is kept incredibly safely guarded. This pair of asymmetric keys is used in the SSL handshake to exchange a further key for both parties to symmetrically encrypt and decrypt data.
公钥作为证书的一部分进行分发，而私钥被保密得非常安全。 这对非对称密钥用于SSL握手，以便为双方交换另一密钥以对称地加密和解密数据。
The client uses the server’s public key to encrypt the symmetric key and send it securely to the server, and the server uses its private key to decrypt it.
客户端使用服务器的公钥加密对称密钥并将其安全地发送到服务器，服务器使用其私钥对其进行解密。
Anyone can encrypt using the public key, but only the server can decrypt using the private key.
任何人都可以使用公钥加密，但只有服务器可以使用私钥解密。
The opposite is true for a digital signature. A certificate can be “signed” by another authority, whereby the authority effectively goes on record as saying “we have verified that the controller of this certificate also controls the property (domain) listed on the certificate”.
数字签名的情况恰恰相反。 证书可以由另一个机构”签名”，由此权威机构有效地记录为”我们已经验证该证书的控制者还控制证书上列出的属性（域名）。
In this case the authority uses their private key to (broadly speaking) encrypt the contents of the certificate, and this cipher text is attached to the certificate as its digital signature.
在这种情况下，权威机构使用其私钥（广泛地说）加密证书的内容，并且该密文作为其数字签名附加到证书。
Anyone can decrypt this signature using the authority’s public key, and verify that it results in the expected decrypted value.
任何人都可以使用权威机构的公钥解密此签名，并验证它是否会产生预期的解密值。
But only the authority can encrypt content using the private key, and so only the authority can actually create a valid signature in the first place.
但只有权威机构可以使用私钥加密内容，因此只有权威机构才能实际创建有效的签名。(回到上面4句可以看到二者为什么相反)
So if a server comes along claiming to have a certificate for Microsoft.com that is signed by Symantec (or some other CA), your browser doesn’t have to take its word for it.
因此，如果服务器声称拥有由Symantec（或其他某些CA）签名的Microsoft.com证书，您的浏览器不必相信。
If it is legit, Symantec will have used their (ultra-secret) private key to generate the server’s SSL certificate’s digital signature, and so your browser use can use their (ultra-public) public key to check that this signature is valid.
如果它是合法的，Symantec将使用他们的（超秘密）私钥生成服务器的SSL证书的数字签名，因此您的浏览器使用可以使用他们的（超公开）公钥来检查此签名是否有效。
Symantec will have taken steps to ensure the organisation they are signing for really does own Microsoft.com, and so given that your client trusts Symantec, it can be sure that it really is talking to Microsoft Inc.
Symantec将采取措施确保他们签署的组织确实拥有Microsoft.com，因此，鉴于您的客户端信任Symantec，可以肯定它确实与微软公司谈判。
总计: CA的私钥与服务器端的私钥是保证安全性的重要关键
CA保证了证书只能由它们签发，服务器保证客户端发来的信息只能由它们解密。
3.3 Self-signing
3.3 自签发
Note that all root CA certificates are “self-signed”, meaning that the digital signature is generated using the certificate’s own private key.
请注意，所有根CA证书都是“自签名”，这意味着使用证书自己的私钥生成数字签名。
There’s nothing intrinsically special about a root CA’s certificate - you can generate your own self-signed certificate and use this to sign other certificates if you want.
根CA的证书没有任何本质上的特殊之处 - 您可以生成自己的自签名证书，并根据需要使用它来签署其他证书。
But since your random certificate is not pre-loaded as a CA into any browsers anywhere, none of them will trust you to sign either your own or other certificates.
但由于您的随机证书未在任何浏览器中作为CA预先加载到任何浏览器中，因此他们都不会信任您签署自己的证书或其他证书。
You are effectively saying “er yeah, I’m totally Microsoft, here’s an official certificate of identity issued and signed by myself,” and all properly functioning browsers will throw up a very scary error message in response to your dodgy credentials.
你实际上是在说“呃，是的，我完全是微软，这是我自己发布和签署的官方身份证明”，所有正常运行的浏览器都会抛出一个非常可怕的错误信息，以回应你的狡猾凭据。
This puts an enormous burden on all browser and OS publishers to trust only squeaky clean root CAs, as these are the organisations that their users end up trusting to vet websites and keep certificates safe. This is not an easy task.
这给所有浏览器和操作系统发布者带来了巨大负担，只能信任干净的干净根CA，因为这些组织的用户最终信任它们来审查网站并保证证书安全。这不是一件容易的事。
3.4 What are you trusting?
3.4 你相信什么?
It’s interesting to note that your client is technically not trying to verify whether or not it should trust the party that sent it a certificate, but whether it should trust the public key contained in the certificate.
有趣的是，您的客户端在技术上并未尝试验证它是否应该信任发送证书的一方，而是它是否应该信任证书中包含的公钥。
SSL certificates are completely open and public, so any attacker could grab Microsoft’s certificate, intercept a client’s request to Microsoft.com and present the legitimate certificate to it.
SSL证书是完全开放和公开的，因此任何攻击者都可以获取Microsoft的证书，拦截客户对Microsoft.com的请求并向其提供合法证书。
The client would accept this and happily begin the handshake. However, when the client encrypts the key that will be used for actual data encryption, it will do so using the real Microsoft’s public key from this real certificate.
客户会接受这一点并愉快地开始握手。 但是，当客户端加密将用于实际数据加密的密钥时，它将使用此真实证书中的真实Microsoft公钥进行加密。
Since the attacker doesn’t have Microsoft’s private key in order to decrypt it, they are now stuck. Even if the handshake is completed, they will still not be able to decrypt the key, and so will not be able to decrypt any of the data that the client sends to them.
由于攻击者没有Microsoft的私钥来解密它，因此它们现在被卡住了。 即使握手完成，它们仍然无法解密密钥，因此无法解密客户端发送给它们的任何数据。
Order is maintained as long as the attacker doesn’t control a trusted certificate’s private key. If the client is somehow tricked into trusting a certificate and public key whose private key is controlled by an attacker, trouble begins.
只要攻击者无法控制受信任证书的私钥，秩序就不会发生混乱。 如果客户端以某种方式欺骗信任其私钥由攻击者控制的证书和公钥，则麻烦就开始了。