Http 重温笔记 No.3

关于Https

通信过程

1. 客户端发送一段包含有客户端支持的SSL/TLS协议版本、可支持加密组件（使用的加密算法以及密钥长度等）报文给服务器。
2. 服务器会根据客户端支持的SSL/TLS协议版本以及其支持的加密中选择一种，作为后续通信过程中所使用的SSL/TLS协议以及加密组件，并放在报文中告知客户端。
3. 之后服务器会再发送一段报文，其中包含公开密钥证书。与公钥相配对的私钥则留在服务器自己那。
4. 客户端拿到公开密钥的证书之后，会向颁发数字认证证书的机构确认其合法性。若合法，则会根据与服务器协商确定的加密组件，随机生成一个密钥，而这个密钥将用于后续报文的加密。并将生成好的密钥用服务器给的公钥进行加密，并发送给服务器。
5. 服务器拿到客户端加密过得密钥之后，会用之前留在自己那的私钥去解密获取到密钥。
6. 客户端与服务器之间通信的报文都会用到这个密钥进行加密。

首先我们弄要弄清楚一件事，HTTPS并非应用层的一种新协议。只是HTTP通信接口部分用SSL或者TLS协议代替而已。原先HTTP协议直接和TCP协议对接，而HTTPS则是HTTP先与SSL/TLS通信,再由SSL/TLS和TCP通信。

加密

我们知道HTTP是采用明文传输的，这就免不了你的信息会被他人窥探。即使是采用对称加密算法，无法保证你在发送密钥的过程中不被他人窃取到。换句话说我们保证了密钥的安全传输，那么整个通信过程就不怕被窥探到了。HTTPS采用了非对称加密的方式，用公钥去加密，用私钥去解密。服务器把公钥交给客户端去加密通信密钥，然后再用自己的私钥去解密就可获取到通信密钥。

上面提到了非对称算法感觉是个好东西，服务器和客户端通信的报文采用非对称加密算法不就完了，干嘛还要绕一个弯，采用非对称加密+对称加密的组合。HTTPS这样设计是有其原因的，非对称加密算法看似很美好，但是其对CPU和内存的开销太大。有人做过实验，在加解密同等数量的文件下，非对称算法的开销是对称算法的1000倍以上。由此可见，这个非对称算法是多影响性能。性能这个问题，就算可以忍受，非对称算法有一个致命的缺点就是加密内容的长度不得超过公钥长度，常用的公钥长度是2048位，也就是256个字节，也就意味着加密的密文的大小不能超过256个字节。这个就太坑爹了，现在网络上的图片随随便便就是几千字节，这个就真的不能忍了。

认证

前面说到HTTP整个过程中，你的报文是可以被劫取到的，所以在发送公钥的过程中很难保证其不被掉包。为了保证密钥的合法性，HTTPS采用了数字证书这个概念。整个数字证书认证流程是这样子的：

首先服务器的运营人员会想权威的第三方数字证书认证机构申请公开密钥。数字证书认证机构在判明申请者的身份之后，对已申请的公开密钥做数字签名的操作，并把这个数字签名分配给这个公开密钥，并将已签名过的公开密钥放在公钥证书里面。客户端拿到这个公钥证书之后，向数字证书认证机构提出验证公钥证书上数字签名的请求，以确认公开密钥的真实性。
有了第三方的数字证书验证机构，我们就可以保证了公开密钥不被他人恶意篡改。

完整性保护

有了加密和认证足以保证通信报文可以不被他人看到，但我们报文是可以被他人截取到进行篡改的。比如完整的信息是这样子的“我不要你做我的女朋友了，我要你做我的老婆”，这本来是一句非常浪漫的话，要是被破坏了只传了“我不要你做我的女朋友了”，接收方还不知道这个信息是被篡改过得，那么就出大事了，这对小情侣就拜拜了，一段好姻缘就这么被破坏了。为了世界和平，我们还保护报文的完整性。HTTPS使用了MAC算法来保证其完整性。发送方发送报文会带有一个由MAC算法得出的一个MAC值。接受方拿到报文之后会根据密钥和MAC算法再算出一个MAC值，与传过来的MAC值进行比对，若一致则没有遭受篡改，这样就可以知道报文有没有被篡改过。