Является ли применение шифрования для SMTP хорошей идеей (пока)?

Я использую почтовый сервер, который в настоящее время настроен на использование TLS, если это возможно, при отправке и получении электронной почты.

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

Но стоит ли еще думать об этом или можно с уверенностью сказать, что принудительное шифрование больше не будет проблемой?

Возможно, есть какой-нибудь крупный поставщик, который уже делает это, или что вы считаете лучшей практикой в ​​эти дни?

Практическая проблема заключается в том, что не каждый SMTP-совместимый (RFC довольно старый) сервер может передавать TLS на ваш сервер, поэтому вы можете пропустить прием некоторых сообщений электронной почты.

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

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

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

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

Изменить: Это относится к применению SMTP для целей ретрансляции, а не представления электронной почты. При отправке почты шифрование должно применяться, поскольку диалог SMTP (не фактический адрес электронной почты), возможно, содержит учетные данные для аутентификации.

нет

RFC 821 - 33 года. Вы будете находить письма ретранслировать программами notsupporting STARTTLS. Иногда они будут отправителями электронной почты-заглушки (например, внутренние скрипты), иногда полноценные системы, которые устарели, с TLS отключены / не скомпилированы, системы без достаточной энтропии…

Я не так давно видел сбой исходящих писем, потому что принимающая сторона настроила его только на SMTP через TLS. Это была проблема отправителя (он не должен был использовать эту конфигурацию), но показывает, что это происходит.

Я бы ограничил входящие сообщения только с настроенных вручную IP-адресов. Если процессору вашей кредитной карты не удается запустить STARTTLS, вы, вероятно, предпочитаете прервать соединение (и проконсультироваться с локальным администратором, чтобы он мог предупредить их!), Чем получить эти (потенциально конфиденциальные) данные в незашифрованном виде. Для исходящих сообщений, если вы ранее подключались к этому хосту с помощью STARTTLS, вы можете не делать этого снова небезопасно, вместо этого рассматривая его как потенциальный компромисс. У вас также может быть список хостов, которые всегда используются STARTTLS, таких как gmail или yahoo.

Есть https://www.eff.org/starttls-everywhere проект, предоставляющий список серверов smtp, для которых вы можете (должны?) Уверенно обеспечивать использование starttls.

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

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

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

И, как уже отмечали другие, шифрование по проводам и сквозное шифрование - это две совершенно разные вещи, направленные на разные модели угроз. Не путайте их.

Это вопрос политики.

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

Если такое соглашение не заключено, не включайте принудительный режим.

Нет, это очень плохая идея.

Фактически, как выясняется, большинство серверов / клиентов STARTTLS не реализуют какой-либо алгоритм повторов без StartTLS, если соединение TLS не удается согласовать.

Таким образом, даже реклама STARTTLS в качестве опции уже снижает ваши шансы на получение (и отправку) электронных писем!

Просто выполните поиск, и вы увидите, что многие люди не могут отправлять ЛЮБУЮ электронную почту на домены Microsoft Outlook, обрабатываемые кластером * .protection.outlook.com:

Сообщения Sendmail, отклоненные от Microsoft при использовании TLS

причина: 403 4.7.0 TLS рукопожатие не удалось

Подведем итоги проблем, представленных в двух вышеупомянутых постах:

• может отправлять любую почту на любой хост, кроме тех, которые обрабатываются в Outlook, с или без STARTTLS,
• может отправлять почту без сертификата клиента и без STARTTLS в Outlook,
• или с клиентским сертификатом нулевой длины,
• но не с сертификатом, который не нравится Microsoft, и при сбое клиенты (ну, серверы, работающие в режиме клиента) не пытаются повторно отправить сообщение без STARTTLS, если сервер получателя действительно объявляет STARTTLS!

Аналогично, когда ваш хост действует как сервер, аналогичная ситуация может возникнуть вне вашего контроля, если вы решите включить STARTTLS - когда клиентский сервер видит, что ваш сервер в режиме сервера предлагает STARTTLS, они пытаются согласовать TLS, но если согласование не удается , они просто ждут и повторяют те же самые шаги снова, продолжая терпеть неудачу, пока сообщение не будет возвращено отправителю!

И это случается довольно часто с различными доменами в стране STARTTLS!

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

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

Я должен согласиться с идеей использования оппортунистических TLS. Хотя у меня есть кое-что, что можно добавить к этой идее. Некоторые, вероятно, будут обеспокоены предложениями, однако, поскольку мои предложения здесь не сделаны легкомысленно и без должного рассмотрения, прежде чем выносить суждение, я прошу вас, пожалуйста, прочитать полное обсуждение по прилагаемой ссылке.

Использование оппортунистических TLS является, безусловно, лучшим решением. Угол MITM в качестве аргумента против этого - красная сельдь. В конце концов, как упомянул MH в комментарии, даже «законный» SMTP с соединением TLS может быть MITM и конечный пользователь не может быть мудрее из-за того, что подавляющее большинство почтовых клиентов не утруждают себя проверкой сертификатов в сочетании с подавляющим большинством MTA, использующие TLS, используют самозаверяющие сертификаты (по крайней мере, если вы не используете DNSSEC и TLSA / DANE.) В результате этого и, возможно, других факторов, даже можно утверждать, что пока вы и весь остальной мир реализовал DANE / TLSA и DNSSEC, что при запуске оппортунистического TLS лучше, чем не включать также анонимный diffie-hellman (при этом также используя PFS). По крайней мере, частично, если не главным образом, из-за того, что он все равно будет шифровать трафик, защищая от случайного наблюдателя. В дальнейшей поддержке этой конфигурации (с гораздо более сложным объяснением, чем у меня), пожалуйста, смотрите комментарии Виктора Духовного в этом посте на форуме постфиксов:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Что касается того, почему кто-то может принять предложения Виктора над другими, ну, он написал код TLS, а также код DNSSEC, TLSA / DANE для MTA Postfix, в дополнение к тому, что он написал проекты IETF для обоих DNSSEC. и TLSA / DANE. Таким образом, я бы сказал, что его слова по этому вопросу имеют большой вес, возможно, больше, чем у большинства.

Надеюсь это поможет.

С точки зрения маркетинга по электронной почте, использование TLS является хорошей практикой и безопасным, когда вы знаете, что оно реализовано во всей цепочке поставок. Однако, если безопасность является вашим главным требованием, то шифрование самой электронной почты перед ее отправкой является наиболее безопасным вариантом (например, с PGP).