Осуществляет шифрование для SMTP хорошая идея (уже)?
Я выполняю почтовый сервер, который в настоящее время настраивается для использования TLS, если это возможно, при отправке и получении электронных писем.
Когда Вы читаете в документации об этом, существует также опция осуществить TLS и не принять передачу простого текста электронных писем. Это также предупреждает Вас, что некоторые почтовые серверы еще не могли бы поддерживать шифрование, и шифрование осуществления могло заблокировать эти серверы.
Но это - все еще проблема, о которой нужно думать, или действительно ли безопасно сказать, что осуществление шифрования больше не будет проблемой?
Есть ли возможно некоторый крупный поставщик, который уже делает это или что Вы рассматриваете лучшей практикой в эти дни?
Практическая проблема заключается в том, что не каждый SMTP-совместимый (RFC довольно старый) сервер может передавать TLS вашему серверу, поэтому вы можете пропустить получение некоторых сообщений электронной почты.
Философская проблема при этом невозможно сказать, как электронная почта ретранслируется после (или до) прибытия на ваш сервер.
Это означает, что электронное письмо могло уже быть передано в виде обычного текста через ретранслятор.
Любой, кто серьезно относится к защите содержимого своего электронного письма, должен фактически зашифровать его тело. С шифрованием на маршруте всегда правдоподобно, что оно уже было передано в виде обычного текста.
Итак, чтобы ответить на ваш вопрос, принудительное шифрование на уровне SMTP, вероятно, бессмысленно, увеличивает ваши шансы на пропажу электронной почты и нет гарантированного выгодного вознаграждения.
Правка: это относится к принудительному использованию SMTP для ретрансляции, а не , а не отправки электронной почты. При отправке почты необходимо применять шифрование, поскольку SMTP-диалог (а не фактическая электронная почта), возможно, содержит учетные данные для аутентификации.
Нет
RFC 821 исполнилось 33 года. Вы найдете электронные письма, отправленные программами, не поддерживающими STARTTLS. Иногда это будут незавершенные отправители электронной почты (например, внутренние скрипты), иногда полноценные системы, которые устарели, с отключенным / не скомпилированным TLS, системами без достаточной энтропии…
Не так давно я был свидетелем сбоев исходящих писем, потому что принимающие end был настроен так, чтобы разрешать только SMTP через TLS. Это была проблема отправителя (он не должен был использовать эту конфигурацию), но показывает, что это действительно происходит.
Я бы ограничил входящие сообщения только с IP-адресов, настроенных вручную. Если обработчик вашей кредитной карты не может запустить STARTTLS, вы, вероятно, предпочтете прервать соединение (и вызвать локального администратора, чтобы он мог их предупредить!), Чем получить эти (потенциально конфиденциальные) данные в незашифрованном виде. Для исходящих сообщений, если вы ранее подключались к этому узлу с помощью STARTTLS, вы можете захотеть больше не делать это небезопасно, вместо этого рассматривая это как потенциальную угрозу. У вас также может быть список известных всегда используемых хостов STARTTLS, таких как gmail или yahoo.
Там https://www.eff.org/starttls-everywhere проект, обеспечивающий список smtp-серверов, для которых вы можете (должны?) уверенно принудительно использовать starttls.
Совершенно бессмысленно и, вероятно, вредно отказываться от электронной почты от одноранговых узлов, не способных к шифрованию.
Пока ваш сервер настроен для выполнения гибкого шифрования с любым одноранговым узлом, который его предлагает , вы получаете лучшее из обоих миров: шифрование, когда оно доступно, и электронная почта по обычному тексту, когда его нет.
Пока есть серверы, которые не поддерживают шифрование, это просто означает, что они не могут разговаривать с ты; это плохо. Как только все его поддержат, нет разницы между гибким и обязательным шифрованием.
И, как отмечали другие, шифрование на проводе и сквозное шифрование - это две совершенно разные вещи.обращение к различным моделям угроз. Не путайте их.
С точки зрения маркетинга по электронной почте, использование TLS является хорошей практикой и безопасностью, если вы знаете, что он реализован на протяжении всей цепочки доставки. Однако, если безопасность является вашим главным требованием, тогда шифрование самого электронного письма перед его отправкой является наиболее безопасным вариантом (например, с помощью PGP).
Это вопрос политики.
Обычно, когда TLS применяется для входящей и исходящей почты, это делается для ограниченного набора доменов, которые согласовываются сторонами для удовлетворения потребности (например, деловые партнеры могут иметь соглашение о шифровании всей почты между своими компаниями).
Если такое соглашение не заключено, не включайте принудительный режим.
Нет, это очень плохая идея.
На самом деле, как оказалось, большинство STARTTLS серверов / клиентов не поддерживают реализовать какой-либо алгоритм повтора без StartTLS, если соединение TLS не удалось согласовать.
Таким образом, даже реклама STARTTLS в качестве опции уже снижает ваши шансы на получение (и отправку) электронных писем!
Просто ищите, и вы » Я обнаружу, что многие люди не могут отправить ЛЮБУЮ электронную почту в домены Microsoft Outlook, обрабатываемые кластером * .protection.outlook.com:
Сообщения Sendmail отклонены от Microsoft при использовании TLS
Причина: 403 4.7.0 Ошибка установления связи TLS
Обобщая проблемы, представленные в двух вышеупомянутых сообщениях:
- может отправлять любую почту на любой хост, кроме тех, которые обрабатываются Outlook, со STARTTLS или без, [1 2112] может отправлять почту без сертификата клиента и без STARTTLS в Outlook,
- или с сертификатом клиента нулевой длины,
- , но не с сертификатом, который не нравится Microsoft, и в случае сбоя клиенты (ну , серверы, работающие в клиентском режиме) не пытайтесь повторно отправить сообщение без STARTTLS, если сервер получателя действительно объявляет STARTTLS!
Аналогичным образом, когда ваш хост действует как сервер, аналогичная ситуация может возникнуть вне вашего контроля, если вы решаете включить STARTTLS - когда клиентский сервер видит, что ваш сервер в режиме сервера предлагает STARTTLS, он пытается согласовать TLS, но если согласование не удается,они просто ждут и повторяют те же шаги снова, продолжая терпеть неудачу, пока сообщение не будет возвращено отправителю!
И это действительно часто случается с различными доменами в стране STARTTLS!
К сожалению, не меньше Раньше я был сторонником STARTTLS, а теперь я очень лишен прав, потому что был введен в заблуждение безрисковой рекламой того, что, как я думал, должно было быть гибким шифрованием.
Вы не только не должны требовать STARTTLS, но и может быть даже разумным полностью отключить его, если вы хотите обеспечить совместимость.
Я должен согласиться с идеей использования гибкого TLS. Хотя мне тоже есть что добавить к этой идее. Некоторые, вероятно, будут обеспокоены этими предложениями, однако, так как мои предложения здесь сделаны нелегко и без должного рассмотрения, перед вынесением суждения я прошу вас прочитать полное обсуждение по прилагаемой ссылке.
Использование гибкого TLS - безусловно, лучшее решение. Аргумент против MITM - отвлекающий маневр. В конце концов, как MH упомянул в комментарии, даже «законный» SMTP с TLS-соединением может быть MITM'd, и конечный пользователь не станет мудрее из-за того, что подавляющее большинство почтовых клиентов не утруждает себя проверкой сертификатов в сочетании с подавляющим большинством MTA, выполняющих TLS, используют самозаверяющие сертификаты (по крайней мере, если yiur не использует DNSSEC и TLSA / DANE.) В результате этого и, возможно, других факторов, даже можно утверждать, что пока и вы, и остальной мир реализовал DANE / TLSA и DNSSEC, поэтому при использовании гибкого TLS лучше, чем не включать анонимный diffie-hellman (при одновременном использовании PFS). По крайней мере частично, если не в основном, из-за того, что он все еще будет шифровать трафик, защищая от случайного наблюдателя. Для дальнейшей поддержки этой конфигурации (с гораздо более подробным объяснением, чем у меня), пожалуйста, посмотрите комментарии Виктора Духовного в этом сообщении на форуме постфиксов: http://postfix.1071664.n5.nabble.com/ Отключение -Anonymous-Diffie-Hellman-td67965.html
Что касается того, почему можно принять предложения Виктора над предложениями других, то он написал код TLS, а также код DNSSEC, TLSA / DANE для Postfix MTA в дополнение к будучи тем, кто написал черновики IETF как по DNSSEC, так и по TLSA / DANE. Таким образом, я бы сказал, что его слова по этому поводу имеют довольно большой вес, возможно, даже больший, чем у большинства.
Надеюсь, это поможет.
Мы применяем шифрование SMTP (TLS) на нашем общедоступном почтовом сервере уже два года. Мы узнали, что 99,99% всех «пропущенных» сообщений исходят от спамеров, фишеров и известных эксплуатируемых хостов (мы проверяем каждый IP-адрес). У нас были проблемы только с двумя законными компаниями, которые пытались доставлять электронные письма в виде простого текста, но нам было отказано. После того, как мы уведомили их, они изменили свой сервер или провайдера, чтобы решить эту проблему.
Применение TSL на почтовых серверах делает мир безопаснее и практически делает использование спам-фильтров устаревшим, поскольку ни один спамер или фишер никогда не будет использовать сертификат для отправки зашифрованных сообщений. Это поддерживает наш почтовый сервер в чистоте и быстроте.
До того, как мы это сделали, не менее 96% всей полученной почты помечалось нашим фильтром как спам, теперь более 99% входящей почты являются легитимными. Только спамеры будут советовать против этого.