web-dev-qa-db-ja.com

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

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

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

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

emailsecurityhttps
19
Amelio Vazquez-Reina

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

正しい。 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に基づいており、自由に使用できます。オープンソースの実装は GnuPG （ Windowsの場合 、 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