经过三年的发展 Squid 5.1代理服务器新稳定版发布 它可以在生产系统上使用(版本 5.0.x 是测试版)。
使 5.x 分支稳定后, 从现在开始,只会修复漏洞和稳定性问题,并且还允许进行小的优化。 新功能的开发将在新的实验分支6.0中完成。 鼓励旧 4.x 稳定分支的用户计划迁移到 5.x 分支。
Squid 5.1 主要新特性
在这个新版本中 由于许可问题,Berkeley DB 格式支持已被弃用. Berkeley DB 5.x 分支已经好几年没有管理了,仍然存在未修补的漏洞,并且升级到新版本不允许更改 AGPLv3 许可证,其要求也适用于以库形式使用 BerkeleyDB 的应用程序。 - Squid 是在 GPLv2 许可下发布的,AGPL 与 GPLv2 不兼容。
该项目没有使用 Berkeley DB,而是使用 TrivialDB DBMS, 与 Berkeley DB 不同的是,它针对同时并行访问数据库进行了优化。 Berkeley DB 支持暂时保留,但现在建议在“ext_session_acl”和“ext_time_quota_acl”驱动程序中使用“libtdb”存储类型而不是“libdb”。
此外,还添加了对 RFC 8586 中定义的 HTTP CDN-Loop 标头的支持,该标头允许在使用内容交付网络时检测循环(标头提供保护,防止请求在 CDN 之间由于某种原因重定向期间返回到原来的CDN,形成无限循环)。
此外, SSL-Bump 机制, 它允许拦截加密的 HTTPS 会话的内容,h增加了对通过其他服务器重定向欺骗性 HTTPS 请求的支持 使用基于 HTTP CONNECT 方法的常规隧道在 cache_peer 中指定的代理(不支持通过 HTTPS 传输,因为 Squid 还不能在 TLS 内传输 TLS)。
SSL-Bump 允许在第一个拦截的 HTTPS 请求到达时建立 TLS 连接 与目标服务器并获取其证书。 随后, Squid 使用收到的实际证书的主机名 从服务器并创建一个假证书, 它在与客户端交互时模仿请求的服务器,同时继续使用与目的服务器建立的TLS连接来接收数据。
还强调的是,议定书的实施 ICAP (互联网内容适配协议),用于与外部内容验证系统集成, 添加了对数据附件机制的支持 它允许您将附加元数据标头附加到回复中,放置在消息之后。 身体。
而不是考虑“dns_v4_first»要确定 IPv4 或 IPv6 地址族的使用顺序, 现在考虑了 DNS 中响应的顺序- 如果在等待 IP 地址解析时首先出现来自 DNS 的 AAAA 响应,则将使用生成的 IPv6 地址。 因此,首选地址族设置现在在防火墙、DNS 中或在启动时使用“–disable-ipv6”选项完成。
提议的更改将加快配置 TCP 连接的时间,并减少 DNS 解析延迟对性能的影响。
重定向请求时,使用“Happy Eyeballs”算法, 它立即使用接收到的 IP 地址,而无需等待解析所有可能可用的目标 IPv4 和 IPv6 地址。
为了在“external_acl”指令中使用,已添加“ext_kerberos_sid_group_acl”驱动程序,以使用 Kerberos 对 Active Directory 中的验证组进行身份验证。 OpenLDAP 包提供的 ldapsearch 实用程序用于查询组名。
添加了 mark_client_connection 和 mark_client_pack 指令以将 Netfilter (CONNMARK) 标签绑定到单个数据包或客户端 TCP 连接
最后提到按照Squid 5.2和Squid 4.17发布版本的步骤 漏洞已修复:
- CVE-2021-28116 - 处理特制 WCCPv2 消息时信息泄漏。 该漏洞允许攻击者破坏已知 WCCP 路由器列表并将流量从代理客户端重定向到其主机。 该问题仅在启用了 WCCPv2 支持的配置中以及在可能欺骗路由器的 IP 地址时才会出现。
- CVE-2021-41611:验证允许使用不受信任的证书访问的 TLS 证书时出错。
最后,如果您想了解更多信息,可以查看详细信息 在下面的链接中。