HTTP协议和HTTPS协议的那些事

文章目录

HTTPS VS HTTP
HTTPS=HTTP+加密+证书+完整性保护
加密
对称加密
非对称加密
混合加密
证书
完整性保护
HTTPS并不能取代HTTP
SSL是把双刃剑
HTTPS的遗憾之处

HTTPS VS HTTP

计算机网络 (二) 应用层：HTTP协议详解

在之前的文章中介绍了HTTP协议，虽然从中了解了他优秀的一面，但是也能看到他许多的不足。

由于其本身通信使用明文，没有进行加密，也没有确认通信方的一种机制，所以在互联网上近似于裸奔，很容易就会受到中间人攻击，导致安全存在问题。

通信时数据并没有进行加密，而是使用明文，很容易就会被窃听

没有验证通信对象的机制，导致了可能会有人假扮客户端进行通信

无法验证报文的完整性，中途可能被人篡改，自己又无法确认

HTTP的主要缺点如下

通信使用明文，内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法验证报文的完整性，有可能遭到篡改

为了弥补上述缺点，HTTPS就诞生了，HTTPS并不是一个新的协议，而是身披SSL外壳的HTTP，通过引入加密，证书，完整性保护来保证了他的安全。

HTTPS=HTTP+加密+证书+完整性保护

加密

对称加密

对称密钥加密也叫做共享密钥加密，其实就是加密和解密采用了同一个密钥

双方在进行通信时，发送方会利用密钥进行加密，再将密钥一同发送给接收方，让其使用这个密钥进行解密。

这种方法看起来不错，但是也存在问题，如果在发送的时候被拦截下来，密钥就会泄露给中间人，此时中间人就可以通过密钥来对之后的数据进行解密，此时也就失去了加密的意义

这时，就引入了非对称加密

非对称加密

非对称加密又叫做公开密钥加密，他使用一对非对称的密钥，一把叫做私有密钥，一把叫做公有密钥。故名思意，共有密钥是公开的，任何人都可以获得，而私有密钥则不能让任何人知道

当进行通信时，发送方使用对方的公有密钥进行加密，而接收方接收时则使用自己的私有密钥进行解密，这样一来，用于解密的私钥就完全掌握在接收者自己手里，中间人也无法从中窃取密钥，安全也一定程度的得到了保障。

混合加密

但是，从上面的描述也可以看出来，由于非对称加密的处理比起对称加密来说较为复杂，所以如果在通信时一直使用非对称加密，就会导致通信的效率大大的降低，所以HTTPS采用对称加密和非对称加密并用的混合加密机制

具体怎么做呢？

使用非对称加密的方式来交换之后用来进行加密解密的对称加密密钥

（因为对称加密的主要问题就是无法确保密钥是否安全，而此时采用非对称加密来传输密钥，就能很好的规避这个问题）
在确保之前交换安全的情况下，使用对称加密密钥来进行通信

(而非对称加密的最大问题就在于其复杂的处理机制导致效率降低，所以在安全的情况下使用对称加密就可以大大提高效率)

证书

虽然数据得到了加密，不至于明文裸奔，但是这时以及安全了吗？

答案是否定的，我们还需要考虑到HTTP的第二个缺点，没有验证对象。

假设这样一个情景，小明和小张进行通信，中间人在双方第一次通信时就截获了小明的公钥，即使无法使用私钥解密，但是他仍然想出了一个坏点子——偷天换日，此时他冒充小明，将自己生成的公钥发送给小张。

此时小张误以为他就是小明，所以使用中间人的公钥进行加密，将对称加密的密钥发送了过去。

此时中间人就可以通过自己的私钥来进行解密，于是就获取了对称加密的密钥。之后他接着使坏——此时再伪装成小张，将密钥再一次加密后发送给小明，此时小明也认为他就是小张。

通过这种手法，中间人就能在双方都不知情的情况下，掌握了双方的对称加密密钥，轻松的截取了双方的通信内容。

为了解决这个问题，HTTPS引入了数字证书这一机制。

服务器的运营人员会向数字证书认证机构来进行认证，在机构对其验明身份之后，就会对服务器的公钥做一个数字签名，并且将公钥放入公钥证书后绑定在一起。

此时当客户端接收到服务器发送的公钥证书的时候，就会向证书认证机构来验证数字签名是否正确，来判断该公钥是否遭到替换，确保了公钥的真实性。

此时即使中间人想仿造公钥证书，但也因为无法通过机构的验证而被识破。

此时，中间人就没有使坏的空间了。

这就是HTTPS使用加密以及证书来确保安全的整个流程

完整性保护

在上面的流程中，应用层发送数据的时候会附加MAC报文摘要，MAC能够查知报文是否遭受到篡改，从而让保护报文的完整性。

HTTPS并不能取代HTTP

SSL是把双刃剑

HTTPS也叫做披着SSL外壳的HTTP，在通信接口部分他使用了SSL和TLS来进行代替。

对于HTTP协议来说，他直接和TCP进行通信。

而HTTPS为了保证安全，使用了SSL来提供保障，通信时首先与SSL进行通信，再由SSL来与TCP进行通信，正是因为由SSL的存在，才使得HTTP具备了HTTPS的加密、证书、安全性保障这些功能。

但是成也萧何，败也萧何，SSL为HTTPS保障安全的同时，也降低了他的效率

SSL主要慢在两个方面

和HTTP相比，网络负载可能会变慢2到100倍。由于HTTPS还需要额外进行SSL通信，整体上处理通信量不可避免的增加了。
SSL为了确保安全，在客户端和服务端都需要进行大量的加密和解密的运算处理，导致其比起HTTP来说会更多的消耗服务器和客户端的硬件资源，导致负载增强。

HTTPS的遗憾之处

SSL的高度安全带来的低效率以及高负载使得HTTPS并不会一直使用（或者干脆不用）

（对于高访问量的Web网站来说，进行大量的加密解密出来带来的负载十分庞大，并且对于非敏感信息（可公开信息）也没有加密的必要，所以大多数网站并不会一直使用HTTPS，而是只在进行私密内容传输的时候才会使用，来确保资源的节约。）
数字证书的高昂成本使得个人网站及非盈利网站望而却步

（要进行HTTPS通信，数字证书是必不可少的，但是对于一些非盈利的网站以及个人网站来说，每年用来购买数字证书带来的花销并不是一个小数目，所以大多还是继续使用HTTP