web-dev-qa-db-ja.com

IRCクライアントからBitlbeeへ-エンドツーエンド暗号化？

私はBitlbeeの初心者で、libpurpleと一緒に使用してすべてのメッセージングを集約しています。とてもかっこいいですが、セキュリティ上の懸念がいくつかあります。それを明確にしておきたいと思います。

IRCクライアント（emacsでweechat.elを使用しています）からローカルのBitlbeeゲートウェイに接続する場合、Bitlbeeのサポートがないため、情報をエンドツーエンドで暗号化しておくことができないようですクライアントSSLの場合？

これは、情報がクリアテキストで送信されることを意味します。

weechat.el --[〜＃〜] ssl [〜＃〜]-> WeeChat（Relay）--[〜＃〜] plain [〜＃〜] -> Bitlbee --[〜＃〜] ssl [〜＃〜]-> |ファイアウォール| -> Skype/Facebook

私が見つけることができる唯一のアドバイスは、stunnelを使用して外部ネットワークからの接続を保護することに関するものです。良いアドバイスですが、これはローカルでは役に立ちません。stunnelは最終的にはセキュリティで保護されていない接続を介してbitlbeeと通信するため、ローカルのstunnelを使用するのは確かに時間の無駄ですか？

安全でないローカルホスト接続を持つことは比較的リスクが低いことを理解していますが、サーバーへのルートアクセス権を持つ誰かが、クライアント上のユーザーの識別と送信されたメッセージを技術的にloインターフェイスを介して盗聴できることを意味しますか？

理想的な世界では、この情報はどの接続でもクリアテキストで表示されることはありません。

私が持っているいくつかの質問

クライアントからBitlbeeにエンドツーエンドのSSL暗号化を提供することは可能ですか？

そうでない場合は、クライアントとサーバーを同じサーバー上に配置する（またはstunnelを使用する）以外にどのような手順をお勧めしますか？明らかに、ポート6667ですべての着信トラフィックをブロックできますが、他に何かありますか？

ローカルホスト接続でのパケットスニッフィングの実際のリスクを誰かが明らかにできますか？

securityssllocalhostircweechat
1
Phil

クライアントからBitlbeeにエンドツーエンドのSSL暗号化を提供することは可能ですか？

いいえ、BitlbeeはサーバーSSL/TLSをサポートしていません。

良いアドバイスですが、これはローカルでは役に立ちません。stunnelは最終的にはセキュリティで保護されていない接続を介してbitlbeeと通信するため、ローカルのstunnelを持つことは確かに時間の無駄ですか？

Stunnelは、クライアントと同じホストではなく、Bitlbeeと同じホスト上で実行されるという考え方です。

ローカルホスト接続でのパケットスニッフィングの実際のリスクを誰かが明らかにできますか？

Linuxおよび他のほとんどのUnixライクなオペレーティングシステムでは、これはroot、つまりサーバーの管理者のみが利用できます。 rootを信頼しないと、サーバーを信頼できません。

3
user1686