HTTP协议

Https协议是一种在Http协议基础上上进行加密的协议

浏览本篇博客之前请先了解什么是公钥和私钥

1.什么是Http协议

Http（Hyper Text Transfer Protocol，超文本传输）协议，位于TCP/IP四层模型中的应用层

Http协议通过请求/响应的方式在客户端和服务端进行通讯

但是Http协议不够安全，它的信息传输以明文方式传输，不做任何加密，相当于数据在网络上”裸奔“

2.加密

假设小明想给小红发送消息，因为http是明文传输，很有可能有人恶意截获信息甚至篡改信息，这种行为叫做中间人攻击

1）对称加密

①加密方式

小明和小红可以约定一种对称加密，方式，使用随机生成的密钥进行加密，第一次先告诉对方要用的密钥，之后两个人的信息在发送的时候用密钥加密，接收的时候用密钥解密

②风险

虽然使用对称加密可以提高数据的安全性，但是第一次的对话还是明文传输的，中间人可以截获第一次的对话来获取密钥，从而使中间人可以破解之后的对话

2）非对称加密

我们可以使用非对称加密，为密钥的传输做一层额外的保护

①加密方式

小明访问小红

在通信之前，小红先把自己的公钥Key红公发送给小明

小明拿到小红的公钥之后，自己生成一个用于对称加密的密钥Key称，并用接收到的Key红公对Key称进行加密，并传回给小红

小红拿到响应的这一大坨后，用自己的私钥将外层的Key红公解密开，拿到内部的Key称，之后就和对称加密后面一样，用Key称进行加密传输

②风险

中间人虽然不知道小红的私钥，但是可以在第一次小红发给小明Key红公时将其截获，并将自己的公钥Key中公告诉小明

这样小明就会以为小红告诉他加密的公钥是Key中公，那么他就会用Key中公进行加密，产生的就会是由Key中公加密的key称：

小明响应给小红这一坨时再次被中间人截获，中间人用自己的私钥解开Key中公的加密，就成功获取到了Key称，他再将Key称用key红公加密发给小红

小明小红建立了正常的、以Key称为密钥的加密传输，中间人却在中间悄无声息的获得了密钥，他能随意的通过获得的Key称破解传输内容

3）证书

魔高一尺，道高一丈

出现上述风险的时候，有必要引入第三方，一个权威的证书颁发机构（CA）来解决
数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的，或者证书可以用来确认对方的身份
证书的部分关键信息如下，主要作用通过下面的流程大家就能明白了

流程

作为服务端的小红把自己的公钥Key红公发给证书颁发机构（CA）来申请证书

CA用自己的私钥Key书私对Key红公进行加密，并且通过服务端网址等信息生成一个证书签名，并对证书签名也用Key书私加密，再将被加密过的Key红公和Key书私还有其他信息一起制作成证书

证书制作完成后，机构把证书发送给小红

这之后如果小明要访问小红，小红告诉小明的就不是自己的公钥Key红公了，而是把证书传过去，证书里有被Key书私加密过的Key红公

小明拿到证书之后先检查证书的真伪，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥Key书公，小明拿出对应CA的Key书公将证书解密，得到证书签名

接下来小明按照根据相同的签名规则，自己也生成一个证书，然后将两个证书对比，如果两个证书一致，则说明证书有效

证书验证有效后，小明就可以放心的使用Key书公解密证书，得到Key红公

后面的步骤与非对称加密的后续相同：

小明生成Key称，用Key红公将其加密，发给小红

小红用自己的私钥解密得到Key称，后续的传输小红小明用Key称加密自己传送的数据

为什么中间人截取替换证书不起作用

假设中间人要做这样的事：小明要访问小红，小红会将证书发给小明，小红把证书发给小明的时候，中间人截取了小红的证书，然后用自己的公钥申请证书，替换掉小红的证书发给小明

但是没有什么卵用，因为证书的签名是由服务端（这里也就是小红）的网址形成的

小明拿到证书解析发现这的确是一个权威机构发的证书，可是证书中服务端的地址（中间人的地址）和小明要访问的地址（小红的地址）不匹配，小明就知道中间有人捣乱

3. HTTPS

上述的就是HTTPS的主体思想，HTTPS在HTTP基础上增加了SSL安全层，刚才的一系列认证过程就是在SSL层实现的

---

感谢洋洋姐对证书工作原理的解释

参考：程序员小灰-漫画：什么是HTTPS协议