网易面试：说说 HTTPS 原理？HTTPS 如何保证数据安全？

本文原文链接

文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录博客园版 为您奉上珍贵的学习资源：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你实现技术自由，完成职业升级，薪酬猛涨！加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领

免费赠送资源宝库： Java 必备百度网盘资源大合集价值>10000元加尼恩领取

网易面试：说说 HTTPS 原理？HTTPS 如何保证数据安全？

尼恩特别说明：尼恩的文章，都会在《技术自由圈》公号发布，并且维护最新版本。如果发现图片不可见，请去《技术自由圈》公号查找

45岁老架构尼恩说在前面

在45岁老架构师尼恩的读者交流群(100+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团、蚂蚁、得物的面试资格，遇到很多很重要的相关面试题：

http为什么不安全？为啥用 HTTPS ?

说一下 HTTPS 的执行流程？

HTTPS 是如何保证传输安全的?

说说 https 原理 ? HTTPS 是如何保证传输安全的?

最近有小伙伴面试网易，都问到了这个面试题。 小伙伴没有系统的去梳理和总结，所以支支吾吾的说了几句，面试官不满意，面试挂了。

所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

当然，这道面试题，以及参考答案，也会收入咱们的《尼恩Java面试宝典PDF》V175版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取

1：http的原理和不安全传输

要说https，必须了解http。

在介绍http的传输过程为啥不安全这个问题之前，回顾一下 http的传输过程。

HTTP传输的传输过程

HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML文件，图片文件，查询结果等，一般基于B/S架构，即浏览器作为HTTP客户端通过URL向HTTP服务端（WEB服务器）发送所有请求。

45岁老架构师图解一下HTTP传输的传输过程（以访问百度为例）：

对上图的 HTTP传输的传输过程（以访问百度为例）进行介绍，大致如下：

域名解析（DNS 查询）
- 当你在浏览器（如 Chrome、Firefox 等）中输入 “www.baidu.com” 并按下回车键后，浏览器首先会进行域名解析。它会向本地 DNS 服务器（通常由你的网络服务提供商提供）发送一个 DNS 查询请求，询问 “www.baidu.com” 对应的 IP 地址。
- 本地 DNS 服务器如果缓存中有这个 IP 地址，就会直接返回；如果没有，它会向更高级别的 DNS 服务器（如根 DNS 服务器、顶级域名 DNS 服务器等）进行查询，直到获取到百度服务器的 IP 地址（例如，百度服务器的 IP 可能是 14.215.177.38 等）。这个过程就像是在电话本中查找一个电话号码一样，通过域名找到对应的服务器位置。
建立 TCP 连接（三次握手）
- 浏览器在获取到百度服务器的 IP 地址后，就会开始建立 TCP（传输控制协议）连接。这是一个可靠的面向连接的协议，用于保证数据的准确传输。
- 第一次握手：浏览器（客户端）向百度服务器（服务器端）发送一个带有 SYN（同步序列号）标志的 TCP 数据包，这个数据包中还包含一个随机生成的序列号（如 SEQ = x），表示客户端想要建立连接并且告知服务器初始序列号。
- 第二次握手：服务器收到客户端的 SYN 包后，会返回一个带有 SYN/ACK（同步确认）标志的数据包。这个数据包中包含服务器自己生成的 SYN 序列号（如 SEQ = y），同时确认收到客户端的序列号（ACK = x + 1），表示服务器同意建立连接并且也告知客户端自己的初始序列号。
- 第三次握手：客户端收到服务器的 SYN/ACK 包后，会发送一个带有 ACK 标志的数据包，确认收到服务器的序列号（ACK = y + 1）。至此，TCP 连接建立成功，就像双方通过三次握手确定了通信的规则和起始位置。
发送 HTTP 请求
- 建立好 TCP 连接后，浏览器会根据 HTTP 协议向百度服务器发送一个 HTTP 请求。这个请求通常包括请求行、请求头和请求体（如果有）。
- 请求行包含请求方法（如 GET、POST 等）、请求的资源路径（如 /，表示请求百度首页）和 HTTP 协议版本（如 HTTP/1.1）。例如，一个 GET 请求可能是 “GET / HTTP/1.1”。
- 请求头包含了许多关于请求的额外信息，如浏览器的类型（User - Agent）、接受的内容类型（Accept）、是否支持压缩（Accept - Encoding）等。例如，“User - Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36”，这个请求头表明了浏览器是 Chrome 的某个版本，运行在 Windows 10 操作系统的 64 位版本上。
- 如果是 POST 请求，请求体可能包含用户提交的数据，如在百度登录页面输入的用户名和密码（当然，百度登录实际使用更安全的方式）。
服务器处理请求并返回响应
- 百度服务器收到浏览器的 HTTP 请求后，会根据请求的内容进行处理。如果是请求首页，服务器会查找对应的 HTML 文件以及相关的资源文件（如 CSS、JavaScript 等）。
- 服务器会根据处理结果生成一个 HTTP 响应。响应同样包括响应行、响应头和响应体。响应行包含 HTTP 协议版本、响应状态码和状态消息。例如，“HTTP/1.1 200 OK” 表示请求成功，服务器找到了请求的资源并返回。
- 响应头包含了关于响应的各种信息，如内容类型（Content - Type），如果返回的是 HTML 文件，可能是 “Content - Type: text/html”；还可能包含内容长度（Content - Length）等信息。
- 响应体就是服务器返回的实际内容，如 HTML 页面的代码。这个代码会被浏览器接收并用于渲染页面。
关闭 TCP 连接（四次挥手）
- 浏览器收到服务器的响应并完成页面渲染后，就会开始关闭 TCP 连接。这是一个四次挥手的过程。
- 第一次挥手：浏览器（客户端）发送一个带有 FIN（结束）标志的 TCP 数据包，表示客户端想要关闭连接。
- 第二次挥手：服务器收到客户端的 FIN 包后，会返回一个 ACK 包，表示收到客户端的关闭请求。
- 第三次挥手：服务器在处理完一些剩余的事务后，也会发送一个带有 FIN 标志的数据包，表示服务器也准备关闭连接。
- 第四次挥手：客户端收到服务器的 FIN 包后，会发送一个 ACK 包，确认收到服务器的关闭请求。

至此，TCP 连接完全关闭，整个 HTTP 传输过程结束。

HTTP传输的特点：明文传输

第三步：客户端发生http请求，把一条消息，以明文的方式，发送到服务器。
第四步：客户端发生http请求，服务的响应报文，也是以明文的方式，发回给客户端。

Http 明文传输，主要有这些缺点：窃听风险、篡改风险、冒充风险：

窃听风险：请求信息明文传输，容易被窃听截取。
篡改风险：数据的完整性未校验，容易被篡改
冒充风险：没有验证对方身份，存在冒充危险

大家登录的时候，如何账号密码都是明文传输，在传输链路上，有很多的中间设备（如WiFi、路由器、交换机、网络嗅探工具等），这样，客户端发出的请求，很容易被中间环节拦截，然后被不法分子截取利用。

因此，HTTP协议不适合传输一些敏感信息，比如：各种账号、密码等信息，使用http协议传输隐私信息非常不安全。

2：http为什么不安全？

HTTP（超文本传输协议）被认为不安全，主要有以下几方面原因：

一、窃听风险：数据传输未加密，容易被窃听截取

HTTP 在传输数据时采用的是明文形式，这意味着数据在网络传输过程中是以原始的、未经过加密处理的文本格式进行发送的。

例如，当用户在网页上输入登录账号和密码等敏感信息时，这些信息会以明文的形式通过网络从客户端（如浏览器）发送到服务器端。

如果在传输过程中被不法分子通过网络嗅探工具（如 Wireshark 等）进行监听，那么他们就能够轻易获取到这些明文数据，进而可能导致用户的账号被盗用、个人隐私信息泄露等严重后果。

二、冒充风险：缺乏身份验证机制，存在冒充危险

HTTP 本身并没有提供强大的身份验证机制来确保通信双方的真实身份。

对于客户端来说，无法准确确认与之通信的服务器是否真的是其声称的合法服务器。不法分子有可能通过一些手段（如 DNS 劫持等）将用户请求重定向到他们伪造的服务器上，而用户在不知情的情况下就可能会向这个伪造的服务器发送数据。同样，对于服务器端而言，也难以绝对确认请求来自合法的客户端，这就为中间人攻击等安全威胁留下了可乘之机。

三、篡改风险：数据的完整性未校验，容易被篡改

中间人攻击：由于 HTTP 数据传输未加密且缺乏可靠的身份验证，攻击者可以在客户端和服务器之间的网络路径上进行拦截，充当 “中间人”。他们一方面接收客户端发送的数据，另一方面又伪装成客户端向服务器发送数据，或者反之，这样就可以篡改、窃取传输中的数据。
数据篡改攻击：因为传输的是明文数据，攻击者一旦截获了传输中的数据，就可以相对容易地对数据内容进行修改，比如篡改订单信息、修改用户提交的表单内容等，然后再将篡改后的内容发送给服务器，而服务器可能无法察觉数据已经被篡改，从而按照错误的信息进行处理。
重放攻击：攻击者可以截获并记录合法的 HTTP 请求，然后在之后的某个时间再次发送这些请求，就好像这些请求是刚刚由合法用户发出的一样。例如，截获了用户的一次登录请求，然后不断地重放这个登录请求，可能会导致用户账户被异常登录等情况。

3：如何解决中间环节的传输安全问题？

综上所述，HTTP 的这些特性使其在面对网络安全威胁时较为脆弱，所以在涉及敏感信息传输等场景下，如何解决中间环节的传输安全问题？

通常的方案：采用更安全的 HTTPS 协议（HTTP Secure，即在 HTTP 基础上加入了 SSL/TLS 加密和身份验证等安全机制）实现传输安全。

问题是， https 协议比较复杂, 有两个大的复杂部分：

https 复杂的部分之一：加密和密钥管理部分

加密算法的多样性：HTTPS 使用多种加密算法来确保数据安全。例如，SSL/TLS 协议（HTTPS 的基础）支持多种对称加密算法（如 AES、3AES/DES 等）和非对称加密算法（如 RSA、ECDSA 等）。在握手阶段，客户端和服务器需要协商使用哪种加密算法，这涉及到对双方支持的加密算法进行比较和选择。比如，服务器可能支持 AES - 128、AES - 256、3AES/DES 等对称加密算法，而客户端可能只支持 AES - 128 和 3AES/DES，双方需要通过协商确定最终使用 AES - 128 进行后续的数据加密。
密钥交换过程复杂：在非对称加密的密钥交换过程中，服务器需要生成一对公钥和私钥。公钥用于发送给客户端，私钥则由服务器自己保存。客户端使用服务器提供的公钥来加密一些信息（如预主密钥），然后发送给服务器。服务器再用自己的私钥进行解密。例如，在 RSA 密钥交换中，服务器的公钥长度可能较长（如 2048 位），计算过程涉及到大数的乘法和模运算，这个过程相对复杂，并且对计算资源有一定要求。而且，为了保证密钥交换的安全性，还需要考虑防止中间人攻击等安全威胁。
证书验证环节：HTTPS 依赖数字证书来验证服务器的身份。证书由权威的证书颁发机构（CA）颁发，其中包含了服务器的公钥、服务器的身份信息（如域名等）以及证书颁发机构的签名。客户端在连接服务器时，需要验证证书的有效性。这包括检查证书是否过期、证书的签名是否被篡改、证书的颁发机构是否可信等多个步骤。例如，当浏览器访问一个网站时，会检查证书中的域名是否与正在访问的域名一致，还会检查证书的有效期。如果证书过期或者域名不匹配，浏览器会弹出警告信息，提示用户可能存在安全风险。

https 复杂的部分之二：通信过程中的多层协议交互

握手协议：HTTPS 的握手过程比较复杂。首先是客户端向服务器发送一个 “ClientHello” 消息，其中包含客户端支持的 SSL/TLS 版本、加密算法列表、随机数等信息。服务器收到后，会返回一个 “ServerHello” 消息，选择合适的 SSL/TLS 版本、加密算法，并发送自己的随机数和数字证书。之后，客户端和服务器还会进行密钥交换等一系列操作来确定用于后续数据加密的密钥。这个握手过程涉及到多个消息的交互和复杂的参数协商，以确保双方能够在安全的基础上进行通信。
记录协议与加密通信：在握手完成后，进入数据传输阶段，即通过记录协议进行通信。数据在传输前需要进行加密处理，使用协商好的对称加密算法（如 AES）。并且，数据会被分成一个个记录进行传输，每个记录都有自己的格式，包括记录头（用于标识记录类型等信息）和加密后的记录内容。在接收端，需要对记录进行解密和重组，以恢复原始的数据。这种分层的协议结构和加密通信方式使得 HTTPS 的通信过程比 HTTP 更加复杂。

45岁老架构师的一贯以来的风格都是： 庖丁解牛，由浅入深。接下来，给大家细致介绍一下这个核心难题。

由于 https 确实过于复杂，咱们从最为基础的、最为的HTTP加密传输讲起。

4. 最为简单的HTTP加密传输：对称加密+HTTP

既然，明文传输不安全，那我们加密是不是就可以了。

在正式的 http请求和响应之前，咱们加入一个步骤：

客户端首先去服务端获取一个密钥。

怎么生成密钥呢？基础的加密算法主要有：

（1）对称加密（Symmetric Cryptography）

（2）非对称加密（Asymmetric Cryptography）

对称加密算法加密（Symmetric Cryptography）

先可以考虑最为简单的，也是最不安全的加密算法：对称加密算法加密（Symmetric Cryptography）。

对称性加密也称为密钥加密。对称加密的典型处理流程，大致如下图所示：

在对称加密算法中：

加密方（如服务端）使用一个密钥（通常是一个秘密的数字序列）对明文（原始信息）进行加密操作，将其转换为密文（经过加密后的信息）。
解密方必须使用完全相同的密钥才能将密文还原为明文。例如，若使用密钥 “12345” 对消息 “Hello” 进行加密，那么在接收端也必须使用 “12345” 这个密钥来解密，才能得到原始的 “Hello” 消息。

对称加密的特点是：

使用同一个密钥加密和解密，所以优点是速度快；
要求共享密钥，缺点是密钥管理不方便，容易泄露密钥。

常见的对称加密算法（Symmetric Cryptography）有AES/DES、AES等。

AES/DES加密算法出自IBM的数学研究，被美国政府正式采用之后开始广泛流传，但是近些年使用越来越少，因为AES/DES使用56位密钥，以现代计算能力 24小时内即可被破解。

虽然如此，在对安全要求不高的应用中，还是可以使用AES/DES加密算法。由于其速度快，对称性加密通常在消息发送方需要加密大量数据时使用。

常见的对称加密算法有：AES/DES、3AES/DES、AES。假如AES/DES 用对称算法加密后，HTTP流程又是怎样的：

对称加密HTTP 的传输过程（以AES/DES 对称加密例）

45岁老架构师图解一下HTTP传输的对称加密传输过程（以AES/DES 对称加密例）：

对上图的 HTTP 对称加密传输的传输过程（以AES/DES 对称加密例）进行介绍，大致如下：

客户端在开始正式的请求之前，需要先进行密钥的请求。服务端给客户端创建一个专用的密钥，然后返回给客户端。
客户端把要发送的request 消息，用密钥加密，request 传输过程中，密文传输。
服务器收到密文消息，用同一把密钥把密文解密成明文，后进行业务处理。处理完成后，服务端把response消息报文返回给客户端之前，需要进行加密，response传输过程中，密文传输。

常见的对称加密算法有：AES/DES、3AES/DES、AES

第一种：AES/DES（Data Encryption Standard）

基本原理：AES/DES 是一种分组加密算法，它将数据分成固定长度（64 位）的分组进行加密。它的加密过程主要包括初始置换、16 轮迭代的加密变换（使用子密钥）、逆初始置换等步骤。在每一轮迭代中，通过复杂的函数（涉及置换、替换等操作）对数据进行处理，并且每一轮使用不同的子密钥，这些子密钥是由原始的 56 位密钥（64 位密钥中的 8 位用于奇偶校验）通过密钥编排算法生成的。
密钥长度：其密钥长度通常为 56 位，在当时的计算环境下，这种密钥长度提供了一定的安全性。然而，随着计算机计算能力的不断提高，56 位的密钥长度已经相对容易被破解。
应用场景：由于其出现较早，在一些对安全性要求不是极高的早期系统或简单的数据加密场景中可能会被使用。例如，一些老旧的企业内部数据存储系统，在数据敏感度不高的情况下，可能会使用 AES/DES 进行简单加密。

第二种：3AES/DES（Triple - Data Encryption Standard）

基本原理：3AES/DES 是为了增强 AES/DES 的安全性而提出的。它实际上是对 AES/DES 加密过程进行了三次迭代。其加密方式有多种组合，常见的是使用三个不同的密钥（密钥 1、密钥 2 和密钥 3）进行加密，先使用密钥 1 进行 AES/DES 加密，然后使用密钥 2 进行 AES/DES 解密，最后再使用密钥 3 进行 AES/DES 加密。这种加密方式在一定程度上增加了加密的复杂性和安全性。
密钥长度：因为是三次 AES/DES 操作，若每个密钥长度为 56 位，总共的有效密钥长度可达 168 位。不过，在实际应用中，也可以使用两个密钥（令密钥 1 = 密钥 3），此时有效密钥长度为 112 位。
应用场景：3AES/DES 在需要比 AES/DES 更高安全性，但又兼容 AES/DES 系统的情况下使用。比如在一些金融系统的过渡阶段，从传统的 AES/DES 加密升级到更安全的 AES 之前，可能会使用 3AES/DES 作为过渡加密方案，以保护金融交易数据等敏感信息。

第三种：AES（Advanced Encryption Standard）

基本原理：AES 也是分组加密算法，它的分组长度可以是 128 位，加密轮数会根据密钥长度不同而不同（10 轮、12 轮或 14 轮）。其加密过程主要基于字节替换、行移位、列混淆和轮密钥加等操作，这些操作在每一轮加密中循环进行，通过复杂的数学变换来保证数据的安全性。AES 的安全性基于数学上的难题，如在有限域上的多项式运算等。
密钥长度：AES 支持 128 位、192 位和 232 位三种密钥长度，较长的密钥长度提供了更高的安全性。例如，128 位密钥长度的 AES 加密，其密钥空间非常巨大，使得暴力破解几乎是不可能的。
应用场景：AES 是目前应用最广泛的对称加密算法之一。在各种安全要求较高的领域都有应用，如网络通信加密（包括 VPN 等）、金融数据加密、政府敏感信息加密等。例如，在移动支付系统中，为了保护用户的支付信息安全，通常会使用 AES 对交易数据进行加密，防止用户的银行卡号、密码等信息泄露。

对称加密+HTTP 的问题？

最为简单的HTTP加密传输（对称加密+HTTP），这种方式的优点：

密文传输，而不是明文传输
加密和解密性能高

对称加密+HTTP的问题:

服务端、客户端需要共享同一个密钥。
所以：在开始数据传输之前，服务端需要把密钥发给客户端。

问题是？

服务端如何安全地将密钥分发给客户端？在第一阶段发送密钥的时候，如何不被拦截的？毫无疑问，这是一个巨大的挑战。

没有办法阻止拦截，或者说，拦截是不可避免的。当我们通过网络直接发送密钥，那么密钥很容易在传输过程中被第三方拦截。

因为 HTTP 本身是明文传输协议，没有加密机制来保护密钥传输过程。

如何解决对称加密+HTTP 的问题？使用非对称加密，或者说使用两个密钥：

一个私钥，一个公钥。
公钥是可以公开的密钥，被拦截了也无所谓。

5. 相对安全的HTTP加密传输：非对称加密+HTTP

既然对称算法加密+HTTP 还是不够安全，那我们用非对称加密+HTTP。

什么是非对称加密算法（Asymmetric Cryptography）？

非对称加密算法（Asymmetric Cryptography）又称为公开密钥加密算法，它需要两个密钥，一个称为公开密钥（公钥）；另一个称为私有密钥（私钥）.

公开密钥与私有密钥是一对。

如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；
如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。

因为加密和解密使用的是两个不同的密钥，所以这种算法叫作: 非对称加密算法。

公开密钥是可以公开的，大家都知道都没有问题。

非对称加密的典型处理流程，大致如下图所示：

图：非对称加密的典型处理流程

非对称加密优点是公开密钥是可以公开的，知道了公钥，也没办法解密。

非对称加密缺点是速度慢。

典型的非对称加密算法有RSA、DSA等。

非对称加密HTTP 的传输过程（以RSA 非对称加密例）

45岁老架构师图解一下非对称加密 HTTP传输的传输过程（以RSA 非对称加密例）：

使用非对称加密算法之后，HTTP流程又是怎样的，如下图：

对上图的 HTTP 对称加密传输的传输过程（以AES/DES 对称加密例）进行介绍，大致如下：

客户端在开始正式的请求之前，需要先进行公钥的请求。服务端给客户端创建一个专用的公钥（或者通用的也行），然后返回给客户端。
客户端把要发送的request 消息，用公钥加密，request 传输过程中，密文传输。
服务器收到密文消息，用配套的私钥，把密文解密成明文，后进行业务处理。
处理完成后，服务端把response消息报文返回给客户端之前，需要进行私钥加密，response传输过程中，密文传输。
客户端收到 response 密文，用公钥解密，得到明文。

注意，上面的流程，涉及到非对称加密的规则：

公开密钥与私有密钥是一对。
如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；
如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。

非对称加密HTTP 的传输的问题？

非对称算法（如：RSA）有个弊端，它很慢。

来看看非对称加密 RSA 加密和解密的大致时间：

加密时间RSA 加密时间受多种因素影响，包括密钥长度、消息长度和计算机性能等。

一般来说，对于一个 1024 位的 RSA 密钥和较短的消息（如 128 字节），在普通的4c8g 上进行加密可能需要几毫秒到几十毫秒的时间。

如果密钥长度增加到 2048 位，加密相同长度的消息可能需要几十毫秒到几百毫秒的时间。
解密时间

解密通常比加密更耗时。

同样以 1024 位 RSA 密钥和 128 字节消息为例，在4c8g计算机上解密可能需要几十毫秒到上百毫秒

如果密钥长度增加到 2048 位，解密时间可能会增加到几百毫秒甚至超过 1 秒，尤其是当消息长度较长或者计算机性能较差时，解密时间会显著延长。

来看看AES/DES（对称加密）的加密和解密的大致时间：

对于较短的数据块（比如几百字节到几 KB），在4c8g计算机上进行一次 AES/DES 加密或解密操作，大致时间可能在微秒级到几十微秒级之间。例如，对一个 1KB 的数据块进行 AES/DES 加密，可能花费 10 微秒左右的时间。
在4c8g计算机上，对几十字节的数据块进行 AES/DES 加密或解密，时间可能在几微秒左右。例如，对 50 字节的数据块进行 AES/DES 加密，可能只需 2 - 3 微秒。
在4c8g计算机上对 1KB 数据块进行 AES/DES 加密大概需 10 微秒左右，当数据块增大到 10KB 时，加密或解密时间可能会增加到几十微秒，比如 30 - 50 微秒左右。
在4c8g计算机上，对几百 KB 的数据块进行 AES/DES 加密或解密，时间可能会上升到毫秒级。例如，对 500KB 的数据块进行 AES/DES 加密，可能需要 1 - 2 毫秒左右的时间。

简单对比一下， AES/DES（对称加密）的性能是非对称算法（如：RSA）的1000倍。

45岁老架构师不得不感慨：竟然有如此巨大的差距，毫秒级别和微秒级别呀。

所以，非对称加密虽然在安全性上更高，但由于其性能和资源消耗的问题，通常不用于大量数据的直接的对称加密。

6 相对安全的HTTP加密传输：非对称算法 + 对称加密 + HTTP

AES/DES（对称加密）+ 非对称算法（RSA）的强强联合

怎么办呢？能不能结合起来呢？充分发挥各自的优点：

AES/DES（对称加密）+ 非对称算法（RSA）如何实现强强联合，完成安全的 HTTP 传输呢？

首先把传输分成两个阶段：

第一阶段： AES/DES 密钥传输阶段：在开始http的数据传输之前，首先通过非对称加密算法，交换一下 AES/DES的密钥。这个阶段充分利用了非对称加密的安全性。
第二阶段：http的数据传输阶段：开始 http的数据传输之后，使用第一阶段的 AES/DES 密钥，进行数据加密后再传输，在传输过程中使用密文传输。

HTTPS协议，就是这么干的。

HTTPS协议的第一阶段非对称加密主要用于密钥交换，而第二阶段数据传输则主要依赖于对称加密。

HTTP 两阶段加密传输的过程（ RSA非对称算法 +AES/DES 对称加密）

45岁老架构师图解一下HTTP 两阶段加密的传输过程（非对称算法 +AES/DES 对称加密RSA ）：

第一阶段： AES/DES 密钥传输阶段：首先通过 RSA 非对称加密算法，交换一下 AES/DES的密钥。
第二阶段：http的数据传输阶段：使用第一阶段的 AES/DES 密钥，进行数据加密后再传输。

具体如下图：

对上图的 HTTP 对称加密传输的传输过程（以AES/DES 对称加密例）进行介绍。

第一阶段： AES/DES 密钥传输阶段：首先通过 RSA 非对称加密算法，交换一下 AES/DES的密钥。

第一小步：客户端在开始正式的请求之前，需要先进行公钥的请求。服务端给客户端创建一个专用的公钥（或者通用的也行），然后返回给客户端。（图上忽略了这个小步）
第2小步：客户端把要发送的 AES/DES 密钥的 request 消息，用公钥加密，request 传输过程中，密文传输。
第3小步：服务器收到密文消息，用配套的私钥，把密文解密成明文，后进行业务处理。
第4小步：处理完成后，服务端把AES/DES 密钥 response消息报文返回给客户端之前，需要进行私钥加密，response传输过程中，密文传输。
第5小步：客户端收到 response 密文，用公钥解密，得到AES/DES 密钥的明文。

45岁老架构师老架构师尼恩提示，由于上图实在太大，第一阶段的第一小步获取 rsa 公钥的请求和响应的流程，尼恩直接在上图忽略了。

第二阶段：http的数据传输阶段，使用第一阶段的 AES/DES 密钥，进行数据加密后再传输。

第1小步：客户端发送 http request之前，用自己的AES/DES 密钥（对称加密密钥）对其进行对称解密，再发送给服务端
第2小步：服务器接收到客户端发来的request 密文之后，用自己的AES/DES 密钥（对称加密密钥）对其进行对称解密，再进行业务处理。
第3小步：处理完成后，服务端用 AES/DES 密钥 response消息报文加密，再发送 client客户端，response传输过程中，密文传输。
第4小步：客户端收到 response 密文，用AES/DES 密钥解密，得到response 明文。

HTTP 两阶段加密传输的（非对称算法RSA +AES/DES 对称加密）特点

第一阶段： AES/DES 密钥传输阶段，通过非对称算法RSA 交换一下 AES/DES的密钥。这个阶段充分利用了非对称加密的安全性。虽然性能低下，但是在长连接场景下，一个连接可以反复发请求，所以不影响性能。
第二阶段：http的数据传输阶段：开始 http的数据传输之后，使用 AES/DES 密钥进行数据加密后再传输。 AES/DES 虽然不是太安全，但是性能高，另外，可以使用更高性能的AES 算法，提高第二阶段的对称加密的安全性。

7 HTTPS 协议的构成：HTTPS = HTTP+ SSL/TLS

前面已经讲到，HTTPS协议就是两阶段的加密通讯：

第一阶段非对称加密主要用于密钥交换
而第二阶段数据传输则主要依赖于对称加密。

HTTPS协议是基于 SSL/TLS 协议实现这个两个阶段的。

HTTPS 的定义与原理

HTTPS 即 Hypertext Transfer Protocol Secure，是一种网络传输协议，通过在 HTTP 的基础上增加安全性来保护客户端与服务器之间的数据传输5。

HTTPS 使用 SSL/TLS 协议对数据进行加密，确保数据在传输过程中不会被窃取或篡改，有效防止中间人攻击，保证通信过程的机密性和完整性.

HTTPS 与 SSL/TLS 的关系紧密，具体如下：

HTTPS  = HTTP+ SSL/TLS

两阶段的加密通讯过程，是 SSL/TLS 协议完成的。

SSL/TLS 的定义与发展

SSL 即 Secure Sockets Layer，是由网景公司研发的安全套接层协议，旨在为网络通信提供安全及数据完整性保障145.
TLS 即 Transport Layer Security，是 SSL 的升级版，IETF 对 SSL 3.0 进行标准化并添加少数机制后形成，通常被标示为 SSL 3.1 等，其最大优势在于独立于应用协议，高层协议可透明地分布在 TLS 协议之上145.

HTTPS 与 SSL/TLS 的具体关系

HTTPS 依赖 SSL/TLS 实现加密：

HTTPS 的核心就是在 HTTP 协议和 TCP 协议之间加入了 SSL/TLS 层，利用 SSL/TLS 提供的加密、身份验证等功能，对 HTTP 数据进行加密处理，将原本明文传输的 HTTP 数据转换为密文传输，从而确保数据的安全性和完整性。例如，当用户在浏览器中访问一个 HTTPS 网站时，浏览器会先与服务器建立 SSL/TLS 连接，在此基础上再进行 HTTP 通信.
SSL/TLS 为 HTTPS 提供安全保障：

SSL/TLS 协议通过一系列的加密算法、密钥交换机制和数字证书等技术，实现客户端与服务器之间的身份认证、数据加密和消息完整性校验，为 HTTPS 通信提供了可靠的安全保障，使得用户在网络上传输敏感信息时更加安全可靠.
版本兼容性影响 HTTPS 通信：

不同版本的 SSL/TLS 在安全性和功能上有所不同，较新的版本通常修复了旧版本的漏洞并提供了更强的加密算法和安全特性。因此，在 HTTPS 通信中，客户端和服务器需要协商确定使用的 SSL/TLS 版本，以确保双方能够正常通信并提供足够的安全保障。如果客户端和服务器支持的 SSL/TLS 版本不匹配，可能会导致通信失败或出现安全风险.

关于 SSL/TLS 协议 的详细介绍
请参考尼恩的  《尼恩Java 高并发核心编程 卷1》 最新版本

公钥传输的第三方劫持问题？

在SSL/TSL加密传输的开始的时候，客户端需要首先获得服务端的公钥，这个过程可能会被第三方劫持，具体如下图所示：

图：客户端的Client Hello请求被第三方劫持，此图来自《尼恩Java 高并发核心编程卷1》

当客户端首先获得服务端的公钥时，是发送Client Hello帧，这个数据包被劫持时，服务端发送到客户端的公钥，会被第三方截获。

第三方截取到客户端，第三方自己会伪造一对密钥（包含公钥和私钥），并将伪造的公钥发送给客户端。

当服务端发送数据给客户端的时候，第三方也会将信息进行劫持，用一开始截获的公钥进行解密后，然后使用自己的私钥将数据再一次加密后发送给客户端，而客户端收到后使用第三方（劫持方）的公钥去解密。

反过来也是如此，当客户端发送数据给服务端时，报文亦会被劫持方截取和转发，并且，整个截取和转发的过程是对于客户端和服务端都是透明和不可见的，但信息却被悄然泄露了。

数据帧被劫持的过程，大致如下图所示：

图：数据帧被劫持的过程，此图来自《尼恩Java 高并发核心编程卷1》

HTTPS 如何防止第三方劫持的公钥，确定公钥的传输安全？这里涉及到了 CA 数字证书（Certificate Authority）

CA 数字证书（Certificate Authority）的颁发

为了防止拿到第三方劫持的公钥，CA 数字证书（Certificate Authority）就出现了。

数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，它是由权威机构——CA机构（Certificate Authority、认证中心）发行的，人们可以在网上用它来识别对方的身份。

数字证书颁发过程一般为：用户首先产生自己的密钥对，并将公钥及身份信息提供给CA机构（认证中心）。

CA机构（认证中心）在核实身份后，确认一下这些认证请求确实由用户提交的，然后执行一些必要的步骤，然后给用户一个数字证书。

一个数字证书中含有三个部分：证书内容、散列算法、加密密文。

证书内容：包含服务端的个人信息 / 公钥信息 / 其他信息；当然，最重要的公钥信息，这是我们要重点保护的内部。
加密密文（/数字签名）：这部分为证书内容通过hash 散列算法计算出摘要之后，然后使用CA机构的私钥进行RSA 非对称加密后的密文，加密密文也可以理解成为CA机构自己的数字签名。

如图所下：

CA机构（认证中心）证书的生成过程如下：

应用服务器的公钥和应用的个人信息，经过Hash算法加密，形成消息摘要；
将消息摘要拿到拥有公信力的认证中心（CA），用它的CA 中心的私钥对消息摘要加密，形成数字签名.
公钥和个人信息、数字签名共同构成数字证书。

CA 数字证书的验证流程

当客户端发起请求时，服务端将该数字证书发送给客户端，客户端首先需要对证书进行验证。

客户端验证 CA证书具体的方法为：

客户端从服务端拿到 CA 数字证书
客户端通过CA机构拿到公钥，
客户端使用 CA机构公钥，对CA证书做验证

客户端使用 CA机构公钥，对CA证书做验证的流程是：

首先客户端需要对证书CA 证书的数字签名（加密密文）进行解密，这里解密用到了 CA 公钥，解密之后，获得服务端证书的内容摘要（散列值）
然后，客户端将证书内容（Server信息、Server公钥，其他）使用相同的散列算法进行 hash计算，获取一段摘要（散列值）
比对两个摘要（散列值），如果两者相等，说明证书中的Server公钥没有被第三方篡改，仍然是服务端原始公钥 , 如果两者不相等，则说明服务端证书发生了第三方篡改，说明服务端有被劫持。

客户端使用 CA机构公钥，对CA证书做验证的结果是：

数字证书的内容部分，用同样的Hash算法，再次生成消息摘要；
数字证书的密文部分，用CA的公钥解密，得到CA创建的原始的消息摘要；
两者对比，如果相同，就没有人Server 的公钥了。

注意，这里出现了两个公钥：

Server 公钥：这个是后面 https 协议在传输 AES 密钥阶段要用的。
CA的公钥：这个是解密 CA证书用的，一般是浏览器从 CA证书服务器，自己去下载的。 Server端不管这个公钥。

CA 的数字签名，相当于给 Server 公钥盖个章，作为证明。

还有一个问题，如何验证验证CA 证书的颁发机构的合法性？

操作系统和浏览器通常会内置一些权威 CA 机构的根证书。根证书是 CA 认证中心给自己颁发的证书，是整个信任链的起始点，没有上层机构再为其本身作数位签章，所以都是自签证书。从技术上讲，根证书包含 CA 机构的信息、公钥以及 CA 机构对自身信息和公钥的签名，它的公钥用于验证由该 CA 机构颁发的其他证书的签名，从而确定这些证书的真实性和有效性

如果待验证的 CA 证书里边，能够追溯到这些内置的根证书。或者说，沿着证书链向上查找，最终能够找到受信任的根证书，则可认为该 CA 机构是合法的。

例如，常见的浏览器会内置一些知名 CA 机构的根证书，当访问一个网站时，浏览器会验证该网站的证书是否由这些受信任的 CA 机构颁发，或者是否能够通过受信任的根证书追溯到合法的证书链。

数字证书的格式是啥呢？

数字证书的格式普遍采用的是X.509国际标准，X.509是一种进行身份认证的行业安全标准，在该标准中，用户可生成一段信息及其摘要(亦称作信息“指纹”)，并用专用密钥对摘要加密以形成签名，接收者用发送者的公共密钥对签名解密，并将之与收到的信息“指纹”进行比较，以确定其真实性。

X.509标准有不同的版本，其中X.509/V2和X.509/V3都是目前比较新的版本，但是都在原有版本（X.509/V1）的基础上进行功能的扩充，其中每一版的数字证书，大致包含下列信息：

（1）证书的版本信息；

（2）证书的序列号，每个证书都有一个唯一的证书序列号；

（3）证书所使用的签名算法；

（4）证书的发行机构名称，命名规则一般采用X.500协议格式；

（5）证书的有效期，通用的证书一般采用UTC时间格式，它的计时范围为1950-2049；

（6）证书所有人的名称，命名规则一般采用X.500协议格式；

（7）证书所有人的公开密钥；

（8）证书发行者对证书的数字签名。

8. 完整的HTTPS 两阶段加密的传输过程

服务器必须要有一套CA数字证书，可以自己制作，也可以向CA机构申请。区别是：自己颁发的证书需要客户端验证通过。

互联网的证书，一般都是向CA机构申请的。这套证书其实就是一对公钥和私钥

有了证书之后，来看看咱们的

上图的完整的HTTPS 两阶段加密的传输过程，分为两个大的阶段：

第一阶段： CA证书与 Client DES 密钥传输阶段，第一阶段，也叫做握手阶段。
第二阶段：http的数据传输阶段，使用第一阶段的 AES/DES 密钥，进行数据加密后再传输

第一阶段：握手阶段，完成 CA证书与 Client DES 密钥传输。

第1小步：客户端在浏览器里输入一个https网址，然后连接到server的443端口。客户端在开始正式的请求之前，需要先进行公钥的请求，发起https请求之后，服务器默认是来请求CA证书的（证书里边有Server公钥）。
第2小步：服务器将自己的CA数字证书（含有公钥）发送给客户端。
第3小步：客户端收到 CA数字证书，用CA 公钥解密和验证，如果不通过，则弹出警告框。
第4小步：如果证书没问题，客户端生成一个AES /DES 传输密钥（对称加密），用证书的公钥对它加密，发给服务端。
第5小步：服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥, 这就是后面的传输阶段的传输密钥。然后，服务器端使用使用密钥（客户端）加密一段握手消息，发送给客户端浏览器
第6小步：客户端浏览器获取信息后，用密钥（客户端）解密并计算握手消息的HASH，若与服务器发来的HASH一致，此时握手结束，之后所有的听信数据将由之前浏览器生成的随机密码（客户端密钥）利用对称密码算法加密