ssl代理
目录
SSL 握手过程（核心步骤）
SSL 代理的工作原理
1. 透传模式（非解密转发）
2. 中间人模式（解密转发）
SSL 代理的类型（按部署位置）
1. 正向 SSL 代理（客户端侧代理）
2. 反向 SSL 代理（服务器侧代理）
SSL 握手过程（核心步骤）
SSL 连接建立前需通过 “握手过程” 协商加密参数、交换密钥并验证身份，具体步骤如下（以客户端 - 服务器单向认证为例，即仅验证服务器身份）：
-
客户端发起请求（Client Hello） 客户端向服务器发送：支持的 SSL/TLS 版本（如 TLS 1.3）、可选加密套件（如 ECDHE-RSA-AES256-GCM-SHA384）、客户端随机数（Client Random）、会话 ID（可选，用于复用会话）等。
-
服务器回应（Server Hello） 服务器确认：选择的 SSL 版本和加密套件、服务器随机数（Server Random），并发送数字证书（含服务器公钥），同时可选发送 “服务器密钥交换” 消息（如使用 ECDHE 等密钥交换算法时，需传递额外参数）。
-
客户端验证服务器身份 客户端检查服务器证书：
-
验证证书是否由信任的 CA 签发（客户端内置信任的 CA 列表）；
-
检查证书是否过期、是否被吊销；
-
通过 CA 公钥验证证书上的 CA 签名，确认证书未被篡改，最终获取服务器公钥。
-
-
客户端发送预主密钥（Pre-Master Secret） 客户端生成预主密钥（Pre-Master Secret），用服务器公钥加密后发送给服务器（仅服务器私钥可解密）。
-
双方生成会话密钥 服务器用私钥解密得到预主密钥，双方基于 “预主密钥 + 客户端随机数 + 服务器随机数” 通过相同算法生成主密钥（Master Secret），再从主密钥派生出：
-
会话密钥（对称加密密钥，用于后续数据加密）；
-
MAC 密钥（用于验证数据完整性）。
-
-
验证握手完整性 客户端发送 “Finished” 消息：用会话密钥加密，包含此前所有握手消息的哈希值（验证握手未被篡改）。服务器验证通过后，发送自己的 “Finished” 消息。
-
加密通信开始 握手完成，后续客户端与服务器的所有数据均用会话密钥（对称加密）加密传输，同时通过 MAC 校验确保完整性。
SSL 代理的工作原理
根据是否解密流量，SSL 代理分为两种模式：
1. 透传模式（非解密转发）
代理仅作为 “流量中转站”，不解析 SSL 内容，直接转发客户端与服务器之间的加密数据包。
-
适用场景：负载均衡（如反向代理将 SSL 流量分发到后端服务器）、简单流量路由，无需检查内容。
-
特点：不接触明文数据，不要求代理拥有证书，客户端与服务器直接完成 SSL 握手。
2. 中间人模式（解密转发）
代理分别与客户端、服务器建立独立的 SSL 连接，实现 “解密 - 处理 - 再加密” 的全流程：
-
步骤 1：客户端向代理发起 SSL 连接，代理使用自己的证书（需客户端信任）与客户端完成握手，客户端的加密流量被代理用私钥解密为明文；
-
步骤 2：代理对明文数据进行处理（如安全审计、内容过滤）；
-
步骤 3：代理用服务器的公钥（或代理自身证书）与服务器建立 SSL 连接，将处理后的明文重新加密后发送给服务器。
-
核心要求：客户端需信任代理的 CA 证书（否则浏览器会提示 “证书无效”）；代理需持有可用于解密的私钥。
SSL 代理的类型（按部署位置）
根据代理服务的对象（客户端 / 服务器），SSL 代理可分为正向 SSL 代理和反向 SSL 代理：
1. 正向 SSL 代理（客户端侧代理）
部署在客户端与互联网之间，为客户端提供 SSL 连接代理服务。
-
场景：企业内部管控（如员工通过代理访问外部 HTTPS 网站，代理解密流量检查是否有数据泄露）、突破网络限制（通过代理访问加密内容）。
-
示例：企业内网的安全代理服务器，员工浏览器配置代理后，所有 HTTPS 请求先发送到代理，代理解密检查后再转发到目标服务器。
2. 反向 SSL 代理（服务器侧代理）
部署在服务器集群前端，接收客户端的 SSL 连接，再转发到后端服务器。
-
核心作用
：
-
SSL 卸载：由代理处理加密解密，减轻后端服务器的计算负担；
-
负载均衡：解密后将请求分发到多个后端服务器（如电商网站的负载均衡器）；
-
安全防护：隐藏后端服务器 IP，集中处理证书管理和安全策略。
-
-
示例：CDN 节点或负载均衡器，客户端的 HTTPS 请求先到代理，代理用网站证书与客户端握手，解密后将明文转发给后端业务服务器（代理与后端服务器可再建立 SSL 连接确保内部通信安全）。