5分钟图解HTTPS加密原理，SSL/TLS尽在掌握！
互联网时代，我们无时不刻沉浸在网络的浪潮。不知道大家是否注意到，在访问一写涉及到支付/金融/登录/网购等敏感业务时，会发现这些网站都会被重定向到https:// 的 URL ，比如：
- 地址为绿色, 表示使用了加密传输，安全且可信任;
- 地址为红色, 则表示虽然开启了加密, 但网站身份未验证, 不保证中间不会被人篡改。
从我们在地址栏敲下 https:// 网站那一刹那, 到内容显示到我们面前, 中间经过了哪些过程了? 浏览器根据什么来判断, 当前网站网址是安全的还是未验证的? 今天就跟大家一起探索互联网外交安全策略SSL/TLS协议运行机制。
SSL/TLS协议的由来
由来
最早期的通信是不使用SSL/TLS的HTTP通信，也就是没有加密的通信。在人们的信息传递过程中存在了很多的问题：被第三方窃听，被第三方修改通信内容，被第三方冒充他人身份参与通信。种种信息安全问题得到大家的重视。大家都希望能有一种加密的信息传输，能够保证信息安全，SSL/TLS协议诞生。
历史发展
互联网加密通信协议的历史，几乎与互联网一样长：
1994年，NetScape公司设计了SSL 1.0版，但是未发布；
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞；
1996年，SSL 3.0版问世，得到大规模应用；
1999年，互联网工程任务组（IETF）标准化了一种名为TLS的新协议，这是SSL的升级版本；
2006年和2008年，TLS两次升级，分别更新至TLS 1.1和TLS 1.2。紧接着2011年发布了TLS 1.2的修订版；
TLS 1.3的最终版本于2018年8月发布，包含许多安全性和性能改进。
由此可见，SSL和TLS简单地可以理解为是同一种协议的不同版本，故它们总是成对出现。
SSL/TLS在TCP/IP参考模型中的位置
SSL/TLS其实是一个协议族而非单个协议，由SSL/TLS握手协议、修改密文协议、报警协议以及记录协议四部分组成。
SSL/TLS协议自身可分为两层：主要的有SSL记录协议和SSL握手协议。
SSL记录协议建立在可靠的传输协议，如TCP之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
SSL握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商交换密钥等。
SSL/TLS如何实现安全保障呢
使用SSL/TLS协议，能够使我们在互联网上的通信做到“看不懂、改不掉、仿不了”，这组安全协议真的很复杂！分别对信息安全的机密性、完整性和可认证性做了确认。
机密性：当通信双方确信没有人能够理解他们的对话内容时，通信被认为是保密的。使用对称加密可以实现通信的机密性。
完整性：SSL/TLS具有校验机制，握手协议中定义了MAC，一旦信息被篡改，通信双方会立即发现并采取措施。
可认证性：为防止恶意攻击者冒充合法网站，网站需要通过证书和公钥加密来向Web浏览器证明自己的身份，在此过程中，浏览器需要两件事情来信任证书：证明另一方是证书的持有者，并证明证书是可信的。
在互联网通信中，通过建立共享密钥和证明证书的所有权的过程来实现机密性和可认证性，SSL/TLS协议则是通过“握手”流程来实现这两点，当中的完整性是由握手协议定义的MAC来实现。那么，如此至关重要的“握手”流程是怎么样的呢？
详解“握手”流程
"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。
客户端发出请求（ClientHello）
客户端向服务器发出请求，会带上以下信息：
- 一个客户端生成的随机数
- 支持的加密方式，即图中的Cipher Suite
- 支持SSL/TLS协议的版本号
- Session ID，如果是之前断开的会话，会带上Session ID用来恢复会话。
- 签名使用的哈希算法
服务器回应（SeverHello）
服务器响应客户端的请求，如果上一步带上了Session ID，则直接恢复会话，否则带上以下信息给客户端：
- 选择SSL/TLS协议版本号
- 选择加密方式
- 一个服务器生成的随机数
- 服务器证书
客户端会在这里校验服务器证书的合法性，包括检测证书有效时间，以及证书中域名与当前会话域名是否匹配，并沿着信任链查找顶层证书颁发者是否是操作系统信任的CA机构。
客户端回应
客户端校验服务器证书的合法性，生成premaster secret，向服务器发送以下信息：
- 用服务器证书取出的公钥加密后的premaster secret，这里的premaster secret其实是另一个随机数
- 加密约定改变通知，通知服务器，以后的通信都适用协商好的加密方法和密钥进行加密
- 客户端握手结束通知。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供服务器校验。
服务器最后确认
这是握手过程的最后一步，服务器会把以下信息发送给客户端：
- 加密约定改变通知，通知客户端，以后的通信都适用协商好的加密方法和密钥进行加密
- 服务器握手结束通知，该报文也作为校验消息，供客户端验证。
到这个时候，客户端和服务器同时拥有了3个随机数，使用这三个随机数生成的密钥，将被用于后续通信的对称加密。
题外话
1.如何保证公钥属于被访问的合法网站？
将公钥放在数字证书中，签发证书的CA是被信任的，故公钥是被信任的。
2.为什么要这么复杂地产生会话密钥，何不直接传输商定好的密钥更方便？
随着攻击手段的不断发展，任何传输过程都不受信任，即使将会话密钥进行加密传输，都有被窃取的危险。因此采用Diffle-Hellman密钥协商算法，在传输过程中能够始终不出现会话密钥本身，会话密钥仅在握手结束时在客户端和服务器本地各自生成。
3.既然产生对称的会话密钥很复杂，为什么不采用可避免密钥泄露问题的公钥加密？
因为公钥加密相比于对称加密，计算速度很慢，不适用于通信时的大量数据加密。
4.在握手过程中如何确认服务器是私钥持有者？
客户端无法看见服务器的私钥，那就让服务器证明它可以使用私钥即可，服务器使用私钥对客户端已知的信息进行数字签名，若客户端能够用服务器的公钥认证该数字签名，则可确定对方持有相应私钥。
今天比昨天更博学了！
