代码之家  ›  专栏  ›  技术社区  ›  Joshua

无法验证dkim的正文哈希

  •  2
  • Joshua  · 技术社区  · 15 年前

    我正在编写一个C dkim验证器,遇到了一个我无法解决的问题。现在,我正在计算body散列,如中所述。 Section 3.7 Computing the Message Hashes . 我正在处理使用Exchange 2010 Transport Agent SDK中EdgeTransportAsyncLogging示例的修改版本丢弃的电子邮件。它不在保存时转换电子邮件,只打开基于messageid的文件,并将原始数据转储到磁盘。

    我能够成功计算中提供的示例电子邮件的正文哈希。 Section A.2 使用以下代码:

    SHA256Managed hasher = new SHA256Managed();
    ASCIIEncoding asciiEncoding = new ASCIIEncoding();
    string rawFullMessage = File.ReadAllText(@"C:\Repositories\Sample-A.2.txt");
    string headerDelimiter = "\r\n\r\n";
    int headerEnd = rawFullMessage.IndexOf(headerDelimiter);
    string header = rawFullMessage.Substring(0, headerEnd);
    string body = rawFullMessage.Substring(headerEnd + headerDelimiter.Length);
    byte[] bodyBytes = asciiEncoding.GetBytes(body);
    byte[] bodyHash = hasher.ComputeHash(bodyBytes);
    string bodyBase64 = Convert.ToBase64String(bodyHash);
    string expectedBase64 = "2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=";
    Console.WriteLine("Expected hash: {1}{0}Computed hash: {2}{0}Are equal: {3}",
      Environment.NewLine, expectedBase64, bodyBase64, expectedBase64 == bodyBase64);
    

    上述代码的输出为:

    Expected hash: 2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=
    Computed hash: 2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=
    Are equal: True
    

    现在,大多数电子邮件都是通过 c=relaxed/relaxed 设置,这要求您在散列和验证之前对主体和头进行一些操作。当我在做这件事的时候(没能让它起作用),我终于发现了一个消息 c=simple/simple 这意味着你要处理整个身体减去任何空的 CRLF 在身体的末端。(真的,身体规范化的规则是相当… simple )

    这里是 real DKIM email (右键单击并保存,浏览器会吃掉结尾 慢性淋巴细胞白血病 )使用简单的签名算法(完全未修改)。现在,使用上述代码并更新 expectedBase64 hash我得到以下结果:

    Expected hash: VnGg12/s7xH3BraeN5LiiN+I2Ul/db5/jZYYgt4wEIw=
    Computed hash: ISNNtgnFZxmW6iuey/3Qql5u6nflKPTke4sMXWMxNUw=
    Are equal: False
    

    预期的哈希是 bh= 领域 DKIM-Signature 标题。现在,第二个测试中使用的文件是来自Exchange2010传输代理的直接原始输出。如果倾斜,可以查看修改后的 EdgeTransportLogging.txt .

    此时,无论我如何修改第二封电子邮件,更改开始位置或 慢性淋巴细胞白血病 在文件的末尾,我无法使文件匹配。令我担心的是我无法验证 任何 到目前为止,body hash(简单或轻松)可能无法通过exchange 2010处理dkim。

    1 回复  |  直到 15 年前
        1
  •  1
  •   poolie    15 年前

    我在python-dkim中尝试了这个方法,并且得到了一个体散列不匹配的结果。

    我想可能是交换的 GetMimeReadStream 没有提供传输时的实际字节,因此哈希不匹配。可能是将消息分解成它的mime部分,然后getmimereadstream提供给您 消息的有效表示形式,但不是最初与之一起发送的。

    也许还有另一个API可以提供真正的原始字节?

    或者,在这个过程中,到了这个时候,消息已经被撕开,原始消息被丢弃了,您需要更早地钩住它。

    也许您应该尝试通过将一条DKIM签名的消息发送到一个非Exchange服务器来截取它,看看它是否适用于您的代码。 GetContentReadStream 可能有用吗?

    不管怎样,我接下来要做的是尝试找到一个API,它为您提供所发送内容的逐字节性。