Nach dreijähriger Entwicklungszeit wird eine stabile Version des Squid 5.1-Proxyservers vorgestellt, die für den Einsatz in Produktionssystemen bereit ist (Versionen 5.0.x hatten den Status von Beta-Versionen). Nachdem der 5.x-Zweig stabilisiert wurde, werden nur noch Schwachstellen und Stabilitätsprobleme behoben, kleinere Optimierungen sind ebenfalls zulässig. Die Entwicklung neuer Funktionen wird in einem neuen experimentellen Zweig 6.0 durchgeführt. Benutzern des vorherigen stabilen 4.x-Zweigs wird empfohlen, die Migration zum 5.x-Zweig zu planen.
Wichtigste Neuerungen von Squid 5:
- Durch die Implementierung des ICAP-Protokolls (Internet Content Adaptation Protocol), das für die Integration mit externen Content-Inspektionssystemen verwendet wird, wurde Unterstützung für den Datenanhangsmechanismus (Trailer) hinzugefügt, der es Ihnen ermöglicht, zusätzliche Header mit Metadaten anzuhängen, die nach dem Nachrichtentext platziert werden Antwort (Sie können beispielsweise eine Prüfsumme und Details zu den identifizierten Problemen senden).
- Bei der Weiterleitung von Anfragen kommt der „Happy Eyeballs“-Algorithmus zum Einsatz, der die empfangene IP-Adresse sofort verwendet, ohne auf die Auflösung aller potenziell verfügbaren IPv4- und IPv6-Zieladressen zu warten. Anstatt die Einstellung „dns_v4_first“ zu berücksichtigen, um die Reihenfolge zu bestimmen, in der eine IPv4- oder IPv6-Adressfamilie verwendet wird, wird jetzt die Reihenfolge der DNS-Antworten berücksichtigt: Wenn beim Warten auf die Auflösung einer IP-Adresse zuerst eine DNS-AAAA-Antwort eintrifft, dann die resultierende Es wird eine IPv6-Adresse verwendet. Daher erfolgt das Festlegen der bevorzugten Adressfamilie jetzt auf Firewall-, DNS- oder Startup-Ebene mit der Option „--disable-ipv6“. Die vorgeschlagene Änderung beschleunigt den TCP-Verbindungsaufbau und verringert die Leistungsauswirkungen der DNS-Auflösungslatenz.
- Zur Verwendung in der Direktive „external_acl“ wurde der Handler „ext_kerberos_sid_group_acl“ für die Authentifizierung mit Gruppenüberprüfung in Active Directory mithilfe von Kerberos hinzugefügt. Zur Abfrage des Gruppennamens wird das vom OpenLDAP-Paket bereitgestellte Dienstprogramm ldapsearch verwendet.
- Die Unterstützung für das Berkeley DB-Format wurde aufgrund von Lizenzproblemen eingestellt. Der Berkeley DB 5.x-Zweig wird seit mehreren Jahren nicht mehr gewartet und weist weiterhin ungepatchte Schwachstellen auf, und der Wechsel zu neueren Versionen erlaubt keine Änderung der Lizenz auf AGPLv3, deren Anforderungen auch für Anwendungen gelten, die BerkeleyDB in Form einer Bibliothek verwenden – Squid ist unter der GPLv2 lizenziert und AGPL ist nicht mit GPLv2 kompatibel. Anstelle von Berkeley DB wurde im Projekt auf die Verwendung des TrivialDB DBMS umgestellt, das im Gegensatz zu Berkeley DB für den gleichzeitigen parallelen Zugriff auf die Datenbank optimiert ist. Die Berkeley DB-Unterstützung wurde vorerst beibehalten, es wird jedoch empfohlen, für die Handler „ext_session_acl“ und „ext_time_quota_acl“ jetzt den Speichertyp „libtdb“ anstelle von „libdb“ zu verwenden.
- Unterstützung für den CDN-Loop-HTTP-Header hinzugefügt, der in RFC 8586 definiert ist und es Ihnen ermöglicht, Schleifen bei der Verwendung von Content-Delivery-Netzwerken zu erkennen (der Header bietet Schutz vor Situationen, in denen eine Anfrage im Prozess der Umleitung zwischen CDNs aus irgendeinem Grund an das zurückkommt ursprüngliches CDN, das eine Endlosschleife bildet).
- Dem SSL-Bump-Mechanismus wurde Unterstützung für die Umleitung gefälschter (neu verschlüsselter) HTTPS-Anfragen über andere in Cache_peer angegebene Proxyserver mithilfe eines regulären Tunnels basierend auf der HTTP CONNECT-Methode hinzugefügt, der das Organisieren des Abfangens des Inhalts verschlüsselter HTTPS-Sitzungen (Übertragung) ermöglicht über HTTPS wird nicht unterstützt, da Squid TLS noch nicht innerhalb von TLS übergeben kann. SSL-Bump ermöglicht nach Erhalt der ersten abgefangenen HTTPS-Anfrage den Aufbau einer TLS-Verbindung mit dem Zielserver und den Erhalt seines Zertifikats. Danach verwendet Squid den Hostnamen des vom Server empfangenen echten Zertifikats und erstellt ein Dummy-Zertifikat, mit dem es bei der Interaktion mit dem Client den angeforderten Server imitiert, während es weiterhin die mit dem Zielserver hergestellte TLS-Verbindung zum Empfang von Daten verwendet (so). Damit die Ersetzung nicht zu Ausgabewarnungen in Browsern auf der Clientseite führt, müssen Sie Ihr Zertifikat, das zum Generieren von Dummy-Zertifikaten verwendet wird, zum Stammzertifikatspeicher hinzufügen.
- Mark_client_connection- und mark_client_pack-Anweisungen hinzugefügt, um Netfilter-Markierungen (CONNMARK) an Client-TCP-Verbindungen oder einzelne Pakete zu binden.
Im Anschluss wurden die Releases Squid 5.2 und Squid 4.17 veröffentlicht, in denen folgende Schwachstellen behoben wurden:
- CVE-2021-28116 – Bei der Verarbeitung von mit WCCPv2 erstellten Nachrichten sind Informationen durchgesickert. Die Sicherheitslücke ermöglicht es einem Angreifer, die Liste bekannter WCCP-Router zu beschädigen und den Proxy-Client-Verkehr auf deren Host umzuleiten. Das Problem tritt nur in Konfigurationen mit aktivierter WCCPv2-Unterstützung auf und wenn es möglich ist, die IP-Adresse des Routers zu fälschen.
- CVE-2021-41611 – Bei der Validierung von TLS-Zertifikaten ist ein Fehler aufgetreten, der den Zugriff mit nicht vertrauenswürdigen Zertifikaten ermöglicht.
Source: opennet.ru