Kann Squid als "TLS-Terminierungs-Proxy" verwendet werden, um TCP-Verbindungen mithilfe von Client-Zertifikaten zu verschlüsseln?

Abstrakt

Ich benötige eine verschlüsselte TCP-Verbindung von mehreren Clients zu einem einzelnen Port über das Internet. Kann das mit Squid realisiert werden?

Konkrete Situation

In unserem Unternehmen verwenden wir eine Überwachungs- und Client-Management-Lösung, auf die über LAN und VPNs zugegriffen werden kann. Der Zugriff sollte jetzt über externe Notebooks erfolgen, die das Firmen-VPN nicht verwenden . Die Kommunikation muss verschlüsselt sein (TLS). Die Clientauthentifizierung muss Clientzertifikate verwenden. Die Kommunikation wird von den Clients initiiert und verwendet einen einzelnen TCP-Port.

Ergebnisse meiner Untersuchungen

NGINX Plus scheint diese Funktion zu bieten, aber unser Administrator bevorzugt Tintenfisch oder Apache. Im Squid-Wiki fand ich Folgendes: Feature: HTTPS (HTTP Secure oder HTTP über SSL / TLS), in dem die TCP-Verschlüsselung erwähnt wird. Aber ich habe auch diese Warnung gefunden:

Es ist wichtig zu beachten, dass die über CONNECT übergebenen Protokolle nicht auf die Protokolle beschränkt sind, die Squid normalerweise verarbeitet. Im wahrsten Sinne des Wortes kann alles, was eine bidirektionale TCP-Verbindung verwendet, durch einen CONNECT-Tunnel geleitet werden. Aus diesem Grund beginnen die Squid-Standard-ACLs mit "CONNECT! SSL_Ports verweigern" und Sie müssen einen sehr guten Grund haben, eine beliebige Art von Zulassungsregel darüber zu platzieren.

Ähnliche Frage

Diese Frage Die Clientverbindung mit Squid Forward Proxy mit SSL verschlüsseln ist ähnlich, behandelt jedoch keine Reverse Proxys / TLS Termination Proxys.

Was ich wissen muss

Ich habe nur Grundkenntnisse über diese Technologien und unser Administrator hat mich nach der allgemeinen Machbarkeit gefragt.

• Kann Squid zum Speichern der Verschlüsselung von TCP-Verbindungen verwendet werden?
• Kann dies durch Authentifizierung mit Client-Zertifikaten realisiert werden?
• Oder sollte es nur für HTTPS-Verbindungen verwendet werden?

Vielleicht mag Ihr Administrator es nicht, NGINX Plusweil es nicht Open Source ist und ein anderes gut gepflegtes Open Source-Produkt akzeptieren würde. Dann bitten Sie ihn, sich den Tunnel anzusehen . Es ist genau auf Ihre Bedürfnisse zugeschnitten.

Zitieren eines Stunnel-Beispiels bei Wikipedia (für SMTP, aber dies würde auch Ihren Anforderungen entsprechen):

Beispielsweise könnte man stunnel verwenden, um eine sichere SSL-Verbindung zu einem vorhandenen nicht SSL-fähigen SMTP-Mailserver bereitzustellen. Angenommen, der SMTP-Server erwartet TCP-Verbindungen an Port 25. Man würde stunnel so konfigurieren, dass der SSL-Port 465 dem Nicht-SSL-Port 25 zugeordnet wird. Ein E-Mail-Client stellt über SSL eine Verbindung zu Port 465 her. Der Netzwerkverkehr vom Client wird zunächst über SSL an den Stunnel übertragen Anwendung, die den Datenverkehr transparent verschlüsselt / entschlüsselt und ungesicherten Datenverkehr lokal an Port 25 weiterleitet. Der Mailserver sieht einen Nicht-SSL-Mail-Client.

Der Stunnel-Prozess kann auf demselben oder einem anderen Server als die ungesicherte E-Mail-Anwendung ausgeführt werden. Beide Computer befinden sich jedoch normalerweise hinter einer Firewall in einem sicheren internen Netzwerk (sodass ein Eindringling keine eigene ungesicherte Verbindung direkt zu Port 25 herstellen kann).

CONNECT wird nur von HTTP-Clients für einen HTTP-Proxy verwendet, um einen Tunnel durch den Proxy einzurichten. In HTTP gibt es auch kein Schema für eine verschlüsselte Verbindung zu einem HTTP-Proxy.

Ich vermute, dass ein HTTP-Proxy hier nicht das ist, wonach Sie suchen.

Ich weiß nicht, ob Squid TCP-Stecker mit TLS- und Client-Zertifikaten unterstützt, WinGate jedoch. Es kann auch den UserPrincipalName im Zertifikat in einem Active Directory überprüfen.

Haftungsausschluss: Ich arbeite für Qbik, die die Autoren von WinGate sind.