Почему передачи электронной почты между почтовыми серверами часто не шифруются?

Пользователи часто могут выбирать, хотят ли они получить доступ к своему поставщику электронной почты (например, Gmail) по безопасному каналу (например, с использованием HTTPS).

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

Существуют ли какие-либо технологии, которые дают пользователю некоторые гарантии того, что его электронные письма будут безопасно передаваться из конца в конец? Почему бы не сообщить пользователю, когда шифрование не поддерживается, и позволить ему выбрать, хочет ли он, чтобы его электронная почта все еще доставлялась?

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

Верный. SMTP, как и HTTP, является текстовым по умолчанию.

В наши дни многие почтовые серверы поддерживают TLS (ранее известный как SSL) для SMTP. (Это относится и к Gmail.) Однако у него те же проблемы, что и с HTTP [S]: сертификаты, выпущенные известными ЦС, стоят денег, а самозаверяющие - бесполезны ¹ для защиты от атак MitM . Если ваш почтовый сервер выполняет строгую проверку сертификата получателя (как это делают веб-браузеры), он может не доставить сообщения на серверы, которые используют самозаверяющие сертификаты или собственные ЦС. Если это не так , то он не может быть уверен, что он обращается к нужному серверу, а не к самозванцу .

Кроме того, TLS является относительно недавним дополнением к SMTP, поэтому даже если почтовый сервер получателя поддерживает TLS, отправитель может этого не делать или он может быть отключен по умолчанию.

¹ (Если отправляющий сервер не поддерживает 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.

Фактический почтовый трафик часто шифруется (TLS), но есть несколько других проблем:

• Некоторые клиенты веб-почты, которые показывают HTML-сообщения, могут быть небезопасными, хотя они используют HTTPS, например, нет никакого жесткого разделения между кодом и данными в HTML (визуальные элементы и атаки с использованием javascript -> внедрения)

  • Веб-почта также хранит электронную почту на сервере, а не загружает и хранит ее на локальном компьютере.

• У вас нет возможности узнать, использовался ли TLS / SSL между каждым шагом, очень маленькие серверы НЕ ИМЕЮТ надлежащих сертификатов

  • отправитель должен хотя бы указать, принимать или отклонять отправку электронной почты по небезопасному каналу.

• Электронные письма лежат на серверах в незашифрованном виде или зашифрованы сервером

  • вам придется доверять КАЖДОМУ серверу между вами и получателем

• Электронные письма могут передаваться по любому маршруту, вы не можете указать, каким серверам вы доверяете (диапазоны IP-адресов, AS, страны, домены ...)

• Большие почтовые серверы не используют несколько разных сертификатов и не меняют их достаточно часто (?)

  • возможно, стоит / возможно их перебить (как пытались в США / Великобритании и т. д.)

• следуя трафику, они узнают, когда электронная почта была отправлена ​​и что-то о получателе (какие серверы общаются между собой)

  • даркнеты скрывают эти корреляции

• Реализация openssl была / есть беспорядок

  • там может быть ошибки

• Вы должны доверять центрам сертификации, подписывающим сертификаты

Они есть. Или очень часто они есть.

Либо через SSL, либо через TLS .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Или, если вы действительно параноик, есть PGP или GPG.