☰

为什么邮件服务器之间的电子邮件传输通常不加密？

tag-icon • tag-icon email security https
为什么邮件服务器之间的电子邮件传输通常不加密？

用户通常可以选择是否使用安全的通道（例如使用HTTPS）。

然而，据我所知，当涉及到邮件服务器到邮件服务器的通信时，大多数电子邮件仍然以纯文本传输且未加密，这使得网络上的任何人都可以阅读其内容。

是否有任何技术可以保证用户的电子邮件从端到端安全地发送？为什么不让用户知道不支持加密的情况并让他选择是否仍希望电子邮件被发送？

答案1

然而，据我所知，当涉及到邮件服务器到邮件服务器的通信时，大多数电子邮件仍然以纯文本传输且未加密，这使得网络上的任何人都可以阅读其内容。

正确。SMTP 与 HTTP 一样，默认为纯文本。

如今许多邮件服务器都支持TLS（以前称为 SSL）用于 SMTP。（包括 Gmail。）但是，它存在与 HTTP[S] 相同的问题：由知名机构颁发的证书核证机关需要花钱，而自签名的则毫无价值1中间人攻击。如果您的邮件服务器对接收方的证书进行严格验证（如 Web 浏览器），则可能无法将邮件传递到使用自签名证书或内部 CA 的服务器。如果没有，那么它就不能确定它是否在与正确的服务器通信，并且冒名顶替者。

此外，TLS 是 SMTP 的一个相对较新的功能，因此即使收件人的邮件服务器支持 TLS，发件人的邮件服务器也可能不支持，或者默认情况下可能被禁用。

1（除非发送服务器支持 DANE（TLSA），并且接收服务器的管理员愿意在 DNS 中发布 TLSA 记录。这很少做，而且有点繁琐。）

是否有任何技术可以向用户保证其电子邮件从端到端的安全发送？

两种最常见的电子邮件安全标准：

  • 开放PGP，基于信任网络，免费使用。开源实现是基努（对于 Windows，对于 Thunderbird)，而最初的 PGP 已经演化成为商业PGP桌面。

    对于基于 Web 的电子邮件客户端，火GPG有可能——该死的

  • 邮件/多用途邮件，基于 X.509 基础架构。大多数桌面客户端（包括 Outlook、Thunderbird、Mail.app）都已实现。但是，由于与 TLS/SSL 具有相同的基于权限的结构，因此相对不受欢迎：签名证书需要花钱，而自签名证书无法得到可靠的验证。

在这两种情况下，加密要求接受者必须已经在使用该系统并已生成/获取密钥对。（对于签署， 这发件人的使用密钥对。正常做法是同时对消息进行签名和加密。

当不支持加密时为什么不让用户知道并让他选择是否仍要发送电子邮件？

通常提交的消息排队，并且用户和 MTA 都无法知道下一跳是否支持 TLS – 直到邮件被正在发送，此时没有可靠的方法要求用户确认。（他们可能不在、离线、睡着了，或者正在使用脚本/程序。如果我发送了消息，我希望它能尽快送达。）

此外，使用 SMTP，您永远不知道下一跳是否是最终的，或者它是否会将邮件转发到其他地方。备份 MX 位于完全不同的网络上的情况并不少见。

因此，只有双方都使用 OpenPGP 或 S/MIME 才能实现端到端安全。

答案2

这是2021问题基本不存在了。现在电子邮件几乎都是加密传输的，不再以纯文本形式发送。

此答案基于 维基百科 电子邮件加密。 根据这篇文章：

最常用的电子邮件加密扩展之一是 启动TLS。它是纯文本通信上的 TLS（SSL）层，允许电子邮件服务器将其纯文本通信升级为加密通信。假设发件人和收件人的电子邮件服务器都支持加密通信，则窃听邮件服务器之间通信的窃听者无法使用嗅探器查看电子邮件内容。电子邮件客户端和电子邮件服务器之间的通信存在类似的 STARTTLS 扩展（请参阅 IMAP4 和 POP3，如 RFC 2595 所述）。无论电子邮件的内容是否使用其他协议加密，都可以使用 STARTTLS。

加密消息会被中间电子邮件中继器看到，并可能被中间电子邮件中继器更改。换句话说，加密发生在各个 SMTP 中继器之间，而不是发件人和收件人之间。这既有好处也有坏处。传输层加密的一个关键积极特征是用户无需执行或更改任何操作；他们发送电子邮件时会自动进行加密。此外，由于接收组织可以在没有最终用户合作的情况下解密电子邮件，因此接收组织可以在将​​电子邮件发送给收件人之前运行病毒扫描程序和垃圾邮件过滤器。但是，这也意味着接收组织和任何闯入该组织电子邮件系统的人（除非采取进一步措施）都可以轻松阅读或修改电子邮件。如果接收组织被视为威胁，则端到端加密是必要的。

电子前沿基金会鼓励使用 STARTTLS，并推出了“STARTTLS Everywhere”计划，旨在“让每个人都能简单轻松地确保他们的通信（通过电子邮件）不会受到大规模监视”。对 STARTTLS 的支持已经变得相当普遍；谷歌报告称，截至 2018 年 7 月 24 日，GMail 上 90% 的传入电子邮件和 90% 的传出电子邮件都使用 STARTTLS 加密。

2018 年的情况是，Gmail 收到的 90% 的电子邮件都是加密的。2021 年 1 月， Google 透明度报告 - 传输中的电子邮件加密 有以下统计数据：

出站电子邮件加密：91%
入站电子邮件加密：93%

绝大多数邮件服务器已经使用加密通信，并且这个数字每年都在增加。

STARTTLS 解决了这个问题，并且无需强制所有电子邮件客户端加密其电子邮件。即使客户端到服务器的通信并不总是加密的，服务器之间的通信现在也几乎总是安全的。

答案3

实际的电子邮件流量通常是加密的（TLS），但还存在其他几个问题：

  • 一些显示 HTML 消息的网络邮件客户端可能不安全，尽管它们使用 HTTPS，例如 HTML 中的代码和数据之间没有严格的分离（视觉元素和 javascript -> 注入攻击）

    • webmail 还会将电子邮件保留在服务器上，而不是将其下载并存储到本地计算机

  • 你无法知道每个步骤之间是否使用了 TLS/SSL，非常小的服务器没有适当的证书

    • 发件人至少应该能够指定是否接受或拒绝使用不安全的渠道发送电子邮件

  • 电子邮件以未加密或由服务器加密的形式存储在服务器上

    • 你必须信任你和收件人之间的每台服务器

  • 电子邮件可能通过任何路线传输，您无法指定您信任的服务器（IP 地址范围、AS、国家、域......）

  • 大型电子邮件服务器不会使用多个不同的证书，也不会经常更改它们（？）

    • 也许值得/可以采取强行手段来破解它们（就像美国/英国等国家尝试过的那样？）

  • 通过跟踪流量，他们可以知道电子邮件何时发送以及有关收件人的一些信息（哪些服务器之间相互通信）

    • 暗网隐藏了这些关联

  • openssl 的实现曾经/现在很混乱

    • 可能有错误

  • 你必须信任签署证书的证书颁发机构

答案4

确实如此。或者说，很多时候确实如此。

通过 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。

相关内容