単一ポートを介して暗号化および非暗号化http接続を処理する方法

次の図をご覧ください。

これはどのように機能しますか？

• リモートがhttp：// myhost.com:8080/*を要求する場合、要求はループバックインターフェイスのポート8008で待機するhttpサーバーに転送される必要があります。これは簡単な部分です。

• リモートユーザーがhttp：// myhost.com:8080/specialurlをリクエストすると...

  • アプリケーションレベルのゲートウェイとして機能するプログラムは、暗号化されたセッションへの接続をアップグレードできる必要があります（ポートを変更せずに）

  • リモートブラウザとの暗号化されたセッションを確立した後、ループバックインターフェイスのポート8000​​でリッスンするCプログラムに要求を転送する必要があります

私の質問は：

1. このようなソリューションを運用環境に展開したことはありますか？あなたが持っている場合...
2. アプリケーションゲートウェイとして機能するためにどの製品を使用しましたか？
3. 構成例を教えていただけますか？

厳しい制限：

• 私は、ファイアウォールを介してコントロールを持っていない、と私は内部サーバに外部のトラフィックを得ることができ、それを通して唯一のポートは、ポート番号が無関係である8080で、事はファイアウォールレベルでのみ1ポートのオープンがあることである転送、着信内部サーバーへのトラフィック。
• 内部サーバーはLinuxを実行している必要があります（現在はDebian Lennyを実行しています）
• リモートユーザーは、このサーバーにアクセスするために、現在のWebブラウザーとインターネット接続しか必要ありません。つまり、SSHを介したリバースポートフォワーディングはここではオプションではありません。
• 本番環境でテストされ、簡単に展開できる製品が必要です。私は自分のアプリケーションゲートウェイを開発するつもりはありません（もしそうだった場合、サーバーフォールトではなく、スタックオーバーフローでこの質問をすることになるでしょう）。

ソフト制限：

• Apacheをアプリケーションゲートウェイとして使用しないようにしたい（それが唯一の可能な選択肢である場合は、そうするつもりですが）
• 可能であれば、アプリケーションゲートウェイは成熟したオープンソースソフトウェア製品である必要があります。

これまでにアプリケーションゲートウェイとして試した製品（成功なし）

• nginx
• lighttpd
• ポンド

関連RFC

• RFC2817（... HTTP / 1.1のアップグレードメカニズムを使用して、既存のTCP接続を介してトランスポート層セキュリティ（TLS）を開始する方法を説明します。これにより、セキュリティで保護されていないHTTPトラフィックが同じ既知のポートを共有できます ...）
• RFC2818（... は、TLSを使用してインターネット上のHTTP接続を保護する方法を説明しています。現在の慣行は、HTTP over SSL（TLSの前身）をレイヤー化して、別のサーバーポートを使用することにより、保護されたトラフィックを安全でないトラフィックから区別しています ... ）

それらすべてを支配する1つのポートは、誰かが少なくともJavaの世界でそれを実装したことを示しています。

このようなソリューションを運用環境に展開したことはありますか？

私はしていません-それを行うことを勧めるつもりもありません。私はコンサルタントとして、クライアントに標準化され実績のあるテクノロジーを使用するように働きかけています。エッジケースを除いて、これらのRFCを適切に実装しているシステムはないようです。これは、私が提案したりサポートしたりするものではありません。

Apacheはここでは役に立ちません。特定のポートでHTTPまたはHTTPS接続（両方ではない）のみをリッスンできます。

私の知る限り、この機能を実装する「成熟した製品」はありません。ネットワーク管理者にファイアウォールの別の穴を開けてもらうか、複数のリスニングポートを設定できる外部エンドポイントへのVPNまたはSSHトンネルを設定します。