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


19

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

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

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

Ответы:


19

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

Верный. 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.


2
Примечание: и вопрос, и мой ответ касаются обмена почтой между двумя SMTP-серверами через порт 25. Неважно, поддерживается ли TLS на портах 587 или 465; они предназначены исключительно для отправки сообщений [удаленным] пользователем.
user1686

2
Насколько я понимаю, чаще всего SMTP-соединение НЕ шифровалось. Однако вы можете получить бесплатные сертификаты электронной почты (которые Validate) здесь: instantssl.com/ssl-certificate-products/...
Энди

Обновление: в настоящее время пользовательский интерфейс Gmail предупреждает вас, когда домен получателя не поддерживает шифрование, и в инструкциях предлагается с осторожностью отправлять конфиденциальную информацию.
Blaisorblade

4

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

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

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

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

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

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

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

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

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


2

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

Либо через 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.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.