加密的问题

对称加密

HTTP的通信是明文的，任何一个人都可以监听上面的通信，截取里面的数据包。最容易想到的解决方法无非就是加密。

每次传输之前把消息用加密算法加密，服务器收到了以后再解密。

如下图所示

image.png

这种加密和解密用的是同一个密钥的算法称为对称加密算法。那么实际上加密和解密算法是公开的，密钥是保密的

那么问题就来了，如果密钥在网络上发送的时候被截取了怎么办，也就是说密钥同样不能在网络上传输，但是加密双方都必须知道。

非对称加密

之前的算法需要协商一个保密的密钥，而这个密钥在网络上传输的时候存在被窃取的风险。然后出现了一个RSA非对称加密算法。

这个算法有一对密钥，一个是私钥，它是保密的，一个是公钥，是对外公开的。

那么用私钥加密的数据，只能用对应的公钥来解密
同样，用公钥加密的数据，只有对应的私钥才能解密。

于是浏览器给服务器发消息的时候，浏览器先使用服务器的公钥进行加密，然后服务器可以使用自己的私钥去解密。

反之亦然，服务器给浏览器发信息的时候，使用浏览器的公钥进行加密。

非对称加密 + 对称加密

使用非对称加密好是好，但是特别的慢。相对于非对称加密而言，对称加密会快很多。那么能不能折中一下呢？

我们知道之前用对称加密的时候，问题在于密钥无法安全传输。那么现在能不能先对密钥使用非对称加密，这样保证了密钥的安全传输。等到密钥被对方收到了以后，就使用对称加密，这样可以兼顾安全和性能呢。

身份认证的问题

上面说了，可以对密钥进行非对称加密，对报文进行对称加密，这样可以保证性能和安全性。但是新的问题来了，我们怎么保证对方的身份。也就是说如果服务器给浏览器发的公钥给中间人截取了，然后冒充服务器给浏览器发了一个公钥，这个时候，浏览器并不知道这一切，所以会使用中间人的公钥进行加密，中间人当然就可以解密到消息了。

这就如同古代的时候，新上任的县官被人半路上被绑匪给截了，然后绑匪拿着他的印信冒名顶替，下面的人并不知道此人并非真实县官，这样绑匪自然可以窃取各种机密。

所以问题在于公钥是公开的，完全可以被冒名顶替

公证处

所以问题根源在于，如何证明这个公钥确实是服务器发出来的。

这个问题在现实中就有，公证处就是这样的第三方的存在，他提供的资料受到大家的信任。所以我们也可以搞一个认证中心，给大家颁发一个数字证书，证明这个人的身份。同时证书里面一定有这个人的公钥。

但是证书依然有怎么安全传输，怎么避免被篡改的问题。我们可以使用HASH算法生成一个消息摘要，这就是数字签名。

HASH算法有个特性，只要输入有变化，那生成的数字签名就会有巨大的变化，这样就可以防篡改。

中间人说，虽然改不了公钥，但是可以替换整个原始的信息啊。就如果我们破解开机密码一样，不也是把原来加密以后的密码文件给替换了吗？

道高一尺，魔高一丈，我们再让公信处（CA）用它的私钥对消息摘要加密，形成签名。

原始信息 + 数字签名 = 数字证书

image.png

这样有了第三方的证书，相当于有个参考。我们可以用CA的公钥对数字签名进行解密，以此为基线
当服务器把它的证书给我们的时候，我们可以使用相同的Hash算法生成消息摘要，然后与“基线”对比，就知道是否被篡改过了没。

image.png

总结一下，因为公钥传输有可能被截取，所以我们希望有一个第三方机构能提供基线，我们只要对比基线就知道是否被人篡改过了。这样每个网站它的基线应该是不同的，所以可以使用HASH算法对网站的个人信息生成一个消息摘要。那么我们只需要核对从网站收到的消息摘要与第三方给的消息摘要是否是一样的就可以了。

好了，保证基线正确非常的关键，而第三方机构的证书同样存在没有加密的问题，容易被篡改的问题。

加密的问题：可以让第三方机构使用其私钥对基线加密，我们用其公钥解密即可。
容易被篡改的问题：无解，只能说对CA进行信用分级，在操作系统/浏览器内置一些顶层的CA证书，高层的CA给底层的CA做背书。

这样，网站在给我们发送公钥的时候，实际上是把公钥和加密后的消息摘要放到一起发过来的，我们

使用CA的公钥对加密后的消息摘要进行解密，得到基线
再对含有公钥的个人信息同样使用HASH算法也得到消息摘要

如果没有被篡改过，这两者应该是相等的

HTTPS

image.png

首先浏览器请求服务器的公钥
服务器返回一个含有公钥的数字证书，这个数字证书怎么得到的呢？由含有公钥的原始数据进行HASH以后，再使用CA私钥加密得到数字签名，再和原始数据一起组成了数字证书
浏览器通过数字证书，既验证了服务器的身份，又得到了公钥
使用公钥加密对称加密的密钥
使用对称加密进行通信