【计算机网络】应用层—

文章目录

1. HTTPS 协议简介
2. 了解“加密”
3. HTTPS 保证数据安全传输的三大机制
- 3.1 引入对称加密
- 3.2 引入非对称加密
- 3.3 引入“SSL/TLS证书”（防止中间人攻击）
- 3.4 HTTPS安全机制总结

📄前言：
前面的文章已经对 HTTP 协议进行了较为详细的介绍，本文所介绍的 HTTPS 协议是对 HTTP 协议的补充，HTTPS 协议主要解决的是 HTTP 协议在网络上数据传输的安全问题。

1. HTTPS 协议简介

什么是 HTTPS 协议？

HTTPS 协议又称为“安全超文本传输协议”，它是 HTTP 协议的安全版本，主要通过在 HTTP和TCP/IP 之间添加一层加密层来增强数据传输的安全性。

HTTPS 协议的特点：

加密：HTTPS 协议使用 SSL或TLS 协议对数据进行加密，保证了数据在传输过程中被窃听的安全性（密文与原始明文差异极大）。
数据完整性：HTTPS 协议可以保证数据在传输过程中未被修改，保护了数据的完整性。
身份验证：通过 SSL/TLS 证书验证服务器的身份，保证客户端访问的是目标服务器而非冒名顶替的服务器，可以防止“中间人”攻击。

引入 HTTPS 协议的必要性：
在商场、酒店、KTV等公共场所中，出于加快网络访问速度、下载大型应用/文件、节省流量等目的，我们往往会连接商家提供的 WIFI，但在享受公共网络便利的同时，我们往往容易忽略其中带来的安全隐患：由于互联网上的所有数据都需经过路由器的多次转发，最终到达目标主机。当黑客入侵了这些场所的路由器，就可以通过抓包工具获取所有经过该路由器转发的数据，因此当我们通过网络传输了某些比较敏感的数据（如账户名、密码、身份证、各类支付密码、家庭住址等）且数据是明文传输的，黑客就可以通过这些信息做出某些违法行为，进而造成不可挽回的损失。
在这里插入图片描述

2. 了解“加密”

加密是一种安全技术，通过将原始信息（明文）转换成不易读的格式（密文），来防止未经授权的访问。其中，用来加密的工具称为“密钥”，密钥可以完成明文和密文的相互转换，只有拥有正确密钥的人才能够读取原始信息。

加密根据类型不同可以分为 对称加密和非对称加密。

对称加密：使用相同的密钥进行加密和解密。这种加密方式的优点是加密/解密的速度快，适合大数据量的传输，缺点是密钥的分发和管理比较困难（详见 3.1引入对称加密），一旦一方密钥泄露，加密信息就会被破解。
非对称加密：使用一对密钥（公钥和私钥）进行加密和解密，它的特点是：使用公钥加密需私钥解密，且加密与解密的角色可以互换。非对称加密可以解决密钥的分发和管理问题（详见3.2引入非对称加密），但加密/解密的开销较大，所消耗时间也较长。

思考：经过加密后的数据一定能保证安全传输吗？
答案是否定的。虽然黑客获取加密过的 HTTP 请求后并不能直接

3. HTTPS 保证数据安全传输的三大机制

HTTPS之所以能够保证数据安全地传输，原因是依靠对称加密、非对称加密、数字证书这三大机制的相互配合。

3.1 引入对称加密

通过上述 HTTPS 的介绍我们可以知道，将数据在网络上进行明文传输是非常不安全的，因此需引入对称加密可以有效增加数据传输的安全性，这样一来即使客户端发送的数据被黑客截获，那数据也是相对安全的（密文的破解需要一定的成本和时间）。
在这里插入图片描述
注意：使用对称加密传输数据时，需给每个客户端分发不同的密钥，原因是假如多个客户端都使用相同的密钥，一旦密钥被黑客破解，那么所有使用该密钥加密的数据都会被轻易获取。

上述过程确实可以很大程度上保证数据的安全传输，但前提是客户端能够正确拿到服务器生成的密钥，那么问题来了，客户端如何拿到密钥呢？
答案其实也很明确，通过网络传输对称密钥。（如下图）
在这里插入图片描述

这时候我们可能又有一个疑问：假如黑客在通信双方使用密文传输前就已经入侵了中间网络设备，那么这个加密不就相当于“脱裤子放屁”，也就跟明文传输没有区别了？
事实上对称加密确实存在上述问题，因此它通常只适合于正式进行数据传输的过程中，而不适用于数据传输前的密钥传递。

3.2 引入非对称加密

我们已经知道了，对称加密存在密钥分发问题，因此引入非对称加密不仅可以保证数据的安全传输，也可以解决密钥的分发问题。（如下图）
非对称加密的原理也非常简单：服务器生成一对密钥（公钥和私钥），通过由服务器持有私钥，客户端持有公钥，在数据传输前服务器将公钥通过网络传输给客户端，之后客户端使用公钥对 HTTP 请求进行加密，服务器再通过私钥对密文进行解密。在这种机制下，就算黑客通过入侵网络设备获取了公钥，由于他没有私钥，也就不能得到客户端发送的原始信息。（如下图）
在这里插入图片描述
注意：通过上述非对称已经可以完美解决数据的安全传输和密钥的分发问题，但上述加密过程还存在两个问题：（1）黑客虽然获取不了客户端发送的密文请求，但可以通过公钥解密得到服务器返回的响应（2）非对称加密解密开销加大，频繁使用该方式传输数据会造成没必要的开销。

针对第一个问题，在大部分场景下不是一个严重问题，因为采用加密的方式传输数据的初心是为了保护用户发送请求中的隐私数据（如账户密码、身份证、家庭住址、各类支付密码等），而服务器返回的数据大部分情况下是可以被公开的。

对于第二个问题，频繁非对称加密解密不仅会消耗额外的硬件资源，而且造成的时间开销还会影响用户的使用体验。因此，在实际情况中往往采用非对称加密的方式将公钥传输给客户端，接着客户端再生成一把对称密钥，使用公钥对该密钥进行加密后传输给服务器，服务器收到请求后使用私钥解密得到对称密钥，在后面的通信过程中，双方都使用对称密钥传输信息。这样一来两个都得以解决。（如下图）
在这里插入图片描述

3.3 引入“SSL/TLS证书”（防止中间人攻击）

上述过程引入非对称加密后，利用 非对称加密+对称加密 相结合的手段巩固了 HTTPS 安全传输的基本盘，但仍然存在一个严重的漏洞——中间人攻击，如果黑客利用了该漏洞，通信双方的传输数据将被悄无声息的获取，等同于明文传输！！！

什么是中间人攻击呢？

中间人攻击指攻击者在通信双方之间秘密穿插自己，甚至伪装成通信的另一方，使得通信双方认为他们在直接地、安全地与对方通信，但实际上所有传递的信息都经过攻击者，从而通过这种攻击达到窃取通信过程的敏感数据或篡改数据的目的。

那么攻击者如何通过“中间人攻击”达到隐藏自己、获取通信过程中的数据呢？具体步骤如下：

客户端向服务器询问公钥
黑客传递询问公钥请求，服务器端生成 public1 和 private1，并把公钥public1 作为响应返回。
黑客收到 public1后保存下来（用于后面加密对称密钥，达到隐藏自己的目的），同时自己生成 public2和private2，将 public2返回给客户端
客户端收到公钥后，用 public2 加密自己生成的对称密钥并传递给服务器
黑客收到请求，使用 private2 解密获取用于日常数据传输的对称密钥，再用 public1 加密对称密钥，传递给服务器。（这样既能使服务器和客户端能够正常使用对称密钥传输数据，也能够达到隐藏自己的目的，后面就能随意监听通信双方传输的数据，甚至伪装成另一方与对面通信，以此达到其他非法目的）
服务器收到请求，使用 private1 解密获取对称密钥，此时服务器和客户端都认为彼此是直接、安全地进行通信。

在这里插入图片描述

要解决上述“中间人攻击”问题，可以引入公证机构颁发的“SSL/TLS证书”（数字证书），那么公证机构和数字证书分别是什么呢？

公证机构是一个受信任的第三方机构，它负责颁发、管理和吊销数字证书。公证机构会验证证书申请者（网站）的身份，以确保证书申请者的身份是合法和受信任的。

数字证书，也称为SSL/TLS证书，是一种文件形式的身份凭证，用于证明公钥的所有权。数字证书上有域名、服务器公钥、组织名称等信息，还包含一个最关键的信息——数字签名。

那么数字签名又是什么呢？它的作用是什么？
数字签名是将证书上的其他属性通过一定计算得到一个校验和，再通过公证机构生成的私钥（非对称密钥）加密得到的加密校验和。
众所周知校验和的作用是用来验证数据在传输过程中是否发生改变（出错或被篡改），而对于客户端来说，它本身持有公证机构生成的配对的公钥（预装浏览器或操作系统时内置的），只需使用公证机构发布的公钥对数字签名解密得到原始校验和，再与证书上内容计算得到的校验和进行比较，若校验和一致则说明服务器公钥、网址等信息是正确且安全的。（如下图）
在这里插入图片描述

思考一：若黑客替换了证书中的公钥是否可行？
答案是否定的。原因是一旦服务器的公钥被替换，客户端如果证书计算出来的校验和一定与解密后的原始校验和不一致，这样则说明了公钥或其他内容被修改过。

思考二：若黑客将公钥连同加密的校验和一同替换了是否可行？
答案也是否定的、若要替换校验和需使用私钥加密，而私钥是公证机构持有的，若使用黑客生成的私钥加密校验和，客户端则不能正确解密数字签名，因此这种方法也是行不通的。

思考三：若黑客也向公证机构申请一个证书，将证书里的公钥、校验和等属性替换成自己的，后面再将证书传递给客户端，借助上述的中间人攻击手段，达到窃听、修改通信数据的目的。这种方法是否可行？
答案依旧是否定的。原因是申请证书需要提交各种证明自己身份的资料，公证机构会对这些资料进行审查，若发现申请的域名不是自身持有的则不会颁发数字证书。