Squid può essere utilizzato come "proxy di terminazione TLS" per crittografare le connessioni TCP utilizzando i certificati client?

Astratto

Ho bisogno di una connessione TCP crittografata da più client a una singola porta su Internet. Questo può essere realizzato con Squid?

Situazione concreta

Nella nostra azienda utilizziamo una soluzione di monitoraggio e gestione dei client accessibile tramite LAN e VPN. Ora dovrebbe essere accessibile da notebook esterni che non utilizzano la VPN aziendale . La comunicazione deve essere crittografata (TLS). L'autenticazione client deve utilizzare i certificati client. La comunicazione viene avviata dai client e utilizza una singola porta TCP.

Risultati delle mie indagini

NGINX Plus sembra offrire questa funzione ma il nostro amministratore preferisce i calamari o gli apache. Nel wiki di calamari ho scoperto che: Caratteristica: HTTPS (HTTP Secure o HTTP over SSL / TLS) in cui è menzionata la crittografia TCP. Ma ho anche trovato questo avvertimento:

È importante notare che i protocolli passati attraverso CONNECT non si limitano a quelli normalmente gestiti da Squid. Letteralmente tutto ciò che utilizza una connessione TCP a due vie può essere passato attraverso un tunnel CONNECT. Questo è il motivo per cui gli ACL predefiniti di Squid iniziano con deny CONNECT! SSL_Ports e perché è necessario disporre di un'ottima ragione per posizionare qualsiasi tipo di regola di consenso al di sopra di essi.

Domanda simile

Questa domanda Crittografa la connessione client con proxy squid forward tramite SSL è simlar, ma non tratta i proxy inversi / i proxy di terminazione TLS.

Quello che devo sapere

Ho solo conoscenze di base su tali tecnologie e il nostro amministratore mi ha chiesto fattibilità generale.

• Squid può essere utilizzato per salvare la crittografia delle connessioni TCP?
• Questo può essere realizzato utilizzando l'autenticazione con certificati client?
• O dovrebbe essere usato solo per le connessioni HTTPS?

Forse al tuo amministratore non piace NGINX Plusperché non è open source e accetterebbe un altro prodotto open source ben mantenuto. Quindi chiedigli di guardare lo stunnel . È progettato esattamente per le tue esigenze.

Citando un esempio di stunnel su wikipedia (per SMTP, ma questo si adatterebbe anche alle tue esigenze):

Ad esempio, si potrebbe usare lo stunnel per fornire una connessione SSL sicura a un server di posta SMTP non compatibile con SSL. Supponiamo che il server SMTP si aspetti connessioni TCP sulla porta 25. Uno configurerebbe lo stunnel per mappare la porta SSL 465 sulla porta non SSL 25. Un client di posta si connette via SSL alla porta 465. Il traffico di rete dal client passa inizialmente su SSL allo stunnel applicazione, che crittografa / decodifica in modo trasparente il traffico e inoltra il traffico non protetto alla porta 25 in locale. Il server di posta vede un client di posta non SSL.

Il processo di stunnel potrebbe essere in esecuzione sullo stesso o su un server diverso dall'applicazione di posta non protetta; tuttavia, entrambe le macchine in genere si trovano dietro un firewall su una rete interna sicura (in modo che un intruso non possa stabilire la propria connessione non protetta direttamente alla porta 25).

CONNECT viene utilizzato solo dai client HTTP a un proxy HTTP per stabilire un tunnel attraverso il proxy. Non esiste nemmeno uno schema in HTTP per una connessione crittografata a un proxy HTTP.

Sospetto che un proxy HTTP non sia quello che stai cercando qui.

Non so se Squid supporti i plug-in TCP con TLS e certificati client, ma WinGate lo fa. Ha anche la possibilità di verificare UserPrincipalName nel certificato in un Active Directory.

Disclaimer: lavoro per Qbik che sono gli autori di WinGate.