当前位置：首页 > news >正文

wordpress数据库密码解密商品标题优化

news 2025/7/29 23:57:45

wordpress数据库密码解密,商品标题优化,某某公司网络营销策划书,南宁个人网站建设前言：本篇将介绍TLS握手的实际握手过程，TLS握手创建了Client和Server之间“被保护的通道”，2个单向通道用来保护批量数据的传输（通过Confidentiality、Integrity和Authentication），一个通道是从Client到Ser…

前言：本篇将介绍TLS握手的实际握手过程，TLS握手创建了Client和Server之间“被保护的通道”，2个单向通道用来保护批量数据的传输（通过Confidentiality、Integrity和Authentication），一个通道是从Client到Server，另一个是从Server到Client。本篇将介绍最基础的握手 - 即握手采用的是RSA密钥交换，并通过追条记录（Record）的形式来阐述该过程。

在整个握手的过程中，Client和Server会交换并计算特定的值。上图两侧的框是双方所拥有的信息。开始时，Server已经拥有了证书、公钥和私钥，

1、Handshake：Client Hello

第一条Record是Client Hello，里面包含5个部分

Version
- 包含了Client所支持的TLS/SSL的最高版本
Random Number - 32 bytes / 256 bits
- 前4个字节编码时间戳（防止两个拥有相同随机数的不同的Client Hello相互发送信息）
Session ID - 8 bytes / 32 bits
- 00000...本篇中Client Hello的初始会话ID都是0
Cipher Suites
- Client会发送它所支持的密码套件的列表，Server会从中挑选
Extensions
- 如果有扩展的话会包含在握手中，本篇不包含扩展

2、Handshake：Server Hello

收到Client Hello后，Server会发出Server Hello，和Client Hello一样，包含5部分

Version
- 包含了Server所支持的TLS/SSL的最高版本
Random Number - 32 bytes / 256 bits
- 前4个字节编码时间戳
Session ID - 8 bytes / 32 bits
- Server生成的用于识别后续会话密钥的值
Cipher Suites
- Server（从Client发送的列表中）挑选的密码套件
Extensions
- 如果有扩展的话会包含在握手中，本篇不包含扩展

在Client Hello和Server Hello之后，Client和Server都获得了额外的信息

两者都知道了互相支持的TLS版本。如果Client发送说它支持TLS 1.3，Server返回说它支持TLS 1.2，这就表明两者互相支持的最高的版本是TLS 1.2，两者将用TLS 1.2协议进行握手
两者都知道了互相的随机数（Client Random、Server Random）
两者也知道未来会用来参考本次会话的ID
互相同意的用来保护这次TLS会话的密码套件

3、Handshake：Certificate

这条记录包含了Server证书和完整的证书链，Client会收到证书和公钥。Client收到证书后会问自己2个问题：证书是否合法？（用CA公钥进行的签名可以验证其合法性，在此处Client拥有了其所需要的东西来验证该签名）；Server是否是该证书的真正拥有者？（验证Server拥有与证书匹配的私钥，会由Key Exchange Record所验证）

4、Handshake：Server Hello Done

这是一条空的Record，表明Server此时没有更多信息进行发送；然而，握手的其他变体可能会要求Server发送更多信息。

5、Handshake：Client Key Exchange

Client Key Exchange有2个主要目的

创建相互的密钥材料（例如，SEED Value种子值，Client和Server两者都用来生成会话密钥）
证明Server确实是该证书的拥有者

2个目的都将由特殊的值所达成，即 Pre Master Secret，预主密钥。上图中用红色虚线框描述，表明该值是加密发送的

Pre Master Secret 的生成
- Client生成 Pre-Master-Secret （包含48个字节）
  - 2 bytes - TLS/SSL Version
  - 46 bytes - Random（随机生成的）
- 之后，Pre-Master-Secret 会被Server的公钥进行加密（Client已经有了，因为前面的Record中Server已经发送了）
- Pre-Master-Secret 被加密后进行在线传输，唯一能提取该加密信息的，是拥有与之相匹配的私钥的一方，即有对应私钥的Server
- 现在，两者就都拥有了 Pre-Master-Secret
Pre Master Secret 的生效（在本例中，该值被用作种子值，来生成TLS会话密钥）
- 双方都有了匹配的SEED Value
  - 种子值被用来生成会话密钥
  - 预主密钥被用来生成主密钥（Master Secret）[ 将其他值与PreMasterSecret相结合，这些值是“master secret”文字字符串（包含在RFC里了）、Client Random和Server Random，这4个值会相互结合来生成Master Secret ]
  - 主密钥被用来生成会话密钥 [ 将其他值与Master Secret相结合，这些值是“Key expansion”文字字符串、Client Random和Server Random，这4个值会相互结合来生成会话密钥 ]
    - 至少生成4个会话密钥（2套不同的密钥）：
      - 保护Client发送信息的Client Encryption Key和Client HMAC Key
      - 保护Server发送信息的Server Encryption Key和Server HMAC Key
- 特定加密协议需要 I.V. 即 Initializational Vector，初始化向量，这是（PRF）计算必要的I.V.的步骤
- 计算涉及PRF - Pseudo Random Function，伪随机数函数
  - 生成任意长度的摘要的哈希算法

到此，Client和Server双方都有了完全相同的会话密钥；但是，Client或Server并不知道另一方拥有相同的密钥。

因而，余下的握手将给双方证明：另一方拥有正确的会话密钥。

6、Change Cipher Spec（不是Handshake Record）

该记录表明Client已做好安全通话的一切准备（意味着它可以计算出会话密钥了）。我们可以阅读该记录，Client在说，它做好准备去更改由Client和Server所指定的密码。

7、Handshake：Finished

向Server证明：Client有正确的会话密钥
这会由特定的值（Encrypted Verification）来完成，过程如下
- Client计算出之前所有握手记录（5个）的哈希，这5个记录会一起被哈希，生成Handshake Hash
- 然后，Handshake Hash会与其他值（“client finish”字符串和Master Secret）相结合来生成验证数据（Verification Data）
- 最终，验证数据会被Client Session Keys加密，生成加密验证
  - Server用自己的Client会话密钥副本进行验证
  - 验证Client和Server“看见”相同的握手记录
理论上，Server也看见了之前5个握手记录（即Handshake Hash），“client finished”字符串，同时Server也有Mater Secret，这表明Server能合并得到相同的Verification Data；之后，Server收到加密验证后，用Client Session Key副本去进行解密，如果得到的结果和Server自己合并得到的验证数据相同，这就向Server表明，Client拥有相同的会话密钥。如果有人在Client发送出Client Hello后，Server接受到之前，进行篡改，两边的Verification Data会不匹配

8、Change Cipher Spec（不是Handshake Record）

该记录表明Server已做好安全通话的一切准备（意味着它可以计算出会话密钥了）

9、Handshake：Finished

向Client证明：Server有正确的会话密钥
类似的过程
- Client计算出之前所有握手记录（6个）的哈希，得到Handshake Hash
- Handshake Hash会与其他值（“server finish”字符串和Master Secret）相结合来生成验证数据（Verification Data）
- 验证数据会被Server Session Keys加密，生成加密验证
  - Client用自己的Server会话密钥副本进行验证