Однако, насколько мне известно, когда речь идет об обмене данными между почтовым сервером и почтовым сервером, большинство электронных писем по-прежнему передаются в виде простого текста и не шифруются, что позволяет любому пользователю в сети читать их содержимое.
Верный. 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.