Pagkatapos ng tatlong taon ng pag-unlad, ang isang matatag na paglabas ng Squid 5.1 proxy server ay ipinakita, na handang gamitin sa mga sistema ng produksyon (mga release na 5.0.x ay may katayuan ng mga bersyon ng beta). Matapos mabigyan ng stable na status ang branch ng 5.x, mula ngayon ay gagawin na lang dito ang mga pag-aayos para sa mga kahinaan at problema sa stability, at pinapayagan din ang mga menor de edad na pag-optimize. Ang pagbuo ng mga bagong feature ay isasagawa sa bagong experimental branch 6.0. Ang mga gumagamit ng dating stable 4.x branch ay pinapayuhan na magplanong lumipat sa 5.x branch.
Mga pangunahing inobasyon sa Squid 5:
- Ang pagpapatupad ng ICAP (Internet Content Adaptation Protocol), na ginagamit para sa pagsasama sa mga external na sistema ng pag-verify ng nilalaman, ay nagdagdag ng suporta para sa mekanismo ng attachment ng data (trailer), na nagbibigay-daan sa iyong mag-attach ng mga karagdagang header na may metadata sa tugon, na inilagay pagkatapos ng mensahe body (halimbawa, maaari kang magpadala ng checksum at mga detalye tungkol sa mga natukoy na problema).
- Kapag nagre-redirect ng mga kahilingan, ginagamit ang algorithm na "Happy Eyeballs", na agad na gumagamit ng natanggap na IP address, nang hindi naghihintay na maresolba ang lahat ng potensyal na available na IPv4 at IPv6 target address. Sa halip na isaalang-alang ang setting na "dns_v4_first" upang matukoy kung ang IPv4 o IPv6 address family ay ginagamit, ang pagkakasunud-sunod ng tugon ng DNS ay isinasaalang-alang na ngayon: kung ang tugon ng DNS AAAA ay unang dumating kapag naghihintay na malutas ang isang IP address, pagkatapos ay gagamitin ang resultang IPv6 address. Kaya, ang pagtatakda ng gustong pamilya ng address ay ginagawa na ngayon sa antas ng firewall, DNS o startup gamit ang opsyong "--disable-ipv6". Ang iminungkahing pagbabago ay nagpapahintulot sa amin na pabilisin ang oras ng pag-setup ng mga koneksyon sa TCP at bawasan ang epekto ng pagganap ng mga pagkaantala sa panahon ng paglutas ng DNS.
- Para sa paggamit sa "external_acl" na direktiba, ang "ext_kerberos_sid_group_acl" na tagapangasiwa ay idinagdag para sa authentication na may group checking sa Active Directory gamit ang Kerberos. Upang i-query ang pangalan ng grupo, gamitin ang ldapsearch utility na ibinigay ng OpenLDAP package.
- Ang suporta para sa format ng Berkeley DB ay hindi na ginagamit dahil sa mga isyu sa paglilisensya. Ang sangay ng Berkeley DB 5.x ay hindi pinananatili sa loob ng ilang taon at nananatiling may hindi natatakpan na mga kahinaan, at ang paglipat sa mga mas bagong release ay pinipigilan ng pagbabago ng lisensya sa AGPLv3, ang mga kinakailangan nito ay nalalapat din sa mga application na gumagamit ng BerkeleyDB sa anyo ng isang library - Ang pusit ay ibinibigay sa ilalim ng lisensya ng GPLv2, at ang AGPL ay hindi tugma sa GPLv2. Sa halip na Berkeley DB, ang proyekto ay inilipat sa paggamit ng TrivialDB DBMS, na, hindi katulad ng Berkeley DB, ay na-optimize para sa sabay-sabay na parallel na pag-access sa database. Ang suporta sa Berkeley DB ay pinananatili sa ngayon, ngunit ang mga "ext_session_acl" at "ext_time_quota_acl" na mga humahawak ay inirerekomenda na ngayon ang paggamit ng "libtdb" na uri ng imbakan sa halip na "libdb".
- Nagdagdag ng suporta para sa CDN-Loop HTTP header, na tinukoy sa RFC 8586, na nagbibigay-daan sa iyong makakita ng mga loop kapag gumagamit ng mga network ng paghahatid ng nilalaman (ang header ay nagbibigay ng proteksyon laban sa mga sitwasyon kapag ang isang kahilingan sa proseso ng pag-redirect sa pagitan ng mga CDN sa ilang kadahilanan ay bumalik sa orihinal na CDN, na bumubuo ng walang katapusang loop ).
- Ang mekanismo ng SSL-Bump, na nagbibigay-daan sa iyong harangin ang mga nilalaman ng mga naka-encrypt na HTTPS session, ay nagdagdag ng suporta para sa pag-redirect ng mga spoofed (muling na-encrypt) na mga kahilingan sa HTTPS sa pamamagitan ng iba pang mga proxy server na tinukoy sa cache_peer, gamit ang isang regular na tunnel batay sa pamamaraang HTTP CONNECT ( Ang paghahatid sa pamamagitan ng HTTPS ay hindi suportado, dahil hindi pa madala ng Squid ang TLS sa loob ng TLS). Binibigyang-daan ka ng SSL-Bump na magtatag ng koneksyon sa TLS sa target na server kapag natanggap ang unang na-intercept na kahilingan sa HTTPS at makuha ang certificate nito. Pagkatapos nito, ginagamit ng Squid ang hostname mula sa totoong sertipiko na natanggap mula sa server at lumilikha ng isang dummy na sertipiko, kung saan ginagaya nito ang hiniling na server kapag nakikipag-ugnayan sa kliyente, habang patuloy na ginagamit ang koneksyon ng TLS na itinatag sa target na server upang makatanggap ng data ( upang ang pagpapalit ay hindi humantong sa mga babala sa output sa mga browser sa panig ng kliyente, kailangan mong idagdag ang iyong sertipiko na ginamit upang makabuo ng mga gawa-gawang sertipiko sa root certificate store).
- Nagdagdag ng mark_client_connection at mark_client_pack na mga direktiba upang itali ang mga marka ng Netfilter (CONNMARK) sa mga koneksyon sa TCP ng kliyente o mga indibidwal na packet.
Mainit sa kanilang mga takong, ang mga release ng Squid 5.2 at Squid 4.17 ay nai-publish, kung saan ang mga kahinaan ay naayos:
- CVE-2021-28116 - Pag-leakage ng impormasyon kapag nagpoproseso ng mga espesyal na ginawang mensahe ng WCCPv2. Ang kahinaan ay nagbibigay-daan sa isang umaatake na sirain ang listahan ng mga kilalang WCCP router at i-redirect ang trapiko mula sa mga kliyente ng proxy server patungo sa kanilang host. Ang problema ay lilitaw lamang sa mga pagsasaayos na may naka-enable na suporta sa WCCPv2 at kapag posibleng madaya ang IP address ng router.
- CVE-2021-41611 - Ang isang isyu sa pag-verify ng TLS certificate ay nagbibigay-daan sa pag-access gamit ang mga hindi pinagkakatiwalaang certificate.
Pinagmulan: opennet.ru