Gmail、yahoo、hotmailのパブリックウェブメールサービスからメールが送信されるとどうなりますか?
私は電子メールプロトコルを詳しく理解していませんが、私の知る限り、電子メールトラフィックは暗号化されておらず、メッセージは宛先サーバーに到達する前に(プレーンテキストで)多くのメールサーバーに渡されます。しかし、これは最近他の人々から質問されました。彼らの見解では、大手プロバイダーの1つが使用されている場合、電子メールメッセージは暗号化され、セキュリティについて心配する必要はありません。
彼らがこれについて正しく、適度に安全な電子メールであるかどうか知っていますか?ありがとうございました!
2つのメールサーバー間のSMTPセッションは暗号化できますが、ifのみがそれをサポートし、if両端で使用することを選択します。したがって、Gmailからexample.netにメールを送信する場合、example.netが準備ができて喜んでいる場合にのみ、Googleは暗号化できます。このため、トランスポート層で電子メールが中程度に安全であることさえ信頼できません。 (安全なエンドツーエンドの唯一の方法は、S/MIMEまたはPGPを使用してメールを暗号化することですが、メールを交換する相手もメールサーバーと同じように船上にいる必要があります)。
大きな3つが日和見的なSTARTTLSを実行しているかどうかについては、その証拠は見たことがありませんが、以前よりもメールサーバーログの読み取りに費やす時間は少なくなっています。そうである場合でも、それらはまだすべてのSMTP接続の半分にすぎず、暗号化の使用を保証できません。
私は、gmail.com、yahoo.com、hotmail.comのテスト済みMXホストをバナーで表示しています。 STARTTLSをアドバタイズするのはGmailだけです。つまり、相手が望んだ場合、GmailだけがSMTPセッションを暗号化してくれます。
私は自分が所有するサーバーにメールを送信し、回線を監視することにより、Gmailのアウトバウンドをテストしました。 STARTTLSが提供されている場合、Googleは実際にSTARTTLSを利用し、Gmailユーザーがメールを送信するときにSMTPトランザクションを暗号化します。 Googleへの小道具。
「送信」メール暗号化に関する限り、Google 1、Yahoo 0、Microsoft 0。
以下のコメントのとおり、これらを自分でテストする場合、それは非常に簡単です。
このような:
$ Host -t mx yahoo.com
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25
Trying 66.196.118.35...
Connected to mta5.am0.yahoodns.net.
Escape character is '^]'.
220 mta1315.mail.bf1.yahoo.com ESMTP YSmtpProxy service ready
ehlo myhost.linode.com
250-mta1315.mail.bf1.yahoo.com
250-8BITMIME
250-SIZE 41943040
250 PIPELINING
quit
221 mta1315.mail.bf1.yahoo.com
Connection closed by foreign Host.
$
ちなみに、Yahooはすぐに接続しないと接続を切断します。入力に時間がかかりすぎたため、ehloをカットアンドペーストする必要がありました。
更なる更新:
2014年1月の時点で、Yahooは現在暗号化を行っています-私は(上記のように)テストして検証しました。ただし、 The Register と Computerworld の両方で、SSL設定のイントラケース(Perfect Forward Secrecyなど)により、Yahooによって実装された多くのことが望まれることが報告されています。
さらに更新:
Googleは現在、SMTP暗号化データを Transparency Report Safer Email section に含めています。他のユーザーが暗号化する意思があるかどうかについてデータを共有しているため、上位の数値を確認したり、個々のドメインをクエリしたりできます。
補遺:
@SlashNetworkは、メールを交換する前にTLSをネゴシエートすることをrequireにメールサーバーを構成することが可能であることを指摘しています。これは本当ですが、引用 Postfixドキュメント :
"smtpd_tls_security_level = encrypt"を設定することにより、Postfix SMTPサーバーがSTARTTLSをアナウンスし、TLS暗号化なしのメールを受け入れないように、TLSの使用を強制できます。 RFC 2487によれば、これは公的に参照されているPostfix SMTPサーバーの場合には適用してはなりません。このオプションはデフォルトでオフになっており、ほとんど使用されません。
現在、世界はRFCに違反する実装でいっぱいですが、この種のこと(たとえば、ポストマスターへのバウンスやメールの受け入れなどのルーチンに必要な機能を破壊する可能性があるもの)は、おそらく否定的な結果をもたらす可能性が高くなります。
メールゲートウェイがよく許可するより良いソリューションは、 ドメインごとのポリシーベースのTLS要件 を課すことです。たとえば、通常、「example.comと通信するときにEntrustによって署名された有効な証明書を使用してTLSを要求する」と言うことができます。これは通常、同じ親会社の一部であるがインフラストラクチャが異なる(買収:と考える)組織やビジネス関係を持つ組織(ACME、Inc.とアウトソーシングされたサポートコールセンター会社と考える)の間に実装されます。これには、気になるメールの特定のサブセットが確実に暗号化されるという利点がありますが、SMTPメールのオープン(デフォルトでは誰からでも受け入れられる)アーキテクチャは破られません。
補遺++
Googleは 読者へのメールパスがある場合、Gmailはセキュリティに関する情報をパーコレートします を発表しました。したがって、これらの舞台裏の暗号化手順は、もう少しユーザーに通知されます。
(おそらくまだ証明書の出所については気にしません。ビットの暗号化の単なる指標です)。
チェーンには3つのポイントを考慮する必要があります。メールサーバー間の転送(Googleとexample.orgなど)、メールサーバーとクライアント間の転送、およびメールサーバー自体です。
メールサーバー間のトラフィックは暗号化される場合とされない場合があります。あなたはそれに頼るべきではありません、そして私の知る限り、クライアントからそれを強制する方法はありません。
クライアントとメールサーバー間のトラフィックは暗号化されている場合とされていない場合があります。 SSLを介して接続する場合(WebインターフェイスまたはSMTPを介して)、チェーンの最後は安全ですが、受信者については何も言えません。逆に、受信者であれば安全にメールを取得できますが、送信者(またはCC/BCCの誰か)が同じことを行わないと、リークが発生します。
そして最後に、メールサーバー自体があります。誰かがハッキングしたり、ソーシャルエンジニアリングを利用したりして、メールサーバーが暗号化されていないコンテンツを保存している場合は、不運なことになります。
TL; DR:チェーン全体(クライアントと関連するすべてのメールサーバーの両方)を制御しない限り、これは事実上決してあり得ないことですが、信頼できるセキュリティで電子メールを送信する唯一の方法は、PGPなどを使用してローカルで暗号化および復号化することです。
ここには2つの異なる質問があります。
gownfawrは(1)をうまく処理しています。
Gmail はデフォルトで(2)を暗号化するため、メールを表示する場合、デフォルトではHTTPSを介して行われるため、スヌーパーはGmailがブラウザにメールを送信するのを監視できません。他の人はまだスイートをフォローしていないと思います。 (完全な開示、私はGoogleで働いています)。
Gmailは、デフォルトで[常に使用する
https
]設定を使用するように設定されています...
"ウェブメールをより安全にする" には、多数の大規模なウェブメールプロバイダーのメールボックスのプレーンテキスト読み取りを回避するための手順がありますが、最新のものであることを保証できません。
SMTPサーバーのSTARTTLS構成のテスト に記載されているWebサイトを使用して、自分でテストできます。必ず受信と送信の両方をテストしてください。