HTTPS--TLS 总结归纳

SSL / TLS 握手详细过程

1. "client hello"消息：客户端通过发送"client hello"消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择，还有一个"client random"随机字符串。
2. "server hello"消息：服务器发送"server hello"消息对客户端进行回应，该消息包含了数字证书，服务器选择的密码组合和"server random"随机字符串。

3. 验证：客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：

   1. 检查数字签名
   2. 验证证书链 (这个概念下面会进行说明)
   3. 检查证书的有效期
   4. 检查证书的撤回状态 (撤回代表证书已失效)
4. "premaster secret"字符串：客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)"，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。
5. 使用私钥：服务器使用私钥解密"premaster secret"。
6. 生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
7. 客户端就绪：客户端发送经过共享密钥 KEY加密过的"finished"信号。
8. 服务器就绪：服务器发送经过共享密钥 KEY加密过的"finished"信号。
9. 达成安全通信：握手完成，双方使用对称加密进行安全通信。

结合wirshark工具

握手过程图示

参考 “网络协议那些事儿 - 如何抓包并破解 HTTPS 加密数据?”，本文是抓取的 www.imooc.com 网站数据包，基于 TLS v1.2 协议未对数据包做解密处理。

下图展示了 HTTPS 链接建立、TLS 握手协议里参数传递、证书验证、协商对称密钥的过程，更详细的内容，下文会介绍。

Client Hello

在一次新的握手协议中，客户端(浏览器)首先发出的一条消息是 “Client Hello”，告诉服务器我将给你传递这些数据：

• Version：客户端支持的最佳协议版本号。
• Random：客户端提供给服务器的随机数，在每次握手中都会重新生成，这个随机数用于后续生成密钥。
• Session ID：会话 ID 在第一次链接时该字段是空的，表示客户端并不希望恢复某个已存在的会话。
• Cipher Suites：客户端所支持的所有秘密套件，按优先级顺序排列。

Handshake Protocol: Client Hello 
  Handshake Type: Client Hello (1) 
  Length: 223 
  Version: TLS 1.2 (0x0303) 
  Random: b0fcb3aca27c6de8b0e4f146b92d33f24e6a671e62f8f6f669aabbfc19bb4326 
  Session ID Length: 0 
  Cipher Suites Length: 92 
  Cipher Suites (46 suites) 
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) 
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) 
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) 
    ... 

Server Hello

“Server Hello” 是服务器在收到客户端 “Client Hello” 之后的一个回应，告诉客户端服务器的协议版本、服务器也会给出一个随机数 Random 用于后续生成密钥，Cipher Suite 是从客户端 “Client Hello” 消息的 Cipher Suites 里选择的一个密码套件。

Handshake Protocol: Server Hello 
    Handshake Type: Server Hello (2) 
    Length: 89 
    Version: TLS 1.2 (0x0303) 
    Random: 616d836f609800aaa1713462f61d50cc6472c45b54c0ac58dd52b9db4d555f6f 
    Session ID Length: 32 
    Session ID: 279fb99351526e29a4ce41af4cbff5575933e5c45dff7a2016a16cdf414f22c2 
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) 

Certificate, Server Key Exchange, Server Hello Done

Certificate(发送服务器证书信息到客户端)

Handshake Protocol: Certificate 
    Handshake Type: Certificate (11) 
    Length: 2781 
    Certificates Length: 2778 
    Certificates (2778 bytes) 
        Certificate Length: 1407 
        Certificate: 3082057b30820463a0030201020210040f1f824b17ca53814dc5c6f4c6a0a8300d06092a… (id-at-commonName=*.imooc.com) 
        Certificate Length: 1365 
        Certificate: 3082055130820439a003020102021007983603ade39908219ca00c27bc8a6c300d06092a… (id-at-commonName=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1,id-at-organizationName=DigiCert Inc,id-at-countryName=US) 

“Server Key Exchange” 消息是携带密钥交换算法需要的额外数据，目的是计算主密钥需要的另一个值：“预主密钥(premaster secret)”。

不同的算法套件对应的消息内容也是不同的，下面 EC Diffie-Hellman(简称 ECDHE)就是密钥交换算法，这个对应 “Server Hello” 消息中选择的密码套件 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 中的 ECDHE。

下面 Server Params 中的 Curve Type 表示曲线类型，本次选中的椭圆曲线名称为 named_curve：secp256r1，再确定基点 G，此时还会选择生成一个随机数做为服务端椭圆曲线的私钥，存放到本地，再根据基点 G 和椭圆曲线的私钥计算出椭圆曲线公钥(这里的椭圆曲线公/私钥都是临时的，只对本次链接生效)，名字为 Pubkey 传递给客户端。

为了确保椭圆曲线公钥信息不被篡改，将 Server Params 与客户端和服务器随机值连在一起使用私钥签名，客户端从证书中获得服务器的公钥，就可验证是否来自服务器。客户端和服务器的随机值对于一次握手是唯一的，这也意味着攻击者无法重复利用该签名。

Handshake Protocol: Server Key Exchange 
    Handshake Type: Server Key Exchange (12) 
    Length: 329 
    EC Diffie-Hellman Server Params 
        Curve Type: named_curve (0x03) 
        Named Curve: secp256r1 (0x0017) 
        Pubkey Length: 65 
        Pubkey: 049c1c4eaa2ab8ae7b54482efc5d07e2b191174d804d660be07ded253c86f9bc5cd24f34… 
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601) 
            Signature Hash Algorithm Hash: SHA512 (6) 
            Signature Hash Algorithm Signature: RSA (1) 
        Signature Length: 256 
        Signature: 5b9b1a750f0168f0a57852b4a77c14c351c5b97d7eb4a470fa8e3cf9e385cf7ac16f056f… 

调用 PRF 伪随机函数函数生成 48 字节(384 位)主密钥

调用 PRF 伪随机函数函数生成 48 字节(384 位)主密钥。

构建会话密钥

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

客户端发出 Change Cipher Spec, Encrypted Handshake Message

Change Cipher Spec

“Change Cipher Spec” 消息表示客户端已生成加密密钥，并切换到加密模式。

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec 
    Content Type: Change Cipher Spec (20) 
    Version: TLS 1.2 (0x0303) 
    Length: 1 
    Change Cipher Spec Message 

注意：“Change Cipher Spec” 不属于握手协议，它是另一种密钥规格变更协议。

Encrypted Handshake Message

这个是将之前所有的握手数据做一个摘要，再用最后协商好的对称加密算法对数据做加密，

通过 “Encrypted Handshake Message” 消息发送到服务器进行校验，这个对称加密密钥是否成功。

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message 
    Content Type: Handshake (22) 
    Version: TLS 1.2 (0x0303) 
    Length: 60 
    Handshake Protocol: Encrypted Handshake Message 

服务器计算密钥

服务器在收到客户端 “Client Key Exchange” 消息后，这时可以拿到 Client Random（第一个随机数）、Server Random（第二个随机数）、Client Params（包含第三个随机数，也是预主密钥），先计算出预主密钥后（通过自己的私钥解密客户端发来的公钥加密的预主密钥），再分别计算出主密钥和最终的会话密钥，这块可参考客户端计算密钥一样的。

服务器发出 Change Cipher Spec, Encrypted Handshake Message

Change Cipher Spec

服务器发出 “Change Cipher Spec” 消息告诉客户端，服务端已生成密钥，请求客户端切换加密模式。

Encrypted Handshake Message

“Encrypted Handshake Message” 这条消息也是服务器对握手的所有数据用协商好的对称加密算法加密，供客户端校验。

如果对抓取后的报文做解密，这里看到的是 “Finished” 消息。