HTTPS原理

HTTPS原理

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性.----百度词条

加密

传输过程中报文做了加密处理，保证了安全，现有加密方式一般有对称加密和非对称加密2种方式。

采用对称加密，需要通信双方事先约定好加密密钥，约定密钥这个不难，问题在于怎么传输这个密钥，直接明文传输这个密钥，那整个通信也是脱裤子放屁多此一举。

采用非对称加密，非对称加密分为公钥和私钥，公钥加密的数据可以用私钥解密，私钥加密的数据可以用公钥解密，发送方A可以用B的公钥进行加密，接受方B可以自己的私钥解密，这样做的确满足了安全的要求，但是非对称加密相对于对称加密来说性能上差了百倍，如果https单纯采用非对称加密那么通信体验上来说很难接受。

回过头来看对称加密的问题点在于密钥的安全性传输，解决了这个问题，肯定优先采用对称加密进行传输，想到非对称加密能保证安全传输，我们可以将对称加密的密钥通过非对称加密传输来保证安全，之后数据的传输使用对称加密保证安全同时也兼顾性能。

讲到这是不是整个https的原理就解开了呢？

大家来看个问题，上述过程有个风险点在于第一步，通信方B传输自己公钥的过程中有安全隐患，如果有黑客C在半路截取了你的报文，把B的公钥换成黑客C自己的的公钥，然后拦截A的报文用自己的私钥解密，在通过B的公钥加密来伪造报文和B通信

上述的风险点在于我们无法确认B公布公钥真的属于B，于是引入了数据签名，B把自己的个人信息，公钥等信息一起做了数字签名来防止别人篡改，但是这样的确公布的信息没法篡改了，但是黑客可以将整个B公布的信息全部换成自己的信息，伪造整个签名。

所以单纯的签名没有用，还需要进一步的处理，于是乎引入的公证机关CA（类似我们现实中的工作处），CA用他们的私钥对B的签名进行加密，这个加密串，我们把这个加密串加上B原始的信息统一为数字证书公布出去，A拿到证书后，先用同样的签名算法对B的信息进行签名，然后用CA的公钥去对证书里的加密串解密，对比2者是否相同，如果相同认为证书可信赖。

这里还是存在一个问题CA的公钥怎么安全传输？其实CA的公钥由CA的上一级来验证，这样一级一级往上形成了一条CA链，最顶层的是浏览器默认信任的根证书。


总结

1. 采用RSA传输对称加密的密钥
2. 实际传输过程中采用对称加密算法
3. RSA公钥的安全由CA保证，顶层CA浏览器默认信任