基本的なメールセキュリティについていくつかの仮定を行っています。全体像を確実に理解できるように、これらのポイントのいくつかを確認または明確化したいと思います。私が間違っているところを修正してください:
この質問への答え はある程度の洞察を提供しますが、私が探しているすべてを網羅していません。
これはすべて、デスクトップまたはモバイルクライアントを使用して、POPまたはIMAP経由でアクセスされる従来の電子メールサービス、およびSMTP(ウェブメールは無視)を前提としています。
メッセージを取得しているとしましょう-クライアントアプリがユーザー名とパスワードをPOPサーバーに渡し、POPサーバーが私を認証してメッセージを返信します。 SSL/TLSを使用していない場合、メッセージと資格情報を含む会話全体がプレーンテキストになります。そして、ネットワークトラフィックを監視している誰もが、すべてを傍受することができます。また、SSLを使用している場合は、パブリックネットワーク上でも、会話全体が安全です。その権利はありますか?
私の理解では、サーバーが他のユーザーのサーバーと通信する場合、従来のメッセージは安全ではありません。そのため、メッセージ自体はサーバー間の転送中に脆弱である可能性がありますが、少なくともSSLでは、私の電子メールパスワードは安全です。
私が理解している場合、PGPまたは同様のものはメッセージ自体が暗号化されていることを意味します。そのため、私と受信者の秘密鍵が安全である限り、誰もメッセージを読むことができません。でもそれは単なるメッセージですよね? IMAP/SMTP/POP接続ではありませんか?メッセージにPGPを使用していて、SMTPへの非SSL接続を使用している場合、認証のためにプレーンテキストのユーザー名とパスワードを送信し続けます。
基本的に、私はメールプロバイダーがPOP/IMAP/SMTP接続にSSL/TLSを提供することを拒否する理由を理解しようとしています-特定のプロバイダーは、電子メールは本質的に安全でないため、実際にはSSLを提供しないと言っています。あなたを保護するために何でもしてください、そして彼らは本当に安全な電子メールのためにPGPを提案します。 SSLはエンドツーエンドのメッセージ保護ではないかもしれませんが、少なくとも私の資格情報を保護し、その過程のかなりの部分(私のSMTPサーバーへ、およびPOPサーバーから受信者への仮定)の間メッセージを保護することを主張したいと思いますSSLで接続しています)。
私はそれですべてをまっすぐにしますか?
あなたの質問に答えるには:
SSL/TLSを使用して電子メールにアクセスしている場合、POPかIMAPかに関係なく、トラフィックだけを分析して電子メールのテキストを解読するのは非常に困難です。とは言っても、私が働いていた法律事務所などの一部の大企業は、私たちとインターネットの間にサーバーを置いていて、SSLを取り除いているので、答えはあなたが安全だと答える資格があります。
また、アクセスした後もメッセージが電子メールサーバーに残っている場合は、電子メールプロバイダーが賄賂を受け取ったり、強制的に引き渡したりする可能性があります。もちろん、GPGはこの問題を解決します。メールプロバイダーにPOPを介してダウンロードしたメッセージを削除するよう依頼することもできますが、メッセージを安全に削除する能力と意思があることを信頼する必要があります。
SSLを使用すると、電子メールのパスワードを使用してログインするときに、コンピューターと電子メールサーバーの間のトラフィックを傍受してパスワードを簡単に読み取ることはできません。
PGPについてのあなたの理解はほぼ正しいです。メッセージが公開鍵でエンコードされて送信された場合、秘密鍵を破った人だけがそれを読むことができます。送信者の秘密鍵は、あなた宛のメッセージをデコードするために使用できないため、無関係です。電子メールのパスワードがプレーンテキストで送信されたとしても、傍受されて、誰かがあなたの電子メールにアクセスしたり、あなたになりすまして送信したりする可能性があると完全に考えている場合。常にPGPを使用してすべてのメッセージを暗号化および署名し、他の人が同じようにした場合、これはメッセージの内容を保護します。
電子メールプロバイダーが単なる怠惰を超えてSSLを提供することを望まない理由は想像できません。最近では無料の証明書も入手できます!無料のウェブメールプロバイダーのほとんどがSSLを提供しています(Gmailなど)。それらの使用を検討しましたか?
メッセージを取得しているとしましょう-クライアントアプリがユーザー名とパスワードをPOPサーバーに渡し、POPサーバーが私を認証してメッセージを返信します。 SSL/TLSを使用していない場合、メッセージと資格情報を含む会話全体がプレーンテキストになります。
必要ではありません必要ありません。 SMTP、POP、IMAPはすべて、複数の認証メカニズムをサポートできます。その一部は暗号化されています(CRAM-MD5、GSSAPIなど)。 非プレーンテキスト認証 の下の適切なリストを参照してください。この方法では、実際のメールは安全ではありませんが、資格情報がネットワーク上で安全である可能性があります。
また、SSLを使用している場合は、パブリックネットワーク上でも、会話全体が安全です。その権利はありますか?
そうです。ただし、引用したスレッドで指摘したように、メールには多くのホップが含まれます。クライアントをメールストアサーバーに保護することはできますが、エンドツーエンドの暗号化メカニズムを使用しない限り、送信者のクライアントからメールストアにメールがたどるパスは、おそらく安全ではありません。
基本的に、メールプロバイダーがPOP/IMAP/SMTP接続用のSSL/TLSの提供を拒否する理由を理解しようとしています
彼らは安くて怠惰で、彼らが子供だったとき、誰も自転車にヘルメットを着用する必要がなかったからです。
SSLはエンドツーエンドのメッセージ保護ではないかもしれませんが、少なくとも私の資格情報を保護し、その過程のかなりの部分(私のSMTPサーバーへ、およびPOPサーバーから受信者への仮定)の間メッセージを保護することを主張したいと思いますSSLで接続しています)。
はい、特にこれらの資格情報がおそらくそのプロバイダーでのアカウントの管理など、他の何かに適している場合。
私はそれですべてをまっすぐにしますか?
本質的に、はい。
しかし、私はあなたがそれについてあなたのプロバイダーと議論するあなたの時間を浪費していることを提案します。 SSLを提供したくない場合は、別のプロバイダーを探します。それはおそらく、彼らが実際に聴く投票できる唯一の票だ。
この質問はかなりよく答えられました。ただし、送信者の送信SMTPサーバーから受信者の受信MXサーバーへの配信を確認する価値があります。多くの場合、この配信は [〜#〜] starttls [〜#〜] を使用してSMTP接続を暗号化します。 STARTTLS
を使用すると、接続はプレーンテキストで始まり、両側でサポートされていればSSL/TLS接続にアップグレードされます。ただし、SMTPおよびSTARTTLS
には、アクティブな攻撃者がMITM攻撃を実行することを可能にする固有の問題があります。詳細は この記事 を参照してください。
このスレッドで触れたように、SSLはpopサーバーとマシンの間の転送中にのみ受信したメールと、マシンとサーバーのsmtpの間の転送中にのみ送信したメールを保護します。
stryfeが述べたように、一度送信された電子メールがSMTPサーバーに到着すると、残りの転送が受信者のPOPサーバーまで安全であるという証拠はありません。受信者側でも同じことですが、受信者のマシンと電子メールサーバーの間のパスは安全ではありません。例えばpop/imapサーバーが社内にあり、ITチームが調査できるケースを考えてみます。
pGPについては数回言及しました。 PGPを試してみると、Outlook、Thunderbird、Gmail、スマートフォンのユーザーがいる企業で設定するのは簡単ではありません。 CryptoMailer( http://www.thegreenbow.com/cryptomailer )のような確かな代替手段がありますが、これはセットアップと使用が非常に簡単です。