Как отправить электронное письмо с зашифрованной темой и текстом?

Как отправить электронное письмо с зашифрованной темой и текстом?

Я использую зашифрованную электронную почту для общения с некоторыми людьми. К сожалению, шифрование не распространяется на сообщениепредмет.

С одной стороны, я хочу использовать осмысленные темы/названия, но с другой стороны — я теряю половину ценности шифрования, если люди узнают, о чем я говорю с кем-то.

Если говорить более конкретно, то я использую Thunderbird с Enigmail; но мой вопрос касается не только этого.

решение1

Шифрование электронной почты обычнонетвключить заголовки сообщений.

Однако существуют подходы к решению этой проблемы. Я знаю о них:

(1) Стандарт S/MIME

RFC 5751 S/MIME 3.2иhttps://www.rfc-editor.org/rfc/rfc8551, оба описывают следующий метод в разделе 3.1:

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. 

Не объясняется, следует ли изменять "внешнюю" незашифрованную тему определенным образом. Я видел реализацию, которая меняет ее на (hidden).

Поддержка клиентов

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

Внутреннее сообщение RFC822 по сути интерпретируется как пересланное сообщение, что приводит к слегка или сильно запутанному представлению.

  • В Apple Mail (macOS) это довольно удобно, поскольку внутренняя тема отображается на видном месте
  • Thunderbird отобразит его аналогичным образом, но заявит, что это вложение «ForwardedMessage.eml»
  • MS Outlook очень запутан, поскольку он полностью скрывает внутреннее сообщение в виде прикрепленного файла.

(2) Защищенные заголовки (дыра в памяти)

Существует расширенный проект для сообщений PGP:Защищенные заголовки для криптографической электронной почты. Хотя изначально этот подход был нацелен на PGP/MIME, его можно применять и к сообщениям S/MIME, и в проекте он объясняется для обоих. Его предыдущее рабочее название было «Дыра памяти», и иногда его все еще называют этим именем.

Идея заключается в том, чтобы вставить часть содержимого Content-Type: multipart/mixedс атрибутом, protected-headers="v1"содержащим заголовок, который должен быть зашифрован. Затем внешняя тема заменяется (обычно на ..., но это зависит от клиента)

Пример:

Content-Type: multipart/mixed; boundary="kwXSZhfgNn46jmmnp33gvNm4xyrSwUW64";
 protected-headers="v1"
From: Elvis Presley <[email protected]>
To: John Lennon <[email protected]>
Message-ID: <[email protected]>
Subject: ...
 
--kwXSZhfgNn46jmmnp33gvNm4xyrSwUW64
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
 
Hello,

This is the message!  

Kind regards
Elvis
 
--kwXSZhfgNn46jmmnp33gvNm4xyrSwUW64--

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

Поддержка клиентов

  • Тандербёрдтеперь поддерживает защищенные заголовки, но только в сочетании с зашифрованными с помощью PGP электронными письмами (хотя нет никаких причин, по которым это не должно работать точно так же с S/MIME).
  • Я не знаю других клиентов, поддерживающих защищенные заголовки.

Связанный контент