localhost-trafficを暗号化して認証しますか？

Question

同じマシンにいくつかのapp-componentsがありますが、通信する必要がある異なる言語です。そのために、localhostを介したソケット通信を使用しています。転送されたデータは機密情報です。

この通信を暗号化する必要がありますか？

つまり、攻撃者はこれを傍受するためにマシン上でコードを実行できなければならず、その場合ユーザーはとにかく負けてしまいます。

Tom Leek · Accepted Answer

暗号化は、受動的な攻撃者（回線をスパイしてデータの内容を解こうとする悪人）を阻止するために必要であり、integrity（およびその兄弟authentication）により、送信中にデータを変更するアクティブな攻撃者をブロックします。 SSLは両方を提供します。ただし、これは、攻撃者が転送中のデータを実際にスパイしたり変更したりできるコンテキストでのみ意味があります。「localhost」ネットワークを介して通信する、同じマシン上の2つのプロセスの場合、それを実行できる攻撃者は通常、「すでに勝利」しています。

OSにより詳細が異なる場合があります。ただし、セキュリティは通常、暗号化ではなくOSに依存します。たとえば、複数のユーザーがいるUnixシステムについて考えてみます。 2つのプロセスが互いに通信する場合、他のユーザーのプロセスはデータ交換を覗くことができません（攻撃者がrootであり、攻撃者が何でもできる場合を除く）。ただし、なりすましを試みる場合があります。ある時点で、コンポーネントの1つが他のコンポーネントに接続し、TCP socketsはポート番号です。マシン上で（通常のユーザーとして）自分のコードを実行できる攻撃者は、目的のコンポーネントの代わりに接続要求を受信する偽のサーバーを維持する可能性があります。これを防ぐために、クライアントは予期されたサーバーと通信することを確認する必要があります（逆も同様です）。これはSSLで実行できますしかし、より良い解決策が存在します（この場合、システムアクセス権およびgetpeereid()で保護されたパスでUnixドメインソケットを使用します）。

ローカルマシンが「クリーン」であると見なされた場合（悪意のあるコードがマシン上で実行されず、どのIDでも実行されない場合）、localhostへの接続は安全であり、特別な保護は必要ありません。マシンで悪意のある可能性があるが権限のないコードが実行される可能性がある場合（これは、1980年代後半のUnixシステムで一般的な「共有マルチユーザーマシン」モデルです）、OS機能を使用して、接続が実際に伝達されることを確認する必要があります。適切なプロセス（つまり、予期されたIDで実行されているプロセス）に。 SSLはやりすぎです。

techno · Answer

さて、2つのプログラムがローカルホストで実行されている場合、なぜネットワーク通信を使用するのですか？ Named Pipesなどの任意のIPC（プロセス間通信）を使用できます。CreateNamedPipe関数を呼び出すときに、名前付きパイプのセキュリティ記述子を指定できます。セキュリティ記述子は、名前付きパイプのクライアント側とサーバー側の両方へのアクセスを制御します。

名前付きパイプを保護する方法については、アクセス制御モデルをお読みください。 http://msdn.Microsoft.com/en-us/library/windows/desktop/aa374876（v = vs.85）.aspx または、秘密の暗号化アルゴリズムを使用することもできます両方のプロセスにわかっている場合は、シークレットをコードにハードコードできます。

kingmakerking · Answer

私が正しく理解した場合、潜在的な脅威は、悪意のあるプロセス（ローカルで実行中）がローカルで実行され、IPCを介して相互にやり取りする同じアプリの2つのコンポーネントの真ん中に侵入することです。実際、これは見過ごされている脅威モデルであり、 Man-in-the-Machine（MitMa）のようなローカルの攻撃者をだますことは、パスワードマネージャーなどのセキュリティクリティカルなソフトウェアにおいてさえ、実際の脅威です。パスワードマネージャは、デスクトップアプリを1つのコンポーネントとして、ブラウザ拡張機能をもう1つのコンポーネントとして、ローカルサーバーおよびクライアントとして実行します。 OPのアーキテクチャは同様のものを反映していると思います。

OPは、基盤となるオペレーティングシステムについては触れていません。 IPCの選択は、基盤となるOS、セキュリティ機能へのサポート、または特定のIPCメソッドに依存します。したがって、ネットワークソケット（ローカル通信に使用される）1つIPCはすべてに適合します）概念はありません。

私の意見では、IPCはネットワーク通信の場合と同じ慎重さで処理する必要があります。したがって、ネットワークソケットを使用する場合、TLS/SSLベースのアプローチを使用したくなります。 IPC通信をセキュリティで保護するために、実際のネットワーク通信で行うと、魅力的な通信になる場合があります。ただし、次の点に注意してください。

@Tom Leekが指摘したように、TLS/SSLベースのアプローチを使用する価値はありません。 IPC=コンポーネントにセキュリティを提供しますが、証明機関を含む必要なインフラストラクチャは過剰である可能性があります。ここでの目標は、IPの両端の承認だけです強力なIDにバインドするのではなく、チャネル（同じソフトウェアの2つのプロセスまたはコンポーネント）。

他のOSとIPCメソッドについては、以下の点を考慮してください。

ソフトウェアアーキテクチャでIPCチャネルを2つの関連プロセス（たとえば親子）間に確立できる場合）、 anonymous pipes を使用することをお勧めしますおよびソケットペア。これらの場合のIPCチャネルのエンドポイントは、同じプロセスによって同時に作成されるため、信頼できないプロセスは途中で。
MacOSには一意のIPC CFMessagePort のような他のOSでは利用できないメソッドがあり、IPCチャネルは個々のログインセッションに関連付けられています。つまり、別のログインOriginを持つ悪意のあるプロセスが心配である場合、1つのログインセッションからのプロセスは別のセッションと対話できないため、ここではすでに注意が払われています。
名前付きパイプは、@ technoが言及しているように、アプリがWindows固有である限り、妥当なオプションです。ただし、考慮すべき点がいくつかあります。
- 名前付きパイプは、名前付きパイプファイルシステムのルートディレクトリに配置され、システムのすべてのユーザー（ゲストを含む）がアクセスできる特別なパス\。\ pipe \にマウントされます。ソフトウェアが名前付きパイプを使用していて、特定の名前があるとします。その名前のパイプが存在しない場合は、ローカルプロセスがIPCの一端を偽装するパイプを作成できます。したがって、セキュリティ記述子は必須です。
- 最初のインスタンスの作成者は、インスタンスの最大数を決定するとともに、名前付きパイプのすべてのインスタンスへのアクセスを制御するアクセス制御リスト（DACL）を含むセキュリティ記述子を指定します。すべてのユーザーに読み取りアクセスを許可するデフォルト記述子に依存しないように注意してください。
- FILE_CREATE_PIPE_INSTANCEおよびFILE_FLAG_FIRST_PIPE_INSTANCEフラグ。前者は、同じ名前の名前付きパイプのインスタンスが既に存在する場合、FILE_CREATE_PIPE_INSTANCE pipeオブジェクトへのアクセスにより、新しいインスタンスを作成できます。一方、後者は、最初のインスタンスを作成していることを確認します。