一.加密基础知识1.基础a.明文:要传输的原始数据b.密文:对明文进行加密,得到看不懂的内容c.加密:明文--密文的过程d.解密:密文--明文的过程e.密钥:在加密与解密是需要用对应的密钥进行操作2.http与httpsHTTP底层基于 TCP通信前会进行TCP 三次握手建立连接连接建立完成后直接明文传输 HTTP 报文。整个过程不涉及对称加密、非对称加密请求里账号、密码、请求体等数据都是明文裸奔。HTTPS HTTP TLSSSL/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 的根证书公钥用于校验服务器证书的合法性。非对称密钥公钥 / 私钥只在握手阶段用来安全交换预主密钥后续业务通信全程使用对称密钥。阶段 1TCP 三次握手客户端与服务器先完成 TCP 三次握手建立可靠连接。阶段 2Client Hello——客户端发起 TLS 握手客户端发送 TLS 版本、加密套件和 Client Random客户端随机数表示准备协商密钥。密钥状态此时客户端尚未拿到服务器公钥双方还未开始密钥交换服务器私钥仍在服务端本地。阶段 3Server 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很不错,文本内容、格式随时优化修改 加密算法与https
一.加密基础知识1.基础a.明文:要传输的原始数据b.密文:对明文进行加密,得到看不懂的内容c.加密:明文--密文的过程d.解密:密文--明文的过程e.密钥:在加密与解密是需要用对应的密钥进行操作2.http与httpsHTTP底层基于 TCP通信前会进行TCP 三次握手建立连接连接建立完成后直接明文传输 HTTP 报文。整个过程不涉及对称加密、非对称加密请求里账号、密码、请求体等数据都是明文裸奔。HTTPS HTTP TLSSSL/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 的根证书公钥用于校验服务器证书的合法性。非对称密钥公钥 / 私钥只在握手阶段用来安全交换预主密钥后续业务通信全程使用对称密钥。阶段 1TCP 三次握手客户端与服务器先完成 TCP 三次握手建立可靠连接。阶段 2Client Hello——客户端发起 TLS 握手客户端发送 TLS 版本、加密套件和 Client Random客户端随机数表示准备协商密钥。密钥状态此时客户端尚未拿到服务器公钥双方还未开始密钥交换服务器私钥仍在服务端本地。阶段 3Server 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很不错,文本内容、格式随时优化修改