Ein TLS-Forward-Proxy-Listener in Squid 6.13

Mit GnuTLS oder OpenSSL gebaut kann Squid 6.13 Forward-Proxy-Anfragen über TLS annehmen. Das schützt die Verbindung vom Client zum Proxy, ohne die separate Sitzung des HTTPS-Ziels abzufangen.

1. Beschaffen Sie ein Zertifikat für den Hostnamen, über den Clients Squid erreichen. Beschränken Sie den privaten Schlüssel auf Dienstidentitäten, die ihn benötigen.
2. Fügen Sie einen TLS-Listener mit Ihrer zugewiesenen Adresse und echten Zertifikatspfaden hinzu:

https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Behalten Sie Client-Erlaubnisliste und Zielbeschränkungen sowie die Authentifizierungsrichtlinie. Der Listener erteilt keinen Zugriff. Ein vorhandener http_port bleibt ebenfalls aktiv; entfernen oder beschränken Sie diesen älteren Listener, wenn alle Clientverbindungen TLS nutzen müssen. Ein Beschleuniger-, Interception- oder Zertifikatserzeugungsmodus ist nicht nötig.

Prüfen Sie die Konfiguration mit dem Parser, bevor Sie den vorgesehenen Dienst neu laden. Das validiert Struktur und Zertifikatsladen, nicht die Netzwerkerreichbarkeit. Senden Sie nach erfolgreichem Neuladen von einem erlaubten Client eine Anfrage über den TLS-Endpunkt:

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

Verwenden Sie den echten Proxyhostnamen und die freigegebene CA-Datei. Ein öffentlich vertrauenswürdiges Proxyzertifikat braucht möglicherweise kein eigenes Bundle. --proxy-cacert konfiguriert das Proxyvertrauen und hält die Zielprüfung getrennt; behalten Sie beide Prüfungen bei.

Prüfen Sie tatsächlichen Listener und Zertifikatsnamen und testen Sie zusätzlich eine kontrollierte, abzuweisende Quelle. Erfolgreiches Parsen allein bestätigt weder das Clientvertrauen noch die Zugriffsgrenze.