🔗 特性：HTTPS（HTTP 安全或 TLS 上的 HTTP）

• 版本: 2.5
• 更多：RFC 2817、2818、Features/SHTTP

当客户端遇到 https:// URL 时，它可以执行以下三种操作之一：

• 直接与源服务器建立 TLS 连接，或者
• 使用 CONNECT 请求方法通过代理与源服务器建立隧道连接，或者
• 与安全代理建立 TLS 连接。

下面将讨论 Squid 与这些流量类型的交互。

🔗 CONNECT 隧道

CONNECT 方法是一种通过 HTTP 代理隧道连接任何类型的连接的方式。默认情况下，代理会与指定的服务器建立 TCP 连接，并响应 HTTP 200（连接已建立）响应，然后会在客户端和服务器之间来回转发数据包，而不理解或解释隧道流量。有关隧道和 CONNECT 方法的详细信息，请参阅 RFC 2817 和已过期的 通过 Web 代理服务器隧道传输基于 TCP 的协议 草案。

🔗 通过 Squid 进行 CONNECT 隧道

当浏览器通过 Squid 建立 CONNECT 隧道时，访问控制可以控制 CONNECT 请求，但可用的信息有限。例如，在 CONNECT 请求中，URL 的许多常见部分并不存在：

• URL 方案或协议（例如，http://、https://、ftp://、voip://、itunes:// 或 telnet://），
• URL 路径（例如，/index.html 或 /secure/images/），
• 以及查询字符串（例如 ?a=b\&c=d）。

对于 HTTPS，上述部分存在于通过隧道传输的封装的 HTTP 请求中，但 Squid 无法访问这些加密消息。其他隧道协议可能甚至不使用 HTTP 消息和 URL（例如 telnet）。

需要注意的是，通过 CONNECT 传输的协议不限于 Squid 通常处理的协议。字面上说，任何使用双向 TCP 连接的任何内容都可以通过 CONNECT 隧道传输。这就是为什么 Squid 的默认 ACL 以 deny CONNECT !SSL_Ports 开头，以及为什么您必须有非常充分的理由将任何类型的allow规则放在它们之上。

🔗 拦截 CONNECT 隧道

当浏览器配置为与代理通信时，它会发送 CONNECT 请求。因此，理论上不应该需要拦截 CONNECT 请求。待办事项：记录当 Squid 拦截 CONNECT 请求时会发生什么，无论是由于 Squid 被[错误]配置为拦截发往另一个代理的流量，还是因为可能恶意的客户端发送了知道自己将被拦截的手动构造的 CONNECT 请求。

🔗 篡改 CONNECT 隧道

警告：HTTPS 的设计是为了让用户对隐私和安全有信心。在未经用户同意或知情的情况下解密 HTTPS 隧道可能违反道德规范，并且在您的司法管辖区可能属于非法行为。这里和其他地方描述的 Squid 解密功能旨在获得用户同意后部署，或者至少在解密而未经同意在法律上允许的环境中部署。这些功能也说明了为什么用户应该谨慎对待 HTTPS 连接，以及为什么 HTTPS 保护链中最薄弱的环节相当脆弱。从整体网络安全角度来看，解密 HTTPS 隧道构成中间人攻击。攻击工具相当于现实世界中的原子弹：确保您了解自己在做什么，并且您的决策者有足够的信息做出明智的选择。

Squid 的 SslBump 和相关功能可用于解密通过 Squid 代理的 HTTPS CONNECT 隧道。这允许将隧道中的 HTTP 消息视为常规 HTTP 消息进行处理，包括应用详细的访问控制和执行内容适应（例如，检查请求主体是否有信息泄露，并检查响应是否有病毒）。配置错误、Squid bug 和恶意攻击可能导致未加密的消息逃逸 Squid 的边界。

从浏览器的角度来看，封装的消息并未发送到代理。因此，通用的拦截限制，例如无法对单个嵌入式请求进行身份验证，也适用于此处。

🔗 直接 TLS 连接

当浏览器与源服务器建立直接 TLS 连接时，没有 HTTP CONNECT 请求。在此连接上发送的第一个 HTTP 请求已经被加密。在大多数情况下，Squid 不参与其中：Squid 对该连接一无所知，也无法阻止或代理该流量。反向代理和拦截的例外情况将在下面介绍。

🔗 直接 TLS 连接到反向代理

Squid-2.5 及更高版本可以终止 TLS 或 SSL 连接。您必须使用–enable-ssl进行编译。有关更多信息，请参阅 https_port。Squid-3.5 及更高版本会自动检测 GnuTLS 库的可用性，并在可用时启用该功能。必须使用–with-openssl configure 选项显式启用 OpenSSL。如果库安装在非标准位置，您可能需要使用–with-foo=PATH configure 选项。有关详细信息，请参阅configure –help。

这在代理（也称为 HTTP 加速器、反向代理）配置中可能最有用了。只需使用一个普通的 反向代理配置，并在 https_port 行上使用 443 端口和 SSL 证书详细信息来配置 Squid。

🔗 拦截直接 TLS 连接

可以在 Squid 的 https_port 处拦截到源服务器的 HTTPS 连接。这在代理（也称为 HTTP 加速器、反向代理）环境中可能很有用，但仅限于 Squid 可以使用该源服务器 SSL 证书来代表源服务器的情况。然而，在大多数情况下，拦截直接 HTTPS 连接将不起作用并且毫无意义，因为 Squid 无法处理加密流量——Squid 不是一个 TCP 级别的代理。

🔗 篡改直接 TLS 连接

警告：HTTPS 的设计是为了让用户对隐私和安全有信心。在未经用户同意或知情的情况下解密 HTTPS 隧道可能违反道德规范，并且在您的司法管辖区可能属于非法行为。这里和其他地方描述的 Squid 解密功能旨在获得用户同意后部署，或者至少在解密而未经同意在法律上允许的环境中部署。这些功能也说明了为什么用户应该谨慎对待 HTTPS 连接，以及为什么 HTTPS 保护链中最薄弱的环节相当脆弱。从整体网络安全角度来看，解密 HTTPS 隧道构成中间人攻击。攻击工具相当于现实世界中的原子弹：确保您了解自己在做什么，并且您的决策者有足够的信息做出明智的选择。

结合使用 Squid 的 NAT 拦截、SslBump 和相关功能，可以拦截直接 HTTPS 连接并在通过 Squid 代理时解密 HTTPS 消息。这允许将发送到源服务器的 HTTPS 消息视为常规 HTTP 消息进行处理，包括应用详细的访问控制和执行内容适应（例如，检查请求主体是否有信息泄露，并检查响应是否有病毒）。配置错误、Squid bug 和恶意攻击可能导致未加密的消息逃逸 Squid 的边界。

目前，拦截的直接 HTTPS 连接上的 Squid 到客户端流量无法使用动态证书生成，这会导致浏览器警告，并使此类配置近乎不切实际。此限制将由 bump-server-first 项目解决。

从浏览器的角度来看，拦截的消息并未发送到代理。因此，通用的拦截限制，例如无法对请求进行身份验证，也适用于被篡改的拦截事务。

🔗 加密的浏览器-Squid 连接

Squid 可以使用 https_port 接受常规代理流量，就像 Squid 使用 http_port 指令一样。RFC 2818 定义了围绕此的协议要求。

不幸的是，流行的现代浏览器尚未允许配置 TLS 加密的代理连接。目前这些浏览器都有开放的 bug 报告，等待支持的出现。如果您有任何兴趣，请协助浏览器团队完成此事。

与此同时，需要使用 stunnel 或 SSH 隧道等技巧来加密浏览器到代理的连接，然后再离开客户端机器。这些在网络上会有些负担，因此可能速度较慢。

🔗 Chrome

Chrome 浏览器可以通过 TLS 连接连接到代理，如果它在 PAC 文件或命令行开关中被配置为使用一个。GUI 配置似乎（尚未）可能。

更多详情请参阅 http://dev.chromium.org/developers/design-documents/secure-web-proxy

🔗 Firefox

Firefox 33.0 浏览器可以通过 TLS 连接连接到代理，如果它在 PAC 文件中被配置为使用一个。GUI 配置似乎（尚未）可能，尽管有一个用于嵌入 PAC 逻辑的配置技巧。

仍然有一个重要的 bug 存在：

• 使用客户端证书向代理进行身份验证：https://bugzilla.mozilla.org/show_bug.cgi?id=209312

如果您在添加对代理证书的信任方面遇到问题，Patrick McManus 提供了一个解决方案。

类别：功能

导航：站点搜索，站点页面，类别，🔼 向上