Https之单向认证VS双向认证是什么应用场景手法以及防御 -CSDN博客

客户端                          服务器
   |                                |
   | ---- 请求HTTPS连接 -----------> 
   |                                |
   | <--- 发送服务器证书 ------------ 
   |                                |
   | 验证证书有效性（签名、域名等） |
   |                                
   | ---- 握手，完成加密连接 --------> 
   |                                |

流程简单描述：

客户端发起连接：客户端（通常是浏览器）向服务器发起HTTPS连接请求。
服务器返回证书：服务器将自己的SSL/TLS证书发送给客户端。该证书包含服务器的公钥和由受信任的CA签发的信息。
客户端验证证书：
- 签名验证：客户端使用CA的公钥验证证书的签名，确保证书没有被篡改。
- 域名匹配：客户端检查证书中的域名是否与请求的域名匹配。
- 证书有效期：客户端检查证书是否在有效期内。
建立加密连接：如果验证通过，客户端与服务器建立加密的通信信道，所有后续数据会通过此加密通道传输。

特性：

简化操作：客户端无需提供证书，减少了客户端的配置复杂度。
安全性：服务器通过CA证书来确保其身份，但客户端对其身份没有直接的验证能力。
用途：适用于大多数网站，其中服务器是可信的，而客户端无需特别身份验证。

HTTPS单向认证完整流程

步骤1：TCP三次握手

作用：建立客户端与服务器的TCP连接（确保可靠传输）。
具体过程：
1. 客户端发送SYN包（序列号随机生成）。
2. 服务器回复SYN-ACK包（确认客户端序列号 + 生成自己的序列号）。
3. 客户端发送ACK包（确认服务器序列号）。

步骤2：TLS握手阶段

2.1 Client Hello

客户端发送内容：
- 支持的TLS版本：如TLS 1.2、TLS 1.3。
- 客户端随机数（Client Random）：32字节随机值，用于后续密钥生成。
- 支持的加密套件（Cipher Suites）：列出客户端支持的加密算法组合（如TLS_AES_128_GCM_SHA256）。
- 支持的压缩方法：通常为空（现代TLS已弃用压缩）。
- 会话ID（Session ID）：用于会话恢复（若之前已建立连接）。
作用：告知服务器客户端的能力和参数。

2.2 Server Hello

服务器响应内容：
- 选定的TLS版本：选择双方均支持的最高版本（如TLS 1.2）。
- 服务器随机数（Server Random）：32字节随机值，用于密钥生成。
- 选定的加密套件：从客户端列表中选择一个（如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）。
- 会话ID（Session ID）：若支持会话恢复，生成新ID。
作用：确认双方协商的加密参数。

2.3 Server Certificate

服务器发送内容：
- 服务器证书链：包含服务器证书、中间CA证书（如适用）。
- 证书公钥：用于后续密钥交换（如RSA公钥）。
作用：客户端需验证此证书的合法性（域名、有效期、CA签名等）。

2.4 Server Key Exchange（可选）

触发条件：当使用ECDHE等临时密钥交换算法时需发送。
内容：
- 密钥交换参数：如椭圆曲线参数、服务器临时公钥。
- 签名：用服务器私钥对参数签名，供客户端验证。
作用：确保密钥交换过程防篡改。

2.5 Server Hello Done

内容：空消息。
作用：告知客户端“服务器参数发送完毕”。

步骤3：客户端证书验证与密钥生成

3.1 客户端验证服务器证书

验证内容：
1. 证书链完整性：检查根CA是否在本地信任库中。
2. 签名有效性：用CA公钥验证证书签名。
3. 域名匹配：证书中的Subject Alternative Name (SAN)或Common Name (CN)需与访问域名一致。
4. 有效期：证书未过期且未吊销（通过OCSP或CRL检查）。
失败处理：若验证失败，浏览器显示警告（如NET::ERR_CERT_INVALID）。

3.2 Client Key Exchange

客户端生成并发送预主密钥（Pre-Master Secret）：
- RSA密钥交换：客户端生成48字节随机数，用服务器证书中的公钥加密后发送。
- ECDHE密钥交换：客户端生成临时密钥对，发送公钥（服务器用私钥计算共享密钥）。
作用：双方基于预主密钥和随机数生成主密钥（Master Secret）。

3.3 生成主密钥（Master Secret）

输入：Client Random + Server Random + Pre-Master Secret。
算法：使用PRF（伪随机函数）生成48字节主密钥。

公式：

Master Secret = PRF(Pre-Master Secret, "master secret", ClientRandom + ServerRandom)

3.4 Change Cipher Spec

客户端发送：Change Cipher Spec消息。
作用：通知服务器“后续通信将使用协商的加密算法和密钥”。

3.5 Finished

客户端发送：加密的Finished消息。
内容：对之前所有握手消息的HMAC摘要，用主密钥加密。
作用：验证握手过程未被篡改，且密钥正确生成。

步骤4：服务器确认加密通道

4.1 Change Cipher Spec

服务器发送：Change Cipher Spec消息。
作用：通知客户端“后续通信将使用加密算法”。

4.2 Finished

服务器发送：加密的Finished消息。
内容：对握手消息的HMAC摘要，用主密钥加密。
作用：客户端验证服务器密钥一致性。

步骤5：安全通信建立

双方生成会话密钥：基于主密钥派生出对称加密密钥（如AES密钥）和MAC密钥。
后续通信：所有HTTP数据使用对称加密传输（如AES-GCM）。

单向认证的核心特点

特性	说明
服务器身份验证	客户端必须验证服务器证书，防止中间人攻击
客户端身份匿名	服务器不要求客户端提供证书（适用于普通用户访问）
密钥交换安全	预主密钥通过非对称加密传输（RSA）或临时密钥交换（ECDHE）
加密效率	对称加密（如AES）处理后续通信，兼顾安全与性能

单向认证的典型应用场景

Web网站：用户通过浏览器访问HTTPS网站（如电商、社交媒体）。
API接口：移动端App与服务器通信。
云服务：用户登录云存储或SaaS平台。

安全渗透中的风险点

证书伪造攻击：攻击者伪造服务器证书（需用户忽略浏览器警告）。
CA私钥泄露：根CA私钥被窃取可签发任意合法证书。
降级攻击：强制客户端使用弱加密套件（如SSLv3）。

防御建议

客户端：严格校验证书域名、有效期及吊销状态。
服务器：使用强加密套件（如TLS 1.3）、启用HSTS和OCSP Stapling。
CA机构：实施证书透明度（CT）日志，防止恶意证书签发。

通过单向认证，HTTPS在保障服务器身份可信的同时，平衡了安全性与用户体验。理解其流程有助于排查TLS握手失败、中间人攻击等问题。

2. HTTPS双向认证

HTTPS中的双向认证（也叫双向TLS认证或客户端认证）是指在建立安全通信通道时，服务器和客户端都需要互相验证对方的身份。
与单向认证（只有服务器进行身份验证）不同，双向认证增加了对客户端身份的验证。

流程图：双向认证

客户端                          服务器
   |                                |
   | ---- 请求HTTPS连接 -----------> 
   |                                |
   | <--- 发送服务器证书 ------------ 
   |                                |
   | 验证服务器证书有效性 ------------ 
   |                                |
   | ---- 客户端发送客户端证书 -----> |
   |                                |
   | 验证客户端证书有效性 ------------ 
   |                                |
   | ---- 握手，完成加密连接 --------> 
   |                                |

流程简要描述：

客户端发起连接：客户端向服务器发起HTTPS连接请求。
服务器返回证书：服务器将自己的证书发送给客户端，客户端验证服务器身份。
客户端发送证书：客户端向服务器提供自己的证书，证明其身份。
服务器验证客户端证书：服务器验证客户端提供的证书，确保客户端是经过授权的。
建立加密连接：双向验证通过后，客户端与服务器之间建立安全的加密连接。

特性：

更高安全性：双向认证可以验证客户端和服务器双方的身份，避免伪造或中间人攻击。
更多配置：需要客户端提供证书并进行配置，增加了操作复杂度。
用途：适用于需要高安全性和双向信任的场景，如金融系统、企业内部系统等。

双向认证的工作流程：

客户端发起连接请求
- 客户端发起与服务器的HTTPS连接请求，发送一个Client Hello消息，包含支持的SSL/TLS协议版本、加密套件（cipher suites）和其他加密参数。
服务器响应并发送证书
- 服务器收到Client Hello后，会选择一个合适的加密协议版本和加密套件，然后发送Server Hello消息来确认这些选择。
- 服务器发送自己的SSL/TLS证书（通常包含公钥），用于后续的加密和身份验证。
- 在双向认证中，服务器还会请求客户端提供证书。这个步骤通过CertificateRequest消息发出，指示客户端准备发送其证书。
客户端验证服务器证书
- 客户端收到服务器的证书后，会进行验证，确保该证书是由可信的证书颁发机构（CA）签发的，且没有被篡改。
- 验证通过后，客户端将继续进行后续的步骤。
客户端发送自己的证书
- 客户端根据服务器请求，生成并发送自己的SSL/TLS证书（包含客户端的公钥）给服务器。服务器需要使用客户端的证书进行身份验证。
客户端密钥交换
- 客户端生成一个预主密钥（pre-master secret），并用服务器的公钥对其加密。这个加密的预主密钥被发送给服务器。
- 服务器收到客户端加密的预主密钥后，使用自己的私钥解密，并得到预主密钥。
双方生成共享密钥
- 服务器和客户端各自使用预主密钥和之前交换的随机数生成会话密钥。这个会话密钥将用于之后的加密通信。
- 在此时，双方都已经验证了对方的身份，并且通信是通过一个对称加密的会话密钥进行加密的。
身份验证完成
- 在加密的连接中，客户端和服务器可以安全地交换数据，双方身份得到了充分的验证。
通信过程
- 之后，客户端和服务器可以进行加密的通信，所有传输的数据都会使用共享的对称密钥进行加密，以保证数据的机密性和完整性。

双向认证的核心作用：

身份验证： 双向认证要求服务器和客户端都提供证书并验证对方，避免了伪装成合法服务器或客户端的攻击（如中间人攻击）。
数据加密： 双向认证确保双方之间的通信是加密的，防止数据被第三方窃听或篡改。
提升安全性： 尤其适用于敏感场景，比如金融服务、企业内网、物联网设备等，需要更高安全性保护的地方。

各个步骤具体做了什么：

客户端发起请求：发送协议版本、加密套件，表明其支持的加密方式。
服务器响应并发送证书：服务器选择加密方案并提供其证书，开始进行加密通信。
客户端验证服务器证书：客户端验证证书是否可信，确保通信对象是正确的。
客户端发送证书：客户端向服务器提供其证书，进行相互认证。
密钥交换：客户端生成预主密钥，用服务器公钥加密并发送，服务器使用私钥解密，建立共享密钥。
生成会话密钥：双方使用预主密钥和随机数生成会话密钥，用于加密通信。
身份验证完成：双向认证完成，通信通道建立。
通信：加密的安全通信开始，双方可以安全地交换数据。

通过双向认证，可以有效地防止数据被未授权的第三方截取或篡改，同时确保了通信双方的身份真实性。

3. 单向认证与双向认证的区别

特性	单向认证	双向认证
身份验证	仅验证服务器身份	同时验证客户端与服务器身份
证书	仅服务器需要提供证书	服务器和客户端都需要提供证书
安全性	中等，易受到中间人攻击（MITM）	较高，减少了伪造和中间人攻击
操作复杂度	较低，客户端无需配置证书	较高，客户端也需要提供证书
适用场景	适用于大多数网站和应用	适用于需要双向验证的敏感场景

4. 在安全渗透中的作用与攻击手法

单向认证的作用：

合法性验证：单向认证通过服务器证书来保证客户端访问的是合法的服务器。
中间人攻击（MITM）：攻击者可能通过伪造服务器证书或执行SSL/TLS剥离攻击，劫持客户端与服务器的通信。客户端如果没有足够严格的证书验证，容易遭受此类攻击。

双向认证的作用：

双向验证：双向认证可以有效避免客户端与服务器之间的身份伪装。只有持有合法证书的客户端和服务器才能互相信任。
防范中间人攻击：由于双方都进行证书验证，即使攻击者伪造了服务器证书，也无法伪装成合法客户端，或者伪造客户端证书进行访问。

攻击手法：

伪造证书：
- 伪造服务器证书：在单向认证中，攻击者可以通过伪造证书或利用已盗取的证书进行中间人攻击，伪装成服务器与客户端通信。
- 伪造客户端证书：在双向认证中，攻击者如果获取到客户端证书的私钥，可能伪造客户端证书，进行未授权访问。
中间人攻击（MITM）：
- 攻击者可以拦截和篡改通信内容。单向认证下，攻击者可通过SSL/TLS剥离攻击将加密通信降级为明文HTTP，窃取敏感信息。双向认证能有效减少此类风险。
证书吊销攻击：
- 在某些情况下，攻击者可能阻止客户端查询证书撤销列表（CRL）或OCSP，导致已撤销证书看起来仍然有效，从而进行非法访问。