Чи є примусовим шифрування (шифрування) застосування шифрування для 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, на яких ви можете (слід?) Впевнено застосовувати використання запуску.

Цілком безглуздо і, мабуть, активно шкідливо, відмовлятися від електронної пошти від непрацездатних програм для шифрування.

Поки ваш сервер налаштований на опортуністичне шифрування з будь-яким одноранговим партнером, який пропонує його, ви отримуєте найкраще з обох світів: шифрування, коли воно доступне, та електронної пошти по простому тексту, коли його немає.

Поки є сервери, які не підтримують шифрування, мандат це просто означає, що вони не можуть з вами спілкуватися; це погано. Після того, як всі підтримують це, немає різниці між умовно-патологічним та обов'язковим шифруванням.

І як зазначали інші, шифрування по дроту та шифрування в кінці - це дві абсолютно різні речі, що стосуються різних моделей загроз. Не плутайте двох.

Це питання політики.

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

Мені доводиться погоджуватися з ідеєю використання опортуністичних TLS. Хоча, у мене є ще щось додати до ідеї. Деякі, ймовірно, будуть порушені пропозиціями, однак, оскільки мої пропозиції тут не зроблені легко і без належного розгляду, перш ніж виносити рішення, прошу вас прочитати повну дискусію за посиланням, що додається.

Використання опортуністичних TLS - це далеко не все найкраще рішення. Кут MITM як аргумент проти нього - червона оселедець. Зрештою, як згадує MH у коментарі, навіть "законний" SMTP з TLS-з'єднанням може бути MITM'd, а кінцевий користувач не стане мудрішим через те, що переважна більшість поштових клієнтів не намагається перевірити сертифікати в поєднанні з переважною більшістю MTA, які роблять TLS, використовують самопідписані сертифікати (принаймні, якщо ви не використовуєте DNSSEC і TLSA / DANE.) Внаслідок цього та, можливо, інших факторів, навіть можна сперечатися, що поки ви і решта світу реалізував DANE / TLSA та DNSSEC, що під час запуску умовно-патогенних TLS, краще, ніж не мати також анонімного диффлеймана (хоча також використовуючи PFS). Принаймні частково, якщо не переважно тим, що він все ще зашифровує захист руху від випадкового спостерігача. У подальшій підтримці цієї конфігурації (з набагато більш детальним поясненням, ніж у мене), будь ласка, дивіться коментарі Віктора Духовни в цій публікації на форумі з постфіксами:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Щодо того, чому можна брати пропозиції Віктора щодо пропозицій інших, добре, він написав код TLS, а також код DNSSEC, TLSA / DANE для Postfix MTA, на додаток до того, що написав чернетки IETF на обох DNSSEC і TLSA / DANE. Як такий, я б сказав, що його слова з цього приводу мають досить велику вагу, напевно, більше, ніж слова більшості.

Сподіваюся, це допомагає.

З точки зору маркетингу електронної пошти, використання TLS є доброю практикою та безпекою, коли ви знаєте, що вона реалізована через увесь ланцюжок доставки. Однак якщо безпека є вашою основною вимогою, то шифрування самого електронного листа перед його надсиланням - це найбільш безпечний варіант (наприклад, з PGP).