安全 Web 代理提供 TLS 检查服务,让您可以拦截 TLS 流量、检查加密请求并强制执行安全政策。
根据已实施的安全规则和 TLS 检查配置,安全 Web 网关解决方案会建立两个安全连接,一个连接到客户端,另一个连接到外部服务器。然后,安全 Web 代理解决方案会检查这两个安全连接之间的流量。成功完成验证后,您可以将对未加密流量应用的过滤和安全控件应用于加密流量。
证书授权机构在 TLS 检查中的角色
为了确定安全 Web 代理是否应检查 TLS 连接,它会检查其各个安全政策规则上的 tls_inspection_enabled 标志。如果已设置该标志,并且检测到 TLS 连接,安全 Web 代理会生成新的服务器证书。它会将此证书发送到 Certificate Authority Service (CAS),以供您的从属证书授权机构 (CA) 池签署。然后,该证书将提供给客户端,并建立 TLS 连接。生成的证书会缓存一小段时间,以便在后续连接到同一主机时使用。
如果您想检查 TLS 流量,则必须为客户端尝试连接的主机生成服务器证书。此服务器证书必须由组织管理的私有 CA 签名。只有配置为信任此私有 CA 的客户端才会信任这些生成的服务器证书。其中包括浏览器和嵌入式 HTTP 客户端。因此,TLS 检查只能用于拦截和检查贵组织拥有管理控制权的客户端的 TLS 连接。
并非所有 TLS 连接都能成功拦截,即使在组织拥有管理控制权的机器上也是如此。这是因为某些客户端(尤其是嵌入在其他应用中的客户端)已硬编码为仅接受特定服务器证书或由特定 CA 签名的证书(此做法称为证书固定)。例如,Microsoft Windows、MacOS 和 Google Chrome 软件更新。在启用 TLS 检查的情况下,此类连接会失败。出现这种情况是因为安全 Web 代理向客户端呈现的服务器证书的公钥和 CA 链与本地存储的参数不匹配。
如果规则配置为检查 TLS 流量,但客户端不信任安全 Web 代理提供的检查证书,则连接会失败。在这些情况下,TLS 检查会破坏客户端-服务器连接,即使服务器是受信任的也是如此。如需解决此问题,您可以添加规则,以便针对特定条件绕过 TLS 检查。您还可以通过使用 FQDN 将 TLS 检查限制为特定目的地主机、来源(使用安全标记、服务账号或 IP 地址),以及使用规则的 SessionMatcher 属性。
支持的功能
安全 Web 代理 TLS 检查支持以下功能:
与 CAS 紧密集成,CAS 是适用于私有 CA 的高可用性可伸缩型代码库。
能够根据需要使用自己的信任根。您还可以使用现有根 CA 为 CAS 持有的从属 CA 签名。如果您愿意,可以在 CAS 中生成新的根证书。
在安全 Web 代理政策规则中使用 SessionMatcher 实现精细的解密条件。此条件包括网址列表、正则表达式、IP 地址范围和类似表达式中存在的匹配主机。如有需要,您可以将条件与布尔表达式组合使用。
每个安全 Web 代理政策都可以配置自己的 TLS 检查政策和 CA 池。或者,多个安全 Web 代理政策可以共用一项 TLS 检查政策。
常见使用场景
如需启用 TLS 检查,您可以使用以下任一方法:
使用现有的根 CA 对 CAS 中持有的从属 CA 进行签名。CAS 中存储的从属 CA 用于对运行时生成的服务器证书进行签名。
使用存储在外部(不在 CAS 中)的现有根 CA 为从属 CA 签名。当从属 CA 由根 CA 签名后,您可以使用它们对运行时生成的服务器证书签名。
使用 CAS 中生成的根证书。创建根证书后,您需要创建由新根 CA 签名的从属 CA。该从属 CA 用于对运行时生成的服务器证书进行签名。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# TLS inspection overview\n\nTransport Layer Security (TLS)-encrypted web traffic accounts for a large\nportion of all web traffic, and threat actors can use these encrypted\nchannels to launch malicious attacks. As a result, it is critical to\ncheck the TLS-encrypted traffic before forwarding it to its destination.\n\nSecure Web Proxy offers a TLS inspection service that lets you intercept the\nTLS traffic, inspect the encrypted request, and enforce security policies.\n\nBased on the implemented security rules and the TLS inspection configuration,\nthe Secure Web Proxy solution establishes two secure connections, one with the\nclient and another with the external server. The Secure Web Proxy solution then\ninspects the traffic between the two secure connections. After successful\nverification, you can apply the same filtering and security controls to encrypted\ntraffic that you do to unencrypted traffic.\n| **Note:** If you want to use [`ApplicationMatcher`](/secure-web-proxy/docs/cel-matcher-language-reference) in your security rules, then you must [enable TLS Inspection](/secure-web-proxy/docs/enable-tls-inspection) for your Secure Web Proxy instance.\n\nRole of certificate authorities in TLS inspection\n-------------------------------------------------\n\nTo determine if the Secure Web Proxy should inspect a TLS connection, it checks\nthe `tls_inspection_enabled` flag on its individual security policy rules. If the\nflag is set, and if a TLS connection is detected, then Secure Web Proxy generates\na new server certificate. It sends this certificate to the Certificate Authority\nService (CAS) to be signed by your subordinate certificate authority (CA) pool.\nThis certificate is then presented to the client, and a TLS connection is\nestablished. The generated certificate is cached for a short time to be used\non subsequent connections to the same host.\n\nIf you want to inspect TLS traffic, you must generate a server certificate for\nthe host that the client is attempting to connect to. An organization-managed,\nprivate CA must sign this server certificate. Only clients configured to trust\nthis private CA trust these generated server certificates. These include\nbrowsers and embedded HTTP clients. As a result, TLS inspection can only be used\nto intercept and inspect TLS connections from clients that your organization\nhas administrative control over.\n\nNot all TLS connections can be successfully intercepted, even on machines over\nwhich the organization has administrative control. This is because some clients\n(particularly those embedded inside other applications) are hardcoded to only\naccept specific server certificates or those signed by specific CAs\n(a practice known as *certificate pinning*). Microsoft Windows, MacOS,\nand Google Chrome software updates are a few examples. Such connections\nfail in the presence of TLS inspection. This happens because the public key\nand the CA chain of the server certificate that Secure Web Proxy presents to\nthe client do not match with the locally stored parameters.\n\nIf a rule is configured to inspect TLS traffic, but the client does not trust the\ninspection certificates that Secure Web Proxy presents, then the connection\nfails. In these cases, TLS inspection is known to break client-server connections\neven if the server is trusted. To work around this situation, you can add rules\nto bypass TLS inspection for specific criteria. You can also restrict TLS\ninspection to specific destination hosts (by using FQDN), sources (by using\nSecure Tags, Service Account, or IP address), and by using the\n[`SessionMatcher` attribute](/secure-web-proxy/docs/cel-matcher-language-reference#available-attributes-in-sessionmatcher-and-applicationmatcher)\nof a rule.\n\nSupported features\n------------------\n\nSecure Web Proxy TLS inspection supports the following features:\n\n- Tight integration with CAS, which is a highly available and scalable repository for private CAs.\n- The ability to use your own root of trust if required. You can also use an existing root CA to sign for subordinate CAs held by CAS. If you prefer, you can generate a new root certificate within CAS.\n- Granular decryption criteria by using `SessionMatcher` within Secure Web Proxy policy rules. This criteria includes matching hosts present in URL lists, regular expressions, IP address ranges, and similar expressions. If required, criteria can be combined with boolean expressions.\n- Each Secure Web Proxy policy can be configured with its own TLS inspection policy and CA pool. Alternatively, multiple Secure Web Proxy policies can share a single TLS inspection policy.\n\nCommon use cases\n----------------\n\nTo enable TLS inspection, you can use any of the following methods:\n\n- Use an existing root CA to sign subordinate CAs held within CAS. A subordinate\n CA held within CAS is used to sign server certificates generated at runtime.\n\n- Use an existing root CA held externally (not in CAS) to sign subordinate CAs.\n When the subordinate CAs are signed by your root CA, you can use them to\n sign server certificates generated at runtime.\n\n- Use a root certificate generated within CAS. After you create the root\n certificate, you create a subordinate CA signed by your new root CA.\n That subordinate CA is used to sign server certificates generated at\n runtime.\n\nFor more information about these methods, see [Create a subordinate CA\npool](/secure-web-proxy/docs/enable-tls-inspection#create-sub-ca-pool)."]]