一、SSL/TLS

在介绍HTTPS之前，需要先深⼊探讨SSL/TLS，因为HTTPS是构建在
这个基础之上的。

1 背景

SSL/TLS的历史⼏乎和互联⽹历史⼀样长：SSL（Secure Sockets
Layer）的中⽂名称为安全套接层，TLS（Transport Layer Security）的中⽂
名称为传输层安全协议。
1994年，⽹景（NetScape）公司设计了SSL 1.0；
1995年，⽹景公司发布SSL 2.0，但很快发现存在严重漏洞；
1996年，SSL 3.0问世，得到⼤规模应⽤；
1999年，互联⽹标准化组织IETF对SSL进⾏标准化，发布了TLS 1.0；
2006年和2008年，TLS进⾏了两次升级，分别为TLS 1.1和TLS 1.2。
所以，TLS 1.0相当于SSL 3.1；TLS 1.1、TLS 1.2 相当于SSL 3.2、
SSL3.3。在应⽤层⾥，习惯将两者并称为SSL/TLS。
如图5-6所⽰，SSL/TLS处在TCP层的上⾯，它不仅可以⽀撑HTTP协
议，也能⽀撑FTP、IMAP等其他各种应⽤层的协议。

接下来从最基础的对称加密讲起，⼀步步分析SSL/TLS背后的原理和
协议本⾝。

2 对称加密的问题

对称加密的想法很简单。客户端和服务器知道同⼀个密钥，客户端给服务器发消息时，客户端⽤此密钥加密，服务器⽤此密钥解密；反过来，服务器给客户端发消息时，是相反的过程。

这种加密⽅式在互联⽹上有两个问题：
· 密钥如何传输？密钥A的传输也需要另外⼀个密钥B，密钥B的传输
又需要密钥C……如此循环，⽆解。
· 如何存储密钥？对于浏览器的⽹页来说，都是明⽂的，肯定存储不
了密钥；对于Android/iOS客户端，即使能把密钥藏在安装包的某个位置，
也很容易被破解。
当然，这两个问题其实是⼀个问题。因为如果解决了密钥的传输问
题，就可以在建⽴好连接之后获取到密钥，然后只存在内存中，当连接断
开之后，密钥在内存中就被销毁了，也就解决了存储问题。

3 双向⾮对称加密

客户端为⾃⼰准备⼀对公私钥（PubA，PriA），服务器为⾃⼰准备⼀对公私钥（PubB，PriB）。公私钥有个关键特性：公钥PubA是通过私钥PriA 计算出来的，但反过来不⾏，不能根据PubA推算出PriA！对于公私钥之间的数学关系，此处就不再展开讨论。

客户端、服务器把⾃⼰的公钥公开出去，⾃⼰保留私钥。这样⼀来客户端就知道了服务器的公钥，服务器也知道了客户端的公钥。当客户端给服务器发送信息时，就⽤⾃⼰的私钥PriA签名，再⽤服务器的公钥PubB加密。所谓的“签名”，相当于⾃⼰盖了章，或者说签了字，证明这个信息是客户端发送的，客户端不能抵赖；⽤服务器的公钥PubB加密，意味着只有服务器B可以⽤⾃⼰的私钥PriB解密。即使这个信息被C截获了，C没有B的私钥，也⽆法解密这个信息。

服务器收到信息后，先⽤⾃⼰的私钥PriB解密，再⽤客户端的公钥验签（证明信息是客户端发出的）。反向过程同理：服务器给客户端发送信息时，先⽤⾃⼰的私钥 PriB 签名，然后⽤PubA加密；客户端接收到服务器的信息后，先⽤⾃⼰的私钥PriA解密，再⽤服务器的公钥PubB验签。

在这个过程中，存在着签名和验签与加密和解密两个过程：
（1）签名和验签：私钥签名，公钥验签，⽬的是防篡改。如果第三⽅截取到信息之后篡改，则接收⽅验签肯定过不了。同时也防抵赖，既然没有⼈可篡改，只可能是发送⽅⾃⼰发出的。
（2）加密和解密：公钥加密，私钥解密。⽬的是防⽌信息被第三⽅拦截和偷听。第三⽅即便能截获到信息，但如果没有私钥，也解密不了。在双向⾮对称加密中，客户端需要提前知道服务器的公钥，服务器需要知道客户端的公钥，和对称加密⼀样，同样⾯临公钥如何传输的问题。

在继续探讨之前，先看⼀下单向⾮对称加密。

4 单向⾮对称加密

在互联⽹上，⽹站对外是完全公开的，⽹站的提供者没有办法去验证每个客户端的合法性；只有客户端可以验证⽹站的合法性。⽐如⽤户访问百度或者淘宝的⽹站，需要验证所访问的是不是真的百度或者淘宝⽹，防⽌被钓鱼。

在这种情况下，客户端并不需要公钥和私钥对，只有服务器有⼀对公钥和私钥。客户端没有公钥和私钥对，只有服务器有。服务器把公钥给到客户端，客户端给服务器发送消息时，⽤公钥加密，然后服务器⽤私钥解密。反过来，服务器给客户端发送的消息，采⽤明⽂发送。

当然，对于安全性要求很⾼的场景，⽐如银⾏的个⼈⽹银，不仅客户端要验证服务器的合法性，服务器也要验证每个访问的客户端的合法性。对于这种场景，往往会给⽤户发⼀个U盘，⾥⾯装的就是客户端⼀⽅的公钥和私钥对，⽤的是上⾯的双向⾮对称加密。

对于单向⾮对称加密，只有客户端到服务器的单向传输是加密的，服务器的返回是明⽂⽅式，这怎么能保证安全呢？接着往下看。

假设 PubB 的传输过程是安全的，客户端知道了服务器的公钥。客户端就可以利⽤加密通道给服务器发送⼀个对称加密的密钥。

客户端对服务器说：“Hi，我们的对称加密密钥是 xxx，接下来就⽤这个密钥通信。”这句话是通过PubB加密的，所以只有服务器能⽤⾃⼰的PriB解密。然后服务器回复⼀句明⽂：“好的，我知道了。”虽然是明⽂，但没有任何密钥信息在⾥⾯，所以采⽤明⽂也没有关系。

接下来，双⽅就可以基于对称加密的密钥进⾏通信了，这个密钥在内存⾥⾯，不会落地存储，所以也不存在被盗取的问题，⽽这就是SSL/TLS的原型。

5 中间⼈攻击

通过上⾯的分析可以发现，我们并不需要双向的⾮对称加密，⽽⽤单向的⾮对称加密就能达到传输的⽬的。但⽆论双向还是单向，都存在着公钥如何安全传输的问题。下⾯就以⼀个典型的“中间⼈攻击”的案例为例，来看⼀下这个问题是如何被解决的。

本来客户端和服务器要交换公钥，各⾃把⾃⼰的公钥发给对⽅。但被中间⼈劫持了，劫持过程如下：

客户端本来是要把⾃⼰的公钥发给服务器：“Hi，我是客户端1，我的
公钥是PubA。”被中间⼈C劫持之后，C⽤⾃⼰的公钥替换客户端的公钥，然后发给服务器：“Hi，我是客户端1，我的公钥是PubC。”反过来，服务器本来是要把⾃⼰的公钥发给客户端：“Hi，我是服务器，我的公钥是PubB。”被C劫持之后，C⽤⾃⼰的公钥替换服务器的公钥，然后发给客户端：“Hi，我是服务器，我的公钥是PubC。”最终结果是：客户端和服务器都以为⾃⼰是在和对⽅通信，但其实他们都是在和中间⼈ C通信！接下来，客户端发给服务器的信息，会⽤PubC加密，C当然可以解密这个信息；同样，服务器发给客户端的信息也会被
PubC加密，C也可以解密。

这个问题为什么会出现呢？是因为公钥的传输过程是不安全的。客户端和服务器在⽹络上，互相又没见过对⽅，又没有根据，怎么知道收到的公钥就是对⽅发出的，⽽不是被中间⼈篡改过的呢？需要想个办法证明服务器收到的公钥，的确就是客户端发出的，中间没有⼈可以篡改这个公钥，反过来也是⼀样。这就是接下来要讲的数字证书。

6 数字证书与证书认证中⼼

引⼊⼀个中间机构CA。当服务器把公钥发给客户端时，不是直接发送公钥，⽽是发送公钥对应的证书。那么证书是怎么来的呢？

从组织上来讲，CA类似现实中的“公证处”，从技术上讲，就是⼀个服
务器。

服务器先把⾃⼰的公钥PubB发给CA，CA 给服务器颁发⼀个数字证书（Certificate），这个证书相当于服务器的⾝份证。之后，服务器把证书给客户端，客户端可以验证证书是否为服务器下发的。

服务器⽤⾃⼰的公钥PubB通过CA换取证书反过来也同理，客户端⽤⾃⼰的公钥PubA通过CA换取⼀个证书，相当于客户端的⾝份证，客户端把这个证书发给服务器，服务器就能验证整个证书是否为客户端下发的。

当然，对于通常的互联⽹应⽤，只需要客户端验证服务器，不需要服务器验证客户端。
具体的验证过程是怎么操作的呢？
CA有⼀对公钥和私钥对，私钥只有CA知道，公钥在⽹络上，谁都可以知道。服务器把个⼈信息+服务器的公钥发给 CA，CA ⽤⾃⼰的私钥为服务器⽣成⼀个数字证书。通俗地讲，服务器把⾃⼰的公钥发给CA，让CA加盖公章，之后别⼈就不能再伪造公钥了。如果被中间⼈伪造了，客户端拿着CA的公钥去验证这个证书，验证将⽆法通过。

7 根证书与CA信任链

但又会出现类似鸡⽣蛋、蛋⽣鸡的问题，如果让客户端、服务器都信任CA，但CA是个假的怎么办？CA的公钥如何被安全地在⽹络上传输？假如是⼀个假的CA在中间，客户端和服务器都和假的CA通信，互相还以为是和真正的CA通信。CA ⾯临和客户端、服务器同样的问题：客户端和服务器需要证明公钥的确是由⾃⼰发出去的，不是被伪造的；CA同样需要证明，⾃⼰的公钥是由⾃⼰发出去的，不是被伪造的。

答案是给CA颁发证书！CA的证书谁来颁发呢？CA的上⼀级CA。最
终形成图5-14所⽰的证书信⽤链。关于证书信任链，有两点说明：

1.证书信任链的验证过程
客户端要验证服务器的合法性，需要拿着服务器的证书C3，到CA2处去验证（C3是CA2颁发的，验证⽅法是拿着CA2的公钥，去验证证书C3的有效性）；客户端要验证CA2的合法性，需要拿着CA2的证书C2，到CA1处去验证（C2是CA1颁发的）；客户端要验证CA1的合法性，需要拿着CA1的证书C1，到CA0处去验
证（C1是CA0颁发的）；⽽CA0呢，只能⽆条件信任。怎么做到⽆条件信任呢？

Root CA机构都是⼀些世界上公认的机构，在⽤户的操作系统、浏览器发布的时候，⾥⾯就已经嵌⼊了这些机构的Root证书。你信任这个操作系统，信任这个浏
览器，也就信任了这些Root 证书。

2.证书信任链的颁发过程
颁发过程与验证过程刚好是逆向的，上⼀级CA给下⼀级CA颁发证
书。从根CA（CA0）开始，CA0给CA1颁发证书，CA1给CA2颁发证书，
CA2给应⽤服务器颁发证书。最终，证书成为⽹络上每个通信实体的“⾝份证”，在⽹络上传输的都是证书，⽽不再是原始的那个公钥。把这套体系标准化之后，就是在⽹络安全领域经常见到的⼀个词，PKI（Public Key Infrastructure）。

想⼀想在现实⽣活中的例⼦：
· 你出⽣在⼀个⼩镇上，怎么证明你是你呢？
· 镇派出所给你发了个⾝份证，证明你是你；
· 镇派出所为什么可以被信任呢？因为经过了县公安局授权；
· 县公安局为什么可以被信任呢？因为经过了市公安局授权；
……
⼀级级回溯，最后，信任的根是什么？根是国家最⾼机构！

8 SSL/TLS协议：四次握⼿

到此为⽌，我们理解了对称加密、⾮对称加密、证书、根证书等概念
后，再来看SSL/TLS协议就很简单了。

在建⽴TCP连接之后、数据发送之前，SSL/TLS协议通过四次握⼿、两个来回，协商出客户端和服务器之间的对称加密密钥。第⼀个来回，是公钥的传输与验证过程（通过数字证书）；第⼆个来回基于第⼀个来回得到的公钥，协商出对称加密的密钥。接下来，就是正常的应⽤层数据包的发送操作了。
当然，为了协商出对称加密的密钥，SSL/TLS协议引⼊了⼏个随机数，具体细节不再展开，这⾥主要讨论SSL/TLS的核⼼思路。

二、HTTPS

理 解 了 SSL/TLS ， 再 来 看 HTTPS 就 很 简 单 了 ，
HTTPS=HTTP+SSL/TLS。整个HTTPS的传输过程⼤致可以分成三个阶
段。

（1）TCP连接的建⽴。
（2）SSL/TLS四次握⼿协商出对称加密的密钥。
（3）基于密钥，在TCP连接上对所有的HTTP Request/Response进⾏
加密和解密。
其中阶段（1）和阶段（2）只在连接建⽴时做1次，之后只要连接不关闭，每个请求只需要经过阶段（3），因此相⽐HTTP，性能没有太⼤损失。

最后，分析⼀下HTTP/2和HTTPS的关系：HTTP/2主要是解决性能问题，HTTPS主要解决安全问题。从理论上讲，两者没有必然的关系，HTTP/2 可以不依赖于 HTTPS；反过来也如此。把两者同时放在整个⽹络分层体系中，如图5-18所⽰，中间两层都是可选项。去掉中间的两层，变为HTTP 1.1；只去掉HTTP/2⼀层，变为HTTPS；两层都加上，变为HTTP/2+HTTPS。

但在实践层⾯，⽬前主流的浏览器都要求如果要⽀持HTTP/2则必须先
⽀持HTTPS，这也是因为整个互联⽹都在推动HTTPS的普及。