05.HTTPS的实现原理-HTTPS的握手流程(TLS1.2)

简介

主要讲述了混合加密流程完成后,客户端和服务器如何共同获得相同的对称密钥,并通过该密钥进行数据的加密和解密。详细介绍了HTTPS的加密过程,并进一步阐述了TLS握手过程,包括客户端发送Client Hello请求给服务器,告知其支持的TLS版本、生成的随机数以及密码套件等信息,以便服务器根据这些信息与客户端协商并建立安全的连接。

1. TLS握手过程概述

TLS握手过程包括四次握手
1.客户端首先发送Client Hello请求。
2.服务器收到Client Hello后,发送Server Hello、Server Random、Certificate、Server Key Exchange、Server Hello Done等报文。
3.客户端收到服务器端的报文后,生成主密钥并加密后发送给服务器端。
4.服务器端收到客户端的加密数据后,用私钥解密,得到主密钥。
5.双方使用主密钥进行对称加密,完成数据传输。

在这里插入图片描述

2. TLS握手过程细化

在TLS1.2协议中,主密钥(对称密钥)由双方交换参数、协商算法各自生成。不再由客户端生成后,加密传输给服务端。

1.Client Hello包含TLS版本、随机数(Client Random)、密码套件(CipherSuites)等信息。
2.Server Hello确认收到Client Hello,并发送Server RandomECDHE密钥交换算法、Certificate、Server Key Exchange、Server Hello Done等报文。
3.Client收到服务器端的报文后,生成客户端参数(Client Key Exchange),并用服务器端的公钥加密后发送给服务器端。
4.服务器端收到客户端的加密数据后,用私钥解密,生成主密钥。与此同时,客户端也生了相同的主密钥。
5.客户端和服务器端分别用主密钥进行数据加密和解密。

3. 主密钥(对称密钥)生成过程

1.客户端验证完服务器端的合法性后,生成自己的客户端参数(Client Key Exchange),并用服务器端的公钥加密后发送给服务器端。
2.服务器端收到客户端的加密数据后,用私钥解密,得到客户端参数。
3.客户端和服务器端分别用两个参数(Client Key Exchange、Server Key Exchange),通过协商好的ECDHE算法生成预主密钥。然后预主密钥再次和两个随机数(Client Random、Server Random)进行ECDHE算法计算,生成主密钥
4.主密钥用于后续的数据加密和解密。

4. 密码规范变更

1.在生成主密钥后,客户端和服务器端改变密码规范,从非对称加密变为对称加密。
2.使用主密钥进行数据的加密和解密,提高安全性。

往期文章参考:
01.HTTPS的实现原理-HTTPS的概念
02.HTTPS的实现原理-HTTPS与HTTP的区别详解
03.HTTPS的实现原理-HTTPS的工作流程
04.HTTPS的实现原理-HTTPS的混合加密流程

<think>我们正在讨论TLS 1.2协议的握手流程和工作原理。根据用户提供的引用材料,特别是引用[1]、[3]和[4],我们可以详细解释TLS 1.2握手过程。 TLS 1.2握手流程通常需要2-RTT(两次往返时间),包括以下步骤: 1. **ClientHello**:客户端向服务器发送一个ClientHello消息,包含以下信息: - 客户端支持的TLS协议版本(如TLS 1.2- 客户端生成的随机数(Client Random) - 客户端支持的密码套件列表(例如:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) - 客户端支持的压缩方法 - 可选的扩展字段(如服务器名称指示SNI) 2. **ServerHello**:服务器响应一个ServerHello消息,包含: - 服务器选择的TLS协议版本(从客户端提供的版本中选择) - 服务器生成的随机数(Server Random) - 服务器选择的密码套件(例如:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) - 服务器选择的压缩方法(通常为null,表示不压缩) - 可选的扩展字段 3. **Certificate**:服务器发送自己的证书链(Certificate消息),用于向客户端证明其身份。证书中包含了服务器的公钥(用于非对称加密,如RSA或ECDSA)。 4. **ServerKeyExchange**(可选):如果选择的密码套件需要,服务器会发送ServerKeyExchange消息,包含服务器用于密钥交换的参数。例如,如果使用ECDHE(椭圆曲线Diffie-Hellman临时密钥交换),则包含椭圆曲线参数和服务器临时公钥(Server Params)。注意:如果使用RSA密钥交换,则不需要此消息(因为证书中已经包含RSA公钥),但RSA密钥交换方式在TLS 1.3中被废除。 5. **ServerHelloDone**:服务器表示握手消息发送完毕。 6. **ClientKeyExchange**:客户端验证服务器证书后,生成一个预主密钥(Pre-Master Secret)。根据密钥交换方式的不同,处理方式也不同: - 如果使用RSA密钥交换:客户端生成预主密钥(一个随机数),用服务器的公钥加密后发送。 - 如果使用Diffie-Hellman(包括ECDHE):客户端生成自己的临时密钥对,并将客户端临时公钥(Client Params)发送给服务器(此时不需要发送预主密钥,因为双方将通过DH交换共同计算出预主密钥)。 注意:在ECDHE中,客户端和服务器各自持有对方的临时公钥和自己的私钥,通过ECDH算法计算出相同的预主密钥。 7. **ChangeCipherSpec**(客户端):客户端发送ChangeCipherSpec消息,表示后续消息将使用协商好的密钥和算法进行加密。 8. **Finished**(客户端):客户端发送加密的Finished消息,包含前面所有握手消息的摘要(用于验证握手过程的完整性)。 9. **ChangeCipherSpec**(服务器):服务器同样发送ChangeCipherSpec消息,表示后续消息将加密。 10. **Finished**(服务器):服务器发送加密的Finished消息,客户端验证其正确性。 至此,握手完成,双方开始应用数据传输。 关于密钥计算: - 预主密钥(Pre-Master Secret)的生成: - 在RSA密钥交换中,预主密钥由客户端生成并加密传输给服务器。 - 在ECDHE密钥交换中,预主密钥由双方各自计算:客户端使用自己的私钥和服务器临时公钥,服务器使用自己的私钥和客户端临时公钥,通过ECDH算法计算出相同的预主密钥。 - 主密钥(Master Secret)的生成:预主密钥与Client Random、Server Random一起,通过伪随机函数(PRF)生成主密钥: $$ \text{master\_secret} = \text{PRF}(\text{pre\_master\_secret}, \text{"master secret"}, \text{ClientHello.random} + \text{ServerHello.random}) $$ - 会话密钥的生成:主密钥再与Client Random和Server Random通过PRF生成会话密钥(包括对称加密密钥、MAC密钥、初始向量IV等)。 引用[4]中描述了ECDHE密钥交换的具体步骤: 1. 客户端验证服务器证书后,生成自己的客户端参数(Client Key Exchange),即客户端临时公钥,发送给服务器(不需要加密,因为DH交换本身是安全的)。 2. 服务器收到客户端参数后,结合自己的服务器参数(Server Key Exchange中已发送)和私钥,计算出预主密钥。 3. 客户端也使用服务器参数(从ServerKeyExchange获得)和自己的私钥计算出相同的预主密钥。 4. 然后,预主密钥与两个随机数(Client Random和Server Random)通过ECDHE算法(实际上是PRF)生成主密钥,再进一步生成会话密钥。 安全性: - TLS 1.2支持前向保密(Forward Secrecy)的密码套件(如ECDHE),即每次会话使用临时的密钥交换参数,即使长期私钥泄露,过去的会话也无法解密。 - 但是,TLS 1.2也支持非前向保密的密码套件(如RSA密钥交换),因此在实际配置中应优先选择ECDHE套件。 引用[1]指出TLS 1.2存在一些安全与效率限制,例如握手延迟较高(2-RTT),且支持的密码套件较多可能导致协商效率低和安全风险(如弱算法)。 下面我们用流程图简要表示TLS 1.2握手过程(以ECDHE_RSA为例): ``` 客户端 服务器 | | | 1. ClientHello (Version, Random, CipherSuites, ...) | |----------------------------------------------------->| | | | 2. ServerHello (Version, Random, CipherSuite, ...) | | 3. Certificate (Server Certificate Chain) | | 4. ServerKeyExchange (ECDHE Params: curve, server_pubkey) | | 5. ServerHelloDone | |<-----------------------------------------------------| | | | 6. ClientKeyExchange (Client_pubkey) | | 7. [ChangeCipherSpec] | | 8. Finished (Encrypted) | |----------------------------------------------------->| | | | 9. [ChangeCipherSpec] | |10. Finished (Encrypted) | |<-----------------------------------------------------| | | | Application Data (Encrypted) | |<====================================================>| ``` 注意:ChangeCipherSpec是一个独立的协议,它不是一个握手消息,而是一个简单的信号(1字节),表示密码规范变更。 通过以上步骤,TLS 1.2完成了安全的连接建立。然而,由于需要2-RTT,在延迟敏感的场景下性能不如TLS 1.3(1-RTT)。此外,TLS 1.3中移除了不安全的密码套件和算法,并简化了握手流程。 下面根据用户要求,生成相关问题:</think>### TLS 1.2 协议握手流程原理详解 TLS 1.2 握手流程采用 **2-RTT(两次往返)** 设计,核心目标是安全协商会话密钥并验证身份。以下是完整流程解析(以 ECDHE-RSA 密码套件为例): --- #### 一、握手阶段(明文传输) 1. **ClientHello** - 客户端发起连接,发送: - 支持的 TLS 版本(如 `0x0303` 表示 TLS 1.2- 客户端随机数 $C_{\text{random}}$(32 字节) - 支持的密码套件列表(如 `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`) - 可选的 SNI(服务器名称指示) - *作用*:初始化协商参数[^1][^3]。 2. **ServerHello** - 服务器响应: - 选定的 TLS 版本 - 服务器随机数 $S_{\text{random}}$(32 字节) - 确定的密码套件(如 ECDHE-RSA) - *关键点*:双方确认加密算法和密钥交换方式[^3]。 3. **Certificate** - 服务器发送数字证书链,包含: - 服务器公钥(如 RSA 公钥) - CA 签名信息 - *验证*:客户端用信任的 CA 公钥验证证书合法性[^1][^4]。 4. **ServerKeyExchange** - 服务器发送 ECDHE 参数: - 椭圆曲线类型(如 secp256r1- 服务器临时公钥 $Y = y \cdot G$($y$ 为私钥,$G$ 为基点) - *数学基础*:基于椭圆曲线离散对数问题(ECDLP)[^2]。 5. **ServerHelloDone** - 服务器声明握手消息结束。 --- #### 二、密钥交换阶段 6. **ClientKeyExchange** - 客户端生成临时密钥对: - 私钥 $x$(随机数) - 公钥 $X = x \cdot G$ - 发送 $X$ 给服务器[^4]。 - *密钥计算*:双方各自计算预主密钥: $$ \text{Pre-Master Secret} = \text{ECDH}(x, Y) = \text{ECDH}(y, X) = x \cdot y \cdot G $$ 7. **主密钥生成** - 结合 $C_{\text{random}}$ 和 $S_{\text{random}}$,通过 PRF(伪随机函数)生成主密钥: $$ \text{Master Secret} = \text{PRF}(\text{Pre-Master Secret}, \text{"master secret"}, C_{\text{random}} + S_{\text{random}}) $$ - *扩展*:主密钥派生会话密钥(加密密钥、MAC 密钥等)[^3][^4]。 --- #### 三、安全确认阶段(加密传输) 8. **ChangeCipherSpec** - 客户端通知:后续消息使用协商的密钥加密。 9. **Finished** - 客户端发送加密的完成消息,包含所有握手消息的 HMAC 摘要。 - 服务器验证摘要完整性。 10. **服务器端 ChangeCipherSpec + Finished** - 服务器同样切换加密并发送完成消息。 - 客户端验证完整性。 ```mermaid sequenceDiagram participant Client participant Server Client->>Server: ClientHello (C_random, CipherSuites) Server->>Client: ServerHello (S_random, Selected Cipher) Server->>Client: Certificate (Server Public Key) Server->>Client: ServerKeyExchange (ECDHE Params: Y) Server->>Client: ServerHelloDone Client->>Server: ClientKeyExchange (X) Client->>Server: ChangeCipherSpec Client->>Server: Finished (Encrypted) Server->>Client: ChangeCipherSpec Server->>Client: Finished (Encrypted) ``` --- #### 四、核心安全机制 1. **前向保密(Forward Secrecy)** - ECDHE 使用临时密钥:会话结束后 $x$ 和 $y$ 被丢弃,即使服务器私钥泄露,历史会话也无法解密[^2][^4]。 2. **身份验证机制** - 证书验证:确认服务器身份 - Finished 消息:验证握手过程未被篡改 3. **密钥派生** - 分层密钥派生函数: $$ \text{Master Secret} \xrightarrow{\text{PRF}} \text{Key Block} \rightarrow \begin{cases} \text{Client MAC Key} \\ \text{Server MAC Key} \\ \text{Client Encryption Key} \\ \text{Server Encryption Key} \\ \text{IVs} \end{cases} $$ --- #### 五、与 TLS 1.3 的关键差异 | **特性** | TLS 1.2 | TLS 1.3 | |------------------|--------------------------|--------------------------| | 握手耗时 | 2-RTT | 1-RTT(默认) | | 密钥交换 | 显式 ServerKeyExchange | 通过 key_share 扩展合并 | | 前向保密 | 可选(需 ECDHE) | 强制实现 | | 密码套件 | 支持弱算法(如 RC4) | 仅 AEAD 加密算法 | | 会话恢复 | Session ID/Ticket | PSK 模式(支持 0-RTT) | > **注**:TLS 1.2 的 RSA 密钥交换无前向保密性,已被 TLS 1.3 废除[^1][^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值