【计算机网络】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机构的公钥也被篡改了呢？为了解决这个问题，现代的浏览器一般会在内部直接植入常用认证机关的公开密钥。（直接不用通信，一步到位最安全）

其它证书

EV SSL证书（Extended Validation）可以验证网站背后的公司是否真实存在。

而客户端也有对应的客户端证书，可以让服务器安全验证客户端的公开密钥，但是日常生活中，因为客户端证书需要单独付费购买，而且针对客户端的伪装确实比较少见，事实上只有少部分高保密要求的服务如网上银行或者保密单位等才会使用。

不通过权威的第三方机构，也可以有证书，这就是自签名证书，显然，因为不通过权威机构，这个服务器证书在网上没什么大用，浏览器在访问该服务器时，会显示“无法确认连接安全性”，“该网站的安全证书存在问题”等，来提醒用户。（总是“坚持访问”真的有风险！！）

为什么不一直用HTTPS？

通过本章节的学习，我们大概已经能猜到原因了——加密通信实在是太复杂了。HTTPS通信，证书是必须的，而证书需要向CA机构花钱购买，并不便宜，对于很多服务器和个人网站来说非常不划算。

而且HTTPS的加密解密过程会消耗相当多的资源，导致通信速度变慢的同时服务器负载会变大，尤其是那些访问量较大的Web网站，加密和解密占用的消耗很大。对于一些没有那么重要的通信，直接用HTTP是更合理的选择。

你确实可以用密码写一张小纸条，再把它放在一个结实盒子里，然后用你哥们的锁把它扣上（记得确认一下是不是你哥们的锁），然后把盒子递过去，等你哥们用他的钥匙打开，回复你，再用你的锁扣上，这样确实很安全。

但你不会，你只会直接在纸条上写“放学速抢操场篮球架”，然后拜托旁边的同学递过去，毕竟，你只是想约哥们打球，你要传输的信息并不是你的身份证号和银行卡密码。

内容总结自人民邮电出版社《图解HTTP》