1. 为什么采用HTTPS协议通信
1.1 HTTP存在的安全问题
HTTP 由于是明文传输，所以安全上存在以下三个风险
- 【窃听风险】：通信使用明文，内容可能被窃听
- 【冒充风险】不验证通信方的身份，因此有可能遭遇冒充
- 【篡改风险】：无法证明报文的完整性，所以有可能遭到篡改
1.2 HTTPS解决了什么
HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险
- 【信息加密】:所有信息都是加密传播，第三方无法窃听。
- 【身份认证】:配备身份认证，防止身份被冒充。
- 【校验机制】：一旦报文被篡改，通信双方会立刻发现。
1.3 小结
HTTPS就是在原HTTP的基础上加上一层用于数据加密、解密、校验、身份认证的安全层SSL/TSL，用于HTTP存在的安全隐患。
2. HTTPS和HTTP的区别
- HTTPS是加密传输协议，HTTP是明文传输协议;
- HTTPS 协议需要向 CA（证书权威机构）申请数字证书；
- HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO（比如：为保护用户隐私安全,谷歌优先索引HTTPS网页）
- HTTPS标准端口443，HTTP标准端口80;
- HTTPS基于传输层，HTTP基于应用层;
- HTTPS在浏览器显示安全锁，HTTP没有显示。
简述：HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）协议代替而已，说白了，HTTPS是身披 SSL 外壳的 HTTP。
3. 认识SSL/TSL
3.1 什么是SSL/TSL
SSL是什么？
HTTP之下TCP之上的一个协议层，基于HTTP标准并对TCP传输数据时进行加密。
那TLS又是什么？
TSL是SSL协议的升级版，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。现在习惯将这个两个组合在一起称为SSL/TLS，只要知道它是一种用于加密的安全协议就好了
事实上我们现在用的都是TLS，但因为历史习惯，SSL这一术语更为常用，以下我也直接把SSL/TSL简称为SSL
3.2 SSL大概的工作流程
- 客户端向服务器端索要并验证公钥。
- 双方协商生成”对话密钥”（三个随机数）。
- 双方采用”对话密钥”进行加密通信。
其中前2个步骤是SSL握手过程，是整个https通信过程中用到[非对称加密]的阶段.
SSL握手过程详解*
握手阶段一共有4次通信，且都是明文的
- 客户端向服务器发起加密通信的请求，这次请求称为ClientHello，发送的内容包括
一个随机数x，用来后续生产会话密钥 客户端支持的加密算法 客户端支持的SSL协议版本 支持的压缩方式
- 服务端收到请求后，响应客户端请求，这次请求称为ServerHello，返回如下数据
确认支持的SSL协议版本 确认加密算法 服务端公钥，为了数据安全，会放到证书中 一个随机数y，用来后续生产会话密钥
- 客户端收到服务器响应后，首先验证证书的有效性（即是否认证机构颁发，是否在有效期内），验证通过后，会从证书中取出公钥，并向服务端发送如下数据
一个随机数Z，用来后续生产会话密钥，注意这个随机数会用公钥加密一个通知，告诉服务端，后续通信都用商定的加密方式和会话密钥进行 一个通知，告诉服务端，客户端握手结束
上述三步完成后，客户端就拥有了三个随机数，然后就用这三个数配合非对称加密算法生成一个【会话密钥】
4.服务端收到最后一个随机数后，用私钥解密后就拥有了跟客户端一样的三个随机数，然后生成跟客户端相同的会话密钥，并做最后的回应
上述4次通信完成后，客户端和服务端各自拥有了一个相同的会话密钥
4. 白话HTTPS安全通信原理
我们先从一个基本的聊天软件说起，我们要实现A（客户端）能发一个hello消息给B（服务端），通过一幅幅流程图，来分析从HTTP到HTTPS的演变过程通。
4.1 为什么会出现对称加密
4.1.1 HTTP明文传输
最早HTTP中是明文传输的，客户端发出请求，服务端进行响应，就是这么简单
4.1.2 对称加密的出现
对称加密：指的就是加、解密使用的同是一串密钥，所以被称做对称加密。
常见的对称加密算法：DES，AES等
但是我们对数据进行加密了，问题解决了吗？
-
多个客户端怎么办？
在WWW环境下，我们的Web服务器的通信模型没有这么简单，有成千上万的客户端。
想一想，loading........
答案是：如果对每一个客户端都用不同的秘钥进行传输
-
对称加密秘钥如何传输？ 我们对每个客户端应用不同的对称加密秘钥，服务器端怎么告诉客户端该使用哪种对称加密算法呢？ 只能是在一端生成一个秘钥，然后通过HTTP传输给另一端
4.2 为什么会出现非对称加密
既然对称加密行不通？可以换个思路，用“非对称加密”代替“对称加密”。
非对称加密：指的是加、解密使用不同的密钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。反之，私钥加密的信息，只有公钥才能解密 最常用的非对称加密算法：RSA
私钥只保存在服务器端，公钥可以发送给所有的客户端。
在传输公钥的过程中，肯定也会有被中间人获取的风险，但在目前的情况下，至少可以保证客户端通过公钥加密的内容，中间人是无法破解的，因为私钥只保存在服务器端，只有私钥可以破解公钥加密的内容。
4.3 为什么会出现数字证书
- 公钥替换问题
如果非对称加密中公钥被中间人拿到篡改呢，像下面这样
- 数字证书解决公钥替换？
非对称加密中公钥被掉包，是因为客户端无法分辨传回公钥的到底是中间人，还是服务器，这也是密码学中的身份验证问题 在HTTPS中，使用 证书 + 数字签名 来解决这个问题。
数字签名= 证书中加密后的证书编号
数字证书 = 网站信息 + 数字签名
假如中间人拦截后把服务器的公钥替换为自己的公钥，因为数字签名的存在，会导致客户端验证签名不匹配，这样就防止了中间人替换公钥的问题。
4.4 为什么会出现数字签名
第三方认证机构是一个开放的平台，我们可以去申请，中间人也可以去申请
数字签名，解决了同一机构颁发的不同证书被篡改问题。
4.5 小结
我们通过以上的四个问题，尝试还原了HTTPS的设计过程。这样，我们也就明白了为什么HTTPS比HTTP多那么多次的交互，为什么HTTPS的性能会差，以及找到HTTPS的性能优化点。
而上面一大堆工作都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通信时双方使用这个对称加密算法进行加密解密，这里就不做详细描述了。
5. 总结
HTTPS就是使用SSL/TLS协议进行加密传输，让客户端拿到服务器的公钥，然后客户端随机生成一个对称加密的秘钥，使用公钥加密，传输给服务端，后续的所有信息都通过该对称秘钥进行加密解密，完成整个HTTPS的流程
