SSL/TLS协议的运行原理浅析—https通信过程及CA证书诠释

互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL TLS协议变得异常复杂。理清https原理与CA证书体系

互联网的通信安全，建立在SSL/TLS协议之上。

本文简要介绍SSL/TLS协议的运行机制。文章的重点是设计思想和运行过程，不涉及具体的实现细节。如果想了解这方面的内容，请参阅RFC文档。

为什么需要采用https加通信

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。

（2） 篡改风险（tampering）：第三方可以修改通信内容。

（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

（1）所有信息都是加密传播，第三方无法窃听。

（2）具有校验机制，一旦被篡改，通信双方会立刻发现。

（3）配备身份证书，防止身份被冒充。

互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。

https简史

互联网加密通信协议的历史，几乎与互联网一样长。

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0版问世，得到大规模应用。

1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

HTTPS，也称作HTTP over TLS。TLS的前身是SSL

目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。

TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

https 相比http 多了层TLS

TLS 握手

False Start

False Start 有抢跑的意思，TLS False Start 是指客户端在发送 Change Cipher Spec Finished 同时发送应用数据（如 HTTP 请求），服务端在 TLS 握手完成时直接返回应用数据（如 HTTP 响应）。这样，应用数据的发送实际上并未等到握手全部完成，故谓之抢跑。这个过程如下图所示：

可以看到，启用 False Start 之后，TLS 阶段只需要一次 RTT 就可以开始传输应用数据。False Start 相当于客户端提前发送加密后的应用数据，不需要修改 TLS 协议，目前大部分浏览器默认都会启用，但也有一些前提条件：

服务端必须在 Server Hello 握手中通过 NPN（Next Protocol Negotiation，下一代协议协商，Google 在 SPDY 协议中开发的 TLS 扩展，用于握手阶段协商应用协议）或 ALPN（Application Layer Protocol Negotiation，应用层协议协商，NPN 的官方修订版）表明自己支持的 HTTP 协议，例如：http/1.1、http/2；
使用支持前向安全性（Forward Secrecy）的加密算法。False Start 在尚未完成握手时就发送了应用数据，Forward Secrecy 可以提高安全性；

https握手基本的运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

如何保证公钥不被篡改？

将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

公钥加密计算量太大，如何减少耗用的时间？

每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

（1）客户端向服务器端索要并验证公钥。

（2）双方协商生成”对话密钥”。

（3）双方采用”对话密钥”进行加密通信。

上面过程的前两步，又称为”握手阶段”（handshake）。

https握手阶段的详细过程

“握手阶段”涉及四次通信，我们一个个来看。需要注意的是，”握手阶段”的所有通信都是明文的。

TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下：

浏览器将自己支持的一套加密规则发送给网站。
网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
浏览器获得网站证书之后浏览器要做以下工作：

a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
网站接收浏览器发来的数据之后要做以下的操作：

a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

b) 使用密码加密一段握手消息，发送给浏览器。
浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

HTTPS对应的通信时序图如下

客户端发起HTTPS请求

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

在这一步，客户端主要向服务器提供以下信息。

（1）支持的协议版本，比如TLS 1.0版。

（2）一个客户端生成的随机数，稍后用于生成”对话密钥”。

（3）支持的加密方法，比如RSA公钥加密。

（4）支持的压缩方法。

这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

（1）确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2）一个服务器生成的随机数，稍后用于生成”对话密钥”。

（3）确认使用的加密方法，比如RSA公钥加密。

（4）服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。

然后，向服务器发送下面三项信息。

（1）一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。

至于为什么一定要用三个随机数，来生成”会话密钥”，dog250解释得很好：

“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。

（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。

如果消息的内容非常多，每次都用公钥和私钥将同一信息加密两次显然很费时间。因此数字签名往往不直接用私钥加密原文，而是加密原文的散列值。

散列值(又称哈希值)，是指将原数据通过散列函数(又称哈希函数)，打乱混合，重新创建的一个值，通常是一个很短的看上去随机的字母和数字组成的字符串。

一个良好的散列函数应该拥有以下特性：

单向性：只能通过原文计算出散列值，而不能通过散列值找到原文
抗冲突性：确保两个不同的消息不会被计算成同一个散列值

由于散列值拥有的这些特性，使得他们可以被看作原消息的摘要或者指纹。使用散列函数使得计算签名所需的开销大为减小，目前的数字签名方案中大多都使用了散列函数。

对称加密和非对称加密的优劣及应用

谈谈“对称加密”和“非对称加密”的概念

1. 啥是“加密”和“解密”？

通俗而言，你可以把“加密”和“解密”理解为某种【互逆的】数学运算。就好比“加法和减法”互为逆运算、“乘法和除法”互为逆运算。

“加密”的过程，就是把“明文”变成“密文”的过程；反之，“解密”的过程，就是把“密文”变为“明文”。在这两个过程中，都需要一个关键的东东——叫做“密钥”——来参与数学运算。

2. 啥是“对称加密”？

所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用【相同的】密钥。这个比较好理解。就好比你用 7zip 或 WinRAR 创建一个带密码（口令）的加密压缩包。当你下次要把这个压缩文件解开的时候，你需要输入【同样的】密码。在这个例子中，密码/口令就如同刚才说的“密钥”。

3. 啥是“非对称加密”？

所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用【不同的】密钥。这玩意儿比较难理解，也比较难想到。当年“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。

由于篇幅有限，对“非对称加密”这个话题，俺就不展开了。有空的话，再单独写一篇扫盲。

4. 各自有啥优缺点？

看完刚才的定义，很显然：（从功能角度而言）“非对称加密”能干的事情比“对称加密”要多。这是“非对称加密”的优点。但是“非对称加密”的实现，通常需要涉及到“复杂数学问题”。所以，“非对称加密”的性能通常要差很多（相对于“对称加密”而言）。

这两者的优缺点，也影响到了 SSL 协议的设计。

HTTPS一般使用的加密与HASH算法如下：

非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

CA 证书的原理及用途

数字证书怎么起作用

服务器在获取到数字证书后，服务器会将数字证书发送给客户端，客户端就需要用CA的公匙解密数字证书并验证数字证书的合法性。

在早期的互联网时代，我们的网站、软件，都是依赖于我们自己的信任而使用的。

我知道http://cmbchina.com这个地址是招商银行，是因为招行营业厅的MM告诉我的，我信任营业厅的这个MM。这种信任是非常薄弱和糟糕的。即使这个网址是真的，你也不能保证你访问的网址是被劫持的，如DNS劫持。

证书是如何解决信任问题(访问的的确实是目的网址)？

证书有两个功能：

身份标识，证明这个网站/软件/其他的发布者是谁（如微软、UBI、Google、招行）。
数字签名，确保这个网站/软件/等等的内容没有被任何人篡改。

数字证书，用来证明公开密钥拥有者的身份的电子文件。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误。

数字证书通过信任链的方式来保证安全。首先，由数字证书认证机构(CA)发行了一些根证书，这些根证书往往都被广泛认可，并且已经事先储存在操作系统和浏览器内。

数字签名同样基于非对称加密原理——公钥加密的信息可以被私钥解密，同时私钥加密的信息也可以被公钥解密，而私钥是由自己保管的。

也就是说，如果发送方使用自己的私钥将信息加密，作为签名并附在消息中，而接收方可以用发送方的公钥对其进行解密，这就证明了发送方确实是私钥的拥有者，也就证明了发送方的身份。由于无法获得私钥，消息也无法在传输中被调包或者篡改。

推荐阅读《信任网络，PGP，GPG》、《公钥基础设施》

证书颁发体系了

几乎网络上所有的证书（除去用于个人用途的自签名证书以及根证书颁发机构的证书），都是由某个证书颁发机构颁发的。

证书颁发机构负责核实证书申请者的真实身份（例如我们公司网站申请SSL证书就需要提交公司营业执照的影印件，还有证明自己拥有网站域名的材料），以及吊销被泄漏和滥用的的证书。也就是说证书颁发机构，就是证书所有者身份的确认人。

一旦你信任了某个证书颁发机构，就等于信任了这个证书颁发机构所颁发的所有证书的身份确认信息！操作系统只会把确认好的身份信息展示给你！

神马是根证书颁发机构？

证书颁发机构和域名一样，是一个树状的结构，全球有为数不多的几个根证书颁发机构。这些根证书颁发机构轻易不颁发证书，因为一旦根证书颁发机构的证书被泄漏，所有直接间接的证书，都会受到严重的影响。所以，根证书颁发机构一般授权二级证书颁发机构颁发证书，一旦信任一个根证书颁发机构，等同于信任其下所有颁发的所有证书，以及其授权的二级证书颁发机构颁发的所有证书。更为严重的事情是，根证书颁发机构，是整个证书颁发体系中，唯一不受任何身份验证的。其身份的正确性，由其自行保证！也就是说，根证书颁发机构可以宣称自己是任何一个公司，没有任何人和组织可以对其进行审查！事实上，根证书颁发机构是整个证书体系中，最薄弱的环节。这就是为什么上次微软在操作系统中内置CNNIC这个流氓的根证书引起了网络上广泛的质疑。根证书几乎只能由操作系统内置，通过操作系统安装程序二进制代码的安全来确保正

如何能拿到CA的公匙呢？

我们的电脑和浏览器中已经内置了一部分权威机构的根证书，这些根证书中包含了CA的公匙。

之所以是根证书，是因为现实生活中，认证中心是分层级的，也就是说有顶级认证中心，也有下面的各个子级的认证中心，是一个树状结构，计算机中内置的是最顶级机构的根证书，不过不用担心，根证书的公匙在子级也是适用的。

客户端用CA的公匙解密数字证书，如果解密成功则说明证书来源于合法的认证机构。解密成功后，客户端就拿到了摘要。

此时，客户端会按照和CA一样的Hash算法将申请信息生成一份摘要，并和解密出来的那份做对比，如果相同则说明内容完整，没有被篡改。最后，客户端安全的从证书中拿到服务器的公匙就可以和服务器进行安全的非对称加密通信了。服务器想获得客户端的公匙也可以通过相同方法。

根证书泄露的权限

CNNIC、12306以及Alibaba,他的根证书是获取所有权限，意味着他们可以伪造微软的更新包或签名的驱动程序

12306起码还有个提示下载，Alibaba让你安装个安全控件，CNNIC是偷偷摸摸装。

未经用户许可，利用安全控件窃取系统权限，安装根证书的行为，毋庸解释，流氓无疑。所谓安全目的，均是障目之术，毫无节操。

让我们在windows系统中运行certmgr.msc 打开证书管理器，看看我们的电脑里都安装了哪些根证书。

安装该根证书的危害

安装之后，你的计算机系统（或者浏览器）会信任该「CA 机构」所签名的所有证书。根据安装说明，该证书不仅能签名用于标识网站的身份的证书，还能签名应用程序，即 .exe 和 .dll 文件。

这意味着，如果铁道部没有按照规范正确管理该根证书对应的私钥的话，一旦被滥用，或者被攻击盗用，那么：

攻击者可以实施中间人攻击，伪装成支付宝、网上银行、微信、网页邮箱等网站，获取你的登录和隐私信息，篡改网页内容，以你的身份提交转账和订单、与你的亲友同事聊天等。
攻击者可以为病毒和木马签名。拥有一个受系统信任的签名，恶意软件更容易在用户不知不觉间潜入。
这是一个 SHA1 签名的证书。因为其安全性比较低，各大浏览器厂商将逐渐淘汰该类证书。
当然还有一些其它的用法，毕竟这个证书的权限非常大。

关于这方面，请看《数字证书及CA的扫盲介绍》。

HTTPS 协议的需求是啥？

花了好多口水，终于把背景知识说完了。下面正式进入正题。先来说说当初设计 HTTPS 是为了满足哪些需求？

很多介绍 HTTPS 的文章一上来就给你讲实现细节。个人觉得：这是不好的做法。早在2009年开博的时候，发过一篇《学习技术的三部曲：WHAT、HOW、WHY》，其中谈到“WHY 型问题”的重要性。一上来就给你讲协议细节，你充其量只能知道 WHAT 和 HOW，无法理解 WHY。俺在前一个章节讲了“背景知识”，在这个章节讲了“需求”，这就有助于你理解：当初为什么要设计成这样？——这就是 WHY 型的问题。

兼容性

因为是先有 HTTP 再有 HTTPS。所以，HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。

这里所说的兼容性包括很多方面。比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS；比如对浏览器厂商而言，改动要尽可能小；……

基于“兼容性”方面的考虑，很容易得出如下几个结论：

1. HTTPS 还是要基于 TCP 来传输

（如果改为 UDP 作传输层，无论是 Web 服务端还是浏览器客户端，都要大改，动静太大了）

2. 单独使用一个新的协议，把 HTTP 协议包裹起来

（所谓的“HTTP over SSL”，实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动）

打个比方：如果原来的 HTTP 是塑料水管，容易被戳破；那么如今新设计的 HTTPS 就像是在原有的塑料水管之外，再包一层金属水管。一来，原有的塑料水管照样运行；二来，用金属加固了之后，不容易被戳破。

可扩展性

前面说了，HTTPS 相当于是“HTTP over SSL”。

如果 SSL 这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟 HTTP 搭配，还能够跟其它的应用层协议搭配。岂不美哉？

现在看来，当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。

接着刚才打的比方：如果把 SSL/TLS 视作一根用来加固的金属管，它不仅可以用来加固输水的管道，还可以用来加固输煤气的管道。

保密性（防泄密）

HTTPS 需要做到足够好的保密性。

说到保密性，首先要能够对抗嗅探（行话叫 Sniffer）。所谓的“嗅探”，通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网，那么监视者通过嗅探，就知道你在访问哪些网站的哪些页面。

嗅探是最低级的攻击手法。除了嗅探，HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如“重放攻击”（后面讲协议原理的时候，会再聊）。

完整性（防篡改）

除了“保密性”，还有一个同样重要的目标是“确保完整性”。关于“完整性”这个概念，在之前的博文《扫盲文件完整性校验——关于散列值和数字签名》中大致提过。健忘的同学再去温习一下。

在发明 HTTPS 之前，由于 HTTP 是明文的，不但容易被嗅探，还容易被篡改。

举个例子：

比如咱们天朝的网络运营商（ISP）都比较流氓，经常有网友抱怨说访问某网站（本来是没有广告的），竟然会跳出很多中国电信的广告。为啥会这样捏？因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP，ISP 很容易就可以在你访问的页面中植入广告。

所以，当初设计 HTTPS 的时候，还有一个需求是“确保 HTTP 协议的内容不被篡改”。

真实性（防假冒）

在谈到 HTTPS 的需求时，“真实性”经常被忽略。其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。

举个例子：

你因为使用网银，需要访问该网银的 Web 站点。那么，你如何确保你访问的网站确实是你想访问的网站？（这话有点绕口令）

有些天真的同学会说：通过看网址里面的域名，来确保。为啥说这样的同学是“天真的”？因为 DNS 系统本身是不可靠的（尤其是在设计 SSL 的那个年代，连 DNSSEC 都还没发明）。由于 DNS 的不可靠（存在“域名欺骗”和“域名劫持”），你看到的网址里面的域名【未必】是真实滴！

（不了解“域名欺骗”和“域名劫持”的同学，可以参见俺之前写的《扫盲 DNS 原理，兼谈“域名劫持”和“域名欺骗/域名污染”》）

所以，HTTPS 协议必须有某种机制来确保“真实性”的需求（至于如何确保，后面会细聊）。

性能

再来说最后一个需求——性能。

引入 HTTPS 之后，【不能】导致性能变得太差。否则的话，谁还愿意用？

为了确保性能，SSL 的设计者至少要考虑如下几点：

如何选择加密算法（“对称”or“非对称”）？
如何兼顾 HTTP 采用的“短连接”TCP 方式？

（SSL 是在1995年之前开始设计的，那时候的 HTTP 版本还是 1.0，默认使用的是“短连接”的 TCP 方式——默认不启用 Keep-Alive）

小结

以上就是设计 SSL 协议时，必须兼顾的各种需求。后面聊协议的实现时，俺会拿 SSL 协议的特点跟前面的需求作对照。看看这些需求是如何一一满足滴。

设计 HTTPS 协议的主要难点

设计 HTTPS 这个协议，有好几个难点。俺个人认为最大的难点在于“密钥交换”。

在传统的密码学场景中，假如张三要跟李四建立一个加密通讯的渠道，双方事先要约定好使用哪种加密算法？同时也要约定好使用的密钥是啥？在这个场景中，加密算法的【类型】让旁人知道，没太大关系。但是密钥【千万不能】让旁人知道。一旦旁人知道了密钥，自然就可以破解通讯的密文，得到明文。

好，现在回到 HTTPS 的场景。

当你访问某个公网的网站，你的浏览器和网站的服务器之间，如果要建立加密通讯，必然要商量好双方使用啥算法，啥密钥。——在网络通讯术语中，这个过程称之为“握手/handshake”。在握手阶段，因为加密方式还没有协商好，所以握手阶段的通讯必定是【明文】滴！既然是明文，自然有可能被第三方偷窥到。然后，还要考虑到双方之间隔着一个互联网，什么样的偷窥都可能发生。

因此，在握手的过程中，如何做到安全地交换密钥信息，而不让周围的第三方看到。这就是设计 HTTPS 最大的难点。

参考链接

MicroSoft TechNet, SSL/TLS in Detail
Jeff Moser, The First Few Milliseconds of an HTTPS Connection
Wikipedia, Transport Layer Security
StackExchange, How does SSL work?
http://www.codeceo.com/article/https-ssl-tls.html
http://www.codeceo.com/article/ssl-tls-run.html

摘取文章：

http://www.cnblogs.com/ttltry-air/archive/2012/08/20/2647898.html

https://www.cnblogs.com/svan/p/5090201.html

https://www.zhihu.com/question/22306245/answer/21002652

一篇文章读懂HTTPS及其背后的加密原理 https://juejin.im/post/5caab0bff265da24cf311d5b

TLS 握手优化详解 https://imququ.com/post/optimize-tls-handshake.html

转载本站文章《SSL/TLS协议的运行原理浅析—https通信过程及CA证书诠释》,
请注明出处：https://www.zhoulujun.cn/html/theory/ComputerScienceTechnology/network/2017_0118_7945.html