După trei ani de dezvoltare, noua versiune stabilă a serverului proxy Squid, 5.1, a fost lansată și este gata de utilizare în sistemele de producție (versiunile 5.0.x erau beta).
După ce ramura 5.x va atinge o stare stabilă, de acum înainte vor fi implementate doar remedieri pentru vulnerabilități și probleme de stabilitate , împreună cu optimizări minore. Dezvoltarea de noi funcționalități va avea loc în noua ramură experimentală 6.0. Utilizatorii ramurii stabile 4.x anterioare sunt încurajați să planifice o migrare către ramura 5.x.
Principalele caracteristici noi ale Squid 5.1
În această nouă versiune, compatibilitatea cu formatul Berkeley DB a fost depreciată din cauza unor probleme de licențiere . Ramura Berkeley DB 5.x nu a fost întreținută de câțiva ani și încă prezintă vulnerabilități neremediate, iar actualizarea la versiuni mai noi nu permite modificarea licenței AGPLv3, ale cărei cerințe se aplică și aplicațiilor care utilizează Berkeley DB ca bibliotecă. Squid este lansat sub licența GPLv2, iar AGPL este incompatibil cu GPLv2.
În loc de Berkeley DB, proiectul a migrat pentru a utiliza TrivialDB DBMS, care, spre deosebire de Berkeley DB, este optimizat pentru acces paralel simultan la baza de date. Suportul pentru Berkeley DB este menținut deocamdată, dar acum se recomandă utilizarea tipului de stocare „libtdb” în loc de „libdb” în handlerele „ext_session_acl” și „ext_time_quota_acl”.
În plus, a fost adăugat suport pentru antetul HTTP CDN-Loop, definit în RFC 8586, care permite detectarea buclelor atunci când se utilizează rețele de livrare a conținutului (antetul oferă protecție împotriva situațiilor în care o cerere, în timpul redirecționării între CDN-uri din anumite motive, returnează la CDN-ul original, formând o buclă infinită).
În plus, mecanismul SSL-Bump, care permite interceptarea conținutului sesiunilor HTTPS criptate, a adăugat suport pentru redirecționarea cererilor HTTPS falsificate prin alte servere proxy specificate în cache_peer folosind un tunel obișnuit bazat pe metoda HTTP CONNECT (transmiterea prin HTTPS nu este acceptată, deoarece Squid nu poate încă transmite TLS în cadrul TLS).
La primirea primei cereri HTTPS interceptate, SSL-Bump stabilește o conexiune TLS cu serverul țintă și obține certificatul acestuia. Squid folosește apoi numele de gazdă al certificatului real primit de la server pentru a crea un certificat fals, pe care îl folosește pentru a se da drept serverul solicitat atunci când interacționează cu clientul , continuând în același timp să utilizeze conexiunea TLS stabilită cu serverul țintă pentru a primi date.
De asemenea, merită menționat faptul că implementarea ICAP (Internet Content Adaptation Protocol), utilizat pentru integrarea cu sisteme externe de verificare a conținutului, a adăugat suport pentru mecanismul de atașare a datelor , care permite atașarea de antete de metadate suplimentare la răspuns, plasate după corpul mesajului.
În loc să ia în considerare „dns_v4_first»Pentru a determina ordinea de utilizare a familiei de adrese IPv4 sau IPv6, acum se ia în calcul ordinea răspunsului în DNS- Dacă răspunsul AAAA de la DNS apare primul în timp ce așteptați rezolvarea unei adrese IP, va fi utilizată adresa IPv6 rezultată. Prin urmare, setarea preferată a familiei de adrese se face acum în firewall, DNS sau la pornire cu opțiunea „–disable-ipv6”.
Modificarea propusă va accelera timpul de configurare a conexiunilor TCP și va reduce impactul performanței întârzierilor în rezoluția DNS.
La redirecționarea cererilor, se utilizează algoritmul „Happy Eyeballs”, care utilizează imediat adresa IP primită, fără a aștepta rezolvarea tuturor adreselor IPv4 și IPv6 de destinație potențial disponibile.
Pentru utilizare în directiva „external_acl”, driverul „ext_kerberos_sid_group_acl” a fost adăugat pentru autentificare cu grupuri de verificare din Active Directory folosind Kerberos. Utilitarul ldapsearch furnizat de pachetul OpenLDAP este utilizat pentru interogarea numelui grupului.
S-au adăugat directivele mark_client_connection și mark_client_pack pentru a lega etichetele Netfilter (CONNMARK) de pachete individuale sau conexiuni TCP client
În final, se menționează că, urmând pașii din versiunile publicate de Squid 5.2 și Squid 4.17, au fost corectate următoarele vulnerabilități:
- CVE-2021-28116 - Scurgerea informațiilor la procesarea mesajelor special elaborate WCCPv2. Vulnerabilitatea permite unui atacator să corupă lista de routere WCCP cunoscute și să redirecționeze traficul de la clientul proxy la gazda acestuia. Problema se manifestă numai în configurații cu suport WCCPv2 activat și când este posibil să falsifice adresa IP a routerului.
- CVE-2021-41611: eroare la validarea certificatelor TLS care permit accesul utilizând certificate de încredere.
În cele din urmă, dacă doriți să aflați mai multe despre acest subiect, puteți verifica detaliile la linkul următor.