一.Https背景介绍：SSL/TLS协议的由来

最早期的通信是不使用SSL/TLS的HTTP通信，也就是没有加密的通信。信息传递过程中存在很多的问题：被第三方窃听，被第三方修改通信内容，被第三方冒充他人身份参与通信。大家都希望能有一种加密的信息传输，能够保证信息安全，SSL/TLS协议诞生。

历史发展

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

1994年，NetScape公司（网景公司）设计了SSL 1.0版，但是未发布；

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

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

1999年，互联网工程任务组（IETF）标准化了一种名为 TLS 1.0 的新协议，这是SSL的升级版本；

2006年和2008年，TLS两次升级，分别更新至TLS 1.1和TLS 1.2(修复了1.1中的漏洞)。紧接着2011年发布了TLS 1.2的修订版；

然而直到2013年大部分的浏览器才开始支持TLS 1.2。

2018.8 ，TLS 1.3的最终版本发布，包含许多安全性和性能改进。

由此可见，SSL和TLS简单地可以理解为是同一种协议的不同版本，故它们总是成对出现。

TLS 1.3于2018.3月发布，你的浏览器应该已经支持它了。
TLS 1.3进一步改进了安全性，移除了一些不安全的特性。

实际上现代的浏览器已经基本不使用SSL，使用的都是TLS， SSL 3.0于2015年已经寿终正寝 —— 各大浏览器也不支持了。但是由于SSL这个术语存在的时间太长，很多地方还是广泛的使用它，但是要清楚其实它说的是TLS。
有调查显示现在绝大部分浏览器（> 99.5%)都使用TLS 1.2或者TLS 1.3。只有不足1%的浏览器仍然使用TLS 1.0或者TLS 1.1。
TLS 1.2仍然是主流协议（本文写于2020年初），相信将来逐渐TLS 1.3将会作为主流协议。
很多浏览器将会开始不支持TLS 1.0和1.1:

SSL/TLS在TCP/IP参考模型中的位置

SSL/TLS其实是一个协议族而非单个协议，由SSL/TLS握手协议、修改密文协议、报警协议以及记录协议四部分组成。

SSL/TLS协议自身可分为两层：主要的有SSL记录协议和SSL握手协议。

SSL记录协议建立在可靠的传输协议，如TCP之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

SSL握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商交换密钥等。

使用SSL/TLS协议，能够使我们在互联网上的通信做到“看不懂、改不掉、仿不了”，这组安全协议真的很复杂！分别对信息安全的机密性、完整性和可认证性做了确认。

机密性：当通信双方确信没有人能够理解他们的对话内容时，通信被认为是保密的。使用对称加密可以实现通信的机密性。

完整性：SSL/TLS具有校验机制，握手协议中定义了MAC，一旦信息被篡改，通信双方会立即发现并采取措施。

可认证性：为防止恶意攻击者冒充合法网站，网站需要通过证书和公钥加密来向Web浏览器证明自己的身份，在此过程中，浏览器需要两件事情来信任证书：证明另一方是证书的持有者，并证明证书是可信的。

在互联网通信中，通过建立共享密钥和证明证书的所有权的过程来实现机密性和可认证性，SSL/TLS协议则是通过“握手”流程来实现这两点，当中的完整性是由握手协议定义的MAC来实现。那么，如此至关重要的“握手”流程是怎么样的呢？

题外话

将公钥放在数字证书中，签发证书的CA是被信任的，故公钥是被信任的。

2.为什么要这么复杂地产生会话密钥，何不直接传输商定好的密钥更方便？

随着攻击手段的不断发展，任何传输过程都不受信任，即使将会话密钥进行加密传输，都有被窃取的危险。因此采用Diffle-Hellman密钥协商算法，在传输过程中能够始终不出现会话密钥本身，会话密钥仅在握手结束时在客户端和服务器本地各自生成。

3.既然产生对称的会话密钥很复杂，为什么不采用可避免密钥泄露问题的公钥加密？

因为公钥加密相比于对称加密，计算速度很慢，不适用于通信时的大量数据加密。

客户端无法看见服务器的私钥，那就让服务器证明它可以使用私钥即可，服务器使用私钥对客户端已知的信息进行数字签名，若客户端能够用服务器的公钥认证该数字签名，则可确定对方持有相应私钥。