Stabile Veröffentlichung des Proxy-Servers Squid 5

Nach drei Jahren Entwicklung wird die stabile Veröffentlichung des Proxy-Servers Squid 5.1 präsentiert, die für den Einsatz in produktiven Systemen bereit ist (die Versionen 5.0.x hatten den Status von Beta-Versionen). Nachdem der Version 5.x der Status stabil zugewiesen wurde, werden in ihr künftig nur noch Sicherheitsfehlerbehebungen und Stabilitätsprobleme vorgenommen, auch kleinere Optimierungen sind erlaubt. Die Entwicklung neuer Funktionen wird in einem neuen experimentellen Zweig 6.0 erfolgen. Benutzern der vorherigen stabilen Version 4.x wird empfohlen, den Übergang auf die Version 5.x zu planen.

Wichtigste Neuerungen in Squid 5:

• Im Implementierungsprotokoll ICAP (Internet Content Adaptation Protocol), das zur Integration mit externen Content-Überprüfungssystemen verwendet wird, wurde die Unterstützung für den Mechanismus zur Anfügung von Daten (trailer) hinzugefügt, der es ermöglicht, zusätzliche Header mit Metadaten, die nach dem Nachrichtentext eingefügt werden, an die Antwort anzuhängen (zum Beispiel kann eine Prüfziffer und Details zu ermittelten Problemen übermittelt werden).
• Beim Weiterleiten von Anfragen wird der Algorithmus „Happy Eyeballs“ verwendet, der sofort die erhaltene IP-Adresse nutzt, ohne auf die Auflösung aller potenziell verfügbaren Zieladressen IPv4 und IPv6 zu warten. Statt die Einstellung „dns_v4_first“ zur Bestimmung der Reihenfolge der Nutzung von IPv4- oder IPv6-Adressen zu berücksichtigen, wird nun die Reihenfolge der DNS-Antworten berücksichtigt: Wenn beim Warten auf die Auflösung zuerst die DNS AAAA-Antwort eintrifft, wird die erhaltene IPv6-Adresse verwendet. Damit wird die Einstellung der bevorzugten Adressfamilie nun auf der Ebene der Firewall, DNS oder beim Starten mit der Option „—disable-ipv6“ vorgenommen. Die vorgeschlagene Änderung ermöglicht eine Beschleunigung der Zeit zur Etablierung von TCP-Verbindungen und verringert den Einfluss von Verzögerungen bei der Auflösung in DNS auf die Leistung. IP-Adressen Für die Verwendung in der Direktive „external_acl“ wurde der Handler „ext_kerberos_sid_group_acl“ hinzugefügt, um die Authentifizierung mit Gruppenprüfungen in Active Directory mittels Kerberos zu unterstützen. Für die Abfrage des Gruppennamens wird das Tool ldapsearch verwendet, das im OpenLDAP-Paket bereitgestellt wird.
• Für die Verwendung in der Direktive „external_acl“ wurde der Handler „ext_kerberos_sid_group_acl“ hinzugefügt, um die Authentifizierung mit Gruppenprüfungen in Active Directory mithilfe von Kerberos durchzuführen. Zur Abfrage des Gruppennamens wird das Dienstprogramm ldapsearch verwendet, das im Paket OpenLDAP enthalten ist.
• Das Berkeley DB-Datenbankformat wurde aufgrund von Lizenzproblemen als veraltet erklärt. Der Branch Berkeley DB 5.x wird seit mehreren Jahren nicht mehr unterstützt und weist unbehobene Sicherheitsanfälligkeiten auf. Ein Upgrade auf neuere Versionen ist aufgrund der Lizenzänderung auf AGPLv3 nicht möglich, deren Anforderungen auch für Anwendungen gelten, die BerkeleyDB in Form einer Bibliothek verwenden – Squid wird unter der GPLv2-Lizenz bereitgestellt, und die AGPL ist inkompatibel mit der GPLv2. Anstelle von Berkeley DB wurde das Projekt auf die Verwendung der Datenbank TrivialDB umgestellt, die im Gegensatz zu Berkeley DB für gleichzeitigen parallelen Zugriff auf die Datenbank optimiert ist. Die Unterstützung für Berkeley DB bleibt vorerst erhalten, jedoch wird nun empfohlen, in den Handlern „ext_session_acl“ und „ext_time_quota_acl“ den Speichertyp „libtdb“ anstelle von „libdb“ zu verwenden.
• Die Unterstützung für den HTTP-Header CDN-Loop, der in RFC 8586 definiert ist und es ermöglicht, Schleifen beim Einsatz von Content Delivery Networks zu erkennen, wurde hinzugefügt (der Header bietet Schutz gegen Situationen, in denen eine Anfrage während der Umleitung zwischen CDNs aus bestimmten Gründen zurück zur ursprünglichen CDN kommt und eine endlose Schleife bildet).
• Im SSL-Bump-Mechanismus, der es ermöglicht, den Inhalt von verschlüsselten HTTPS-Sitzungen abzufangen, wurde die Unterstützung für die Umleitung von modifizierten (neu verschlüsselten) HTTPS-Anfragen über andere Proxy-Server, die in cache_peer angegeben sind, hinzugefügt, unter Verwendung eines regulären Tunnels basierend auf der HTTP CONNECT-Methode (die Übertragung über HTTPS wird nicht unterstützt, da Squid derzeit TLS innerhalb von TLS nicht übertragen kann). SSL-Bump ermöglicht es, bei der ersten abgefangenen HTTPS-Anfrage eine TLS-Verbindung zum Zielserver herzustellen und dessen Zertifikat zu erhalten. Danach verwendet Squid den Hostnamen aus dem tatsächlich von dem Server erhaltenen Zertifikat und erstellt ein gefälschtes Zertifikat, mit dem der angeforderte Server beim Austausch mit dem Client imitiert wird, während weiterhin die für die Datenerfassung verwendete TLS-Verbindung mit dem Zielserver aufrechterhalten wird (um zu vermeiden, dass die Umstellung in den Browsern auf der Clientseite Warnungen ausgibt, muss das für die Generierung der gefälschten Zertifikate verwendete Zertifikat in den Speicher der Stammzertifikate aufgenommen werden).
• Es wurden die Direktiven mark_client_connection und mark_client_pack zum Verknüpfen von Netfilter-Tags (CONNMARK) mit clientseitigen TCP-Verbindungen oder einzelnen Paketen hinzugefügt.

In unmittelbarem Anschluss wurden die Versionen Squid 5.2 und Squid 4.17 veröffentlicht, in denen Schwachstellen behoben wurden:

• CVE-2021-28116 – Informationsleck bei der Verarbeitung speziell formatierter WCCPv2-Nachrichten. Diese Schwachstelle ermöglicht es einem Angreifer, die Liste der bekannten WCCP-Router zu beschädigen und den Verkehr der Proxy-Server-Kunden auf seinen eigenen Host umzuleiten. Das Problem tritt nur in Konfigurationen auf, in denen die Unterstützung für WCCPv2 aktiviert ist und eine IP-Adressenspoofing des Routers möglich ist.
• CVE-2021-41611 – Fehler bei der Überprüfung TLS-Zertifikate, der den Zugriff unter Verwendung von nicht vertrauenswürdigen Zertifikaten ermöglicht.

Quelle: opennet.ru