企业官网建设流程全解析

一.加密基础知识

1.基础

a.明文:要传输的原始数据

b.密文:对明文进行加密,得到看不懂的内容

c.加密:明文-->密文的过程

d.解密:密文-->明文的过程

e.密钥:在加密与解密是需要用对应的密钥进行操作

2.http与https

HTTP底层基于 TCP，通信前会进行TCP 三次握手建立连接，连接建立完成后直接明文传输 HTTP 报文。整个过程不涉及对称加密、非对称加密，请求里账号、密码、请求体等数据都是明文裸奔。

HTTPS = HTTP + TLS（SSL/TLS 是 HTTPS 的核心加密协议）

SSL（安全套接字协议）诞生于 1996 年，SSL3.0 演进升级为 TLS1.0，日常常合称为 SSL/TLS。

SSL/TLS 核心要素包含非对称加密，非对称加密有一对密钥：公钥用于加密、认证；

私钥用于解密、签名。

HTTPS 的加密分三个阶段：

• 先是完成TCP的三次握手

• TLS 握手阶段：使用非对称加密（RSA/ECC），作用是协商会话密钥、校验服务器证书；
• TLS 握手完成后传输业务 HTTP 报文阶段：使用对称加密（AES），加密真实的请求与响应数据

3.加密的格式

对称加密:一个密钥,既可以加密,也可以解密。

特点:

• 速度快、效率高,适合加密大量数据。比如用同一把钥匙锁门和开门,操作简单快捷。
• 密钥分发和管理比较困难。就像只有一把钥匙,要安全地交给对方很麻烦。
• 一旦密钥泄露,数据安全就无法保证。好比钥匙被别人复制,门锁就形同虚设。
• 常见算法有 DES、AES 等。

非对称加密:一对密钥,一个公钥用于加密,一个私钥用于解密。公钥可以公开分发,私钥必须严格保密。

特点:

• 安全性更高,解决了密钥分发问题。安全协商出对称密钥就已经在需要的人手里,整个过程密钥不外发
• 速度较慢,适合加密少量数据或用于数字签名。
• 常见算法有 RSA、ECC 等。

二.普通的非对称加密

1>.正常情况下交互

先看图>:

后续的信息传递就是通过key加密解密,因为key是在服务器与客户端的本地,中间人无法获取,自然信息就安全,所以中间攻击就是在获取key之前一系列交互被篡改

过程>:

阶段 1：服务端初始化，生成非对称密钥对

服务端在本地运行非对称加密算法（如 RSA），生成一对唯一绑定的密钥：

• 公钥 S：可以公开传播，任何人都可以获取，作用是加密数据
• 私钥 S：仅服务端本地绝密保存，绝不对外泄露，作用是解密数据。

阶段 2：客户端生成 Client Random 并发起握手

• 客户端在本地生成一段随机数Client Random，并将该随机数随握手信息(密钥交换请求)一起发送给服务器，表示准备开始协商密钥。

阶段 3：服务端响应并明文分发公钥

• 服务端收到客户端的握手信息和Client Random后，在本地生成一段随机数Server Random，并将公钥 S 以纯明文形式直接通过网络发送给客户端，不附加任何身份证明、数字签名或权威机构证书。
• 客户端收到公钥 S 后，直接在本地保存备用，不做任何身份校验。

阶段 4：客户端生成并加密预主密钥

• 客户端在本地生成一段随机字符串，称为预主密钥（Pre-Master Secret），用于后续生成对称密钥
• 客户端使用刚刚收到的公钥 S，对预主密钥进行非对称加密，得到加密后的密文。
• 客户端将这份密文发送给服务端。

阶段 5：服务端解密预主密钥

• 服务端收到客户端发来的密文。
• 服务端使用自己本地保存的私钥 S对密文进行非对称解密，还原出明文的预主密钥。
• 此时状态：
  • 服务端持有：公钥 S + 私钥 S + 明文预主密钥
  • 客户端持有：公钥 S + 明文预主密钥
  • 双方都拥有了相同的预主密钥，且全程信道上从未传输过明文的预主密钥。

阶段 6：双方独立派生对称会话密钥

• 客户端和服务端分别在本地，使用完全相同的密钥派生算法，结合预主密钥，以及之前交互中生成的 Client Random、Server Random，计算出最终的对称会话密钥。
• 因为输入参数和算法完全一致，双方计算出的对称密钥内容完全相同。
• 此时非对称加密的核心使命完成，后续业务数据不再使用公钥 S 和私钥 S 加解密。

阶段 7：对称加密传输业务数据

后续所有 HTTP 请求、响应等业务数据，全部使用这个对称会话密钥进行对称加密（如 AES）后再传输。对称加密计算速度快、性能高，适合大量业务数据传输。

2>.被中间人攻击

也很好理解：客户端与服务器交互时不校验消息来源，双方只负责收发数据。中间人可拦截客户端消息，窃取后再转发给服务器；也可篡改服务器信息发给客户端，通信便不再安全。

很大可能出现>:客户端发消息被中间人拦截从而盗取信息转发到服务器上,同时服务器的信息也被中间人篡改并发送给客户端,此时就完蛋了

流程图如下>:

可以看到非常危险

三.Https加密过程

上一节中的普通非对称加密之所以会被中间人攻击，是因为客户端在收到服务器公钥后没有校验对方身份。HTTPS 在 TLS 握手中引入 CA 数字证书，先用证书完成身份认证，再协商对称会话密钥，最终用对称加密保护业务数据。

1>.证书与身份校验

证书由权威机构 CA 签发，通常包含机构名称、过期时间、服务器公钥、签名等内容。客户端本地内置了各大 CA 的根证书公钥，因此能够校验服务器证书是否合法。

校验的过程可以理解为如下>:

• 客户端先检查证书的签发机构、有效期、域名等信息是否匹配。
• 随后客户端拿着证书里的内容进行计算，得到摘要check1。
• 客户端再使用 CA 公钥解密证书中的签名，得到check2。
• 如果check1与check2相同，说明证书内容没有被篡改，证书中的服务器公钥是可信的。

2>.流程介绍

图片>:

加入证书后的 HTTPS 加密过程

前置说明（单向认证 HTTPS 标准场景）

• 服务器：拥有一对非对称密钥，即服务器公钥 + 服务器私钥。公钥封装在数字证书里公开对外分发，私钥仅保存在服务器本地，绝不对外传输。
• 客户端：初始没有自己的非对称密钥对，只内置各大 CA 的根证书公钥，用于校验服务器证书的合法性。
• 非对称密钥（公钥 / 私钥）只在握手阶段用来安全交换预主密钥，后续业务通信全程使用对称密钥。

---

阶段 1：TCP 三次握手

• 客户端与服务器先完成 TCP 三次握手，建立可靠连接。

阶段 2：Client Hello——客户端发起 TLS 握手

• 客户端发送 TLS 版本、加密套件和 Client Random（客户端随机数），表示准备协商密钥。
• 密钥状态：此时客户端尚未拿到服务器公钥，双方还未开始密钥交换；服务器私钥仍在服务端本地。

阶段 3：Server Hello + 下发证书——服务器返回证书并协商参数

• 服务器确认 TLS 版本、加密套件，返回 Server Random（服务器随机数）和服务器数字证书。
• 密钥动作：证书中携带服务器公钥，相当于服务器把自己的公钥公开交给客户端；服务器私钥始终保留在服务端本地，不会随证书发出。

阶段 4：客户端校验证书，生成并加密预主密钥

• 客户端确认证书对应真实的目标服务器后，在本地生成预主密钥（Pre-Master Secret）。
• 密钥动作：客户端使用服务器公钥对预主密钥进行非对称加密，得到密文后发送给服务器。
• 核心特性：这段密文只有对应的服务器私钥才能解开，中间人即使截获也无法解密出预主密钥。

阶段 5：服务器解密预主密钥

• 服务器收到加密后的预主密钥密文，使用自己本地的私钥进行非对称解密，还原出明文的预主密钥。

阶段 6：双方独立生成对称会话密钥

• 双方此时同时拥有 Client Random、Server Random 和预主密钥，使用完全相同的算法，各自独立推导出完全一致的对称加密密钥 Key。
• 密钥状态：从这一步开始，后续通信不再使用服务器的公钥 / 私钥，全部改用这个对称密钥 Key。

阶段 7：双方发送 Finished 消息，完成双向校验

这是客户端向服务器提交的「密钥一致性校验 + 握手完整性校验」凭证

流程如下>:

• 客户端会把从最开始 Client Hello 到当前为止，所有发送和收到的握手报文，通过哈希算法（如 SHA-256）计算出一份唯一的 “握手摘要”，相当于整个握手过程的数字指纹。
• 再使用刚生成的对称密钥 Key对这份握手摘要进行加密，生成 Finished 消息发送给服务器。
• 服务器先用本地对称密钥 Key 解密客户端的 Finished 消息，将解密出的握手摘要与自身本地计算的摘要比对；
• 校验通过后，再用同一个对称密钥 Key 加密自身视角的握手摘要，返回 Finished 消息给客户端。
• 核心作用：完成双向闭环校验，既验证双方生成的对称密钥是否完全一致，也校验整个握手过程的报文(理解为数据)没有被中间人篡改；任意一方校验失败都会直接终止连接。

阶段 8：安全连接建立，对称加密通信

• 双方完成双向校验，确认对称密钥一致且握手全程无篡改，TLS 握手阶段正式结束。
• 后续所有 HTTP 业务请求、响应数据，全部使用这个对称密钥 Key进行加解密传输，兼顾安全性与性能。
• 服务器的公钥、私钥在握手阶段完成全部使命，后续不再参与任何业务数据的加解密运算。

3.缺点

上述流程是经典的RSA 密钥交换方案，特点是服务器证书中的公钥长期固定，私钥长期保存在服务器本地。

RSA 密钥交换的优缺点：

• 优点：握手过程中只要发现报文被篡改或密钥不一致，就会立即终止会话。
• 缺点：不具备前向保密能力。所有会话都依赖服务器这把固定的私钥解密，一旦服务器私钥泄露，攻击者就可以用抓包保存的历史流量，解密出之前所有的预主密钥和会话密钥，导致历史消息全部透明，甚至可能被篡改伪造。

4.ECDHE的双向加密过程

RSA 密钥交换的问题是服务器长期私钥一旦泄露，历史会话就会被解密。ECDHE 改用每次握手临时生成的密钥对来完成密钥交换，长期私钥只负责签名认证，从而解决前向保密问题。

核心前置：

• 服务器长期密钥对：长期公钥放在数字证书里对外公开；长期私钥只用来给临时参数签名，不参与真正的密钥交换。
• 临时密钥对：客户端和服务器在每次握手时，各自在本地随机生成一对临时密钥（临时私钥 + 临时公钥），临时私钥用完即销毁。

ECDHE 双向加密流程：

第一步：TCP 三次握手

• 客户端与服务器先完成 TCP 三次握手，建立可靠连接。

第二步：客户端发送 Client Random

• 客户端在本地生成一段随机数Client Random，通过 ClientHello 消息发送给服务器，表示准备开始 TLS 握手并协商密钥。

第三步：服务器返回 Server Random

• 服务器收到客户端的 ClientHello 后，确认 TLS 版本和加密套件，在本地生成一段随机数Server Random，通过 ServerHello 消息返回给客户端。

第四步：客户端与服务器各自生成本地临时密钥对

注意>:此时就不会生成预主密钥了

• 客户端：在本地随机生成一对临时密钥对（临时私钥 + 临时公钥），临时私钥只保存在客户端本地，临时公钥用于后续交换，临时私钥用完即销毁。
• 服务器：同样在本地随机生成一对临时密钥对（临时私钥 + 临时公钥），临时私钥只保存在服务器本地，临时公钥用于后续交换，临时私钥用完即销毁。

第五步：服务器用长期私钥签名临时公钥

• 服务器：使用自己的长期私钥，对服务器临时公钥参数做数字签名，再把临时公钥参数和签名一起发给客户端。相当于给临时参数盖了一个只能由服务器本人盖的章。
• 客户端：等待接收服务器发来的临时公钥参数和签名。

第六步：客户端验签并交换临时公钥

• 客户端：收到服务器临时公钥参数和签名后，先用证书中的服务器长期公钥验签，确认服务器临时公钥未被篡改；验签通过后，把自己的临时公钥明文发给服务器。
• 服务器：接收客户端发来的临时公钥。
• 说明：客户端临时公钥可以明文发送，因为即使被截获，也无法单独推算出共享密钥。

第七步：客户端与服务器各自独立计算同一个共享密钥

• 客户端：使用自己的临时私钥 + 服务器的临时公钥，通过 ECDH 算法独立计算共享密钥。
• 服务器：使用自己的临时私钥 + 客户端的临时公钥，通过 ECDH 算法独立计算共享密钥。
• 结果：双方计算出的共享密钥完全相同，且整个过程中临时私钥不上网传输。

第八步：派生对称会话密钥并开始加密通信

• 客户端：在本地把共享密钥与 Client Random、Server Random 一起派生为对称会话密钥。
• 服务器：同样在本地把共享密钥与 Client Random、Server Random 一起派生为对称会话密钥。
• 后续：双方完成 Finished 校验，确认密钥一致且握手无篡改后，后续业务数据全部用对称密钥加密传输。

临时公钥被篡改会怎样？

• 先签名再下发：ECDHE 里服务器下发的临时公钥参数不是裸发的，而是先用服务器长期私钥做了数字签名，再把临时公钥参数和签名一起发给客户端。
• 客户端先验签：客户端收到后不会直接使用，而是先用证书里的服务器长期公钥验签，确认签名来自服务器本人，同时确认临时公钥参数没被篡改，确认无误后才使用这份临时公钥。
• 公钥不只是用来加密：非对称加密的密钥对有双向用法——正向是公钥加密、私钥解密；反向是私钥签名、公钥验签。任何拿到长期公钥的人都能通过验签确认签名来自服务器本人。
• 被篡改就直接失败：临时公钥参数只要被中间人篡改一点点，验签结果就对不上；一旦验签失败，客户端就会认定这份临时公钥不可信，立即终止握手，不再继续生成会话密钥。

所以 ECDHE 防篡改的核心不是直接加密预主密钥，而是用签名保证临时参数来源可信、内容没被改过。

ECDHE 的主要优点：

• 每次握手生成临时密钥对：每次会话使用随机生成的临时私钥，用完即销毁，不落盘、不长期保存。
• 支持前向保密：即使服务器长期私钥泄露，也无法解密之前抓包保存的历史会话，因为每次会话密钥都是临时且独立的。
• 服务器私钥只用于签名认证：长期私钥不参与实际密钥交换，仅用于对临时公钥参数签名，身份认证与密钥交换解耦。
• 双方独立计算共享密钥：客户端和服务器通过交换公开参数，各自独立计算出相同的会话密钥，临时私钥不会在网络上传输。

通俗解释：

• 每次握手生成临时密钥对：每次通话前都临时配一把新钥匙，通完话就把这把钥匙销毁，下次再通话重新配一把全新的钥匙。
• 支持前向保密：因为每次都用新钥匙，攻击者就算事后拿到服务器长期保存的“主钥匙”，也解不开以前保存的历史通话，因为历史通话用的是早已销毁的临时钥匙。
• 服务器私钥只用于签名认证：服务器长期私钥不真正参与密钥交换，只负责“签名盖章”，证明“我确实是这台服务器”。真正交换密钥时，已经改用临时生成的密钥对。
• 双方独立计算共享密钥：双方各自在本地用公开参数独立算出同一把会话钥匙，网络上只传公开参数，不传真正的会话钥匙和临时私钥，所以中间人拿不到。

不得不说,csdn里集成的AI agent很不错,文本内容、格式随时优化修改