¿Servidor de envoltura de socket TLS / agente de reenvío?

1

Una opción que suelen usar las organizaciones para reenviar una conexión TCP de texto sin formato a través de la red es el reenvío de puertos local y remoto SSH. SSH une un puerto localmente y reenvía todo el tráfico a la máquina remota a través de SSH.

Esta es una gran solución por varias razones, a saber, que obtiene el cifrado y la autenticidad del mensaje, y también tiene una garantía de autorización en que el usuario debe tener acceso SSH a la máquina (y root si el el puerto está por debajo de 1024).

Sin embargo, en el caso de querer el cifrado de mensajes y la autenticidad sin querer autenticarse, no estoy seguro de que haya otra solución existente a la mano.

Lo que pude imaginar, sin embargo, es una configuración de servidor / agente que envolvería TLS y haría el reenvío de puertos cuando fuera necesario. Diga que necesito ejecutar Redis a través de Internet (por qué está fuera del punto, si pregunta por qué, solicite otro servicio que se ajuste mejor a su imaginación). Una solución decente sería ejecutar un proceso en el servidor Redis que se uniera a un puerto determinado y actuara como un proxy TLS. Deberá ejecutar un protocolo de enlace TLS completo para conectarse y transferir datos a este proxy.

La segunda mitad de la ecuación sería ejecutar algo del lado del cliente en los servidores que necesitan conectarse a Redis. Esto volvería a escuchar en un puerto local, pero reenviaría el tráfico a través de TLS al proxy TLS mencionado anteriormente.

¿Existe tal tecnología? Me gustaría la opción eventual de usar certificados SSL del lado del cliente para la autenticación, pero simplemente actualizar a TLS sobre texto sin formato es un gran beneficio en mi opinión.

    
pregunta Naftuli Kay 21.09.2015 - 22:08
fuente

2 respuestas

1

Puede que desee echar un vistazo a stunnel , que proporciona túneles con tecnología SSL. Dependiendo de cómo lo configure, puede proporcionar lo que busca.

Tenga cuidado de realizar el cifrado debido a posibles atacantes, y los atacantes pueden convertirse en activos , es decir, intentar alterar los datos en tránsito o enmascararse como un servidor o cliente genuino. Si no hay autenticación de cliente, el servidor no puede estar seguro de con quién está hablando. Si configura stunnel en el lado del servidor para usar un certificado autofirmado, y configura los clientes para que acepten cualquier certificado que el servidor envíe, entonces sus clientes pueden hablar con un servidor falso, y esto puede terminar con un desagradable Man-in-the-Middle .

Por lo tanto, incluso si hace que los clientes sean "anónimos" (sin autenticación del cliente), probablemente querrá autenticar el servidor, es decir, hacer que el servidor use un certificado adecuado que el cliente valida. (A menos que use el túnel solo para transmitir un protocolo que esté debidamente protegido, por ejemplo, haga SSH-within-SSL, lo cual es posible pero tal vez no sea lo que está imaginando).

    
respondido por el Thomas Pornin 21.09.2015 - 22:16
fuente
0

El Bus de servicio de Azure está diseñado para manejar este escenario exacto. Puede reenviar y asignar cualquier puerto a través de 443 al Centro de datos de Azure y consumirlo en otro host.

Es posible realizar una variedad de escenarios de autenticación, incluido el anónimo.

    
respondido por el random65537 22.10.2015 - 13:35
fuente

Lea otras preguntas en las etiquetas