¿Se puede usar Squid como "proxy de terminación TLS" para encriptar conexiones TCP utilizando certificados de cliente?

Resumen

Necesito una conexión TCP encriptada de varios clientes a un solo puerto a través de Internet. ¿Se puede realizar esto con Squid?

Situación concreta

Utilizamos una solución de supervisión y gestión de clientes en nuestra empresa a la que se puede acceder a través de LAN y VPN. Ahora debería ser accesible desde portátiles externos que no utilizan la VPN de la empresa . La comunicación debe estar encriptada (TLS). La autenticación de clientes debe usar certificados de clientes. La comunicación es iniciada por los clientes y utiliza un solo puerto TCP.

Resultados de mis investigaciones.

NGINX Plus parece ofrecer esta función, pero nuestro administrador prefiere calamares o apache. En el wiki de calamar encontré que: Característica: HTTPS (HTTP Secure o HTTP sobre SSL / TLS) donde se menciona el cifrado TCP. Pero también encontré esta advertencia:

Es importante notar que los protocolos pasados ​​a través de CONNECT no se limitan a los que Squid maneja normalmente. Literalmente, todo lo que utiliza una conexión TCP bidireccional se puede pasar a través de un túnel CONNECT. Esta es la razón por la cual las ACL predeterminadas de Squid comienzan con deny CONNECT! SSL_Ports y por qué debe tener una muy buena razón para colocar cualquier tipo de regla de permiso por encima de ellas.

Pregunta similar

Esta pregunta Cifrar la conexión del cliente con el proxy de squid forward usando SSL es similar, pero no trata los proxies inversos / proxies de terminación TLS.

Lo que necesito saber

Solo tengo conocimientos básicos sobre esas tecnologías y nuestro administrador me pidió viabilidad general.

• ¿Se puede usar Squid para guardar el cifrado de conexiones TCP?
• ¿Se puede lograr esto mediante la autenticación con certificados de cliente?
• ¿O debería usarse solo para conexiones HTTPS?

Tal vez a su administrador no le guste NGINX Plusporque no es de código abierto y aceptaría otro producto de código abierto bien mantenido. Luego pídale que mire a Stunnel . Está diseñado para sus necesidades exactas.

Citando un ejemplo de stunnel en wikipedia (para SMTP, pero esto se ajustaría también a sus necesidades):

Por ejemplo, uno podría usar stunnel para proporcionar una conexión SSL segura a un servidor de correo SMTP no compatible con SSL. Suponga que el servidor SMTP espera conexiones TCP en el puerto 25. Uno configuraría el stunnel para asignar el puerto SSL 465 al puerto no SSL 25. Un cliente de correo se conecta a través de SSL al puerto 465. El tráfico de red del cliente inicialmente pasa por SSL al stunnel aplicación, que encripta / desencripta de manera transparente el tráfico y reenvía el tráfico no seguro al puerto 25 localmente. El servidor de correo ve un cliente de correo no SSL.

El proceso stunnel podría ejecutarse en el mismo servidor o en un servidor diferente de la aplicación de correo no seguro; sin embargo, ambas máquinas generalmente estarían detrás de un firewall en una red interna segura (de modo que un intruso no podría hacer su propia conexión no segura directamente al puerto 25).

CONNECT solo es utilizado por clientes HTTP a un proxy HTTP para establecer un túnel a través del proxy. Tampoco hay un esquema en HTTP para una conexión cifrada a un proxy HTTP.

Sospecho que un proxy HTTP no es lo que estás buscando aquí.

No sé si Squid admite enchufes TCP con TLS y certificados de cliente, pero WinGate sí. También tiene la capacidad de verificar el UserPrincipalName en el certificado a un Active Directory.

Descargo de responsabilidad: trabajo para Qbik, que son los autores de WinGate.