0

Linux環境で次のポリシー/スキームに基づいて何らかのSSLサーバーを作成できるかどうか疑問に思っています。

（1）最初のリクエストは、親サーバープロセスで着信する必要があります。SSL接続を確立し、リクエストの最初の解析も処理した後、リクエスト（ソケット）はリクエスト処理プロセスに転送され、さらに処理が行われます。

（2）リクエスト処理プロセスは、事前に実行する必要があるものになります。この意味では、ここではfork-exec-pipeベースのスキームは使用しません。

（3）親サーバープロセスと要求処理プロセス間の通信については、sendmsg（）-SCM_RIGHTS手法を使用して、開いたソケット記述子を親サーバープロセスから要求処理プロセスにコピーするために、いくつかのIPCが確立されています。

（4）SSL機能に関しては、OpenSSL（libssl）を使用することになっています。

（5）リクエスト処理では、親サーバープロセスの共有ソケット記述子を利用して、新しいSSLソケットを作成することになっています。

重要なのは、サーバーとリクエスト処理プロセスの間でデータを転送するパフォーマンスを無駄にしたくないということです。また、リクエストごとにリクエスト処理プロセスを生成したくありません。そのため、事前にリクエスト処理プロセスを作成したいと思います。

私がここで作ろうとしていることがあなたにとって意味があるかどうかはよくわかりませんが、上記のアプローチが実行可能かどうかについて、誰かが私にヒントを教えていただければ幸いです。

4

1 に答える 1

1

何を探しているのか、特にSSL暗号化/復号化をどこで実行したいのかが明確ではありません。

リクエストハンドラプロセス内で暗号化/復号化を実行しますか？
それはより可能性の高い解釈のようです。ただし、マスタープロセスでリクエストの解析を行うことについて話します。マスタープロセスで解析されたデータはすでにSSLセッションの一部ですか？その場合、暗号化されたデータにアクセスするには、マスタープロセスでSSLハンドシェイク（初期化とキー交換）を実行する必要があります。その後、元のソケットを別のプロセスに渡すと、親プロセスのSSL状態にアクセスできなくなるため、親が中断したところから復号化を続行できなくなります。クリーンな接続であるかのようにソケットでSSLを再初期化しようとした場合、クライアントはおそらく（正しく）接続の途中での一方的なハンドシェイクをプロトコルエラーとして扱い、接続を終了します。そうでない場合は、再初期化を強制する要求処理プロセスではなく、クライアントのネットワークトラフィックを悪意を持ってリダイレクトする攻撃者である可能性があるため、セキュリティホールが発生します。一般に、初期化されたSSLセッションを、OpenSSLの完全な内部状態（交換されたキー、一部のシーケンス番号など）を通知せずに別のプロセスに渡すことはできません。これは、不可能ではないにしても難しいことです。

親プロセスでSSLセッションに触れる必要がなく、実際のSSLセッションが開始する前に来る暗号化されていないデータのみを解析する場合（たとえば、IMAPのSTARTTLSコマンドに類似）、アイデアは問題なく機能します。SSL交換を開始する必要があるところまで読んでから、SCM_RIGHTSを使用してソケットをバックエンドプロセスに渡します（たとえば、cmsg（3）またはこのサイトの例を参照）。あなたのために仕事をするライブラリ、すなわちlibancillaryもあります。

または、マスタープロセスがリクエストハンドラープロセスに対してSSL暗号化/復号化を実行することを期待していますか？
その場合、元のソケットをリクエストハンドラプロセスに渡すことは意味がありません。リクエストハンドラプロセスから取得するのは暗号化されたデータだけだからです。シナリオでは、バックエンドプロセスへの新しい接続を開く必要があります。これは、バックエンドプロセスが異なるデータ（復号化）を伝送するためです。次に、マスタープロセスは、暗号化されたデータをネットワークソケットから読み取り、復号化して、結果をリクエストハンドラーの新しいソケットに書き込みます。同様に他の方向に。

注意：リクエスト処理プロセスでSSLをまったく気にしないようにしたい場合は、ループバックインターフェイスでリッスンし、スタッドなどを使用してSSL/TLSのダーティな作業を行うことをお勧めします。

つまり、上記のいずれかを選択する必要があります。両方を同時に行うことはできません。

于 2012-06-25T17:16:14.640 に答える