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

Resumo

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

Situação concreta

Utilizamos uma solução de monitoramento e gerenciamento de clientes em nossa empresa, acessível por LAN e VPNs. Agora ele deve estar acessível em 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

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

É importante notar que os protocolos passados ​​pelo CONNECT não estão limitados aos que o Squid normalmente manipula. Quase literalmente, qualquer coisa que use uma conexão TCP bidirecional pode ser transmitida através de um túnel CONNECT. É por isso que as ACLs padrão do Squid começam com negar CONNECT! SSL_Ports e por que você deve ter um bom motivo para colocar qualquer tipo de regra de permissão acima deles.

Pergunta semelhante

Esta pergunta Criptografar a conexão do cliente com o proxy squid forward usando SSL é semelhante, mas não trata os 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 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?

Talvez seu administrador não goste, NGINX Plusporque não é de código aberto e aceitaria outro produto de código aberto bem mantido. Depois peça a ele para olhar o stunnel . Ele foi projetado exatamente para as suas necessidades.

Citando um exemplo de stunnel na wikipedia (para SMTP, mas isso seria adequado também para suas necessidades):

Por exemplo, pode-se usar stunnel para fornecer uma conexão SSL segura a um servidor de email SMTP não compatível com SSL. Suponha que o servidor SMTP espere conexões TCP na porta 25. Um configuraria o stunnel para mapear a porta SSL 465 para a porta não SSL 25. Um cliente de email se conecta via SSL à porta 465. O tráfego de rede do cliente passa inicialmente por SSL para o stunnel aplicativo, que criptografa / descriptografa de forma transparente o tráfego e encaminha o tráfego não seguro para a porta 25 localmente. O servidor de correio vê um cliente de correio não SSL.

O processo de stunnel pode estar em execução no mesmo servidor ou em um servidor diferente do aplicativo de email não seguro; no entanto, as duas máquinas normalmente ficam atrás de um firewall em uma rede interna segura (para que um invasor não possa fazer sua própria conexão não segura diretamente à porta 25).

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

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

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

Isenção de responsabilidade: trabalho para o Qbik, que é o autor do WinGate.