Cómo manejar conexiones http cifradas y no cifradas a través de un solo puerto

Por favor, eche un vistazo al siguiente diagrama.

¿Cómo debería funcionar esto?

• Cuando un control remoto solicita http: // myhost.com:8080/*, la solicitud debe enviarse al servidor http que escucha en el puerto 8008 de la interfaz de bucle invertido. Esta es la parte facil.

• Cuando un usuario remoto solicita http: // myhost.com:8080/specialurl ...

  • El programa que actúa como una puerta de enlace a nivel de aplicación debería poder actualizar la conexión a una sesión cifrada ( sin cambiar los puertos )

  • Después de establecer una sesión cifrada con el navegador remoto, debe reenviar la solicitud al programa C que escucha en el puerto 8000 de la interfaz de bucle invertido

Mis preguntas son :

1. ¿Alguna vez ha implementado una solución como esta en un entorno de producción? Si usted tiene...
2. ¿Qué producto usaste para actuar como puerta de enlace de aplicaciones?
3. ¿Podría proporcionar un ejemplo de configuración?

Restricciones duras :

• No tengo control sobre el firewall , y el único puerto a través del cual puedo ingresar tráfico externo al servidor interno es 8080. El número de puerto es irrelevante, lo importante es que solo hay un puerto abierto en el nivel de firewall que reenvía los mensajes entrantes tráfico al servidor interno.
• El servidor interno debe ejecutar Linux (actualmente ejecuta Debian Lenny)
• Los usuarios remotos no deberían necesitar más que un navegador web actual y una conexión a Internet para acceder a este servidor. Esto significa que el reenvío de puerto inverso a través de SSH no es una opción aquí.
• Necesito un producto que haya sido probado en producción y que pueda implementarse fácilmente. No estoy buscando desarrollar mi propia puerta de enlace de aplicaciones (si ese fuera el caso, supongo que estaría haciendo esta pregunta en Stack Overflow en lugar de hacerlo en Server Fault).

Restricciones suaves :

• Me gustaría evitar poner Apache como una puerta de enlace de aplicaciones (aunque estoy dispuesto a hacerlo si es la única opción posible)
• Si es posible, la puerta de enlace de la aplicación debe ser un producto de software maduro y de código abierto.

Productos probados hasta ahora como puertas de enlace de aplicaciones (sin éxito)

• nginx
• lighttpd
• libra

RFC relevantes

• RFC2817 (... explica cómo utilizar el mecanismo de actualización en HTTP / 1.1 para iniciar Transport Layer Security (TLS) sobre una conexión TCP existente. Esto permite que el tráfico HTTP no seguro y seguro comparta el mismo puerto conocido ...)
• RFC2818 (... describe cómo usar TLS para proteger las conexiones HTTP a través de Internet. La práctica actual es colocar en capas HTTP sobre SSL (el predecesor de TLS), distinguiendo el tráfico seguro del tráfico inseguro mediante el uso de un puerto de servidor diferente ... )

Un puerto para gobernarlos a todos muestra que , al menos , alguien lo ha implementado en el mundo de Java.

¿Alguna vez ha implementado una solución de este tipo en un entorno de producción?

No lo he hecho, ni lo recomendaría. Como consultor, trato de alentar a mis clientes a utilizar tecnologías estandarizadas y probadas. Ningún sistema parece implementar adecuadamente esos RFC excepto en casos extremos, y eso no sería algo que quisiera sugerir o apoyar.

Apache no te ayudará aquí. Solo puede escuchar conexiones HTTP o HTTPS (no ambas) en cualquier puerto dado.

Que yo sepa, no existe un "producto maduro" que implemente esta funcionalidad. Haga que su administrador de red le haga otro agujero en el firewall o configure un túnel VPN o SSH en un punto final externo donde pueda configurar múltiples puertos de escucha.