Squid 5.1 經過三年的開發,這些是它的新聞

經過三年的發展 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連接來接收數據。

還強調的是,議定書的實施 卡普 (互聯網內容適配協議),用於與外部內容驗證系統集成, 添加了對數據附件機制的支持 它允許您將附加元數據標頭附加到回復中,放置在消息之後。 身體。

而不是考慮“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 證書時出錯。

最後,如果您想了解更多信息,可以查看詳細信息 在下面的鏈接中。


成為第一個發表評論

發表您的評論

您的電子郵件地址將不會被發表。 必填字段標有 *

*

*

  1. 負責數據:MiguelÁngelGatón
  2. 數據用途:控制垃圾郵件,註釋管理。
  3. 合法性:您的同意
  4. 數據通訊:除非有法律義務,否則不會將數據傳達給第三方。
  5. 數據存儲:Occentus Networks(EU)託管的數據庫
  6. 權利:您可以隨時限制,恢復和刪除您的信息。