it-swarm-ja.com

メールサーバー間のメール転送が暗号化されないことがよくあるのはなぜですか?

多くの場合、ユーザーは、安全なチャネルを使用して(たとえば、HTTPSを使用して)メールプロバイダー(Gmailなど)にアクセスするかどうかを選択できます。

ただし、私の知る限り、メールサーバーからメールサーバーへの通信に関しては、ほとんどの電子メールは依然としてプレーンテキストで転送され、暗号化されていないため、ネットワーク上の誰でもコンテンツを読むことができます。

メールがエンドツーエンドで安全に送信されることをユーザーに保証するテクノロジーはありますか?暗号化がサポートされていない場合はユーザーに知らせて、メールを引き続き配信するかどうかをユーザーに選択させてください。

19

ただし、私の知る限りでは、メールサーバー間のメール通信では、ほとんどのメールが暗号化されずにプレーンテキストで転送されるため、ネットワーク上の誰でもコンテンツを読み取ることができます。

正しい。 SMTPは、HTTPと同様に、デフォルトではプレーンテキストです。

最近、多くのメールサーバーがSMTPの [〜#〜] tls [〜#〜] (以前はSSLと呼ばれていました)をサポートしています。 (これにはGmailが含まれます。)ただし、HTTP [S]の場合と同じ問題があります。有名な CA によって発行された証明書には費用がかかり、自己署名証明書には価値がありません。1MitM攻撃 から保護するため。メールサーバーが受信者の証明書を厳密に検証する場合(Webブラウザーが行うように)、自己署名証明書または社内CAを使用しているサーバーへのメッセージの配信に失敗する可能性があります。 does n'tの場合、それが適切なサーバーと通信していて、 なりすまし ではないことを確認できません。

また、TLSはSMTPに比較的最近追加されたものであるため、受信者のメールサーバーがTLSをサポートしている場合でも、送信者のメールサーバーがサポートしていないか、デフォルトで無効になっている可能性があります。

1 (送信サーバーがDANE(TLSA)をサポートし、受信サーバーの管理者がTLSAレコードをDNSで公開することを気にしない限り、これはめったに行われず、やや面倒です。)

メールがエンドツーエンドで安全に送信されることをユーザーに保証するテクノロジーはありますか?

2つの最も一般的な電子メールセキュリティ標準:

  • OpenPGP 、信頼のWebに基づいており、自由に使用できます。オープンソースの実装は GnuPGWindowsの場合Thunderbirdの場合 )であり、元のPGPは商用に進化しました PGPデスクトップ

    Webベースの電子メールクライアントの場合、 FireGPG が考えられますくそー

  • S/MIME 、X.509インフラストラクチャに基づく。ほとんどのデスクトップクライアント(Outlook、Thunderbird、Mail.appを含む)によって実装されます。ただし、TLS/SSLと同じ権限ベースの構造のため、比較的人気がありません。署名された証明書は費用がかかり、自己署名された証明書は確実に検証できません。

どちらの場合も、encryptionは、recipientがすでにシステムを使用していて、キーペアを生成/取得している必要があります。 (signingの場合、sender'sキーペアが使用されます。通常の方法は、メッセージの署名と暗号化の両方です。)

暗号化がサポートされていないことをユーザーに知らせ、電子メールを引き続き配信するかどうかをユーザーに選択させてはどうでしょうか。

通常送信されるメッセージはqueuedであり、ユーザーもMTAも、ネクストホップがTLSをサポートしているかどうかを知ることができません。メッセージがbeing sentになるまで、その時点でユーザーに確認を求める信頼できる方法はありません。 (AFK、オフライン、スリープ、またはスクリプト/プログラムの可能性があります。メッセージを送信した場合は、できるだけ早く配信されるようにします。)

さらに、SMTPを使用すると、ネクストホップが最終的なものなのか、それともメールを別の場所に中継するだけなのかがわかりません。バックアップMXがまったく異なるネットワーク上にあることは珍しくありません。

したがって。エンドツーエンドのセキュリティは、双方がOpenPGPまたはS/MIMEを使用している場合にのみ可能です。

19
user1686

実際のメールトラフィックは多くの場合暗号化(TLS)されますが、他にもいくつかの問題があります。

  • HTMLメッセージを表示する一部のWebメールクライアントは、HTTPSを使用していても安全ではない可能性があります。たとえば、HTMLのコードとデータを明確に分離することはできません(ビジュアル要素とJavaScript->インジェクション攻撃)

    • ウェブメールは、ローカルコンピュータにダウンロードして保存する代わりに、サーバーにメールを保存します
  • すべてのステップでTLS/SSLが使用されているかどうかを知る方法はありません。非常に小さなサーバーには、適切な証明書がありません。

    • 送信者は、少なくとも安全でないチャネルを使用した電子メールの送信を受け入れるか失敗するかを指定できる必要があります
  • 電子メールは、暗号化されていないサーバーまたはサーバーによって暗号化されたサーバーに置かれます

    • あなたと受信者の間のすべてのサーバーを信頼する必要があります
  • 電子メールは任意のルートを使用して転送される可能性があり、信頼するサーバー(IPアドレス範囲、AS、国、ドメインなど)を指定することはできません。

  • 大規模な電子メールサーバーは複数の異なる証明書を使用せず、それらを頻繁に変更しない(?)

    • それらをブルートフォースにする価値がある/可能性があります(米国/英国などが試みたように?)
  • 電子メールがいつ送信されたか、および受信者に関する何か(サーバーが相互に通信する)を知っているトラフィックを追跡することによって

    • ダークネットはこれらの相関関係を隠します
  • opensslの実装は混乱していた/混乱している

    • たぶんバグがある
  • 証明書に署名する認証局を信頼する必要があります

4
Awek

彼らです。または非常に頻繁にあります。

SSL経由、または [〜#〜] tls [〜#〜]

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

または、あなたが本当に妄想的であるなら、PGPまたはGPGがあります。

2
Majenko