Diffie-Hellmanを使用してSSL証明書を検証しますか？
私は暗号化にかなり慣れていないので、助けが必要です。解決しようとしている問題があります。
私の問題は次のとおりです。
- 相互に通信するWebサーバーと（iOS）アプリがあります。
- 通信を安全にしたいので、HTTPSを使用しています。
- Webサーバーとアプリはイントラネットを介して通信しており、どちらの側もインターネットにアクセスできません。
- インターネットに接続されていないため、Webサーバー上のSSL証明書は自己署名されており、CAに対して検証することはできません。
したがって、私の問題は、HTTPS接続を確立すると、証明書を検証できないために証明書を信頼できないため、MITM攻撃が発生する可能性があることです。したがって、必要なのは、CAに頼らずに証明書を検証する方法です。
私の考えは、Diffie-Hellmanを使用してアプリとWebサーバーの間に安全な接続を確立し、証明書を転送することから始めます。これにより、SSL接続が確立されているときに、証明書が正しいかどうかを確認できます。
これは機能しますか？それとも、MITMやその他の攻撃の影響を受けやすいのでしょうか。もしそうなら、他にどのように私の問題を解決できますか？
また、私の顧客はそれぞれ独自のWebサーバーを持っているため、独自の自己署名証明書を持っていることにも言及する価値があります。したがって、公開鍵をアプリに埋め込むことはできません。
私はあなたがあなたがしていることを完全に理解しているとは思わないので、私はあなたのステップを説明しようとします：
... Diffie-Hellmanを使用してアプリとWebサーバー間の安全な接続を確立することから始めます。
ピアのIDを確認しないため、これは匿名のDH接続になります。また、トラストアンカーがまだないため、そのIDを確認できません。身元を確認しないため、誰と話しているのかわからない。これは、MITM攻撃が発生する可能性があることも意味するため、この接続内で取得したデータを信頼しないでください。
...証明書を転送して、SSL接続が確立されているときに、証明書が正しいかどうかを確認できるようにします。
これは、MITM攻撃に対して開かれている信頼できない接続を使用して、将来の接続のためにトラストアンカーを転送することを意味します。取得した証明書が実際に会話したいピアの証明書であり、攻撃者の証明書ではないことを確認する方法はありません。
要約：「トラストアンカーがないため検証なし」を「実際に信頼されていないトラストアンカーに対する検証」に置き換えます。
あなたが書く：
インターネットに接続されていないため、Webサーバー上のSSL証明書は自己署名されており、CAに対して検証することはできません。
ここにはいくつかの誤解があります。証明書に関するいくつかの基本的な要素を言い換えてみましょう。
- 証明書は、取得方法によって価値を獲得したり失ったりすることはありません。証明書にとって重要なのは、誰が署名したかです。
- インターネットに接続する必要はありません。実際、これが証明書の要点です。これらは、サードパーティのシステムと通信することなく検証できる方法で、名前を公開鍵にバインドする方法です。 。証明書は意味オフラインシステムで機能します。
- 証明書は、アプリオリ既知の「トラストアンカー」（別名「ルートCA」）に関して検証されます。自己署名証明書は、独自のルートCAであると称する証明書です。
- 以前のDiffie-Hellman鍵交換を実行しても、上記のいずれにも何も変わりません。これらすべての証明書の署名はいずれも信頼を生み出しません。信頼は転送済みですが、それでもどこかで開始する必要があります。つまり、トラストアンカーです。 Diffie-Hellmanやその他の暗号化アルゴリズムを使用しても、信頼を得ることができません。
- システムがインターネットに接続されていても、何も変更されません。
あなたの場合、クライアント（iOSアプリ）が本物のサーバー（Webサーバー）と通信していることを確認できるようにする必要があります。そのための最も簡単な方法は、サーバーで自己署名証明書を使用し、アプリでその証明書のコピーをハードコーディングすることです。誤解を避けるために：certificateには公開鍵が含まれていますが、秘密鍵は含まれていません。サーバーには証明書と秘密鍵の両方があり、アプリは証明書のみを認識します。ハードコードされた証明書を使用すると、アプリは、ハードコードされた証明書で公開鍵を使用することにより、適切なサーバーと確実に通信できます。つまり、アプリは、サーバーが送信する証明書を、アプリの内臓にすでに含まれている証明書とビットごとに比較することで検証します。
やや複雑ですが、おそらくより柔軟な方法は、独自のCAを実行することです。自己署名ルートCAを作成し、対応する証明書をトラストアンカーとしてアプリにインストールします。また、そのCAでサーバーの証明書を発行（つまり署名）します。アプリは通常のX.509検証を適用します。つまり、サーバーから送信された証明書が実際にそのトラストアンカーの1つによって署名されていることを確認します。
デバイスの信頼できる証明書のリストに証明書を追加できます。 このサイト その方法の説明がありますが、基本的には、証明書を各デバイスに電子メールで送信するか、 Apple iPhone管理ツール を使用して多くのデバイスに追加できますデバイス。製品にはセットアップ手順が含まれているようです（サーバーをセットアップする必要があるため、アプリをダウンロードするだけでは不十分です）。そのため、それを手順に追加できます。
編集：Diffie-Hellmanは、man-in-the-middle攻撃の影響を受けやすいことに加えて、あなたの目標にはまったく適していません。 DHが行うことは、当事者が安全なチャネルを介して秘密を共有しなくても、安全でないチャネルを介して共有秘密をネゴシエートできるようにすることです。どちらの当事者も、その共有秘密が何であるかを意味のある形で制御することはできません。 DHはnot暗号化技術です。これは、アリスがボブに選択したものを送信できるようにする必要があるためです。DHが行うのは、両方に次のようなものを与えることだけです。彼らは知っていて、他の誰も知りません。 DHを実行した後に対称暗号化を適用できますが（ElGamalは基本的にそれです）、DH自体は選択した情報を転送できません。
また、DHにはMitM攻撃に対するno保護がないため、送信される情報を何らかの方法で信頼できるものにする必要があります（アプリにバンドルするかどうかは関係ありません[すべての人に同じ証明書を使用することを拒否し、DH資格情報の再利用でも同じ問題が発生します]、または署名することによって[これは文字通り一部のSSLモードの動作方法です]）。いいえ、DHはあなたが探しているものではありません。
あなたがやりたいことは、 ラージプート で述べられている「信頼の基本原則」に根本的に違反しています。第三者）"。
問題が本当に証明書を信頼していないことである場合、信頼できるストアに証明書を追加することはできません。 1つの解決策は、単一のCAを使用してすべての証明書を発行し、その証明書をすべてのデバイスに保持するか、「信頼の初期化」の時点でインストールすることです。信頼の初期化は常に最も危険な瞬間であり、次のいずれかのオプションを介してのみ実行する必要があります（電子メールは安全ではありません）。
- デバイスを信頼できる「ゾーン」に物理的に移動します。
- 両方から信頼されているサードパーティを介して（つまり、FedExで証明書を配信するか、手作業で配信します）
等.
インターネットに接続していなくても、信頼できる機関からの証明書を使用できるはずです。 get証明書（および関連する中間CA証明書）へのインターネット接続が必要ですが、購入したら、イントラネットに転送してWebサーバーにインストールできます。
唯一の潜在的な問題の原因は、クライアントがインターネット接続なしで証明書の失効ステータスを確認できないことですが、iOSは失効に到達できない場合でもSSL/TLS接続を通過させることを理解しています（ CRLまたはOCSP）サーバー。
編集：私は別の考えられる問題を考えました：クライアントは実際に会社に登録されている適切なドメイン名を使用してサーバーに到達する必要があります-「server.local」、「server.private」、またはIPアドレスはありません。会社の通常のDNSサーバーはイントラネット上で到達できませんが、一般的にイントラネット上にプライベートDNSサーバーをセットアップすることは可能であることに注意してください（実際、それらはすでに1つ持っている可能性があります）。