[ 转发和ARC ]

修改签名邮件的安全网关

在归因DKIM故障或建议对安全处理进行更改之前,找到网关转换并比较原始签名输入。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • 网关的存在本身并不能证明它导致了签名失败。
  • 比较选定的标头实例和规范化的正文覆盖范围。
  • 后来失败的签名并不能证明它之前已经验证过。
  • 可信入口结果和下游检查可以描述不同的消息版本。
在此页面上

在指责网关之前找到修改

安全网关可以合法地检查或转换邮件,同时使下游复杂化 DKIM 确认。 URL 重写、附件替换和正文警告都是可能的示例,但网关的存在本身并不能证明签名失败。确定哪些表示进入网关、哪些表示离开网关以及评估身份验证的位置。

本文未访问任何网关帐户或消息流。原始证据门:原始和修改后的原始消息、签名者放置以及前后验证测试。这些物品仍未收集。工作案例纯属虚构。任何操作变更都必须保留预期的安全控制并遵循所有者批准的流程。

盘点准确的加工顺序

绘制从消息接受到身份验证、威胁检查、内容修改、签名和转发传递的序列。一项服务可以组合这些功能,并且一条路由上可以出现多个网关。仅当实际配置支持时才记录版本和启用的行为。不要假设产品在重写之前总是进行验证,或其输出连接器总是进行签名。

RFC 7960描述了删除有害内容、标记可疑垃圾邮件或更改 URL 的边界过滤器。它还解释了为什么在过滤器修改后评估身份验证会产生不同的结果。这些是建筑上的可能性,而不是对特定租户的判断。消息跟踪和保留的副本是将记录的机制与事件连接起来所必需的。 RFC 7960第 3.2.5 节

确定失败的签名涵盖的内容

对于每个 DKIM-Signature, 保留签名域d=, 选择器 s=, 规范化 c=, header list h= and any l= body-length value. The 正文哈希 根据选定的规范化主体输入进行计算;签名还涵盖指定的标头实例。如果不知道是否选择了该实例以及规范化是否保留了差异,“网关更改了标头”是不完整的。 RFC 6376第 3.4–3.5 和 5.4 节

宽松的规范化可以容忍特定的空格和标头格式更改。它不会将任意 HTML 编辑、URL 替换或附件更改视为等效内容。相反,所选覆盖范围之外的添加字段不需要使现有签名无效。标头重复和过度签名可能会使评估变得复杂,因此请比较选定的实例,而不仅仅是唯一字段名称的列表。 RFC 6376第 3.4 和 5.4 节

比较原始消息而不改变证据

使用来自批准的捕获点的未更改的原始消息文件。渲染的屏幕截图可以隐藏MIME边界、编码更改和折叠标题。通过编辑器重新保存消息本身可以更改行结尾或序列化,因此请保留原始消息并对副本进行分析。记录捕获时间、路线位置和文件哈希,以将每个样本连接到所声明的步骤。

后来失败的签名并不能证明该签名在网关之前是有效的。 RFC 6376警告验证者通常无法从无效签名推断出先前的有效性。因此,建议的测试包括对保留的输入和输出的验证,并保留相关的密钥和验证者上下文。否则,先前存在的签名错误可能会被错误地归因于网关。 RFC 6376第 4.2 节

通过虚构的 URL 替换进行工作

假设一个虚构的作者域签名验证原始输入消息并覆盖其整个正文。然后,网关将 HTML MIME部分中的 URL 替换为威胁防护 URL。相应的输出包含不同的规范化主体字节,并且验证尝试报告主体哈希不匹配。这些假设形成了说明性测试结果;这里没有进行这样的测试。

该比较支持了一个狭隘的结论,即观察到的替换影响了该签名的覆盖主体。这并不意味着每个网关操作都会破坏每个签名或应该关闭保护。 gateway.example的附加签名可以验证该域对修改消息的处理,但它不会重建原始作者签名或自动与不相关的作者域对齐。 RFC 6376第 3.4 和 5.1 节 RFC 9989第 5.3 节

保持入口结果和下游验证不同

在内部安全转换之前,组织可能会依赖在其受信任入口处执行的身份验证。保留结果背后的评估者身份和信任边界。评估修改字节的下游接收器可能会正确获得不同的DKIM结果。复制一个 Authentication-Results 消息中的字段本身并不能使该字段在产生它的边界之外值得信赖。 RFC 8601第 5 节和第 7 节

ARC 可以通过参与的处理程序进行事先评估,但链验证和对这些处理程序的信心仍然是不同的问题。 RFC 8617并未使ARC成为恢复旧DKIM签名的机制。其发布类别为实验性;经审查的将ARC移至历史记录的提案仍然是一个活跃的草案。不要承诺启用ARC会使每个下游接收者接受网关修改的邮件。 RFC 8617第 5.2 和 9.3 节 IETF提案状态

在预期更改之后放置合法签名

对于在组织控制的域下编写的出站邮件,受支持的设计可以在最终合法内容更改之后放置授权一致签名者。验证后续步骤不会再次修改涵盖的内容。网关不能仅仅因为中继该作者的消息而合法地签名为外部作者的域;相关域名授权和密钥保管必须存在。 RFC 6376第 5.1 节

审查数据包应说明哪些控制保持活动状态、建议哪种处理顺序以及如何重复前后验证。不要仅仅为了产生绿色指示器而使用减少的身体覆盖范围或全面的身份验证绕过。成功的授权测试将仅支持其采样的路由和消息形式。该草案中仍然缺少原始原始对、实际签名者放置和受控验证结果。

[ 外卖 ]

证明原始验证结果和涵盖的变更。在审查支持的处理和签署订单的同时,保持威胁防护处于活动状态。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

安全网关所有者

保留防护目的

身份验证故障排除应解释保护和修改如何相互作用,而不是在没有证据的情况下删除控制。

后续步骤

  1. 验证后列出已启用的转换及其顺序。
  2. 通过批准的捕获路径保留原始和输出样本。
  3. 与邮件签名所有者一起审查任何处理订单提案。

DKIM验证器维护者

识别选定的输入

验证者结果应与签名、公钥上下文和正在检查的精确表示相关联。

后续步骤

  1. 记录每个签名的覆盖范围和算法参数。
  2. 在归因以后的损坏之前建立输入有效性。
  3. 将主体哈希不匹配与其他验证失败区分开来。

事件协调员

约束修理及其索赔

得到广泛支持的原因比基于一条消息的全产品声明更有用。

后续步骤

  1. 将观察到的转换链接到受影响的签名。
  2. 避免广泛的身份验证绕过或减少覆盖范围作为装饰修复。
  3. 需要实际范围内的路由和消息形式的变更后证据。

[ 常见问题解答 ]

常见问题

每次网关编辑都会破坏所有DKIM签名吗?

不会。效果取决于每个签名选择的内容及其规范化。允许的格式更改或在选定覆盖范围之外添加的字段可能与替换覆盖的 URL 或附件不同。独立评估签名。

哪些DKIM标签属于网关调查?

保留d=, s=, c=, h= 和任何 l= 值,以及完整的原始消息和验证器结果。这些标识了签名域、密钥选择器、规范化和相关覆盖范围;它们不能代替实际验证输入。

失败的下游签名能否证明网关破坏了它?

不可以。签名在处理之前可能已经无效。可信的归因需要保留的输入进行验证,输出比较显示相关的覆盖更改,并保留密钥和验证者上下文。

为什么屏幕截图不足以比较网关更改?

呈现的视图可以隐藏MIME结构、内容传输编码、行结尾和选定的标头实例。在已知边界保持原始捕获不变并分析工作副本,以便调查不会改变自己的证据。

添加网关域签名是否可以修复作者签名?

不会。它通过网关的签名域创建单独的断言。原始签名仍然可独立评估,并且DMARC对齐取决于有效签名域和邮件作者域之间的关系。

可信入口通行证可以与内部验证失败共存吗?

是的,如果两项检查评估转换前后的不同表示。记录哪个系统产生了原始结果以及为什么它是可信的。不要自动将该信任扩展到任意复制的结果标头。

ARC应该被描述为通用网关修复吗?

不会ARC提供接收者可以根据自己的信任决策进行评估的断言;它不会恢复原始DKIM签名。经审查的重新分类提案仍然是有效的互联网草案,因此在提出部署建议之前应重新检查状态和支持。

在接受网关修复之前,还缺少哪些证据?

原始和修改后的原始消息、签名者位置以及前后验证测试仍未收集。虚构的 URL 替换示例仅演示了推理。没有更改安全设置、网关帐户或实时消息。

[ 来源 ]

来源

  1. IETF Datatracker:将ARC重新分类为历史性的
  2. RFC 6376 :域名密钥识别邮件 ( DKIM ) 签名
  3. RFC 7960 : DMARC和间接电子邮件流之间的互操作性问题
  4. RFC 8601 :用于指示消息认证状态的消息头字段
  5. RFC 8617 :认证接收链 ( ARC ) 协议
  6. RFC 9989 :基于域的消息身份验证、报告和一致性 ( DMARC )

[ 词汇表 ]

词汇表

边界过滤器
消息处理组件,根据组织安全策略检查邮件并可能转换内容。
签约边界
授权签名者将所选消息表示形式固定到DKIM签名中的点。
规范化输入
由签名的指定规范化规则生成的用于加密处理的标头或正文表示形式。
选定的标头实例
通过DKIM标头选择包含的标头字段的特定出现,包括重复字段和过度签名注意事项。
网关断言
由网关做出的身份验证或签名声明,其身份和信任范围必须与原作者的声明区分开来。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库