HTTPS协议

首先简介HTTP协议

超文本传输协议，位于TCP/IP四层模型当中的应用层。HTTP协议通过请求/响应的方式，在客户端和服务端之间进行通信

HTTP致命缺点

明文传输，不够安全

演变流程

A是客户端，B是服务端
有一天A发送请求给B

不巧遭受中间人攻击（专业名字）

然后就GG,赶快去哄星星咯

解决思想演变

①对称加密

中间人说小菜一碟，我截获你们第一次交换密钥的对话就好了

②非对称加密+对称加密

非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。

A收到公钥KEY1后把对称的密钥Key2用公钥KEY1加密后给B

两人就可以利用Key2进行对称加密的通信了

中间人采用三十六计之-偷天换日

然后

这样一来，两个人后续的通信尽管用Key2做了对称加密，但是中间人已经掌握了Key2，所以可以轻松进行解密。

③引入第三方，一个权威的证书颁发机构（CA）来解决

到底什么是证书呢？证书包含如下信息？

具体流程：

1.作为服务端的B，首先把自己的公钥KEY1发给证书颁发机构，向证书颁发机构申请证书。
2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端B。
3.当A向B红请求聊天的时候，B不再直接返回自己的公钥，而是把自己申请的证书返回给A。

4.A收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以A只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。接下来，A按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。验证成功后，A就可以放心地再次利用机构公钥，解密出服务端B的公钥Key1

5.最后，B用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信
试想一下，中间人能够偷天换日换证书吗？
不能，因为证书的签名是由服务端的网址等信息生成（网址可是唯一的），并经过机构私钥加密，所以说中间人还不能纂改

这就是HTTPS的主题思想

HTTPS协议在HTTP基础之上增减了SSL安全层 上面的一系列认证流程就是在SSL层完成的