传输层安全协议 (TLS) 加密流量占 Web 流量的绝大部分。由于威胁行为者经常使用这些加密通道来隐藏恶意活动，因此在这些流量到达目的地之前对其进行检查至关重要。
Secure Web Proxy 提供集成的 TLS 检查服务，让您可以拦截和解密 HTTPS 流量。通过了解加密请求，安全 Web 代理可以应用高级安全政策（例如对完整请求路径进行网址过滤和 HTTP 标头检查），以保护您的环境免受隐藏在加密隧道中的威胁。
工作原理
TLS 检查的工作原理是建立两个单独的加密连接，Secure Web Proxy 充当安全中介。
客户端握手：当客户端尝试连接到外部网站时，例如
www.example.com，安全 Web 代理会拦截该请求。证书生成：安全 Web 代理会实时为
www.example.com生成临时 证书。根据配置的 证书颁发模式，代理会直接从 CA Service 为每个 网域请求叶证书，或者使用 CA 池中的缓存中间 CA 证书在本地对叶证书进行签名。信任验证：然后，客户端会收到该临时证书。
检查点：流量在 Secure Web Proxy 实例中解密。在此阶段，安全政策会应用于纯文本 HTTP 数据。
服务器握手：然后，Secure Web Proxy 会启动与实际目标服务器的第二个 TLS 连接。流量会重新加密并发送到目标地址。
主要特性
Secure Web Proxy TLS 检查服务提供了一个灵活且伸缩框架，可通过以下能力管理已加密流量：
集成专用信任：与 CA Service 的内置集成 提供了一个由 Google 管理的高可用性存储库，用于存储您的专用 CA。
灵活的信任根：使用现有的本地根证书 授权机构 (CA) 对托管在 CA Service 中的从属 CA 进行签名。然后，您可以直接在 CA Service 中生成和管理全新的根证书。
特定解密：使用
SessionMatcher准确定义要解密的 流量。您可以根据以下参数触发 TLS 检查：- 网站域名：使用 正则表达式和域名列表匹配特定网站。
- 网络条件：以特定来源 IP 地址范围或无类别
域间路由 (CIDR) 地址块（例如
10.0.0.0/24）为目标，以定义网络 边界。 - 布尔逻辑：组合多个条件（例如来源 IP 和目标网址）以创建高度特定的安全规则。
可扩缩的政策架构：
专用政策：为 每个 Secure Web Proxy 政策分配唯一的 TLS 检查政策和 CA 池，以实现严格隔离。
共享政策：通过在多个代理政策之间共享单个 TLS 检查配置，简化政策管理。
完整的统一资源标识符 (URI) 可见性：检查整个 URI （包括域名、路径和查询字符串，例如
www.example.com/downloads/malware.exe），而不仅仅是域名。精确的访问权限控制：使用 TLS 检查为网站的 特定路径强制执行政策。例如，您可以允许访问
www.example.com/documentation，但阻止访问www.example.com/uploads。中间 CA 支持：通过 在本地缓存单个中间 CA 来对叶证书进行签名， 而不是直接向 CA Service 发出每个网域的请求， 从而降低 CA Service 使用费。如需了解详情，请参阅证书颁发 模式。
证书授权机构在 TLS 检查中的角色
为了检查加密流量，Secure Web Proxy 充当受信任的中介。这涉及代理、CA Service 和客户端设备之间的协调过程。
客户端信任要求
TLS 检查专为组织对客户端设备（例如受管理的笔记本电脑、服务器或虚拟机 [VM]）具有管理控制权的环境而设计。
- 专用信任锚点：由于 Secure Web Proxy 提供的证书由您的内部 CA 而非 Public CA 签名，因此只有在预安装了您的专用根 CA 的情况下，客户端才会信任连接。
- 管理范围：来自非托管硬件的连接通常会
触发
Insecure connection警告，因为这些设备缺少您组织的特定信任锚点。
处理拦截失败
即使在受管理的设备上，某些连接也可能因证书固定而无法拦截。 当应用被硬编码为仅接受特定公钥或特定公共 CA 链时，就会发生证书固定。
- 证书固定示例：使用固定的常见服务包括 Windows 和 macOS 系统更新、Google Chrome 更新以及某些 高安全性移动应用。
- 证书固定的结果：当 Secure Web Proxy 提供其签名 证书时，应用会检测到该证书与其 硬编码的预期不符，并终止连接。
缓解和精确控制
为了防止固定应用的服务中断或维护敏感网站的隐私，您可以使用 SessionMatcher 属性绕过检查。 您可以根据以下参数限制或跳过检查：
证书颁发模式
安全 Web 代理支持两种模式来预配在 TLS 检查过程中用于解密流量的证书。选择哪种模式取决于您的费用、性能和审核日志记录要求。
如需了解详情，请参阅配置本地中间 CA 签名。
本地中间 CA 签名
如果您将 certificateIssuanceMode 设置为 LOCAL_INTERMEDIATE_CA_SIGNING，则 Secure Web Proxy 会从您的 CA 池中请求单个中间 CA 证书。代理会缓存此中间 CA，并在本地为所需网域对各个叶证书进行签名。
本地中间 CA 签名证书颁发模式的特点如下：
降低 CA Service 费用：对 CA Service 的请求 仅限于中间 CA 的刷新周期（通常每天一次） 而不是针对每个网域发出请求，从而降低交易费用。
降低可观测性：您的代理在本地签名的各个叶证书不会记录在 CA Service 审核日志中。
直接叶预配
如果您将 certificateIssuanceMode 设置为 DIRECT_LEAF_PROVISIONING，则 Secure Web Proxy 会直接与您的 CA Service 池通信，为每个唯一网域请求叶证书。
直接叶预配证书颁发模式的特点如下：
提高可观测性：每个生成的证书请求都会记录在 CA Service 审核日志中，让您可以跟踪和审核所有 证书生成活动。
提高 CA Service 费用：由于系统会为每个网域向 CA Service 发送请求，因此在有多个唯一网域或代理 任务的环境中，此过程可能会导致更高的 交易费用。
证书授权机构配置方法
如需启用 TLS 检查，请使用以下任一方法设置证书授权机构 (CA)：
CA Service 中的从属 CA：使用现有的外部根 CA 对存储在其中的从属 CA 进行签名 Google Cloud。
外部根 CA：使用外部根 CA 对通过从属 CA 在运行时 生成的证书进行签名。
Google 管理的根 CA：直接在 CA Service 中生成新的根证书，以对从属 CA 进行签名。
如需详细了解这些方法，请参阅 创建从属 CA 池。