【计算机网络】HTTPS——更安全的HTTP通信（个人笔记）

学习日期：2024.6.26

内容摘要：HTTPS存在的意义、特点和工作方式

HTTP的缺点——易窃听、伪装、篡改

在Web及网络基础中，我们已经知道了网页是怎么打开的，HTTP确实是一个相当优秀和方便的协议，但HTTP也有很多不足，最严重的不足就是——不安全。

因为HTTP属于TCP/IP协议族，其工作机制决定了在通信时，通信线路上的设备几乎不可能全部是个人的私有物。因此，通信可能被窃听、篡改或伪装。

我们来举个比较生动的例子，HTTP协议通信就是你坐在教室最左边，想把纸条传给你最右边的好哥们，叫他放学超光速去操场抢个篮板，显然你要通过一堆同学把你的纸条递过去。

易窃听

因为HTTP不具备加密功能，你传出去的纸条是明文（就是直接写的），传输路上的人可能打开来看你的纸条（虽然一般人不会），这就是传输被窃听了。

当然，你可以通过其他协议或者接层加密你的信息。（用密码来写你的小纸条）即使如此，通信也会被窥视到加密的内容，加密只是让人难以破解加密信息的含义，而不能阻止对方看到这次通信的报文信息本身。

易伪装

HTTP协议中的请求和响应不会对通信方的身份进行确认，也就会存在“跟我通信的服务器是否就是我申请通信的服务器，返回的响应是否真的返回到实际提出申请的客户端”这一问题。这就存在被伪装的隐患。听起来可能有点绕，还是拿传纸条举例子。

因为你们教室很大，你看不到你哥们，所以你也不知道你哥们到底有没有收到信息。即使你收到了回复，建立了通信，你也不确定回复你的到底是你哥们还是你们女班长，还是隔壁班的那个一米九体育生。

这可能导致以下隐患：

①无法确定请求/响应发送至目标的Web服务器/客户端是不是我期望的服务器/客户端，可能是伪装的服务器/客户端。

②无法确认通信的对方是否具有访问权限，因为某些服务器上保存的重要信息，只能开放给有特定权限的客户端访问。

③无法判断请求来自何方，出自谁手。

④即使是无意义请求也会照单全收，海量无意义请求下的Dos攻击（Denial of service，拒绝服务攻击），会让服务器瘫痪。

易篡改

HTTP协议无法证明通信的报文完整性，因此在请求和响应送出后，直到对方收到前这段时间，信息即使被篡改也无法知悉。假如有一个坏同学在你和你哥们通信的路上，他偷偷篡改你们俩的通信内容，你们也不会知道，这种攻击叫做中间人攻击。（Man in the middle attack,MITM）

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

为了解决以上这些问题，需要在HTTP中加入加密处理和认证等机制，我们把加入这些之后的HTTP称为HTTPS（HTTP Secure）。

HTTPS并非是应用层的一种新协议，而是HTTP的套壳，HTTP的通信接口部分由SSL（Secure Socket Layer，安全套接层）和TLS（Transport Layer Security，安全传输层协议）代替而已。

通常，HTTP直接和TCP通信，当使用SSL时，则是先和SSL通信，再由SSL和TCP通信。

SSL是独立于HTTP的协议，应用层的其它协议如SMTP和Telnet等都可以配合使用。

HTTPS的加密

在传输如身份信息，银行卡号等等私密内容时，我们显然不希望它们泄露，而HTTPS就会对通信进行加密。SSL采取一种被叫做“公开密钥加密”的加密方式。

加密技术基础

现代加密技术的加密方法一般是公开的，而密钥是保密的，通过这种方法来保证加密方法的安全性，加密和解密都会用到密钥，一旦密钥被攻击者获得，加密就失去了意义。

从共享密钥加密到公开密钥加密

加密和解密用同一个密钥的加密方式称为共享密钥加密，也称对称密钥加密，以共享密钥方式加密时，必须将密钥也发送给对方。但是这会带来一个问题——如何保证密钥能安全送达不被窃听？再加密一层的话，那密钥的密钥被窃听呢？

为了解决这一问题，我们引入了公开密钥加密，公开密钥加密使用一对非对称的密钥，即公开密钥和私有密钥，简称公钥和私钥。私钥必须保密，而公钥可以公开给任何人，随意发布，不怕攻击者窃听。

公开密钥于其说是“钥匙”，不如说像“锁”，在用公开密钥加密方式进行加密通信时，发送者首先用对方的公开密钥进行加密，受信方收到后，再使用自己的私钥进行解密。

公钥就是随意分发出去的锁，即使有人窃听，把“锁”偷去，也打不开包裹，而与你通信的人用你的锁把信息加密好，你再用自己的私钥打开，就完成了安全通信。

公开密钥方式虽然好，但是与共享密钥加密方式相比更加复杂，处理速度也更加的慢。因此，HTTPS一般是通过二者结合的方式，使用公开密钥加密方式来交换共享密钥，再通过共享密钥来通信，这样就能实现安全快速的通信。

证明公开密钥正确性的证书

遗憾的是，公开密钥加密方式也不是完美无缺的，因为其是公开传输的，我们也不知道公开密钥是否遭到了篡改，无法证明收到的公开密钥就是接收方的公开密钥。如果这把“锁”不是接收方的锁，而是被攻击者偷偷篡改成攻击者的“锁”了，那我们的加密就形同虚设了。

为了解决这一问题，可以使用CA（Certificate Authority，数字证书认证机构）和其相关机关颁发的公开密钥证书。

数字证书认证机构是服务器端和客户端都比较信赖的第三方机构。首先，服务器的运营人员会向数字认证机构提出公开密钥的申请，数字认证机构在仔细判明申请者身份后，会对已申请的公开密钥做数字签名，并且将其放入公钥证书后绑定在一起（公钥和服务器对应绑定）。

在通信时，服务器端会将这份公钥证书（又称数字证书，或直接简称证书）发送给客户端，以公开密钥加密方式通信，而客户端则会向CA机构核实，以CA机构的公开密钥进行通信，确认服务器端发送的密钥就是服务器之前登记的公开密钥，一旦核实成功，客户端就能确定：①认证服务器的CA机构是真实有效的机构 ②服务器的公开密钥是值得信赖的。

确实有点绕。我还是用锁举例来帮助理解：我要确认这把锁是不是被人替换了，就去找一个靠谱的公司，这个公司把所有靠谱服务器的锁都在上面登记了。我每次通信的时候就先去公司查一查锁的目录，这把锁是不是对方的那把，如果是就说明没问题。

但是还有一个问题（真服了），在使用这个方式认证时，客户端需要和CA机构通信，那么如何保证客户端和CA机构之间的通信是安全的呢？如果CA机构的公钥也被篡改了呢？为了解决这个问题，现代的浏览器一般会在内部直接植入常用认证机关的公开密钥。（直接不用通信，一步到位最安全）