O Squid pode ser usado como “proxy de terminação TLS” para criptografar conexões TCP usando certificados de cliente?

Question

Resumo

Eu preciso de uma conexão TCP criptografada de vários clientes para uma porta única pela Internet. Isso pode ser realizado com o Squid?

Situação concreta

Usamos uma solução de monitoramento e gerenciamento de clientes em nossa empresa, que é acessível em LAN e VPNs. Ele deve estar agora acessível a partir de notebooks externos que não usam a VPN da empresa . A comunicação deve ser criptografada (TLS). A autenticação de clientes deve usar certificados de clientes. A comunicação é iniciada pelos clientes e usa uma única porta TCP.

Resultados das minhas investigações

NGINX Plus parece oferecer esse recurso, mas nosso admin prefere o squid ou o apache. No wiki do squid eu descobri que: Recurso: HTTPS (HTTP seguro ou HTTP sobre SSL / TLS) onde a criptografia TCP é mencionada. Mas também encontrei este aviso:

It is important to notice that the protocols passed through CONNECT are not limited to the ones Squid normally handles. Quite literally anything that uses a two-way TCP connection can be passed through a CONNECT tunnel. This is why the Squid default ACLs start with deny CONNECT !SSL_Ports and why you must have a very good reason to place any type of allow rule above them.

Questão semelhante

Esta questão Criptografa a conexão do cliente com o proxy de encaminhamento do squid usando SSL é simlar, mas não trata proxies reversos / proxies de terminação TLS.

O que eu preciso saber

Eu tenho apenas conhecimento básico sobre essas tecnologias e nosso administrador me pediu uma viabilidade geral.

• O Squid pode ser usado para salvar a criptografia de conexões TCP?
• Isso pode ser realizado usando autenticação com certificados de cliente?
• Ou deve ser usado apenas para conexões HTTPS?

Answer 1

Talvez seu administrador não goste de NGINX Plus porque não é código aberto e aceitaria outro produto de código aberto bem mantido. Em seguida, peça a ele que examine o stunnel . Ele é projetado exatamente para suas necessidades.

Citando um exemplo de stunnel em wikipedia (para SMTP, mas isso se ajustaria a suas necessidades):

For example, one could use stunnel to provide a secure SSL connection to an existing non-SSL-aware SMTP mail server. Assume the SMTP server expects TCP connections on port 25. One would configure stunnel to map the SSL port 465 to non-SSL port 25. A mail client connects via SSL to port 465. Network traffic from the client initially passes over SSL to the stunnel application, which transparently encrypts/decrypts traffic and forwards unsecured traffic to port 25 locally. The mail server sees a non-SSL mail client.

The stunnel process could be running on the same or a different server from the unsecured mail application; however, both machines would typically be behind a firewall on a secure internal network (so that an intruder could not make its own unsecured connection directly to port 25).

    

Answer 2

O CONNECT é usado apenas por clientes HTTP em um proxy HTTP para estabelecer um encapsulamento por meio do proxy. Não há esquema em HTTP para uma conexão criptografada com um proxy HTTP.

Eu suspeito que um proxy HTTP não é o que você está procurando aqui.

Eu não sei se o Squid suporta plugues TCP com certificados TLS e cliente, mas o WinGate funciona. Ele também tem a capacidade de verificar o UserPrincipalName no certificado para um Active Directory.

Disclaimer: Eu trabalho para Qbik, que são os autores do WinGate.