Шифрование заголовков S / MIME message / rfc822

Question

Я хочу зашифровать определенные заголовки почты (Subject и Reply-To), которые отправляются в зашифрованной почте. Я беру весь MIME (включая заголовки) и успешно шифрую его. Я могу отправить эту зашифрованную почту S / MIME моему почтовому клиенту (Thunderbird) успешно. Он будет успешно расшифрован и проверен как подписанный.

Однако все заголовки, которые отправляются во внутреннем зашифрованном MIME, не используются моим почтовым клиентом.

Согласно RF C -5751 Я должен был обернуть свою почту в сообщение message/rfc822, но я не знаю, как этого добиться.

Ниже приведены примеры моих сообщений, которые я создаю.

Мой первый вопрос: последний MIME, который я создаю message/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--

My Encrypted Почта

Эта зашифрованная почта будет получена и успешно расшифрована и проверена (подпись проверена) моим почтовым клиентом. 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 не найдены (они находятся в зашифрованной почте). Если я добавлю фиктивные значения в соответствии с рекомендациями RF C, эти фиктивные значения будут использоваться моим почтовым клиентом, а не зашифрованными.

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

Редактировать: добавить выдержку из RF C

В РФ C -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

RF C 822 предоставляет обобщенное описание того, как составляются заголовки сообщений электронной почты, и должно обрабатываться системами, через которые они передаются. RF C 5751 S / MIME 3.2 (кстати, его устаревший преемник RF C 8551 S / MIME 4.0 ) подробно описывает, как использовать этот стандарт для создания зашифрованных писем.

Таким образом, ваш подход к шифрованию электронной почты, описанный в разделе Моя зашифрованная почта , является верным и правильным.

Однако ваш подход, описанный в Мое инкапсулированное сообщение / rfc822 , не совсем верен. Вы явно неверно истолковали RF C в отношении того, как применять оболочку rfc822. Оболочка должна находиться вокруг вашего сообщения до того, как будет зашифровано, поэтому оно должно быть внутри зашифрованной части.

В вашем примере незашифрованное сообщение (слегка измененная версия Почта для шифрования ) должно выглядеть следующим образом:

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 Mail зашифрованный субъект не использовался для замены незащищенного «внешнего» субъекта, но, по крайней мере, он отображался заметно ниже исходных заголовков. Это согласуется с RF C, который не очень конкретен c о представлении:

Клиент-получатель должен решить, как представить этот "внутренний" заголовок вместе с незащищенный «внешний» заголовок. Учитывая разницу в безопасности между заголовками, РЕКОМЕНДУЕТСЯ, чтобы получающий клиент предоставлял различие между полями заголовка, в зависимости от того, где они расположены.

Зашифрованный заголовок Reply-To отображается аналогично, но это электронная почта адрес не учитывается при ответе на это письмо.

В Thunderbird внутреннее сообщение отображалось как вложение eml, но, по крайней мере, внутренняя тема отображалась на видном месте. Однако адрес Reply-To вообще не отображался.

Если честно, меня приятно удивляет тот факт, что зашифрованные заголовки вообще поддерживаются обычными почтовыми клиентами, по крайней мере, в некоторой степени.