加密标头 S/MIME 消息/rfc822

Question

我希望加密某些在加密邮件中发送的邮件标头 (Subject和Reply-To)。我正在使用整个 MIME（包括标头）并成功对其进行加密。我可以成功地将此 S/MIME 加密邮件发送到我的邮件客户端 (Thunderbird)。它将成功解密并验证为已签名。

但是，我的邮件客户端不使用在内部加密 MIME 中发送的任何标头。

根据RFC-5751，我应该将我的邮件包装在一条message/rfc822消息中，但我不知道如何实现这一点。

以下是我正在创建的消息示例。

我的第一个问题是，我创建的最后一个 MIMEmessage/rfc822是否结构正确？这可能是邮件客户端的问题吗？我可以对Reply-To标题进行事件加密吗？

如果我能得到一个mesage/rfc822封装消息的例子，那将非常有帮助。

要加密的邮件

这将成功生成已签名的接收邮件，并且邮件客户端正确解释了Subject/Reply-To标头。

Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0

----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

My Message that will be encrypted

----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIIOCAYJKoZIhvcNAQcCoIIN+TCCDfUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gguTMIIFCDCCA/CgAwIBAgIQVz2HAGYJcTJNsPiWLx1f/TANBgkqhkiG9w0BAQsFADCBjTELMAkG
.
.
.
17p13e02JxfyCqltdb6lkOdpRZ6ZlHHuQZyBCuRtJhRN83gvcJ4d7WCxKI349NEa2/tOb8ziFGat
gzvgu+o=
----_NmP-d017e0e3556f7bbc-Part_1--

我的加密邮件

我的邮件客户端将收到此加密邮件并成功解密和验证（签名验证）。Reply-To并且Subject仍然按预期工作，因为它们仍然可见。注意：来自未加密邮件的所有标头都仍然存在于该邮件的加密正文中。

Sender: sender@domain.com
From: sender@domain.com
To: recipient@domain.com
Subject:  A Secret Subject
Reply-To: keepsecret@domain.com
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
 name=smime.p7m
Date: Mon, 24 Feb 2020 16:03:38 +0000
MIME-Version: 1.0

MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
O+EPVCh1fGDFwiFpDtY/z1Lv8g==

我的封装消息/rfc822

此消息将被正确解密，但我的客户无法识别出这是一条加密消息，也无法验证它是否已签名（不太担心）。解密的邮件被解释为转发并附加为.eml文件。但是，没有找到Subject或Reply-To找到标题（它们在加密邮件中）。如果我按照 RFC 的建议添加虚拟值，我的邮件客户端将使用这些虚拟值，而不是加密的值。

Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: sender@domain.com
Sender: sender@domain.com
To: recipient@domain.com
Date: Mon, 24 Feb 2020 15:28:07 +0000
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
MIME-Version: 1.0

----_NmP-07c15c542cedfe74-Part_1
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
 name=smime.p7m

MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
fYU1LuhSBEyymSVRzwWr2T3lrhUe5BZBoY996epZtOPdIYrz2jqUglii1+AUBpUP
UUnpr8+cHTMk/50LHdy3MqMeYA==
----_NmP-07c15c542cedfe74-Part_1

编辑：从 RFC 添加摘录

在 RFC-8551 中，它说明了以下内容

In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the
   sending client MAY wrap a full MIME message in a message/rfc822
   wrapper in order to apply S/MIME security services to these header
   fields.  It is up to the receiving client to decide how to present
   this "inner" header along with the unprotected "outer" header.  Given
   the security difference between headers, it is RECOMMENDED that the
   receiving client provide a distinction between header fields,
   depending on where they are located.

   When an S/MIME message is received, if the top-level protected MIME
   entity has a Content-Type of message/rfc822, it can be assumed that
   the intent was to provide header protection.  This entity SHOULD be
   presented as the top-level message, taking into account
   header-merging issues as previously discussed.

Answer 1

RFC 822提供了关于电子邮件的消息标头如何组成以及如何由其传输所通过的系统进行处理的一般描述。RFC 5751 S/MIME 3.2（顺便说一句，已被其后继RFC 8551 S/MIME 4.0废弃）详细介绍了如何使用该标准创建加密电子邮件。

因此，您按照我的加密邮件中所述加密电子邮件的方法是有效且正确的。

但是，我的封装消息/rfc822中描述的方法并不完全正确。您显然误解了有关如何应用 rfc822 包装器的 RFC。在加密之前，包装器需要位于您的消息周围，因此它将位于加密部分内。

在您的示例中，未加密的消息（稍作修改的版本要加密的邮件）必须如下所示：

MIME-Version: 1.0
Content-type: message/rfc822

From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"

----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

My Message that will be encrypted
[...]

因此，您基本上可以在加密之前将 message/rfc822 添加到消息中。

我已经能够验证这种方法，并在两个接收邮件客户端中测试生成的消息，结果不同。在 macOS 邮件应用程序中，加密的主题不会用来替换不受保护的“外部”主题，但至少它会显着地显示在原始标题下方。这符合 RFC，但 RFC 对演示文稿的描述不是很具体：

由接收客户端决定如何呈现此“内部”标头以及不受保护的“外部”标头。鉴于标头之间的安全差异，建议接收客户端根据标头字段所在的位置区分标头字段。

加密Reply-To标头的显示方式类似，但在回复该电子邮件时，不会考虑其电子邮件地址。

客户支持

客户端对加密标头的支持介于弱和不存在之间。一些测试的结果：

• 没有客户端支持用“内部”加密标头替换“外部”标头
• Apple Mail (macOS) 在邮件中突出显示内部标头
• Thunderbird 将加密部分（包括其标头）显示为转发的消息
• Outlook 不显示加密部分，而是仅显示一条带有附件的空邮件（这是加密邮件），令人困惑

替代方法

本草案中提出了一种看似很有前景的加密电子邮件受保护标头的方法（正在进行中）。这个想法是将受保护的标头作为单独的部分包含在多部分消息中。这部分将由不可知的客户端内联渲染，同时，它可以由支持客户端正确处理。