Я не так разбираюсь в технике, как большинство на этом сайте, поэтому имейте это в виду. Я хотел узнать больше о безопасности электронной почты, поэтому провел небольшое исследование, и все соответствует моему пониманию, поэтому, пожалуйста, поправьте меня там, где это необходимо. Соединение между клиентом и сервером (MSA / MTA?) Может быть зашифровано, но шифрование между сервером (MTA и MTA?) Зависит от каждого сервера, поддерживающего STARTTLS. STARTTLS также может быть реализован между клиентом и сервером.
Единственная слабость STARTTLS, с которой я столкнулся, заключается в том, что соединение может быть принято через шифрование или как обычный текст, поэтому это делает атаку MITM предположительно тривиальной, когда шифрование может быть понижено до обычного текста. Также я понимаю, что существует проблема с подделкой сертификатов, хотя я не знаю, связано ли это напрямую с MITM.
Я читал, что это проблема с реализацией, а не с самим протоколом. Некоторые решения, с которыми я столкнулся, включали настройку клиента либо на уведомление, когда соединение не происходит через SSL / TLS, либо на полное отключение соединения. Есть ли правильный способ реализовать STARTTLS, чтобы MITM был невозможен (вместо того, чтобы реагировать на него, когда это происходит, если это имеет смысл), и где это произойдет? Эти исправления предназначены для соединения сервера с сервером или только для соединения клиента с сервером? Я также хотел бы узнать немного больше о проблеме с поддельными сертификатами, о том, как эта слабость возможна и как ее решить, либо путем реализации, либо другими способами.
Меня больше всего интересует безопасность между сервером и сервером, поскольку сервер-клиент, похоже, не представляет большой проблемы и уже решен большинством ESP. Есть ли лучшая альтернатива STARTTLS? Как я уже упоминал, я новичок во всем этом, и мне потребуются исчерпывающие инструкции по большей части из этого, включая то, как реализовать / настроить. Если никто не может предоставить это здесь, я был бы признателен за любую точку в правильном направлении в отношении учебных ресурсов.
НА СТОРОНЕ ... Мне также интересно узнать о реальных атаках / эксплойтах, и мне было интересно, может ли упомянутый выше тип MITM (сервер к серверу) быть нацелен на конкретное соединение (адрес электронной почты назначения?) или больше похоже на то, чтобы схватить все, что случится с проходящим мимо.
Существует несколько проблем с безопасной транспортировкой электронной почты, и эти вопросы лучше задать на security.stackexchange.com. Почту можно перехватить на разных этапах:
Это означает, что для того, чтобы хотя бы пошаговое шифрование было достаточно безопасным, вам нужно добавить нетривиальные исправления в несколько мест, и большинство из них не контролирует отправляющий MTA.
Чтобы подробно ответить на вопросы из комментариев:
1.) Обычно STARTTLS реализуется между серверами или запускается с клиент-сервера и переходит от перехода к переходу?
STARTTLS должен быть реализован на каждом узле (MTA). Его можно использовать только в том случае, если принимающий MTA поддерживает STARTTLS и отправляющий MTA может это сделать. Это не зависит от того, как почта была доставлена на начальный переход (MTA) от клиента. Обычно TLS с SMTP шифрует только соединение между переходами, поэтому его можно будет прочитать в открытом виде на каждом переходе, если он также не зашифрован сквозным образом (с PGP или S / MIME).
2.) Может ли почта, зашифрованная PGP или S / MIME, по-прежнему перенаправляться с помощью подмены MX?
Да, его еще можно перенаправить. Но само письмо по-прежнему может расшифровать только реальный получатель, то есть владелец целевого ключа.
3.) Нужно ли внедрять DNSSEC в широком масштабе, чтобы быть полезным, или это может быть полезно для отдельного человека, настроив его на собственном почтовом сервере?
Каждый бит помогает, но только немного. И обратите внимание, что ему нужны не только записи DNSSec, но и MTA пересылки должен фактически использовать DNSSec. Большинство MTA, вероятно, используют только DNS и не осознают, получают ли они поддельную запись MX.
4.) Нужно ли вам беспокоиться о внедрении TCP RST для неявных tls или просто явных?
Неявный TLS используется только от клиента к MTA, то есть к начальному переходу. Это наиболее безопасный шаг, потому что он фактически находится под контролем клиента, и клиент обычно использует фиксированный SMTP-сервер с фиксированными настройками TLS, поэтому нет проблем с подменой MX и понижением уровня соединения. Если вместо этого клиент настроен на использование TLS, только если он доступен, атака может работать и против неявного TLS.
5.) Разве вы не можете настроить сервер / MTA для разрыва соединения (возврат электронной почты), если другой MTA не совместим с TLS, т.е. переключиться с гибкого на обязательный, или это то, что вы можете делать только на клиенте (например, Thunderbird) для клиент-серверное соединение?
Большинство серверов могут быть настроены таким образом, но большинству серверов приходится взаимодействовать с множеством серверов, и они не знают заранее, будет ли сервер поддерживать TLS. Но sendmail, например, можно настроить так, чтобы он разговаривал только по TLS с определенными серверами или не говорил по TLS с определенными другими серверами. Таким образом, эту конфигурацию можно усилить для заведомо исправных серверов, но это нужно делать вручную.
6.) Если №5 возможен и электронная почта не возвращается, получит ли отправитель уведомление «не удалось отправить»?
Да, обычно так и бывает, как и со всеми ошибками доставки. Но, как и большинство других ошибок доставки, эти сообщения об ошибках могут понять только технически подготовленные люди.
7.) Что касается сертификатов, которые не проверяются, это то, что можно исправить с помощью правильной конфигурации / реализации. Я читал, что одна из проблем заключалась в том, что многие сертификаты самоподписаны, и большинство MTA принимают их по умолчанию, поэтому они могут оставаться совместимыми с большим количеством MTA. Это часть того, о чем вы говорили?
Это зависит от сервера. Позже, когда я посмотрел, postfix был в порядке, но sendmail не смог должным образом проверить имя хоста по сертификату. И да, самоподписанный - это одна проблема, а другая основная проблема - отсутствие промежуточных сертификатов. Но поскольку доставка почты работает в любом случае (поскольку отправитель игнорирует ошибки сертификата), большинство администраторов не осознают плохую конфигурацию или не заботятся.
8.) Наконец, скажем, что все нетривиальные исправления были внесены, и я понимаю, что другой MTA / клиент находится вне моего контроля. Могут ли эти атаки MITM и инъекций нацелены на определенные соединения, идущие на мой адрес электронной почты и с него? В этой ситуации они не взломали мой сервер, и у них нет предыдущего опыта работы с моими контактами.
Опять же, это только пошаговое шифрование, и почта доступна в открытом виде для чтения и изменения на каждом из прыжков. Таким образом, злоумышленник на любом из переходов, участвующих в передаче (обычно по крайней мере два, один у отправителя и один на сайте получателя) может перехватывать, а также изменять почту и, конечно, может ограничить себя, чтобы иметь дело только с выбранными сообщениями. Единственная защита - это сквозное шифрование с использованием PGP или S / MIME.