XMPPは自己署名SSL証明書でどのくらい安全ですか？
転送中のメッセージを保護するだけでなく、自分も信頼する人も制御していない場所にログが記録されないようにする簡単なIMインフラストラクチャを簡単にセットアップする方法を探しています。私はドイツを拠点としており、Snowden氏によると、私のトラフィックは実際にシフトされて分析されており、私はそのことにまったく満足していません。 IMはその点で私に多くのバグを引き起こすものです。
これを必要とする人々のグループの全員のアカウントを備えた分離されたXMPPサーバーを用意し、自己署名証明書でSSLを要求することを考えています。とにかく、Raspberry PiでXMPPサーバーを実行しているので、SSLセキュリティを追加してみませんか。エラーと診断以外のログを書き込まないように構成されているため、ログの問題はすでに修正されています。問題の人々はピジンを使用する方法を知っていますが、過度に迷惑なものは彼らと一緒に飛ばないでしょう。モバイルも同様に必須ですが、Facebookはあまりにも便利です。 XMPPはそれをカバーしていると思います。
私はOTRがあまり好きではありません。Pidginプラグインは、ある程度の技術的リテラシーを必要とし、時々Pidginをクラッシュさせ、Pidginが完全にフリーズする会話（私にとって）を開始するのに10秒以上かかります。また、私が知る限り、モバイルプラットフォーム用のIM +プラグインしかなく、非常に高価です。セルフホストサーバーとSSL証明書に依存することは、考えられるすべてのプラットフォームで機能するはずです（多分でしょうか？）。クライアント側での設定は比較的簡単で、セキュリティは適切に改善されています。
問題は、それで十分安全かどうかです。少なくとも、このインフラストラクチャを介した通信をNSAデータベースから遠ざけることを目指しています。訓練を受けた専門家などによる直接的な攻撃に耐えることを目指していません。かつては電話と同じくらいプライベートなプライベートな会話があり、日常の問題として他の場所にアーカイブされて分析されていない。
もしそうなら、別の質問ですが、証明書を生成して安全にするための正確な生成方法に関する推奨事項はありますか？一部のアルゴリズムが危険にさらされている可能性があることを読みました。可能であれば、それらを回避したいと思います。ここでいくつかのスレッドを見たことがありますが、そのNSA耐性スピンでは（私が理解している）スレッドはありません。
自己署名証明書は、別のエンティティによって署名された証明書と同じくらい優れています。 Public Key Infrastructure にあるのはそれらだけではありません。最近のすべてのコンピュータには、既知の信頼されたルート証明書のリストが付属しています。これらの信頼されたルートのいずれかによって署名された証明書は、コンピューターによって自動的に信頼されます。自己署名証明書はこの信頼チェーンの一部ではないので、これらの証明書を信頼するのはあなた次第です。クライアントは通常、既知のルートにさかのぼることができない証明書を検出したときにプロンプトを表示するので、そのプロンプトを確認するのはユーザー次第です。
この問題は、このプロンプトを毎回手で確認すると、証明書の人間による検証が非常にエラーを起こしやすいため、中間の人によって非常に簡単に危険にさらされることです。したがって、最初に自己署名証明書の信頼を確立してから、クライアントにそれを処理させる必要があります。これを行う方法はクライアントとプラットフォームによって異なりますが、ほとんど/すべてのプラットフォームには、信頼できる証明書ストアに任意の証明書を追加する方法がいくつかあります。
安全性について..これも上記のとおり、脆弱性のあるソフトウェアやOSを使用しない限り、他の証明書とほぼ同じくらい安全です。 TBH、私は独自のCAを使用して、自分自身でいくつかの証明書をロールしましたが、これまでのところ問題ありません（例：サーバー証明書、ユーザー証明書、RADIUS証明書、SQUID MITM CA）。
おそらくあなたが検討することをお勧めします CAの作成 とCAまたはその中間CAを使用して各ユーザー証明書に署名することで、ユーザーが本当に信頼できるユーザーであり、接続が確立するたびに信頼する中間者。もう1つの利点は、ルート証明書を信頼するだけで、すべてのユーザーが信頼されることです。
XAMPPについてはあまり知りませんが、Forward Secrecyを実装する方法を探す必要もあります。 TLS接続では、これはDHキーを使用して処理されます（少なくとも2048ビットで安全です。通常は4096 dhparamですが、RasPiではdsaparam cuzを使用することをお勧めしますそれはより速く、dhparamと同じくらい安全であると言われています。このように、各セッションで、ハンドシェイクごとに新しいシークレットが生成され、後で証明書が侵害された場合でも、以前のメッセージを解読することはほぼ不可能です。定期的に更新される安全な暗号があるので、 cipherli.st で物事を安全に保つために使用する暗号スイートと曲線を確認することもできます。
また、8kビットのキーを生成しても、8kビットの強度が実際に得られるとは限らないため、物事を「より安全」にするために地平線を越えないでください。それは常にデバイスのエントロピーに依存します。古いDebianバージョンには、「Debianの弱いキーの脆弱性」があり、設定したビット数は関係ありません。キーは常に弱いため、システムを最新の状態に保ち、安全なOSを使用してください。個人的に信頼しています。 （私はBSDを使用して、今日、NSAがLinuxカーネルでコミットを行ったため、このコミットはLinux Distroのいくつかのセキュリティポイントに影響すると言われています。理由、私はNSAはオープンソースのコミットでも信頼していませんが、Linusの決定については判断しません）
その間、ごく少数のユーザーのために独自のPKIを管理する必要はありません。自作のopenSSL CAで十分です。しかし、クリーンにしたい場合は、 [〜＃〜] ejbca [〜＃〜] は、CAとロールされた証明書、および失効リストを管理するのにそれほど悪くありません。
OK、電話はneverプライベートだった。電話会社は常に通話をタップして録音する機能を備えています。このシステムは、法執行機関と政府のスパイ活動を早い段階で支援するように設計されています。電話は個人的なものであり、違反することはできないという考えは誤りです。
技術的知識のない人でも使いやすいシステムを構築しようとしているようですが、その場合は、独自のツールを使用するのではなく、既存のツールを使用することをお勧めします。特に、システムを使いにくくする場合に、ホイールを再発明する価値があるということで、あなたの個人的なコミュニケーションがスパイ機関にとって本当に興味があると本当に思いますか？
独自に署名した証明書は、独自のプールユーザーキーの関連付けを特に構成しない限り、証明書所有者のIDを保証しないため、優れたオプションではありません。これは、管理オーバーヘッドの負荷になります。ユーザーが複数のシステムからツールにログインする場合は、各システムの各秘密鍵をIDに関連付けるか、同じ自己署名鍵を各マシンにエクスポート、転送、インポートする必要があります。ほとんどの読み書きのできるコンピュータユーザーは、それを気にしたくありません。初心者にそれらのことをするように依頼すると、ツールが使用できなくなります。したがって、セキュリティ上の利点がなければ、事態は困難になります。