Sau ba năm phát triển, phiên bản ổn định mới của máy chủ proxy Squid, 5.1, đã được phát hành và sẵn sàng để sử dụng trong các hệ thống sản xuất (các phiên bản 5.0.x là phiên bản beta).
Sau khi nhánh 5.x đạt trạng thái ổn định, từ nay trở đi chỉ có các bản vá lỗi cho các lỗ hổng bảo mật và vấn đề ổn định sẽ được triển khai , cùng với các tối ưu hóa nhỏ. Việc phát triển tính năng mới sẽ diễn ra trong nhánh thử nghiệm 6.0 mới. Người dùng của nhánh 4.x ổn định trước đó được khuyến khích lên kế hoạch chuyển đổi sang nhánh 5.x.
Các tính năng mới chính của Squid 5.1
Trong phiên bản mới này, khả năng tương thích với định dạng Berkeley DB đã bị loại bỏ do các vấn đề về bản quyền . Nhánh Berkeley DB 5.x đã không được bảo trì trong vài năm và vẫn còn các lỗ hổng chưa được vá, và việc nâng cấp lên các phiên bản mới hơn không cho phép thay đổi giấy phép AGPLv3, mà các yêu cầu của nó cũng áp dụng cho các ứng dụng sử dụng Berkeley DB như một thư viện. Squid được phát hành theo giấy phép GPLv2, và AGPL không tương thích với GPLv2.
Thay vì sử dụng Berkeley DB, dự án đã chuyển sang sử dụng hệ quản trị cơ sở dữ liệu TrivialDB, khác với Berkeley DB ở chỗ, TrivialDB được tối ưu hóa cho việc truy cập song song đồng thời vào cơ sở dữ liệu. Hiện tại, hỗ trợ Berkeley DB vẫn được duy trì, nhưng hiện nay khuyến nghị nên sử dụng kiểu lưu trữ "libtdb" thay vì "libdb" trong các trình xử lý "ext_session_acl" và "ext_time_quota_acl".
Ngoài ra, hỗ trợ đã được thêm vào tiêu đề HTTP CDN-Loop, được định nghĩa trong RFC 8586, cho phép phát hiện các vòng lặp khi sử dụng mạng phân phối nội dung (tiêu đề cung cấp bảo vệ chống lại các tình huống trong đó một yêu cầu, trong quá trình chuyển hướng giữa các CDN vì một số lý do, trả về đến CDN ban đầu, tạo thành một vòng lặp vô hạn).
Hơn nữa, cơ chế SSL-Bump, cho phép chặn nội dung của các phiên HTTPS được mã hóa, đã bổ sung hỗ trợ chuyển hướng các yêu cầu HTTPS giả mạo thông qua các máy chủ proxy khác được chỉ định trong cache_peer bằng cách sử dụng một đường hầm thông thường dựa trên phương thức HTTP CONNECT (việc truyền qua HTTPS hiện chưa được hỗ trợ, vì Squid chưa thể truyền TLS trong TLS).
Khi nhận được yêu cầu HTTPS đầu tiên bị chặn, SSL-Bump thiết lập kết nối TLS với máy chủ mục tiêu và lấy chứng chỉ của nó. Sau đó, Squid sử dụng tên máy chủ của chứng chỉ thật nhận được từ máy chủ để tạo chứng chỉ giả, mà nó sử dụng để mạo danh máy chủ được yêu cầu khi tương tác với máy khách , đồng thời vẫn tiếp tục sử dụng kết nối TLS đã thiết lập với máy chủ mục tiêu để nhận dữ liệu.
Cũng cần lưu ý rằng việc triển khai ICAP (Internet Content Adaptation Protocol), được sử dụng để tích hợp với các hệ thống xác minh nội dung bên ngoài, đã bổ sung hỗ trợ cho cơ chế đính kèm dữ liệu cho phép đính kèm thêm các tiêu đề siêu dữ liệu vào phản hồi, được đặt sau phần thân thông báo.
Thay vì tính đến "dns_v4_first»Để xác định thứ tự sử dụng họ địa chỉ IPv4 hoặc IPv6, bây giờ thứ tự của phản hồi trong DNS được tính đến- Nếu phản hồi AAAA từ DNS xuất hiện đầu tiên trong khi chờ địa chỉ IP phân giải, địa chỉ IPv6 kết quả sẽ được sử dụng. Do đó, cài đặt họ địa chỉ ưa thích hiện được thực hiện trong tường lửa, DNS hoặc khi khởi động với tùy chọn "–disable-ipv6".
Thay đổi được đề xuất sẽ tăng tốc thời gian định cấu hình kết nối TCP và giảm tác động hiệu suất của sự chậm trễ trong phân giải DNS.
Khi chuyển hướng yêu cầu, thuật toán "Happy Eyeballs" được sử dụng, thuật toán này ngay lập tức sử dụng địa chỉ IP nhận được mà không cần chờ tất cả các địa chỉ IPv4 và IPv6 đích có thể khả dụng được phân giải.
Để sử dụng trong chỉ thị "external_acl", trình điều khiển "ext_kerberos_sid_group_acl" đã được thêm để xác thực với các nhóm xác minh trong Active Directory bằng cách sử dụng Kerberos. Tiện ích ldapsearch được cung cấp bởi gói OpenLDAP được sử dụng để truy vấn tên nhóm.
Đã thêm chỉ thị mark_client_connection và mark_client_pack để liên kết các thẻ Netfilter (CONNMARK) với các gói riêng lẻ hoặc kết nối TCP của ứng dụng khách
Cuối cùng, cần lưu ý rằng, theo các bước đã được thực hiện trong các phiên bản Squid 5.2 và Squid 4.17 đã được phát hành, các lỗ hổng sau đây đã được khắc phục:
- CVE-2021-28116 - Rò rỉ thông tin khi xử lý thông báo WCCPv2 được chế tạo đặc biệt. Lỗ hổng cho phép kẻ tấn công làm hỏng danh sách các bộ định tuyến WCCP đã biết và chuyển hướng lưu lượng truy cập từ máy khách proxy đến máy chủ của nó. Vấn đề chỉ xuất hiện trong các cấu hình được bật hỗ trợ WCCPv2 và khi có thể giả mạo địa chỉ IP của bộ định tuyến.
- CVE-2021-41611: lỗi khi xác thực chứng chỉ TLS cho phép truy cập bằng chứng chỉ không đáng tin cậy.
Cuối cùng, nếu bạn muốn biết thêm chi tiết, bạn có thể xem tại liên kết sau.