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


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

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

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

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


36
2017-10-18 12:33


Источник




Ответы:


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

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

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

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

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

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


34
2017-10-18 12:43



Я не думаю, что это лучший ответ. Он подходит к правильному выводу, но по неправильным причинам. Это «позволить совершенству быть врагом хорошего» рассуждения. Я думаю, что лучший ответ заключается в том, что если вам требуется шифрование, вы предотвратите доступ к законному электронному письму (поскольку некоторые серверы SMTP не могут шифровать). Если бы не этот фактор, то принудительное шифрование бы быть полезным, хотя по всем причинам, которые вы перечисляете, это не идеально - это было бы лучше, чем ничего, даже если оно не идеально. - D.W.
Я склонен не соглашаться на совершенство, просто добавляя субперфекции; все же я представил изменение ответа, чтобы подчеркнуть возможную техническую несовместимость серверов, совместимых с RFC, но не поддерживающих TLS. - Alex Mazzariol
Спасибо за Ваш ответ! Сначала я не думал о том, что происходит после того, как мой сервер отправил почту на следующий сервер или, как вы сказали, где сообщение «уже было», пока оно не дошло до меня. Разумеется, нет смысла применять шифрование, если принимающая сторона отправляет его в виде обычного текста (возможно, на сервер-сервер той же компании, но все еще через Интернет). - comfreak
Я выбрал этот ответ как принятый, поскольку он ясно показывает, что принудительное шифрование на моем сервере не гарантирует безопасную / зашифрованную передачу сообщения от отправителя получателю, а только с моего сервера на другой. - comfreak
Я думаю, что этот ответ хорош, но не упоминает о том, что шифрование по-прежнему желательно, учитывая, что только в ограниченном количестве случаев кто-то перейдет на большую длину, чтобы перехватить сообщение с открытым текстом отправителя, чтобы обмануть вас. Если вы скрываетесь от ЦРУ / NSA, это может не помочь вам. Но что было бы лучше, обеспечив шифрование, чтобы никто, явно заинтересованный в том, чтобы читать / перехватывать сообщение отправителей и скрывать его до тех пор, пока третья сторона не решит попытаться отследить вас или все ваши сообщения, хранящиеся на серверах NSA, чтобы в один прекрасный день они могут не только начать ... - momo


нет

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

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

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

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


20
2017-10-18 17:49



Спасибо за ответ и за сообщение этой ссылки! Это, по-видимому, хороший подход при решении проблемы «человек-в-середине-атаки», понижающий соединение до незашифрованного разговора. - comfreak


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

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

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

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


11
2017-10-18 15:38



Я бы сказал, что лучшее из обоих миров также позволит вам увидеть разницу, похожую на «блокировку» страницы SSL в Интернете, так что вы знаете, какие электронные письма были бы заблокированы, если бы вы вынудили TLS - user2813274
@ user2813274 Я согласен, и все. Проверьте свои заголовки; они покажут, выполнялся ли какой-либо данный шаг цепи передачи с помощью шифрования или без него. - MadHatter
@MadHatter, если эти заголовки не были полностью подделаны хопом до вашего. - thrig
Там является разница между условным и обязательным шифрованием. Часто для активного MITM возможно нарушить оппортунистическое шифрование, в результате чего конечные точки отказываются от шифрования, которое можно контролировать. При обязательном шифровании соединение будет удалено, что приведет к отказу в обслуживании, но не к нарушению конфиденциальности. - cjm
@cjm, следовательно, моя точка зрения о моделях угроз. Если вы серьезно пытаетесь защитить от атак MITM, может помочь только сквозное шифрование. Опираясь только на шифрование SMTP, бессмысленно; сложный MITM просто маскируется как ваш сервер, а затем передает вам почту после прочтения. Конечно, ваш сервер может иметь правильно подписанный сертификат (что удивительно редко), но вы не можете контролировать, требует ли система отправки вам, поэтому атака MITM, такая как это, будет успешной, несмотря на любые требования, которые вы устанавливаете в зашифрованном соединении. - MadHatter


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

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

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


10
2017-10-18 14:29





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

На самом деле, как выясняется, большинство 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, но может быть даже разумным полностью отключить его, если вы хотите обеспечить интероперабельность.


2
2017-10-20 10:20





Я должен согласиться с идеей использования оппортунистических 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/Disabling-Anonymous-Diffie-Hellman-td67965.html 

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

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


2
2017-10-20 19:07





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


0
2017-10-20 01:25