Come gestire le connessioni HTTP crittografate e non crittografate tramite un'unica porta

Per favore, dai un'occhiata al seguente diagramma.

Come dovrebbe funzionare?

• Quando un telecomando richiede http: // myhost.com:8080/*, la richiesta deve essere inoltrata al server http che è in ascolto sulla porta 8008 dell'interfaccia di loopback. Questa è la parte facile.

• Quando un utente remoto richiede http: // myhost.com:8080/specialurl ...

  • Il programma che funge da gateway a livello di applicazione dovrebbe essere in grado di aggiornare la connessione a una sessione crittografata ( senza cambiare le porte )

  • Dopo aver stabilito una sessione crittografata con il browser remoto, dovrebbe inoltrare la richiesta al programma C in ascolto sulla porta 8000 dell'interfaccia di loopback

Le mie domande sono :

1. Hai mai implementato una soluzione come questa in un ambiente di produzione? Se hai...
2. Quale prodotto hai utilizzato per fungere da gateway applicazione?
3. Potresti fornire un esempio di configurazione?

Restrizioni rigide :

• Io non ho il controllo del firewall , e l'unica porta attraverso la quale posso ottenere il traffico esterno al server interno è 8080. Il numero di porta è irrilevante, la cosa è che c'è solo una porta aperta a livello di firewall che in avanti in entrata traffico al server interno.
• Il server interno deve eseguire Linux (attualmente esegue Debian Lenny)
• Gli utenti remoti non devono avere nient'altro che un browser Web corrente e una connessione Internet per accedere a questo server. Ciò significa che il port forwarding inverso tramite SSH non è un'opzione qui.
• Ho bisogno di un prodotto che è stato testato in produzione e che può essere facilmente distribuito. Non sto cercando di sviluppare il mio gateway applicazione (se così fosse, immagino che farei questa domanda su Stack Overflow invece di farla su Server Fault).

Limitazioni soft :

• Vorrei evitare di mettere Apache come gateway applicazione (anche se sono disposto a farlo se è l'unica scelta possibile)
• Se possibile, il gateway applicazione dovrebbe essere un prodotto software open source maturo.

Prodotti provati fino ai gateway applicazione (senza successo)

• nginx
• lighttpd
• libbra

RFC rilevanti

• RFC2817 (... spiega come utilizzare il meccanismo di aggiornamento in HTTP / 1.1 per avviare Transport Layer Security (TLS) su una connessione TCP esistente. Ciò consente al traffico HTTP non protetto e protetto di condividere la stessa porta ben nota ...)
• RFC2818 (... descrive come utilizzare TLS per proteggere le connessioni HTTP su Internet. La pratica corrente consiste nel sovrapporre HTTP su SSL (il predecessore di TLS), distinguendo il traffico protetto dal traffico non sicuro mediante l'uso di una porta server diversa ... )

Una porta per dominarli tutti, mostra che qualcuno l'ha almeno implementato nel mondo Java.

Hai mai implementato una soluzione del genere in un ambiente di produzione?

Non l'ho fatto, né lo consiglierei mai. Come consulente cerco di incoraggiare i miei clienti a utilizzare tecnologie standardizzate e comprovate. Nessun sistema sembra implementare correttamente quelle RFC, tranne per i casi limite - e questo non sarebbe qualcosa che vorrei suggerire o supportare.

Apache non ti aiuterà qui. Può solo ascoltare le connessioni HTTP o HTTPS (non entrambe) su una determinata porta.

Per quanto ne so, non esiste un "prodotto maturo" che implementa questa funzionalità. Chiedi al tuo amministratore di rete di colpirti con un altro buco nel firewall o impostare un tunnel VPN o SSH su un endpoint esterno in cui è possibile impostare più porte di ascolto.