Como lidar com conexões http criptografadas e não criptografadas através de uma única porta

Por favor, dê uma olhada no diagrama a seguir.

Como isso deve funcionar?

• Quando um controle remoto solicita http: // myhost.com:8080/*, a solicitação deve ser encaminhada ao servidor http que escuta na porta 8008 da interface de loopback. Esta é a parte fácil.

• Quando um usuário remoto solicita http: // myhost.com:8080/specialurl ...

  • O programa que atua como um gateway no nível do aplicativo deve poder atualizar a conexão para uma sessão criptografada ( sem alterar as portas )

  • Após estabelecer uma sessão criptografada com o navegador remoto, ele deve encaminhar a solicitação ao programa C que escuta na porta 8000 da interface de loopback

Minhas perguntas são :

1. Você já implantou uma solução como esta em um ambiente de produção? Se você tem...
2. Qual produto você usou para atuar como um gateway de aplicativo?
3. Você poderia fornecer um exemplo de configuração?

Restrições rígidas :

• Eu não tenho controle sobre o firewall , e a única porta pela qual posso obter tráfego externo no servidor interno é 8080. O número da porta é irrelevante, o fato é que existe apenas uma porta aberta no nível do firewall que encaminha as entradas tráfego para o servidor interno.
• O servidor interno deve estar executando o Linux (atualmente está executando o Debian Lenny)
• Os usuários remotos não precisam de nada além de um navegador da Web atual e uma conexão à Internet para acessar este servidor. Isso significa que o encaminhamento de porta reversa através do SSH não é uma opção aqui.
• Preciso de um produto que tenha sido testado em produção e que possa ser prontamente implantado. Eu não estou olhando para desenvolver meu próprio gateway de aplicativo (se fosse esse o caso, acho que eu faria essa pergunta no Stack Overflow em vez de fazê-lo na falha do servidor).

Restrições suaves :

• Gostaria de evitar colocar o Apache como um gateway de aplicativo (embora eu esteja disposto a fazer isso se for a única opção possível)
• Se possível, o gateway de aplicativo deve ser um produto de software de código aberto maduro.

Produtos testados até os gateways de aplicativos (sem sucesso)

• nginx
• lighttpd
• libra

RFCs relevantes

• RFC2817 (... explica como usar o mecanismo de atualização no HTTP / 1.1 para iniciar o Transport Layer Security (TLS) em uma conexão TCP existente. Isso permite que o tráfego HTTP não seguro e protegido compartilhe a mesma porta conhecida ...)
• RFC2818 (... descreve como usar o TLS para proteger conexões HTTP pela Internet. A prática atual é colocar o HTTP sobre SSL (o antecessor do TLS), distinguindo tráfego protegido de tráfego inseguro pelo uso de uma porta de servidor diferente ... )

Uma porta para governar todos eles, mostra que alguém o implementou no mundo java.

Você já implantou essa solução em um ambiente de produção?

Eu não tenho - nem recomendaria que isso fosse feito. Como consultor, tento incentivar meus clientes a usar tecnologias padronizadas e comprovadas. Nenhum sistema parece implementar adequadamente essas RFCs, exceto em casos extremos - e isso não seria algo que eu gostaria de sugerir ou apoiar.

O Apache não irá ajudá-lo aqui. Ele só pode escutar conexões HTTP ou HTTPS (não as duas) em qualquer porta.

Até onde eu sei, não existe um "produto maduro" que implemente essa funcionalidade. Peça ao administrador da rede que faça um outro furo no firewall ou configure um túnel VPN ou SSH para um ponto de extremidade externo onde você pode configurar várias portas de escuta.