web-dev-qa-db-ja.com

秘密鍵が自分で生成されている間に、自己署名証明書でMiTM攻撃がどのように実行されたのですか？

MongoDBで、クライアントとサーバー間のデータ転送を暗号化するSSL/TLS機能を有効にしました。しかし、私がやったことは、Linuxでopensslを使用して自己署名証明書を生成することです。

問題は、私が秘密鍵を所有していて、他の誰も持っていないときに、誰かが中間者攻撃を実行できる方法です。 CAから購入したときにMiTMを実行できないのはなぜですか？

私のMongoDB接続の実装は次のように簡単です。

pymongo.MongoClient('172.15.141.190:27017', ssl=True, ssl_crlfile='ANY_KEY.pem')

そしてmongoDB configは：

net:   
    port: 27017   
    bindIp: 0.0.0.0   
    ssl:
        mode: preferSSL
        PEMKeyFile: /etc/ssl/mongodb.pem
tlsman-in-the-middleopensslmongodb
1
ALH

TL; DR：自己署名証明書の使用はMITMが可能であることを意味せず、パブリックCAが発行した証明書の使用はMITMが不可能であることを意味しません。ただし、自己署名証明書を使用するクライアントは、これらを間違った方法で処理することが多いため、自己署名証明書を使用するとMITMが可能になる可能性が高くなります。

自己署名証明書を使用すると、一般的にMITMは許可されません。また、パブリックCAによって発行された証明書を使用しても、一般的にMITMからは保護されません。秘密鍵を秘密に保つこととは別に、MITM攻撃に対する重要な保護は、サーバーで使用される証明書の種類ではなく、クライアントでこの証明書がどのようにチェックされるか、つまりサーバーが証明書を使用して適切に認証されるかどうかです。

パブリックCAによって署名された証明書を使用してサーバーを認証する確立された方法は、証明書のサブジェクト、信頼チェーン、有効期限などをチェックすることです-参照 SSL証明書フレームワーク101：ブラウザは実際にサーバー証明書を指定しましたか？ 詳細。ただし、クライアントがこのチェックを行わない場合、またはこれらのチェックを適切に行わない場合、パス内の攻撃者は代わりに独自の証明書を提供する可能性があり、クライアントはそれに気づきません。以前は、このような種類のエラーは、無知またはバグが原因で発生しました。たとえば、証明書をまったくチェックしない、サブジェクトを検証しない、基本的な制約をチェックしないなどです。

自己署名証明書を使用すると、サーバーの適切な認証も実行できます。クライアントが予期する証明書（またはその公開鍵、またはそのハッシュ...）を知っている場合、クライアントは配信された証明書が予期したものと一致することを前もって確認できます。 1。この種の検証は、実際には多くのユースケースで適切に行われます。しかし、他の多くの場合、それは正しく行われません。特定の自己署名証明書ではなく、自己署名証明書を期待する場合、クライアントがすべての証明書チェックを完全に無効にすることは珍しくありません。このような壊れたクライアントでは、攻撃者が任意の証明書を使用するだけでクライアントはそれを受け入れるため、MITMは簡単です。

4
Steffen Ullrich

中間者攻撃は、サーバーとの接続を終了し、クライアントとの2番目の接続を確立することにより、秘密鍵を知らなくても可能です。

これが実際に可能かどうかは、秘密鍵とは関係なく、対応する公開鍵の信頼がクライアント内でどのように管理されるかです。

CAから証明書を取得すると、信頼できるTrust Ankerが使用されるため、「自己署名証明書を信頼する」よりもセキュリティが向上する可能性がありますが、実際の自己署名証明書の信頼を制限すると、セキュリティがさらに向上します。

ただし、他の誰かが使用した鍵生成で素数を使用した可能性があります。その場合、キーは簡単な算術を実行することで簡単に取得できます。

2
Tobi Nary