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

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

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

Вступление

Чтобы облегчить понимание, я выделю три высокоуровневых этапа установления соединений между почтовыми серверами.

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

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

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

Обнаружение почтового сервера получателей

Чаще всего это достигается путем поиска в DNS записей MX (Mail Exchange), которые указывают на один или несколько IP-адресов почтовых серверов, предназначенных для получения почты для домена получателя. Однако существуют и другие механизмы, такие как MTA-STS, записи SRV или даже записи A. Ниже мы рассмотрим некоторые элементы MTA-STS, но не подходы к записи SRV/A (хотя у них есть общие недостатки).

Обнаружение почтовых серверов зависит от DNS , и подавляющее большинство DNS-запросов по-прежнему основаны на UDP-пакетах и, следовательно, не требуют установления соединения и не зашифрованы, что позволяет относительно легко как перехватывать, так и вводить поддельные ответы.

Хотя существуют реализации DNS, использующие TCP, TLS и даже DNS поверх HTTPS , они довольно редки, но снижают вероятность перехвата и внедрения между клиентом и сервером.

Однако развертывание TCP/TLS сосредоточено на улучшении или защите соединения, сами по себе они не предоставляют механизма, гарантирующего, что данные, ответы на запросы DNS, являются подлинными и не были подделаны.

Здесь на помощь приходит DNSSEC . Он обеспечивает подход к цифровой подписи с привязкой к доверию, который гарантирует, что любые ответы DNS для доменов с поддержкой DNSSEC могут быть криптографически подтверждены как подлинные и авторитетные.

А как же ДЕЙН?

• DANE требует DNSSEC для всех запросов DNS, что успешно снижает этот риск.

• MTA-STS публикует почтовые серверы, уполномоченные для домена, перечисляя их в файле политики MTA-STS, размещенном на веб-сервере. Хотя подключение к самому веб-серверу может быть HTTPS (с проверкой сертификата), оно не требует, чтобы DNS-поиск этого веб-сервера был безопасным.
• MTA-STS не требует использования DNSSEC, на самом деле, насколько я понимаю, одна из его «конструктивных особенностей» заключалась в том, что он не зависел от DNSSEC.

• Обнаружение почтового сервера домена получателя зависит от DNS, которому без DNSSEC не хватает безопасности, чтобы гарантировать получение ответов.
• DANE предписывает использование DNSSEC, поэтому в качестве расширения SMTP это наиболее эффективный механизм защиты от этого риска.
• MTA-STS не требует обязательного использования DNSSEC и, несмотря на размещение политики на защищенном HTTPS-сервере, по-прежнему полагается на традиционный поиск DNS.
• Однако MTA-STS можно развернуть с DNSSEC, что снизит большую часть этого риска. Это моя рекомендация, если вы находитесь в процессе развертывания MTA-STS.

Мир перешел на HTTPS в мгновение ока. Сегодня очень необычно найти любой веб-сайт, который не поддерживает HTTPS (даже те, которые не принимают данные вашей кредитной карты). Однако электронная почта не претерпела такого же резкого изменения в безопасности и по-прежнему полагается на то, что мы называем «уступающим TLS». В Opportunistic TLS серверы сначала установят небезопасное соединение, а затем попытаются согласовать и обновить соединение до TLS, но с радостью продолжат работу без TLS, если по какой-либо причине они не могут договориться.

Реальная проблема здесь заключается в том, что «Уступающий TLS» изначально открывает небезопасное соединение и обновляет его до TLS (инициируемого методом STARTTLS). Поэтому относительно легко перехватить такое соединение и заблокировать обновление до TLS, замаскировав поддержку STARTTLS на удаленном сервере. Затем оппортунистические почтовые серверы TLS продолжат обмен электронной почтой без заботы и внимания. Хуже того, ни отправитель, ни получатели даже отдаленно не узнают, что это произошло.

Обе стороны в TLS-соединении используют сертификаты PKI, которые также можно использовать для обеспечения дополнительных уровней доверия к тому, что стороны действительно являются теми, за кого себя выдают, и могут быть независимо проверены с помощью якоря доверия . Однако, учитывая, насколько легко получить сертификаты от поставщиков, таких как LetsEncrypt, это становится менее надежным.

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

А как же МТА-СТС?

• MTA-STS устраняет этот риск (предполагая, что вы не находитесь в режиме «тестирования»), неявно требуя, чтобы для обмена электронной почтой было установлено соединение TLS.

• DANE применяет неявное требование для соединения TLS и тем самым снижает этот риск.

• Оппортунистический TLS полагается на незашифрованное соединение для установления возможности обновления до TLS и, таким образом, уязвим для атаки MITM.
• И DANE, и MTA-STS неявно требуют TLS-соединения перед обменом электронной почтой, поэтому они эффективны для обеспечения по крайней мере базового TLS-соединения.
• Одного TLS недостаточно, чтобы предположить, что соединение достаточно защищено/зашифровано. Многие из протоколов и комплектов шифров, реализованных в TLS, считаются небезопасными (подвергаемыми грубой силе). Это отдельная тема, которую мы рассмотрим в следующей статье.

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

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

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

А как же ДЕЙН?

• Проверка сертификата серверов по защищенной DNSSEC записи TLSA является неотъемлемой частью DANE и обеспечивает окончательную печать утверждения для обеспечения соединения.

• MTA-STS не заходит так далеко, его цель сосредоточена на обеспечении обязательности TLS-соединения и не распространяется на проверку полномочий почтовых серверов.

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

MTA-STS предоставляет некоторые ключевые улучшения для решения проблем Opportunistic TLS, но недостаточно далеко, чтобы устранить все недостатки. Добавление DNSSEC к MTA-STS снижает некоторые риски и является моей рекомендацией (если DANE вам не подходит).

Однако DANE предлагает комплексное решение недостатков, обсуждаемых в этой статье. Если вы рассматриваете как MTA-STS, так и DANE, но хотите выбрать только один, то я рекомендую DANE.

Во всем мире зарегистрировано около 365 миллионов доменных имен, и только 3,7 миллиона доменов используют DANE (приблизительно 1%).

Если мы посмотрим на крупнейших почтовых провайдеров, то заметим, что Gmail развернул MTA-STS, но еще не развернул DANE или даже DNSSEC.

Точно так же Microsoft развернула MTA-STS в Exchange Online в этом году и объявила о своем намерении предложить DANE в будущем, но, вероятно, пройдет еще пара лет, прежде чем они будут поддерживать его как для исходящих, так и для входящих.