俄文网站seo常用的工具

1. TLS字段、参数含义
2. 要了解每个消息是什么意思 基本方式只验证服务端，服务端有证书，变形方式加上验证客户端
3. TLS1.3区别

协商过程

背景

Record层使用的各种加密算法参数，均由Handshake协议协商获得。

具体过程

1. 随机数交换

   • Client/Server相互发送随机数（以明文形式）。

2. 算法选择

   • 协商双方选择使用的加密算法。

3. 公钥交换

   • Server发送自己的公钥证书。
   • Client验证该证书的有效性。

4. 生成Premaster Secret

   • Client生成Premaster Secret，并用Server的公钥加密后发送给Server。
   • Server解密获取Premaster Secret。

5. 密钥计算

   • 双方基于共享的Premaster Secret和随机数，使用约定的算法计算出：
     • W Key（工作密钥）
     • IV（初始化向量）
     • MAC_Secret（消息认证密钥）

1. TLS1.2交互过程

1. 简单过程（ClientHello 和 ServerHello）

• ClientHello：

  • 包含以下信息：

    • 支持的最高协议版本。
    • 32字节随机数（4字节时间 + 28字节随机数）。
    • Session ID（用于Session重用，可选）。
    • 支持的密码算法列表（cipher suites）。

  • 数据结构：

    struct {uint32 gmt_unix_time;opaque random_bytes[28];
    } Random;
    

• ServerHello：

  • 包含以下信息：

    • 同样的32字节随机数。
    • 选定的协议版本和算法（cipher suite，单个）。
    • Session ID（同样可选）。

  • 数据结构：

    struct {ProtocolVersion server_version;Random random;SessionID session_id;CipherSuite cipher_suite;CompressionMethod compression_method;
    } ServerHello;
    

---

2. Server端发送证书及确认

• Certificate：

  • Server端发送证书链，包含从Server证书到信任链开始的完整链。
  • 包含Server的RSA公钥。

• ServerHelloDone：

  • Server端完成Hello阶段，等待Client的响应。

---

3. Client生成并发送密钥 (ClientKeyExchange)

• Premaster Secret：

  • Client根据ServerHello选择的密钥协商算法生成。

  • 生成的48字节Premaster Secret用Server证书公钥加密后发送。

  • 数据结构：

    struct {select (KeyExchangeAlgorithm) {case rsa: EncryptedPreMasterSecret;...} exchange_keys;
    } ClientKeyExchange;
    

• 共享的秘密信息：

  • 共有以下三部分：
    • 32字节Client.random（ClientHello）。
    • 32字节Server.random（ServerHello）。
    • 48字节Premaster Secret（秘密）。

4. 生成Master Secret

• 基于Premaster Secret和随机数生成48字节Master Secret。

• 使用伪随机函数（PRF）：

  master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)[0..47];
  

5. 生成所需的密钥、IV、MAC Secret等

• 基于Master Secret、Client Random和Server Random生成：

  • MAC Secret（消息认证密钥）。
  • 工作密钥（Write Key）。
  • IV（初始化向量）。

• PRF计算：

  key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
  

---

6. ChangeCipherSpec & Finished

• ChangeCipherSpec：

  • 客户端和服务器分别切换到协商好的加密算法及密钥。

• Finished：

  • 双方发送验证消息，表明握手完成：

    verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))[0..verify_data_length-1];
    

---

7. 最基本的Handshake协议流程总结

• 步骤总结：
  1. Client → Server：ClientHello。
  2. Server → Client：ServerHello, Certificate, ServerHelloDone。
  3. Client → Server：ClientKeyExchange, [ChangeCipherSpec], Finished。
  4. Server → Client：[ChangeCipherSpec], Finished。
  5. 双方进入Application Data阶段。

基本变形1 - Client鉴别

变形1：Client鉴别

• 基本背景：
  • 默认情况下，Client会利用Server证书对Server进行鉴别。
  • 在支持双向认证的场景中，Server可以对Client进行鉴别。

流程

1. Server向Client请求证书：

   • 在发送完Server证书之后，Server发送CertificateRequest消息。

   • CertificateRequest中列出了Server接收的Client证书要求，包括：

     • 算法（如RSA、DSS等）。
     • 受信任的CA名称。

   • 数据结构：

     struct {ClientCertificateType certificate_types<1..2^8-1>;SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>;DistinguishedName certificate_authorities<0..2^16-1>;
     } CertificateRequest;
     

---

2. Client响应：
   • Client需要回复Certificate和CertificateVerify消息：

     • Certificate消息：包含Client的证书链，证明自己的身份。

       struct {ASN.1Cert certificate_list<0..2^24-1>;
       } Certificate;
       

     • CertificateVerify消息：

       • 对所有之前的Handshake消息进行数字签名（从ClientHello到当前消息，不包括本消息）。
       • 用于证明Client对所发送消息的完整性及其身份的真实性。

       struct {digitally-signed struct {opaque handshake_messages[handshake_messages_length];};
       } CertificateVerify;
       

---

3. 验证流程：
   • Server验证Client提交的证书是否可信，是否满足其在CertificateRequest中的要求。
   • 确认Client身份后，完成后续Handshake过程。

总结

• 双向认证的场景主要通过Server对Client的证书请求与验证实现。
• Client通过CertificateVerify消息提供对其身份及Handshake消息的数字签名，确保其认证信息的真实性和完整性。

变形2 - 不同类型证书/算法的影响

1. ClientHello

• Client → Server：发送ClientHello消息。
  • 包含随机数 (R_C)。
  • 支持的协议版本、加密算法、压缩方法等信息。

---

2. ServerHello

• Server → Client：发送ServerHello消息。
  • 包含随机数 (R_S)。
  • 确定的协议版本、加密算法、Session ID。

---

3. Server发送附加消息

• Server根据需要发送以下消息：
  • Certificate (可选)：发送Server证书链。
  • ServerKeyExchange (可选)：在非RSA加密时发送，包含密钥交换所需的信息。
  • CertificateRequest (可选)：请求Client提供证书（用于双向认证）。
  • ServerHelloDone：表明Server完成Hello阶段，等待Client响应。

---

4. Client发送响应消息

• Certificate (可选)：发送Client证书，用于证明其身份（双向认证）。
• ClientKeyExchange：发送密钥交换信息（例如，Premaster Secret加密数据）。
• CertificateVerify (可选)：对之前的Handshake消息进行签名，用于验证Client身份。

---

5. ChangeCipherSpec & Finished

• Client → Server：
  • ChangeCipherSpec：通知切换到加密通信。
  • Finished：发送加密的验证消息，表明握手完成。
• Server → Client：
  • ChangeCipherSpec：通知切换到加密通信。
  • Finished：发送加密的验证消息，表明握手完成。

---

6. 加密的Application Data阶段

• 双方开始加密通信，传输实际的应用数据。
• 所有后续数据都受到握手中协商的加密算法和密钥的保护。

重要说明

• 带星号 (*) 的步骤为可选。
• ChangeCipherSpec和Finished标志着切换到加密通信阶段。
• 握手完成后，所有通信均加密。

变形3 - Session重用

Session重用的背景

• Session重用机制旨在提高TLS协议的效率，避免重新协商所有参数。
• 使用Session ID来标识和重用之前的会话。

---

1. 第一次协商会话

• 在首次TLS握手协商时：
  • ServerHello中会给出一个Session ID。
  • 如果Server不想支持Session重用，则不会提供Session ID。
  • 双方完成会话协商后，传输一定的Application Data后，断开连接。

---

2. 第二次会话中Client发起重用

• ClientHello：
  • 在第二次会话中，Client在ClientHello中携带上次的Session ID，表示希望重用Session。
  • 如果Client不希望重用Session，则在ClientHello中不提供Session ID。

---

3. Server处理Client的重用请求

• ServerHello：
  • Server接收到带有Session ID的ClientHello后，会查找自己的缓存：
    • 如果找到与该Session ID对应的Session，并且Server允许重用：
      • 在返回的ServerHello中携带相同的Session ID，表示同意重用。
      • 跳过完整握手过程，直接切换到加密算法，通过发送ChangeCipherSpec和Finished消息完成重用过程。
    • 如果未找到或不允许重用：
      • Server返回一个新的Session ID，表示重新协商。

---

Session重用过程的关键点

1. Client的请求：

   • 在ClientHello中明确是否希望重用Session。

2. Server的处理：

   • 通过Session ID查询缓存，并决定是否接受重用请求。

3. 效率提升：

   • 如果允许重用，跳过复杂的握手过程，直接切换到加密传输阶段。

2. TLS1.3的区别