🔗 功能：Squid-in-the-middle SSL Bump

• 目标：启用 ICAP 对 SSL 流量的检查。
• 版本：3.1 至 3.4。
• 开发者：AlexRousskov，Christos Tsantilas
• 更多：另请参阅 动态 SSL 证书生成 和 源服务器证书模仿 功能。

🔗 详细信息

此功能已在 Squid-3.5 中被 peek-n-splice 取代

此功能已在 Squid-3.3 中被 server-first 取代

Squid-in-the-middle 使用可配置的 CA 证书对直连的 CONNECT 请求和透明重定向的 SSL 流量进行解密和加密。解密后，流量可以通过常规的 Squid 功能（如 ICAP 和 eCAP）进行分析、阻止或适配。

默认情况下，大多数用户代理会警告最终用户可能存在中间人攻击。

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

🔗 限制

🔗 Squid 负责处理服务器证书验证错误

当 HTTP 客户端收到无效的源服务器证书时，它可以利用代理功能来处理验证错误。例如，许多浏览器会发出警告，允许用户检查无效证书，并可选择忽略此连接或未来所有连接的错误。

目前此强大功能不可用，因为 Squid 会做出是否忽略验证错误的最终决定。HTTP 客户端始终收到由 Squid 生成的有效证书，而不是来自源服务器的无效证书。我们正在考虑添加代码来在生成伪造证书时模仿服务器证书错误，从而使用户有机会检查和绕过错误。欢迎提供优质补丁或赞助。

为避免此重大限制，强烈建议升级到 Squid-3.3 或更高版本，并使用 源服务器证书模仿 功能。

🔗 Squid 配置

以下是一个包含 SSL Bump 相关选项的示例 squid.conf 配置片段

🔗 启用 SSL Bump

如何配置 HTTP 端口以处理 CONNECT 请求的示例

http_port 3128 ssl-bump cert=/usr/local/squid3/etc/site_priv+pub.pem

# Bumped requests have relative URLs so Squid has to use reverse proxy
# or accelerator code. By default, that code denies direct forwarding.
# The need for this option may disappear in the future.
always_direct allow all

🔗 访问控制

ssl_bump 用于阻止某些请求被拦截。

如何避免拦截 Squid-3.1 或 Squid-3.2 代理不好的站点的示例

acl broken_sites dstdomain .example.com
ssl_bump deny broken_sites
ssl_bump allow all

Squid-3.3 中的 ssl_bump 指令已更新，允许在几种拦截算法之间进行选择。上述规则现在配置如下

acl broken_sites dstdomain .example.com
ssl_bump none broken_sites
ssl_bump client-first all

然而，Squid-3.3 及更高版本提供了server-first算法，可以替代上述规则中的client-first，并且对于拦截 HTTPS 更好，因为它避免了以下问题。

🔗 其他设置

可能会出现某些证书错误，但它们并非真正的问题。例如，内部站点使用自签名证书，或者内部域名与公开证书名称不匹配。

Squid-3.3 及更高版本

server-first 拦截算法与 证书模仿 允许 Squid 透明地将这些缺陷传递给客户端浏览器，从而做出更准确的安全决策。

Squid-3.1 和 Squid-3.2

sslproxy_cert_error 指令和ssl_error ACL 类型允许在证书存在问题的情况下接受这些域。

安全警告：忽略证书错误是一个安全漏洞。在共享代理中这样做是极其危险的行为。不应轻易进行，也不应针对您不是所有者的域进行（在这种情况下，请在这样做之前尝试修复证书问题）。

允许访问发送错误证书的网站

# ignore errors with certain cites (very dangerous!)
acl TrustedName url_regex ^https://weserve.badcerts.example.com/
sslproxy_cert_error allow TrustedName
sslproxy_cert_error deny all

允许访问尝试使用其他域证书的网站。

# ignore certain certificate errors (very dangerous!)
acl BadSite ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
sslproxy_cert_error allow BadSite
sslproxy_cert_error deny all

🔗 内存使用

警告：与本文其他部分不同，本节内容适用于 Squid-3.3 以及可能支持 动态 SSL 证书生成 和 源服务器证书模仿 的较新代码。当前章节文本主要面向开发者和早期采用者，他们在某些 SslBump 环境中遇到内存消耗过大的问题。如果找到更好的位置，这些笔记可能会被移走。

当前文档特定于 bump-server-first 配置。

🔗 Squid 与 SSL 客户端通信

如果 generate-host-certificates 为“on”（对于 ssl-bump http*ports，默认值为“on”），那么 Squid 会为每个真实的 SSL 服务器证书使用一个 SSL 上下文 (SSL_CTX)（参见 ConnStateData::getSslContextStart）。该 SSL 上下文使用相应的 SSL 服务器的伪造证书进行配置。该伪造证书来自 _security_file_certgen 辅助程序（较旧的 Squid 称之为 ssl_crtd），或者由 Squid 临时生成。伪造证书（或更确切地说，它们的上下文）可能会缓存在 Squid 上下文缓存中。缓存键包括主题名称、通用名称 (CN)、有效期、无效日期以及其他真实证书的属性。存储完整证书链的 SSL 上下文可能会占用几 MB 的 RAM。由于 Squid 通常与大量服务器通信，为了避免容量不足，总证书缓存容量可能需要超过几 GB。请参见dynamic_cert_mem_cache_size 和 Squid bug 4005，了解配置的缓存限制为何目前未能按预期工作。Squid 在重新配置期间不会清空其上下文缓存（尽管在较新版本的 Squid 中，不再使用或不再缓存的端口的上下文会被删除）。

如果 generate-host-certificates 为“off”，那么 Squid 将为该端口上的所有事务使用一个 SSL 上下文 (SSL_CTX)（参见 http_port / https_port），无论其目标是什么（参见 PortCfg::staticSslContext）。该 SSL 上下文是使用 http_port 选项配置的。这是在 Squid 开始（或恢复）处理流量之前完成的，因此使用此上下文不可能实现服务器证书模仿。该上下文在重新配置期间会被重新创建。在撰写本文时，存在几个 bug（带有待处理的端口泄漏补丁），它们可能会在某些 Squid 中阻止这种清理。

🔗 Squid 与 SSL 服务器通信

与 SSL 源服务器通信时，Squid 会为所有服务器使用一个 SSL 上下文（如果使用了 cache_peer，则每个对等体使用一个 SSL_CTX；参见 Config.ssl_client.sslContext 和 FwdState::initiateSSL()）。该 SSL 上下文使用 squid.conf 中的各种 sslproxy_* 指令（或 cache_peer 的 ssl* 选项）进行配置。

OpenSSL 会自动加载并缓存（在 SSL 上下文中）验证 Squid 收到的真实服务器证书所需的证书和 CRL。单个 CRL 可能会占用几 MB。由于 Squid 通常与大量服务器通信，因此总的内部 OpenSSL 缓存大小可能会超过几 GB。OpenSSL 不限制其内部缓存大小，也无法通过 OpenSSL API 进行控制。

与 SSL 服务器直接通信时使用的 SSL 上下文在重新配置时会被释放并重新创建。理论上，当不再使用旧上下文的最后一个 SSL 连接消失时，这应该会清除内部 OpenSSL 证书和 CRL 缓存。在撰写本文时，存在几个 bug（带有待处理的补丁），它们可能会在某些 Squid 中阻止这种清理。

类别：功能，已弃用的功能

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