Однако, насколько мне известно, когда речь идет об обмене данными между почтовым сервером и почтовым сервером, большинство электронных писем по-прежнему передаются в виде простого текста и не шифруются, что позволяет любому пользователю в сети читать их содержимое.
Правильный. SMTP, как и HTTP, является текстовым по умолчанию.
В наши дни многие почтовые серверы поддерживают TLS (ранее известный как SSL) для SMTP. (Это включает в себя Gmail.) Однако у него те же проблемы, что и с HTTP [S]: сертификаты, выпущенные известными центрами сертификации, стоят денег, а самозаверяющие - бесполезны 1 для защиты от атак MitM. Если ваш почтовый сервер выполняет строгую проверку сертификата получателя (как это делают веб-браузеры), он может не доставить сообщения на серверы, которые используют самозаверяющие сертификаты или внутренние ЦС. Если это не так, то он не может быть уверен, что он обращается к нужному серверу, а не к самозванцу.
Кроме того, TLS является относительно недавним дополнением к SMTP, поэтому даже если почтовый сервер получателя поддерживает TLS, отправитель может этого не делать или он может быть отключен по умолчанию.
1 (Если отправляющий сервер не поддерживает DANE (TLSA) и администратор получающего сервера не заботится о публикации записей TLSA в DNS. Это редко делается и несколько утомительно.)
Существуют ли какие-либо технологии, которые дают пользователю некоторые гарантии того, что его электронные письма будут безопасно передаваться из конца в конец?
Два наиболее распространенных стандарта безопасности электронной почты:
OpenPGP, основан на сети доверия и бесплатен для использования. Реализация с открытым исходным кодом - GnuPG (для Windows, для Thunderbird), а оригинальный PGP превратился в коммерческий рабочий стол PGP.
Для веб-клиентов электронной почты возможность FireGPG - черт возьми
S/MIME, на основе инфраструктуры X.509. Реализуется большинством настольных клиентов (включая Outlook, Thunderbird, Mail.app). Однако, относительно непопулярный из-за той же структуры, основанной на полномочиях, что и TLS/SSL: подписанные сертификаты стоят денег, а самоподписанные сертификаты не могут быть надежно проверены.
В обоих случаях шифрование требует, чтобы получатель уже использовал систему и сгенерировал / получил пару ключей. (Для подписи используется пара ключей отправителя . Обычная практика - подписывать и шифровать сообщения.)
Почему бы не сообщить пользователю, когда шифрование не поддерживается, и позволить ему выбрать, хочет ли он, чтобы его электронная почта все еще доставлялась?
Обычно отправленные сообщения ставятся в очередь, и ни пользователь, ни MTA не могут знать, поддерживает ли следующий переход TLS или нет - до тех пор, пока сообщение не будет отправлено, и в этот момент нет надежного способа запросить подтверждение у пользователя. (Это могут быть AFK, офлайн, спящий или скрипт / программа. Если я отправил сообщение, я хочу, чтобы оно было доставлено как можно скорее.)
Кроме того, с SMTP вы никогда не узнаете, является ли следующий переход окончательным или он просто будет пересылать почту куда-то еще. Нередко резервный MX находится в совершенно другой сети.
Следовательно. Сквозная защита возможна только тогда, когда обе стороны используют OpenPGP или S/MIME.
