为什么 HTTPS 比 HTTP 更安全？HTTPS 如何保证数据传输安全性

Posted 2022-02-01 程序员蛋蛋

大家好，我是蛋蛋。

HTTP 和 HTTPS 在许多网站都有用到，但是现在都是极力倡导使用 HTTPS ，究其原因就是 HTTP 它不是安全的，在数据传输过程中会遭到黑客窃取，本篇文章会先讲解 HTTP 缺点，然后再讲解 HTTPS 是如何解决这些问题来保证安全的。

HTTP 缺点

通信使用明文（不加密）,内容可能会被窃听

HTTP 本身不具备加密的功能，因此其在通信过程是使用明文方式发送的。这种方式就有可能造成通信过程中信息会被破解获取。例如一群🐷佩奇在路上坐着敞篷大货车，路过的人一下就能看到这车里都是🐷，信息完全暴露。

不验证通信方的身份，有可能遭遇伪装

HTTP 协议在请求和响应中不会对通信方进行确认。这就存在可能你访问的服务器有可能不是你真正指定的服务器，拿到返回响应的客户端可能不是一开始发起请求的客户端。

这里举个小例子，例如母鸡孵蛋，我偷偷把鸡蛋换成鸭蛋，母鸡照样在那孵，不会有任何的怀疑。

无法证明报文完整性，有可能信息已遭篡改

HTTP 协议 无法证明通信的报文完整性，在请求和响应发出后，在传输过程中内容如果遭到篡改，也没有办法感知到。

例如你从某个网站下载内容，无法确定你客户端下载的文件是否和服务器中存放的文件是否一致，有可能文件在传输过程中被篡改为其他的内容。

什么是 HTTPS

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

为了统一解决 HTTP 上述几个缺点，我们就把加了加密及认证机制的 HTTP 称为 HTTPS 。

HTTPS 并不是一种新的协议。只是 HTTP 通信接口部分采用了 SSL 和 TLS 协议代替。

通常来说，HTTP 是直接和 TCP 进行通信的。当我们使用 SSL 时，会变成先和 SSL 通信，然后再由 SSL 和 TCP 进行通信。

SSL/TLS

SSL 即 安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层。在 1999 年 SSL 更名为 TLS (传输层安全)，正式标准化。

OpenSSL

提到 TLS ,就要说下 OpenSSL ,它是一个开源密码学程序库和工具包，支持了所有公开的加密算法和协议，许多应用软件都适用它作为底层库来实现 TLS 功能，例如 Apache、nginx等。

对称加密与非对称加密

HTTPS 的安全性是由 TLS 来保证的，它为 HTTP 增加了机密性、完整性和身份认证等特性，具体是怎么实现的呢？

我们先来说说机密性。实现机密性的做法就是 “加密”，将需要传递的消息进行加密，只有拥有“钥匙”的人才能拿到原始数据。

这个 钥匙 我们叫做 “密钥”，加密的消息叫 “明文”，加密后的叫做 “密文”。通过密钥来还原数据的过程叫 “解密”，加密解密的整个操作过程就是 “加密算法”。

加密可以分为两种形式，对称加密和非对称性加密。

对称加密

怎么理解对称加密呢？其实很简单，就是指加密和解密使用的密钥都是同一个。只要保证了密钥的安全，那整个通信过程就具有了机密性。

例如你要登陆某个网站，你事先和网站约定好使用一个对称密码，那么在数据传输过程中全是用密钥加密后的密文，只有网站能解密，传输的过程中即使信息被窃取，也无法获得原始数据。

非对称加密

对称加密看起来好像完美实现了机密性，但这其中也有一定的安全隐患，就是如何把密钥安全地传递给对方，因为对称加密只要有密钥就能解密，如果双方约定的密钥在传递过程被窃取，就会造成数据会被很容易的解密。

例如你家的钥匙，你跟你爸妈约定好钥匙放在门外鞋底里，看似安全，但如果别人发现了这个鞋底里藏的钥匙，那你家大门就会被打开，就很危险。

那有没有更安全的加密方式呢，就要说到非对称加密(也叫公钥加密算法)。

它有两个密钥，一个叫 “公钥”，一个叫“私钥”。两个钥匙是不同的，公钥可以给任何人使用，但私钥必须严格保密。

公钥加密的数据只能由私钥解密，反过来，私钥加密后也只能用公钥解密。

网站秘密保管私钥，在网上随意分发公钥，如果你想登录网站，只要用公钥来加密即可，密文只能由私钥持有者才能解密，即使数据传输过程中被黑客获取到，他也无法破解。

混合加密

非对称性加密虽然安全性高，但因为它都是基于复杂的数学运算，速度就会很慢，虽然保证了安全，但通信速度太慢，实用性也会大打折扣。

混合加密就是在通信刚开始的时候使用非对称算法，来解决对称加密密钥交换安全性问题。

对方拿到密文后用私钥解密，拿到对称密钥，这样双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。

这样混合加密就实现了安全和性能兼顾，实现了可靠的机密性。

数字签名和证书

刚刚我们实现了机密性，但这离安全还差的远。

黑客虽然拿不到会话密钥，但是可以窃听足够多的密文，然后尝试修改发给网站，服务器因为无法识别只能接收，它就可以通过服务器的响应获取到有用的信息。

另外，黑客也可以伪造身份发布公钥，如果你拿到的是假的公钥，那么加密就完全失效了。所以在机密性的基础上还需要加上完整性、身份认证等特性，才能实现安全。

摘要算法

实现完整性的手段主要是摘要算法，也就是散列函数、哈希函数。

通过摘要算法可以把数据压缩成一个独一无二的字符串，就例如你的身份证号一样，是唯一的。

它只有算法，没有密钥，加密后也不能被解密，无法逆推出原数据。

完整性

摘要算法如何保证完整性呢？这里举例说明：
我发了条消息：“转账 0.01元 ”，然后这句明文我同时要通过摘要算法生成一个摘要密文，这个摘要密文放在明文后面一起发送给网站，网站接收到后也对收到的明文信息通过摘要算法进行加密，与传过来的摘要密文进行对比，如果一样就说明信息没有被篡改，保持了完整性。

不过摘要算法不具备机密性，如果明文传输，黑客可以把明文消息进行修改同时把摘要也一起改了，网站还是鉴别不出完整性。

所以真正的完整性必须建立在机密性的基础上。

数字签名

黑客其实是可以伪装成你，向网站发起支付、转账等请求消息，因为网站没有办法确认你的身份就会造成钱被偷走。

在现实生活中，我们解决身份认证是通过身份证，签名或者印章等等，来确定这个是本人操作的。

那 HTTPS 是如何解决身份认证问题的？还记得之前提到的非对称加密里的私钥吗，使用私钥再加上摘要算法，就可以实现“数字签名”，同时实现“身份认证”。

数字签名的原理就是把公钥和私钥用法反过来，之前是公钥加密，私钥解密，现在变成私钥加密、公钥解密。

签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。

通过加密算法，摘要算法，数字签名我们已经可以实现数据通信过程中的加密、认证及完整性保护，但是这其中还有一个问题，就是公钥的信任问题。

数字证书

公钥每个人都可以进行发布，我们还缺少一个防止黑客伪装公钥的手段，也就是如何证明这个公钥就是你的公钥呢？

为了解决这个问题，我们需要找一个公认的可信第三方，来帮助构建起公钥的信任链。

这个第三方就是 CA(数字证书认证机构),它扮演着类似网络世界中的公安局，公证中心这种角色，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。

服务器会将由数字证书认证机构颁发的公钥证书发送给客户端，接到证书的客户端可使用公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，就证明服务器的公开密钥是真实有效的。

为什么不全部使用 HTTPS

通过前面的介绍，HTTPS 的安全性比 HTTP 强太多，但是 依然会有很多 Web 网站没有一直使用 HTTPS。

究其原因就是加密通信会消耗更多的 CPU 及内存资源，如果每次通信都进行加密，会消耗相当多的资源。因此如果是非敏感信息则使用 HTTP 通信，包含个人信息等敏感数据，才利用 HTTPS 加密通信。

使用 HTTPS 还有一个问题就是需要证书，而证书必须向认证机构(CA)去购买，这也是一笔不小的费用。

关注我，获取更多 关于 HTTP 和 HTTPS 的硬核知识哦。

HTTP 相关知识学习：
一文了解 HTTP

HTTP 报文详解