Linux网络——HTTPS详解

HTTPS

这也是一个应用层协议，是在HTTP协议的基础上引入了一个加密层

为什么要加密呢，这主要是因为如果不对传输主体加密，当中间人拿到数据后，可以对其中的关键内容进行保存甚至篡改

例如说把服务器ip改成自己的，假装自己是服务器跟你通信

加密

加密就是把明文转换成暗文，解密则相反

在加密和解密的过程中可能需要某些数据进行辅助，这些数据称为密钥

例如说我们双方通信规定和把数据对114514按位异或

我要传输5201314这个数据，异或之后就是5169904

然后这个数据在网络上传输

你收到5169904之后，再对114514按位异或，就能得到5201314了

这样我们其实就完成了一次加密通信，但是实际情况远比这个复杂

常见加密方式

对称加密

刚刚我们传输的这个过程其实就是对称加密，我们使用了同一个密钥114514，也称之为单密钥加密

常见的由DES 3DES AES TDEA Blowfish RC2

这种加密的方式好处就是计算量小，当然是对于计算机来说

速度快，算法公开，加密效率高

但是有一个问题，我要怎么让你知道我使用的是什么方式加密呢

直接写在明文里吗，那这样别人拿到不也能解密

除此之外，服务器也不能记住所有客户端的密钥，那也太二了

因此这个方式是有很大问题的

非对称加密

这个方式就是说，一个密钥不够用了，那我们设置两个吧

一个是公开密钥，另一个是私有密钥

公开密钥谁都能拿到，谁都能用，但是私有密钥只有我自己用

信息用公钥进行加密，编程密钥，用私钥进行解密，变成明文

但是私钥公钥的加解密非常复杂，而且涉及到数论的知识，实际上运算速度也很慢

非对称+对称

因为如果双方都只使用非对称加密，这样做效率十分低下，而且也是有安全问题的

因此还是需要对称加密的

流程是这样的，当客户端和服务器第一次交流时，客户端获取到服务器中生成的公钥S，而服务器自身有私钥S’

而客户端在本地也生成一个对称加密的密钥C，用公钥S加密之后传递给服务器

之后他俩传递信息就用的是这个对称加密的密钥C

但是这样安全吗？？

也不安全，如果中间人就盯着你们俩

中间人也准备了公钥M，私钥M’

当客户端给服务器发送请求时，服务器需要把自己的公钥S返还给客户端

这个时候中间人就拿到报文，偷偷存了一份公钥S，然后进行替换！把服务器的公钥S换成自己的公钥M，然后传给客户端

此时客户端也不道啊，蒙在鼓里，自己的C用M加密，再发回去

中间人用M’解密，得到C，再用S加密传给服务器

这样做双方的交流过程其实是完全在中间人的眼里的！！

数据指纹

数据指纹本身并不是加密的机制，而是一种思想

将数据或者数据的一部分，通过哈希算法生成一串固定的内容

我们可以使用这种思想来存储或者查找数据，因为一旦数据的内容不同了，哈希生成的结果就不同了

证书

既然上面说的非对称加密都不安全了，还有解决方案吗

实际上产生这些问题的原因就是无法确定收到的那个公钥是服务器的还是中间人的

因此我们只需要让服务器的公钥有一个特别显眼的标识

CA认证

服务器在使用HTTPS之前，需要像CA机构申请一份数字证书，里面包含了证书申请者的各种信息，签发信息、域名、申请者、有效时间、最重要的是公钥

就像开锁师傅一定都是在公安局备案过的一样

CA认证也就是权威认证机构颁发的证书，平台也会特定审查，这个认证过程都挺繁琐的，一般也都是找第三方平台帮忙解决

数字签名

数字签名其实就是对数据指纹进行加密，主要是用于验证的，防止数据被篡改

当我们生成了认证证书之后，如何防止证书被篡改呢

CA机构把证书的内容进行数据指纹的提取，然后用CA机构私钥加密，得到一个数字签名

跟随着证书一起发去，当对方收到这些之后，用公钥对数据签名进行解密，然后和证书进行比对，一旦出现差错，就说明证书有问题

这样做，即便是服务器自身想要修改公钥都是不行的，只能向CA机构申请，因为数字签名是由CA私钥生成的，一旦篡改就会被认为不安全

非对称+证书+对称

当客户端访问服务器时，服务器会给客户端返回这个证书

客户端会对证书进行校验，防止证书伪造

判断证书的有效期，颁发机构是否信任，证书是否篡改

这样就能确认公钥一定是服务器的而非中间人的了，后面的对称也都是安全的了

中间人

这时候中间人如果想要篡改证书几乎是不可能的了

如果说是要掉包证书，不能只改公钥，因为哈希值不一样，他没有服务器的私钥，算不出来正确的哈希值

只能向CA机构申请真的证书来掉包

但是真证书里面是有服务器的域名认证信息的，客户端收到之后就一脸蒙蔽

再其次这个申请确实麻烦，需要成本