加密标题S/MIME消息/rfc822 [英] Encrypting Headers S/MIME message/rfc822

问题描述

我正在寻找对通过加密邮件发送的某些邮件头( Subject 和 Reply-To )进行加密的方法.我正在使用整个MIME(包括标头)并成功对其进行了加密.我可以将此S/MIME加密的邮件成功发送到我的邮件客户端(Thunderbird).它将被成功解密并验证为已签名.

I am looking to encrypt certain mail headers (Subject and Reply-To) which are being sent in an encrypted mail. I am taking an entire MIME (Headers included) and successfully encrypting it. I can send this S/MIME encrypted mail to my mail client (Thunderbird) successfully. It will be successfully decrypted and verified as signed.

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

However, any headers that are sent in the inner encrypted MIME are not being used by my mail client.

根据 RFC-5751 我应该将邮件包裹在消息中/rfc822 消息，但我对如何实现这一目标感到茫然.

According to RFC-5751 I should be wrapping my mail in a message/rfc822 message but I am at a loss at how to achieve this.

下面是我正在创建的消息的示例.

Below are examples of my messages that I am creating.

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

My first question is, is the last MIME that I am creating the message/rfc822 correctly structured? Is this possibly an issue with the mail client? Can I event encrypt the Reply-To Header?

如果我能得到一个 mesage/rfc822 封装消息的示例，那将真的很有帮助.

If I could get an example of a mesage/rfc822 encapsulated message that would be really helpful.

要加密的邮件

这将成功导致接收到的邮件已签名，邮件客户端正确解释了 Subject / Reply-To 标头.

This will successfully result in a received mail that is signed and the Subject / Reply-To headers are interpreted correctly by the mail client.

Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
From: [e-mail]
Sender: senderdomain.com
To: [e-mail]
Reply-To: [e-mail]
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 仍按预期工作，因为它们仍然可见.注意:来自未加密邮件的所有标头都仍然存在于此邮件的加密主体中.

This encrypted mail will be received and successfully decrypted and verified (signature verified) by my mail client. Reply-To and Subject are still working as expected as they are still visible. Note: all the headers from the unencrypted mail are all still present inside the encrypted body of this message.

Sender: [e-mail]
From: [e-mail]
To: [e-mail]
Subject:  A Secret Subject
Reply-To: [e-mail]
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的建议添加伪值，则这些伪值将由我的邮件客户端使用，而不是加密的那些.

This message will be decrypted correctly but my client does not recognise that it was an encrypted message or verify that it was signed (Not worried about that so much). The decrypted mail is interpreted as forwarded and attached as an .eml file. However, no Subject or Reply-To headers found (they are in the encrypted mail). If I add dummy values as recommended by the RFC, those dummy values will be used by my mail client, not the encrypted ones.

Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: [e-mail]
Sender: [e-mail]
To: [e-mail]
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 RFC-8551 it states the following

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.

推荐答案

RFC 822 提供了有关电子邮件的邮件标头如何组成以及应通过其传输系统处理的一般描述. RFC 5751 S/MIME 3.2 (顺便说一句，它已被

RFC 822 provides a generalized description of how message headers of an email are composed and should be treated by systems they are transmitted through. RFC 5751 S/MIME 3.2 (btw, obsoleted by it successor RFC 8551 S/MIME 4.0) describes details how to use that standard to create encrypted emails.

因此，如我的加密邮件中所述，您对电子邮件进行加密的方法是正确的.

So your approach to encrypt an email as described under My Encrypted Mail is valid and correct.

但是，我的封装消息/rfc822 中描述的方法不太正确.对于如何应用rfc822包装器，您显然对RFC了误解.包装器必须在您的消息被加密之前 周围，因此它将位于加密的部分内.

However, your approach as described under My Encapsulated message/rfc822 is not quite correct. You have obviously misinterpreted the RFC with regard to how to apply the rfc822 wrapper. The wrapper needs to be around your message before it gets encrypted, so it's going to be inside the encrypted part.

在您的示例中，未加密的邮件(稍作修改的版本要加密的邮件)必须看起来像这样:

In your example, the unencrypted message (a slightly modified version Mail to be encrypted) would have to look like this:

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

From: [e-mail]
Sender: senderdomain.com
To: [e-mail]
Reply-To: [e-mail]
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
[...]

因此，您基本上将消息/rfc822添加到之前的消息中.

So you basically add the message/rfc822 to the message before it gets encrypted.

我已经能够验证这种方法，并在两个结果不同的接收邮件客户端中测试了结果消息.在macOS Mail应用程序中，加密的主题并未用于替换不受保护的外部"主题，但至少在原始标题下方突出显示了该主题.这符合RFC，RFC的表达方式不是很具体:

I have been able to verify this approach and tested the resulting message in two receiving mail clients with different results. With the macOS Mail application, the encrypted subject was not used to replace the unprotected "outer" subject, but at least, it was displayed prominently below the original headers. This is compliant with the RFC which is not very specific about the presentation:

由接收客户端决定如何呈现此内部"标头以及未受保护的外部"标头.考虑到标头之间的安全性差异，建议接收客户端根据标头字段的位置对标头字段进行区分.

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.

以类似的方式显示加密的 Reply-To 标头，但在回复该电子邮件时不接受该电子邮件地址.

An encrypted Reply-To header is displayed similarly, but it's email address is not honored when replying to that email.

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

The support for encrypted headers in clients is somewhere between weak and non-existent. The results of some tests:

• 没有客户端支持将外部"标头替换为内部"加密标头
• Apple Mail(macOS)在消息中突出显示内部标头
• Thunderbird将包含其标题的加密部分显示为转发的消息
• Outlook不会显示加密的部分，但会混淆地显示仅带有附件的空消息(即加密的消息)

此电子邮件保护标头草案(正在进行中).想法是将受保护的标头作为单独的部分包括在多部分消息中.该部分将由不可知论的客户端内联呈现，同时，可以通过支持客户端对其进行适当处理.

There is a seemingly promising approach proposed in this draft for Protected Headers for Cryptographic E-mail (work in progress). The idea is to include the protected headers as a separate part in a multipart message. This part will be rendered inline by agnostic clients, while at the same time, it can be properly processed by supporting clients.

这篇关于加密标题S/MIME消息/rfc822的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！