2

クライアント認証で構成された TLS ハンドシェークでは、サーバーがクライアントの証明書を受信し、それを信頼するかどうかを選択するステップがあります (たとえば、Java では TrustManager を介して行われます)。

サーバーからの最終的な「信頼の失敗」メッセージが、クライアントが実際にその公開鍵を所有していることをサーバーが確認する前または後に送信されるかどうかを知りたいです（たとえば、クライアントの秘密でエンコードされたハンドシェイクから最初のいくつかのメッセージを受信することによって）鍵）。

私の質問の目的は、このクライアントのふりをして彼の公開鍵を使用することにより、サーバーがクライアントを信頼しているかどうかをサードパーティが確認できるかどうかを確認することです。

注: TLS が特定のセキュリティ要件を持つコンテキストで使用される場合、リスクは現実のものになります。たとえば、ピア間で TLS を使用し、連絡先リストからピアを認証する方法として TrustManager を使用する P2P アプリケーションを考えてみましょう。この連絡先リストは非公開にする必要があります。ISP は、ノードが通信する相手の IP を一覧表示し、それから TLS ハンドシェイクを開始して公開証明書を取得し、IP リストにあるノード同士を接続しようとすることができます。最終的に、ISP は非公開であるはずの連絡先リストの大部分を取得できます。

4

2 に答える 2

2

OpenSSLは、クライアント証明書メッセージでクライアント証明書を受信するとすぐに、クライアント証明書も検証します。

ただし、Eugeneが言うように、サーバーが意味のあるアラートを送信する場合は、bad_certificateすぐに送信するか、証明書の確認メッセージで署名を確認した後にのみ送信するかは問題ではありません。これは、誰かが不正な形式の署名を追加で送信した場合（たとえば、間違ったキーを使用した場合）にのみ、証明書が信頼できるかどうかを確認できなくなります。ただし、サーバーがそのように実装されている場合は、生成した秘密鍵を使用して証明書検証メッセージに署名するだけです。その後、署名が有効になり、サーバーは送信された証明書を忠実に検証し、以前と同じ情報を明らかにします。

この状況を緩和するには、対応するアラートをまったく送信しないカスタマイズされたサーバーを使用する必要がありますが、あまり目立たないものを使用する必要があります。

于 2011-07-31T13:06:44.427 に答える
2

これは実装に依存します。私たちの実装は、他の実装と同様に、すぐにエラーを送信します - ほとんどが同じことをすると思います。

ただし、証明書が有効でない場合、サーバーは特定のエラー コード (BadCertificate) を送信するため、このコードがいつ送信されても​​、攻撃者は証明書が受け入れられていないことを知ることができます。この攻撃からサーバーを保護するには、サーバーが別のエラー コードを送信する必要があり、これにより正当なクライアントが混乱します。

証明書がサーバーによって受け入れられたかどうかを検出するリスク (または不愉快な結果) は疑わしいものです。これが問題になる場合は、エラー コードを変更して、OpenSSL のカスタム バージョンまたは使用する他の SSL サーバー モジュールをビルドできます。

于 2011-07-31T10:56:31.357 に答える