Stabile Version des Proxy-Servers Squid 5

Nach drei Jahren Entwicklung wird die stabile Version des Proxy-Servers Squid 5.1 vorgestellt, die bereit ist für den Einsatz in Produktionsumgebungen (die Versionen 5.0.x hatten den Status von Beta-Versionen). Nachdem die 5.x-Reihe den Status 'stabil' erreicht hat, wird es nur noch Sicherheitsupdates und Stabilitätsverbesserungen geben; kleine Optimierungen sind ebenfalls erlaubt. Die Entwicklung neuer Funktionen erfolgt in der neuen experimentellen Reihe 6.0. Nutzern der vorherigen stabilen Version 4.x wird empfohlen, den Übergang zur 5.x-Reihe zu planen.

Die wichtigsten Neuerungen in Squid 5:

• Die Implementierung des ICAP-Protokolls (Internet Content Adaptation Protocol), das zur Integration mit externen Inhaltsprüfsystemen verwendet wird, erhält Unterstützung für einen Anhang-Mechanismus (Trailer), der es ermöglicht, zusätzliche Header mit Metadaten anzuhängen, die nach dem Nachrichtentext platziert werden (zum Beispiel können Prüfziffern und Details zu gefundenen Problemen übermittelt werden).
• Beim Weiterleiten von Anfragen kommt der „Happy Eyeballs“-Algorithmus zum Einsatz, der sofort die erhaltene IP-Adresse verwendet, ohne auf die Auflösung aller potenziell verfügbaren Zieladressen IPv4 und IPv6 zu warten. Anstelle der Berücksichtigung der Konfiguration „dns_v4_first“ zur Bestimmung der Reihenfolge für die Verwendung der Adressfamilien IPv4 oder IPv6 wird jetzt die Antwortreihenfolge im DNS berücksichtigt: Wenn während der Auflösung die Antwort DNS AAAA zuerst eintrifft, wird die erhaltene IPv6-Adresse verwendet. IP-Adressen Damit erfolgt die Konfiguration der bevorzugten Adressfamilie jetzt auf Ebene der Firewall, DNS oder beim Start mit der Option „—disable-ipv6“. Die vorgeschlagene Änderung ermöglicht eine schnellere Etablierung von TCP-Verbindungen und reduziert die Auswirkungen von Verzögerungen bei der DNS-Auflösung auf die Leistung.
• Für die Verwendung in der Direktive „external_acl“ wurde der Handler „ext_kerberos_sid_group_acl“ hinzugefügt, um die Authentifizierung mit Gruppenüberprüfung in Active Directory mittels Kerberos zu ermöglichen. Für die Abfrage des Gruppennamens wird das Utility ldapsearch verwendet, das im OpenLDAP-Paket bereitgestellt wird.
• Der Support für das Berkeley DB-Datenbankformat wurde aufgrund von Lizenzproblemen für obsolet erklärt. Der Branch Berkeley DB 5.x wird seit einigen Jahren nicht mehr gepflegt und weist unbehobene Sicherheitslücken auf. Ein Umstieg auf neuere Versionen ist durch die Änderung der Lizenz auf AGPLv3, deren Anforderungen auch auf Anwendungen zutreffen, die BerkeleyDB in Form einer Bibliothek verwenden, nicht möglich — Squid wird unter der GPLv2-Lizenz bereitgestellt, und AGPL ist mit GPLv2 nicht kompatibel. Statt Berkeley DB wird das Projekt nun auf das Datenbanksystem TrivialDB umgestellt, das im Gegensatz zu Berkeley DB für gleichzeitigen parallelen Zugriff auf die Datenbank optimiert ist. Die Unterstützung für Berkeley DB bleibt vorerst bestehen, doch in den Handlern „ext_session_acl“ und „ext_time_quota_acl“ wird nun die Verwendung des Speichertypen „libtdb“ anstelle von „libdb“ empfohlen.
• Die Unterstützung für den HTTP-Header CDN-Loop, der in RFC 8586 definiert ist und dazu dient, Schleifen bei der Verwendung von Content Delivery Networks zu erkennen, wurde hinzugefügt (der Header schützt vor Situationen, in denen eine Anfrage während der Weiterleitung zwischen CDNs aus irgendeinem Grund an das ursprüngliche CDN zurückgegeben wird und somit eine unendliche Schleife entsteht).
• Im SSL-Bump-Mechanismus, der das Abfangen von Inhalten verschlüsselter HTTPS-Sitzungen ermöglicht, wurde die Unterstützung für die Umleitung von manipulierten (neu verschlüsselten) HTTPS-Anfragen über andere Proxy-Server, die in cache_peer angegeben sind, hinzugefügt. Dies erfolgt über einen regulären Tunnel basierend auf der HTTP CONNECT-Methode (die Übertragung über HTTPS wird nicht unterstützt, da Squid derzeit kein TLS innerhalb von TLS übertragen kann). SSL-Bump ermöglicht es, bei der ersten abgefangenen HTTPS-Anfrage eine TLS-Verbindung zum Zielserver herzustellen und dessen Zertifikat zu erhalten. Anschließend verwendet Squid den Hostnamen aus dem tatsächlichen vom Server erhaltenen Zertifikat und erstellt ein gefälschtes Zertifikat, mit dem der angeforderte Server bei der Interaktion mit dem Client imitiert wird. Dabei wird weiterhin die TLS-Verbindung verwendet, die mit dem Zielserver aufgebaut wurde. Um zu verhindern, dass die Manipulation Warnungen im Browser des Clients auslöst, muss das für die Generierung der gefälschten Zertifikate verwendete Zertifikat im Stammzertifikatspeicher hinzugefügt werden.
• Es wurden die Direktiven mark_client_connection und mark_client_pack hinzugefügt, um Netfilter-Marken (CONNMARK) an Client-TCP-Verbindungen oder einzelnen Paketen zu binden.

Im Anschluss wurden die Versionen Squid 5.2 und Squid 4.17 veröffentlicht, in denen mehrere Sicherheitsanfälligkeiten behoben wurden:

• CVE-2021-28116 — Informationsleck bei der Verarbeitung speziell gestalteter WCCPv2-Nachrichten. Diese Schwachstelle ermöglicht es einem Angreifer, die Liste bekannter WCCP-Router zu manipulieren und den Datenverkehr von Proxy-Server-Clients auf sein eigenes Host umzuleiten. Das Problem tritt nur in Konfigurationen mit aktivierter Unterstützung für WCCPv2 und bei der Möglichkeit des IP-Router-Spoofings auf.
• CVE-2021-41611 — Fehler bei der Überprüfung TLS-Zertifikaten, der den Zugriff mit nicht vertrauenswürdigen Zertifikaten ermöglicht.

Quelle: opennet.ru