Kolmen vuoden kehitystyön jälkeen Squid-välityspalvelimen uusi vakaa versio, 5.1, on julkaistu ja valmis käytettäväksi tuotantojärjestelmissä (versiot 5.0.x olivat beta-versioita).
Kun 5.x-haara saavuttaa vakaan tilan, tästä lähtien korjataan vain haavoittuvuuksia ja vakausongelmia sekä tehdään pieniä optimointeja. Uusien ominaisuuksien kehitys tapahtuu uudessa kokeellisessa 6.0-haarassa. Aiemman vakaan 4.x-haaran käyttäjiä kannustetaan suunnittelemaan siirtymistä 5.x-haaraan.
Squid 5.1 Tärkeimmät uudet ominaisuudet
Tässä uudessa versiossa yhteensopivuus Berkeley DB -formaatin kanssa on vanhentunut lisenssiongelmien vuoksi . Berkeley DB 5.x -haaraa ei ole ylläpidetty useisiin vuosiin, ja siinä on edelleen korjaamattomia haavoittuvuuksia. Uudempiin versioihin päivittäminen ei salli AGPLv3-lisenssin muuttamista, jonka vaatimukset koskevat myös sovelluksia, jotka käyttävät Berkeley DB:tä kirjastona. Squid julkaistaan GPLv2-lisenssillä, eikä AGPL ole yhteensopiva GPLv2:n kanssa.
Berkeley DB:n sijaan projekti siirtyi käyttämään TrivialDB DBMS:ää, joka toisin kuin Berkeley DB on optimoitu samanaikaiseen rinnakkaiseen tietokannan käyttöön. Berkeley DB -tuki säilytetään toistaiseksi, mutta nyt suositellaan tallennustyypin "libtdb" käyttöä "libdb":n sijaan "ext_session_acl"- ja "ext_time_quota_acl"-käsittelijöissä.
Lisäksi lisättiin tuki RFC 8586: ssa määritetylle HTTP CDN-Loop -otsakkeelle, joka mahdollistaa silmukoiden havaitsemisen käytettäessä sisällön toimitusverkkoja (ylätunniste suojaa tilanteilta, joissa pyyntö palaa CDN: ien välillä uudelleen jostain syystä alkuperäiseen CDN: ään muodostaen äärettömän silmukan).
Lisäksi SSL-Bump-mekanismiin, joka mahdollistaa salattujen HTTPS-istuntojen sisällön sieppaamisen, on lisätty tuki väärennettyjen HTTPS-pyyntöjen uudelleenohjaukselle muiden cache_peer-määrityksessä määritettyjen välityspalvelimien kautta käyttämällä tavallista tunnelia, joka perustuu HTTP CONNECT -metodiin (HTTPS-tiedonsiirtoa ei tueta, koska Squid ei voi vielä lähettää TLS-salausta TLS:n sisällä).
Saatuaan ensimmäisen siepatun HTTPS-pyynnön SSL-Bump muodostaa TLS-yhteyden kohdepalvelimeen ja hakee sen varmenteen. Squid käyttää sitten palvelimelta vastaanotetun oikean varmenteen isäntänimeä luodakseen väärennetyn varmenteen, jota se käyttää pyydetyn palvelimen henkilöllisyyden esiintymiseen vuorovaikutuksessa asiakkaan kanssa ja jatkaa samalla kohdepalvelimeen muodostetun TLS-yhteyden käyttöä datan vastaanottamiseen.
On myös syytä huomata, että ICAP:n (Internet Content Adaptation Protocol) käyttöönotto , jota käytetään integrointiin ulkoisten sisällönvahvistusjärjestelmien kanssa, on lisännyt tuen datan liittämismekanismille , joka mahdollistaa lisämetatietootsikoiden liittämisen vastaukseen viestin rungon jälkeen.
Sen sijaan, että ottaisit huomioon "dns_v4_first»IPv4- tai IPv6 -osoiteperheen käyttöjärjestyksen määrittämiseksi nyt DNS: n vastausjärjestys otetaan huomioon- Jos DNS: n AAAA -vastaus ilmestyy ensimmäisenä odottaessaan IP -osoitteen ratkeamista, tuloksena olevaa IPv6 -osoitetta käytetään. Siksi ensisijainen osoiteperheasetus tehdään nyt palomuurissa, DNS: ssä tai käynnistyksen yhteydessä "–disable-ipv6" -vaihtoehdolla.
Ehdotettu muutos nopeuttaa TCP -yhteyksien määrittämiseen kuluvaa aikaa ja vähentää DNS -ratkaisujen viiveiden suorituskykyvaikutuksia.
Pyyntöjä uudelleenohjattaessa käytetään "Happy Eyeballs" -algoritmia, joka käyttää vastaanotettua IP-osoitetta välittömästi odottamatta kaikkien mahdollisesti käytettävissä olevien IPv4- ja IPv6-kohdeosoitteiden selvittämistä.
"External_acl" -direktiivin käyttöä varten "ext_kerberos_sid_group_acl" -ohjain on lisätty todennusta varten Active Directoryn vahvistusryhmien avulla Kerberosia käyttäen. Ryhmän nimen kyselemiseen käytetään OpenLDAP -paketin tarjoamaa ldapsearch -apuohjelmaa.
Lisätty mark_client_connection- ja mark_client_pack -direktiivit sitomaan Netfilter (CONNMARK) -tunnisteet yksittäisiin paketteihin tai asiakkaan TCP -yhteyksiin
Lopuksi mainitaan, että Squid 5.2:n ja Squid 4.17:n julkaistujen versioiden ohjeiden mukaisesti korjattiin seuraavat haavoittuvuudet:
- CVE-2021-28116-Tietovuoto käsiteltäessä erityisesti muotoiltuja WCCPv2-viestejä. Haavoittuvuuden avulla hyökkääjä voi turmella tunnettujen WCCP -reitittimien luettelon ja ohjata liikenteen välityspalvelimesta isäntäänsä. Ongelma ilmenee vain kokoonpanoissa, joissa WCCPv2 -tuki on käytössä, ja kun on mahdollista huijata reitittimen IP -osoite.
- CVE-2021-41611: virhe vahvistettaessa TLS-varmenteita, jotka sallivat pääsyn epäluotettujen varmenteiden avulla.
Lopuksi, jos haluat tietää siitä lisää, voit tarkistaa yksityiskohdat seuraavasta linkistä.