1、 为什么采用HTTPS协议通信

1.1 HTTP存在的安全问题

HTTP 由于是明文传输，所以安全上存在以下三个风险

1、 【窃听风险】：通信使用明文，内容可能被窃听
2、 【冒充风险】不验证通信方的身份，因此有可能遭遇冒充
3、 【篡改风险】：无法证明报文的完整性，所以有可能遭到篡改

1.2 HTTPS解决了什么

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险

1、 【信息加密】:所有信息都是加密传播，第三方无法窃听。
2、 【身份认证】:配备身份认证，防止身份被冒充。
3、 【校验机制】：一旦报文被篡改，通信双方会立刻发现。

1.3 小结

HTTPS就是在原HTTP的基础上加上一层用于数据加密、解密、校验、身份认证的安全层SSL/TSL，用于HTTP存在的安全隐患。

2、 HTTPS和HTTP的区别

1、 HTTPS是加密传输协议，HTTP是明文传输协议;
2、 HTTPS 协议需要向 CA（证书权威机构）申请数字证书；
3、 HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO（比如：为保护用户隐私安全,谷歌优先索引HTTPS网页）
4、 HTTPS标准端口443，HTTP标准端口80;
5、 HTTPS基于传输层，HTTP基于应用层;
6、 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大概的工作流程

1、 客户端向服务器端索要并验证公钥。
2、 双方协商生成”对话密钥”（三个随机数）。
3、 双方采用”对话密钥”进行加密通信。

其中前2个步骤是SSL握手过程，是整个https通信过程中用到[非对称加密]的阶段.

SSL握手过程详解*

握手阶段一共有4次通信，且都是明文的

1、 客户端向服务器发起加密通信的请求，这次请求称为ClientHello，发送的内容包括

一个随机数x，用来后续生产会话密钥 客户端支持的加密算法 客户端支持的SSL协议版本 支持的压缩方式

1、 服务端收到请求后，响应客户端请求，这次请求称为ServerHello，返回如下数据

确认支持的SSL协议版本 确认加密算法 服务端公钥，为了数据安全，会放到证书中 一个随机数y，用来后续生产会话密钥

1、 客户端收到服务器响应后，首先验证证书的有效性（即是否认证机构颁发，是否在有效期内），验证通过后，会从证书中取出公钥，并向服务端发送如下数据

一个随机数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中，使用 证书 + 数字签名 来解决这个问题。假设加密方式是MD5，将网站的信息加密后通过第三方机构的私钥再次进行加密，生成数字签名。

数字签名= 证书中加密后的证书编号
数字证书 = 网站信息 + 数字签名

假如中间人拦截后把服务器的公钥替换为自己的公钥，因为数字签名的存在，会导致客户端验证签名不匹配，这样就防止了中间人替换公钥的问题。

但是第三方机构的公钥怎么跑到了客户端的机器中呢？世界上这么多机器。 其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构CA列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。

4.4 为什么会出现数字签名

第三方认证机构是一个开放的平台，我们可以去申请，中间人也可以去申请

如果没有签名，只对网站信息进行第三方机构私钥加密的话，会存在下面的问题： 因为没有认证，所以中间人也向第三方认证机构进行申请，然后拦截后把所有的信息都替换成自己的，客户端仍然可以解密，并且无法判断这是服务器的还是中间人的，最后造成数据泄露。

数字签名，解决了同一机构颁发的不同证书被篡改问题。

4.5 小结

我们通过以上的四个问题，尝试还原了HTTPS的设计过程。这样，我们也就明白了为什么HTTPS比HTTP多那么多次的交互，为什么HTTPS的性能会差，以及找到HTTPS的性能优化点。

而上面一大堆工作都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通信时双方使用这个对称加密算法进行加密解密，这里就不做详细描述了。

5、 总结

HTTPS就是使用SSL/TLS协议进行加密传输，让客户端拿到服务器的公钥，然后客户端随机生成一个对称加密的秘钥，使用公钥加密，传输给服务端，后续的所有信息都通过该对称秘钥进行加密解密，完成整个HTTPS的流程

文章永久链接：https://tech.souyunku.com/31647