Como lidar com conexões http criptografadas e não criptografadas por meio de uma única porta

Question

Por favor, dê uma olhada no seguinte diagrama.

Como isso deve funcionar?

• Quando um remoto solicita http: // myhost.com:8080/*, o pedido deve ser encaminhado para o servidor http que escuta na porta 8008 da interface de loopback. Essa é 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 ser capaz de atualizar a conexão para uma sessão criptografada ( sem alterar as portas )

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

Minhas perguntas são :

1. Você já implantou uma solução como essa 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 eu posso obter tráfego externo para o servidor interno é 8080. O número da porta é irrelevante, o problema é que existe apenas uma porta aberta no nível do firewall que encaminha o tráfego de entrada para o servidor interno.
• O servidor interno deve estar executando o Linux (atualmente ele está executando o Debian Lenny)
• Os usuários remotos não precisam de nada além de um navegador da Web atual e de uma conexão com a Internet para acessar esse servidor. Isso significa que o redirecionamento de porta reversa por meio 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 o meu próprio gateway de aplicação (se fosse esse o caso, eu acho que eu estaria fazendo essa pergunta no Stack Overflow em vez de perguntar no Server Fault).

Restrições suaves :

• Eu 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 do aplicativo deve ser um produto de software de código aberto maduro.

Produtos testados até o momento como 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 TLS (Transport Layer Security) em uma conexão TCP existente. Isso permite que o tráfego HTTP não seguro e seguro compartilhe a mesma porta conhecida ...)
• RFC2818 (... descreve como usar o TLS para proteger conexões HTTP pela Internet. A prática atual é sobrepor o HTTP ao SSL (o predecessor do TLS), distinguindo o tráfego seguro do tráfego inseguro pelo uso de um porta do servidor diferente ...)

Answer 1

Uma porta para governá-los, mostra que alguém o implementou no mundo java.

Have you ever deployed such a solution in a production environment?

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

    

Answer 2

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

Tanto quanto sei, não há "produto maduro" que implemente essa funcionalidade. Peça ao seu administrador de rede para fazer 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.