Хотя мы не станем оспаривать важность обнаружения вредоносного ПО, перед обнаружением должен быть дешевый и эффективный шаг, а именно предотвращение. Вредоносное письмо, которое никогда не будет доставлено получателям, никогда не вызовет проблем с безопасностью. По данным CSO, 94% вредоносных программ в 2020 году будут распространяться через систему электронной почты. Электронная почта, которая остается важным инструментом и по-прежнему составляет основу многих бизнес-процессов, использует один из самых старых и наименее защищенных протоколов связи в Интернете. Несмотря на то, что существует несколько способов применения политик безопасности протокола передачи почты для предотвращения доставки подозрительных писем, эти методы не так широко декларируются и применяются, как следовало бы.
Безопасность другого распространенного, более старого протокола, HTTP, являющегося основой Всемирной паутины, находится в центре внимания уже более десяти лет, что привело к значительному прогрессу в этой области. Достаточно упомянуть тот факт, что HTTP был почти полностью заменен HTTPS, зашифрованной версией того же протокола, которая обеспечивает конфиденциальность, целостность и подлинность при передаче данных. Не стоит забывать, что всего несколько лет назад некоторые сайты отправляли учетные данные, данные клиентов или платежную информацию через Интернет без какого-либо шифрования. После принятия CCPA, GDPR и других подобных нормативных актов это стало практически немыслимым. Простой новостной сайт без какой-либо аутентификации теперь использует HTTPS, совершенно справедливо, чтобы избежать модификации контента во время передачи, просто для примера. Попробуйте представить себе потенциальные последствия атаки «человек посередине» на один из самых популярных новостных сайтов. Поскольку многие бизнес-процессы используют Интернет и сам протокол не может быть улучшен, необходимо усовершенствовать экосистему в целом, чтобы предотвратить атаки на понижение, кликджекинг, межсайтовый скриптинг и другие вредоносные действия. Но насколько безопасна передача электронной почты? Электронная почта, несомненно, по-прежнему является основой многих формальных и неформальных бизнес-процессов, и поэтому до тех пор, пока это так, она будет являться целью злоумышленников. Ответ на вопрос о безопасности электронной почты прост, но не столь обнадеживающий. Состояние безопасности передачи почты не так хорошо, как в области передачи веб-страниц.
Существуют значительные различия между передачей почты и передачей веб-страниц. Передача веб-страниц обычно осуществляется между веб-клиентом (браузером) и веб-сервером. С другой стороны, почта обычно передается получателям не почтовым клиентом, а сервером почтового провайдера отправителя. Затем он передает почту на почтовый сервер провайдера электронной почты получателя, а затем, наконец, получатель асинхронно скачивает ее с этого сервера. Как видите, существует взаимодействие между сервером и почтовым провайдером, на которое не может повлиять ни один из клиентов. Детали этого взаимодействия определяются серверами-участниками и простым протоколом передачи почты (SMTP), который был разработан в начале 1980-х годов как простой, а не безопасный.
Первоначально протокол не содержал никаких возможностей шифрования. Однако в 1999 году было введено оппортунистическое использование TLS, хотя и только в качестве дополнительного расширения. Двадцать лет спустя, согласно соответствующему RFC, публично упоминаемый сервер все еще не обязан использовать этот механизм для локальной доставки почты. Это означает, что владелец домена получателя, несмотря на законный интерес, не имеет права требовать шифрования в процессе доставки почты. Инициирование шифрования зависит от доброй воли отправителя. Без этого и клиент, и сервер подвергаются опасности со стороны злонамеренной третьей стороны с возможностью «человек посередине», которая может принудительно запретить шифрование, независимо от того, что обе стороны намерены шифровать. Без инициирования шифрования получатель не может проверить подлинность отправителя и наоборот, и, кроме того, почтовая передача уязвима для подслушивания, а также для модификации содержимого. В таких обстоятельствах получатель может считать, что отправитель заслуживает доверия, и, следовательно, считать, что вложение заслуживает доверия. Однако потенциально вложение может оказаться вредоносным ПО, подделанным в почту злоумышленниками.
Возможные решения
Существует несколько механизмов, таких как BIMI, DANE, DKIM, DMARC, DNSSEC, MTA-STS, SPF, TLS-RPT, которые направлены на исправление ситуации, с большей или меньшей степенью успеха. Мы рассмотрим теории, лежащие в основе этих механизмов, их практические ограничения, трудности настройки и достигнутый эффект.
В целом, можно сказать, что наиболее важными ограничениями являются распространенность и выполнимость. Как видно из диаграммы, существуют значительные различия в распространенности, если сравнивать домены, входящие в топ-1000, 100000 и миллион доменов Majestic Million. Распространенность среди самых популярных доменов гораздо выше, чем среди остальных. Причина не может быть только в том, что компании из списка Fortune 1,000 имеют гораздо лучшие финансовые условия, так как эти механизмы могут быть внедрены без значительных затрат. Одной из причин может быть недостаток знаний, несмотря на то, что существует несколько руководств и простых в использовании инструментов для получения необходимых конфигураций для включения этих механизмов. Другая причина может заключаться в том, что не существует регулирующего органа, который мог бы обеспечить использование этих механизмов или выполнение политик, объявленных этими механизмами, а только рекомендовать их, как это делает NIST. Последняя причина, о которой следует упомянуть, заключается в том, что владельцы доменов также не имеют возможности заставить владельцев почтовых систем на стороне получателя выполнять заявленные политики. В любом случае, крупные технологические компании, такие как Google, занимающая значительную долю рынка почтовых услуг, начали оказывать давление на владельцев доменов, желающих предоставлять почтовые услуги для своего домена, публикуя политики, хотя они не обязательно строго их соблюдают.
В целом, отсутствие таких механизмов на стороне отправителя означает относительно высокий риск того, что электронные письма, отправленные с домена, попадут в папку спама или будут отклонены, по крайней мере, крупнейшими почтовыми провайдерами. Отсутствие проверки политик, объявленных с помощью этих механизмов, на стороне получателя может означать относительно высокий риск того, что входящие письма будут приходить от неавторизованных или даже вредоносных субъектов, которые могут выдавать себя за доверенные стороны. Обычно выдача себя за другого является первым шагом целенаправленной атаки, в ходе которой мошенники могут внедрить в организацию дезинформацию или фиктивный контент, такой как мошеннические программы, вирусы, шпионские и вредоносные программы.
Структура политики отправителя (SPF)
Концепция
Сторона отправителя может опубликовать политику с помощью этого механизма, объявив, каким серверам разрешено отправлять почту от имени данного домена. Сторона получателя может использовать опубликованные политики для проверки того, что входящая почта действительно отправлена авторитетным сервером. Сама политика публикуется в TXT-записи заданного домена (например, example.com), а серверы могут быть объявлены по их IP-адресам или косвенно, со ссылкой на другие DNS-записи. Самый простой случай, по крайней мере в этом отношении, заключается в том, что владелец домена обслуживает свой почтовый сервер, а запись MX домена содержит IP-адрес (адреса) почтового сервера (серверов), поэтому ссылаться следует только на запись MX. С другой точки зрения, может показаться, что проще использовать программное обеспечение как услугу для реализации почтовой службы. В этом случае вы можете включить политику поставщика SaaS или просто перенаправить на него.
example.com. IN TXT “v=spf1 mx -all”
example.com. IN TXT “v=spf1 include:_spf.google.com -all”
example.com. IN TXT “v=spf1 redirect:spf.protection.outlook.com -all”
Угрозы
Самая сложная часть системы политики отправителя — это не явное объявление серверов, а объявление действий по умолчанию. Действие по умолчанию отвечает на вопрос, что делать, когда получатель понимает, что не существует явного правила, соответствующего IP-адресу фактического отправителя. Для этого может использоваться специальный механизм (all), опционально с классификатором. Во всех приведенных выше примерах используется квалификатор fail (-), поэтому результат оценки Sender Policy Framework будет неудачным для клиентов, не указанных явно в политике, что означает, что они не авторизованы для использования домена.
Хотя отказ по умолчанию считается наиболее безопасным методом, только менее трети записей SPF используют его. Это может быть связано с тем, что это не самый удобный метод с точки зрения обслуживания, так как отсутствие IP-адреса может привести к сбою в доставке.
Есть два других варианта избежать этой проблемы. Владельцы доменов могут явно заявить, что они не утверждают, является ли IP-адрес авторизованным или нет. Это можно сделать, добавив модификатор neutral (?). Это может показаться удобным с точки зрения технического обслуживания, но практически не имеет никакой дополнительной ценности с точки зрения безопасности. Результат будет таким же, если отсутствует значение по умолчанию, и аналогичный случай, когда отсутствует вся запись SPF. При подсчете всех записей MX, а не только тех, которые содержат записи SPF TXT, соотношение нейтральных модификаторов со значением по умолчанию (все) составляет более одной трети. Более половины записей SPF используют модификатор soft fail (~) при объявлении поведения по умолчанию, что означает, что хост, вероятно, не авторизован. С точки зрения безопасности, это чуть больше, чем если бы он был нейтральным.
Почему действие по умолчанию так важно? Представьте себе политику брандмауэра, которая содержит правило по умолчанию, декларирующее, что должно произойти, когда ни одно правило не соответствует трафику в явном виде, когда оно может сказать, что трафик не утверждает или, вероятно, не авторизован. Это был бы кошмар безопасности. Владельцы доменов должны знать, какие серверы являются авторитетными, и должны строго заявлять об этом. В этом случае получатель может быть уверен, что отправитель является авторитетным и письмо от представителя доверенной компании действительно исходит от него, и, как следствие, не стать жертвой фишинговой или социально-инженерной атаки. Хотя строгие правила могут повлиять на непрерывность бизнеса, что необходимо учитывать, этот вопрос должен решаться с помощью другого механизма, такого как DMARC, а не путем расширения политики.
Серьезным ограничением системы политики отправителя является то, что серверы авторизуются по их IP-адресу (адресам), что уязвимо для IP-спуфинга, и они могут быть объявлены косвенно, ссылаясь на IP-адреса по именам хостов или другим записям DNS, которые уязвимы для DNS-спуфинга. Поскольку политика хранится в записи DNS, она должна передаваться таким образом, чтобы гарантировать целостность данных: без DNSSec или хотя бы DNS через TLS/HTTPS информация о политике уязвима к подделке и изменению. Самая серьезная проблема с системой Sender Policy Framework заключается в том, что, хотя ее распространенность относительно высока, действительно важным вопросом является соотношение серверов-исполнителей. В любом случае, хотя Sender Policy Framework может повысить уровень безопасности, публикация политики имеет лишь скромный эффект, что означает, что ее следует сочетать с другими механизмами, поскольку она не может доказать ни целостность, ни конфиденциальность почты.
DomainKeys Identified Mail (DKIM)
Концепция
Для сравнения, механизм политики отправителя позволяет определить, является ли сервер авторитетным для отправки письма от имени данного домена, в то время как метод DomainKey Identified Mail может использоваться для аутентификации самого письма независимо от того, каким был IP-адрес отправителя. Отправитель вставляет в письмо заголовок (DKIM-Signature), который содержит как минимум хэш тела (bh), подпись содержимого (b), список заголовков (h), включенных при вычислении подписи, алгоритм (a), использованный для создания подписи, и расположение (d, s) открытого ключа, который может быть использован для проверки подписи.
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
Почтовый сервер получателя просто расшифровывает подпись с помощью открытого ключа, найденного в указанном месте. Факт успешной расшифровки доказывает, что письмо было подписано субъектом, который владеет закрытым ключом, связанным с открытым ключом, используемым для расшифровки подписи. Расшифрованное значение является хэшем оригинального письма, который был вычислен модулем подписи сервера отправителя. Сервер-получатель повторно вычисляет хэш и сравнивает его с результатом расшифровки. Если два хэша идентичны, то тело письма (включая вложения) и перечисленные заголовки гарантированно не были изменены третьей стороной. По сути, это означает, что в письме нет вредоносного вложения, если только отправитель не приложил его, и никто не изменил какие-либо данные в письме, например, номер счета, совершив мошенничество с электронной почтой.
Слабые стороны
Выбор подходящего алгоритма подписи и размера открытого ключа требует осторожности при работе с этим механизмом, поскольку не слишком удачное решение может сделать бессмысленными все усилия, приложенные до сих пор. Традиционный тип открытого ключа RSA с размером ключа не менее 2048 бит или любой ключ на основе эллиптической кривой с размером ключа не менее 224 бит, согласно NIST, может оправдать ожидания. Поскольку можно установить несколько ключей, вы можете настроить как ключ RSA для совместимости, так и ECDSA для современности и использования преимуществ криптографии на основе эллиптической кривой, таких как меньший размер ключа. Алгоритм подписи SHA-2 с любым размером дайджеста сообщения может быть подходящим. Однако SHA-1 категорически противопоказан, поскольку против этого алгоритма существует атака коллизии выбранного префикса. Он требует больших вычислительных мощностей, что делает взлом в реальном времени практически невозможным, даже с учетом среднего времени задержки письма, хотя существует возможность атаки воспроизведения, когда злоумышленник может отправить почти такое же письмо позже с измененным номером банковского счета и сроком оплаты, в то время как подпись все еще действительна. Слабым местом механизма DKIM является не криптография, а тот факт, что DKIM не может обеспечить конфиденциальность.
Строгая транспортная безопасность MTA (MTA-STS)
Концепция
MTA Strict Transport Security призвана решить проблему конфиденциальности при отправке почты. Хотя протокол SMTP изначально не содержал возможности шифрования, позже в качестве расширения была добавлена опциональная возможность шифрования, которая до сих пор не является обязательной. Аналогичная ситуация наблюдается и с незашифрованными протоколами HTTP и зашифрованными HTTPS. Злоумышленник с возможностью «человек посередине» может заставить клиента использовать незашифрованный HTTP, если соединение с сервером было инициировано с помощью этого протокола, независимо от того, поддерживает ли сервер зашифрованный протокол HTTPS или нет. Это означает, что весь трафик, передаваемый между сторонами, который может содержать конфиденциальную информацию, может быть перехвачен злоумышленником. Существует условие, которое должно быть выполнено для успешного проведения атаки, а именно: сервер должен поддерживать незашифрованную версию протокола. HTTP не обязательно, но SMTP всегда, а значит, информация о том, что шифрование может быть использовано, должна дойти до клиента. Это и есть Strict Transport Security, которая реализована в виде заголовка в случае HTTP и публикации записи DNS в случае SMTP.
_mta-sts.example.com. IN TXT "v=STSv1; id=20210602165800Z;"
В ходе нашего исследования мы обнаружили, что большинство доменов, поддерживающих MTA-STS, используют дату в поле id. Если предположить, что дата в поле id — это дата публикации последней политики, а также предположить, что политики меняются не очень часто, то можно построить диаграмму, кумулятивно показывающую, сколько политик MTA-STS было опубликовано. Хотя кривая может свидетельствовать о росте, текущая распространенность не достигает и одного процента.
В отличие от протокола HTTP, протокол SMTP не может быть перенаправлен на зашифрованный канал, поскольку протокол SMTP не содержит чего-то подобного коду статуса ответа «перемещен навсегда» в HTTP, поэтому информация о том, что сервер хочет использовать зашифрованную связь, должна доходить до клиента по независимому каналу. В этом случае используется DNS, как и в Sender Policy Framework или DomainKey Identified Mail. Подобно предыдущим механизмам, MTA Strict Transport Security публикуется в TXT-записи. Разница в том, что TXT-записи указывают только факт наличия и текущую версию, а сама политика распространяется через HTTPS из «известного» источника. Запись DNS содержит короткую строку (id), которая уникально идентифицирует данный экземпляр политики, чтобы отправители могли определить, когда политика была обновлена.
version: STSv1
mode: enforce
mx: mail1.example.com
mx: mail2.example.com
max_age: 86400
Политика похожа на заголовок Strict Transport Security в случае HTTP. Она содержит список (mx) серверов, на которых может обрабатываться почта для данного домена, значение времени жизни (max_age) политики, означающее, что клиент может кэшировать политику до этого значения, и режим (mode), указывающий на ожидаемое поведение сервера-отправителя в случае неудачи проверки политики. Политика может объявить, что сервер-отправитель не должен доставлять (enforce) сообщение на сервер, который не прошел проверку имени хоста или сертификата, или не имеет возможности TLS. Для целей тестирования существует режим (testing), который позволяет доставлять почту, несмотря на то, что произошел сбой проверки, но сервер-отправитель может отправить отчет об этом сбое (см. далее TLS-RPT). Существует также режим (none), указывающий на отсутствие активной политики. Сегодня чуть более половины владельцев доменов публикации MTS-STS хотят применять эту политику, в то время как другая половина, предположительно, находится на стадии тестирования. Однако следует отметить, что доля доменов, поддерживающих MTA-STS, в миллионе крупнейших составляет всего 0,7%.
Угрозы
Публикация политики MTA-STS необходима, но далеко не достаточна. Она должна соблюдаться для минимизации риска атаки MITM для обеспечения незашифрованного метода SMTP-коммуникации. Тем не менее, существование и применение протокола TLS не обязательно гарантирует конфиденциальность. Качество и производительность шифрования сильно зависят от деталей настроек TLS. Их следует определять и регулярно пересматривать с должной тщательностью, учитывая при необходимости требования соответствующих стандартов (NIST, PCI DSS, HIPAA).
Слабые стороны
TLS имеет существенное преимущество, а именно: он решает не только проблему конфиденциальности, но и проблему целостности, на которую нацелен DKIM. Однако следует отметить, что MTS-STS не может гарантировать конфиденциальность и целостность на протяжении всего процесса отправки почты, несмотря на Pretty Good Privacy (PGP) или Secure/Multipurpose Internet Mail Extensions (S/MIME) — только в отношении связи MTA, как следует из названия, поэтому в случае связи клиент-сервер (MUA) существуют те же проблемы, когда протокол имеет только оппортунистическую возможность TLS, как IMAP и POP3. К недостаткам механизма относится тот факт, что он требует обслуживания веб-сервера для публикации политики MTA-STS независимо от того, намерен ли владелец домена публиковать веб-страницу или нет, а также требует обслуживания сертификата X.509 для этого веб-сервера, поскольку только HTTPS разрешен для загрузки политики.
SMTP TLS Reporting (TLS-RPT)
Концепция
Хотя обсуждаемые до сих пор темы были строго связаны с безопасностью, мы также должны учитывать непрерывность бизнеса. Внедрение обсуждаемых механизмов несет в себе риск с точки зрения доставки почты. Этот риск не может быть передан и не должен быть принят, так как его можно уменьшить с помощью механизма SMTP TLS Report, объявляющего конечные точки отчетности, куда серверы-отправители могут сообщать о сбоях в проверке политики. Политика может быть опубликована в одной или нескольких TXT-записях, содержащих совокупный URI отчета (rua), который может быть либо адресом электронной почты, либо конечной точкой HTTPS.
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:reports@example.com"
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=https://reporting.example.com/v1/tlsrpt"
Слабые места
Преимущество механизма заключается в том, что он позволяет получать информацию о сбоях проверки MTA-STS на почтовых серверах-отправителях, что может быть как простой технической проблемой, так и активной атакой. Недостатком механизма является то, что почтовым серверам может потребоваться использование протокола (HTTPS), который не связан с отправкой почты и поэтому требует дополнительной функциональности в реализации почтового сервера. Кроме того, протокол имеет свои собственные механизмы безопасности (HSTS, Report-To, Network Error Logging, Expect-CT, …), которые должны поддерживаться в качестве HTTP-клиента в почтовом сервере для обеспечения максимально возможного уровня безопасности. Отчеты о нарушении политики на основе писем требуют правильно настроенного DomainKey Identified Mail (DKIM) на стороне почтового сервера, отправляющего отчет. Если проверка DKIM не удается на стороне почтового сервера-получателя отчета, отчет может быть проигнорирован, согласно RFC. Однако в RFC не обсуждается тот факт, что также может быть проверен Sender Policy Framework, поскольку отчет фактически отправляется почтовым сервером от имени определенного домена. С помощью этих проверок аутентификация корреспондента может быть несколько слабой, поскольку злоумышленник может купить домен, применить правильные настройки DKIM и SPF и отправить дезинформирующие отчеты. Однако при такой деятельности существует риск, что почтовый сервер будет добавлен в черный список. Другой вариант, отправка отчета через HTTPS, предоставляет злоумышленнику гораздо больше возможностей для отправки дезинформирующих отчетов, поскольку получателю гораздо сложнее проверить подлинность отправителя отчета. Возможно, именно по этой причине подавляющее большинство владельцев доменов предпочитают сообщать о нарушении MTA-STS по почте, а не через HTTPS. Это означает, что существует риск, что поддельные отчеты будут отправлены злоумышленником для генерации ложных положительных предупреждений, подрывая доверие к такого рода отчетам, что может указывать на атаки типа «человек посередине» против нашей почтовой системы.
Угрозы
Еще одной проблемой отчетности является тот факт, что она является полностью добровольной. Публикация политики TLSRPT с соответствующим значением URI агрегированного отчета (rua) не обязательно означает, что вы действительно получите какие-либо отчеты, так как получатель может поддерживать или не поддерживать механизм TLSRPT. Даже если получатель поддерживает механизм, далеко не факт, что он поддерживает отправку отчетов, а также намерен отправлять отчеты, поскольку для этого требуется конфигурация и определенное количество ресурсов.
Аутентификация, отчетность и соответствие сообщений на основе домена (DMARC)
Концепция
Отношения между рассмотренными ранее TLS-RPT и MTA-STS аналогичны отношениям между DMARC и Sender Policy Framework (SPF) или DomainKey Identified Mail (DKIM). Когда проверка SPF или DKIM не удается, почтовый сервер-получатель может отправить отчет о неудаче владельцу домена, определенному в записи DMARC TXT. По сравнению с TLS-RPT можно отметить, что здесь присутствуют более сложные настройки. Можно установить не только один тип конечной точки отчета, но и один для совокупной обратной связи (rua) и другой для информации о сбоях в конкретном сообщении (ruf). Интервал отчетов (ri) также может быть установлен, чтобы указать запрос получателям почты генерировать агрегированные отчеты, разделенные не более чем запрошенным количеством времени, и последнее, но не менее важное, политика публикуется как часть DMARC применяется к домену и может также применяться к субдоменам. Владелец домена может попросить получателей почты не предпринимать никаких конкретных действий (none), относиться к почте, не прошедшей проверку DMARC, подозрительно (quarantine) и помещать ее, например, в папку спама, или отклонять (reject) почту, не прошедшую проверку DMARC.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com"
Соотношение необходимых действий наглядно показывает, насколько сильно бизнес зависит от почтовых систем и насколько непрерывность бизнеса важнее безопасности. При использовании принципа «безопасность превыше всего» любая почта, не прошедшая проверку DMARC, будет рассматриваться как подозрительная и должна быть помещена в карантин или отклонена. За исключением 1000 крупнейших владельцев доменов, только меньшинство достаточно смелы, чтобы попросить получателей почты поместить ее в карантин или отклонить. В других случаях большинство просит получателей почты не предпринимать никаких действий, что ставит под сомнение смысл использования DMARC.
Слабые стороны
Аутентифицировать издателя отчета так же сложно, как и в случае SMTP TLS Reporting (TLS-RPT), поэтому существует риск, что отчеты будут подделаны. Несмотря на TLS-RPT, DMARC поддерживает только доставку отчетов по почте, поэтому аутентификация отправителя возможна, но только в ограниченном виде.
Угрозы
Кстати, возможна ситуация, когда есть два сервера, которые поддерживают DMARC и намерены отправлять отчеты при возникновении проблемы, но DMARC взаимно отказывает во время проверки почты с отчетами из-за проблемы конфигурации DMARC или реализации проверки DMARC. В этом случае отправка отчета DMARC взаимно инициируется отчетом DMARC другого сервера, что потенциально может привести к бесконечному циклу. Существуют также ограничения спецификации DMARC, такие как процент (pct) сообщений, к которым должна применяться политика DMARC, или ранее упомянутый интервал отчетов (ri), но эти опции призваны помочь внедрению DMARC, а не избежать атак.
Фирменные индикаторы для идентификации сообщений (BIMI)
Рассмотренные выше механизмы относятся к коммуникации между машинами (M2M). В них нет — или нет хорошо объявленных — последствий успеха и неудачи, обращенных к пользователю. BIMI стремится заполнить этот пробел и сделать результат работы предыдущих механизмов видимым для пользователя. BIMI позволяет отображать логотипы, контролируемые брендом, в поддерживающих почтовых клиентах (MUA) только в том случае, если письмо хорошо аутентифицировано. Это означает, что домен отправителя должен опубликовать DMARC для домена и поддоменов, где политика должна быть установлена либо на карантин, либо на отклонение, а процентная политика поддоменов не может быть меньше 100. Чтобы логотип бренда отображался в почтовом клиенте, письмо должно пройти проверку подлинности DMARC и проверку BIMI, гарантирующую, что домен организации не был выдан за другой, а индикатор бренда является действительным.
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example/bimi/logo.svg"
Слабые стороны
Конфигурация относительно проста по сравнению с ранее описанными механизмами, но следует отметить, что против нее может быть проведена и относительно простая атака. После публикации логотипа злоумышленник может зарегистрировать похожий домен, настроить DKIM, DMARC и скопировать индикатор, чтобы сымитировать атакуемый домен и опубликовать его как свой собственный. В этом случае в почтовом клиенте получателя появится тот же логотип, что и в письме, пришедшем с атакованного или атакующего домена, поэтому получателю будет так же сложно отличить два домена, как и раньше. Ситуация намного хуже, когда атакуемый домен не публикует BIMI, а только атакующий, поэтому последний может казаться более надежным, чем первый. На эту слабость направлены сертификаты Verified Mark Certificates (VMC), которые предоставляют подписанное цифровой подписью доказательство того, что организации разрешено использовать индикатор марки, подобно расширенной валидации, когда сертифицируется не только домен, но и название организации и другие описательные данные. Механизм основан на X.509, поэтому он несет в себе все сложности и трудности, связанные с ним, включая валидацию, проверку отзыва и прозрачность сертификата. Сертификаты Verified Mark могут быть приобретены организацией, только если ее логотип является торговой маркой, поэтому есть опасения, что VMC часть BIMI возвращает нас во времена до Let’s Encrypt, когда не было возможности подписать сертификат в общепризнанном центре сертификации бесплатно, что означает, что он не может достичь высокой распространенности, как и расширенная валидация.
Расширения безопасности системы доменных имен (DNSSEC)
Концепция
DNSSEC — это набор спецификаций расширений для защиты данных, обмениваемых с помощью протокола DNS в недоверенных сетях, таких как Интернет. DNSSEC обеспечивает подлинность и целостность данных, но не конфиденциальность. Поскольку информация, хранящаяся в записях DNS, связанных с ранее рассмотренными механизмами (SPF, DMARC, DKIM…), является публичной, конфиденциальность не требуется, но аутентичность и целостность требуются, то есть мы должны быть уверены, что информация не будет скомпрометирована злоумышленником. DNS через TLS (DoT) и DNS через HTTPS также обеспечивают подлинность и целостность в дополнение к конфиденциальности, но DNSSEC имеет значительное преимущество перед ними, а именно: он может обеспечить подлинность и целостность во время потенциально рекурсивной процедуры разрешения имен. DoT и DoH могут обеспечить конфиденциальность, целостность и подлинность между DNS-клиентом и DNS-резольвером, но невозможно гарантировать, что все DNS-серверы используют DoT/DoH при обслуживании запроса, а клиент не имеет информации о том, использовали они DoT/DoH или нет. Следует отметить, что эти два протокола никогда не предназначались для достижения этой цели, а вместо этого обеспечивали конфиденциальность, а также приватность для конечного пользователя.
Слабые стороны
В случае DNSSEC целостность и подлинность обеспечиваются цифровыми подписями. Ответы из зон, защищенных DNSSEC, подписываются цифровой подписью с помощью ключа, открытая часть которого находится в записи DNSKEY данного домена. Используя этот открытый ключ, клиент DNS может проверить целостность и подлинность ответа. Как и в других случаях, когда целостность и подлинность обеспечиваются цифровыми подписями, ключевым моментом является цепочка доверия, а также типы ключей, их размеры и алгоритмы дайджеста, используемые в цепочке. Открытые ключи, содержащиеся в записях DNSKEY, подписываются DNSKEY домена верхнего уровня вплоть до верхнего уровня (TLD) и корневого домена. Параметры этих ключей определяют уровень безопасности. Поскольку DNSSEC является относительно старым протоколом интернета, и ранние версии не поддерживали сильные алгоритмы шифрования и большие размеры ключей, поэтому обратная совместимость приводит к тому, что до сих пор используются небольшие размеры ключей, однако, большие также поддерживаются.
В настоящее время лишь незначительное меньшинство доменов верхнего уровня используют 1024-битный ключ RSA в качестве самого сильного ключа. В основном используются 2048-битные ключи RSA, хотя следует отметить, что применяются и ключи RSA с меньшим размером ключа. Распространенность открытых ключей на основе эллиптических кривых (ECDSA), несмотря на все их преимущества, особенно низка среди доменов верхнего уровня. Используются только 256-битные ключи, где эквивалентный размер ключа RSA составляет 3072, не используются ни большие размеры ключей, ни кривые алгоритма цифровой подписи Эдвардса (Edwards-curve Digital Signature Algorithm, EdDSA), хотя последний сейчас рекомендуется. Алгоритмы дайджеста не следуют той же схеме, что и типы и размеры ключей: обратная совместимость не оказывает существенного влияния. Только незначительное меньшинство предлагает выходной алгоритм SHA-1. Большинство доменов верхнего уровня предлагают алгоритмы сильного дайджеста.
Следует отметить, что распространенность DNSSEC, к сожалению, низка, несмотря на заявление NIST о том, что организации должны развернуть DNSSEC для всех серверов имен DNS и проверять ответы DNSSEC на всех системах, получающих электронную почту, чтобы обеспечить аутентификацию и защиту целостности записей ресурсов DNS, о которых говорилось выше.
Аутентификация именованных сущностей на основе DNS (DANE)
Концепция
DANE — это протокол, позволяющий привязывать сертификаты X.509 к доменным именам с помощью ранее рассмотренного DNSSEC. Наиболее важным результатом привязки доменных имен и сертификатов X.509 является то, что это делает ненужным любой центр сертификации (ЦС), поскольку он может объявить сертификат X.509 или открытый ключ, используемый на конкретной службе (например, сервере электронной почты) домена. В этом случае открытый ключ X.509 не нуждается в сертификации третьей стороной (CA) того, что открытый ключ X.509 относится к конкретному домену. В рамках выдачи сертификата, подтвержденного доменом, владелец домена должен доказать свое право на сертификацию, в основном путем создания записи DNS с указанным значением. Однако в случае DANE запись TLSA уже создана для хранения открытого ключа или его хэша, поэтому полномочия доказываются путем сопоставления открытого ключа или сертификата X.509 в записи DNS и предоставляются службой. Этот механизм также делает ненужным сопоставление общего имени сертификата и альтернативного имени субъекта (SAN), поскольку сертификат и доменное имя связаны записью DNS, однозначно относящейся к доменному имени. Это означает, что нет необходимости подтверждать привязку центром сертификации, поскольку она криптографически подтверждается DNSSEC. Проверка отзыва сертификата, которая является ахиллесовой пятой всей инфраструктуры открытых ключей (PKI), также становится ненужной, поскольку срок действия сертификата не имеет смысла в этой среде: нет сертификации третьей стороной, срок действия которой может истечь, и владелец домена просто прекращает публикацию ключа, если есть подозрения, что он скомпрометирован. Аналогичная ситуация складывается, когда владелец домена просто хочет регулярно менять ключи, чтобы уменьшить срок их действия, так как это было бы настоятельно рекомендовано, а сейчас блокируется центрами сертификации, несмотря на ряд недостатков механизмов проверки отзыва.
_25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )
Подчеркнутый ранее способ работы не означает, что DANE не может работать вместе с PKI. Записи TLSA имеют четыре поля данных: использование сертификата (2), селектор (0), тип соответствия (1) и данные ассоциации сертификатов соответственно. Использование сертификата определяет, что данные ассоциации сертификатов содержат листовой сертификат (конечный субъект или EE) или ЦС (доверенный якорь или TA), а также определяет, должен ли сертификат, предоставленный сервером, быть выдан ЦС, которому доверяет приложение, выполняющее проверку (PKIX), или нет (DANE). Использование сертификата может принимать следующие четыре значения, при которых сертификат, предоставляемый сервером во время рукопожатия TLS, должен:
- быть выдан уже доверенным ЦС, чей сертификат опубликован в данных ассоциации сертификатов (ограничение ЦС или PKIX-TA)
- быть выдан уже доверенным ЦС, чей сертификат должен точно соответствовать сертификату, опубликованному в данных ассоциации сертификатов (ограничение сертификата службы или PKIX-EE)
- быть выданным УЦ, опубликованным в данных ассоциации сертификатов (Trusted anchor assertion или DANE-TA)
- точно соответствовать сертификату, опубликованному в данных ассоциации сертификатов, и может быть самоподписанным сертификатом (Domain issued certificate или DANE-EE).
Selector определяет, должен ли полный сертификат (0) или информация об открытом ключе субъекта, являющаяся частью сертификата, отправленного сервером, быть сопоставлена с данными ассоциации, а тип сопоставления определяет способ представления данных ассоциации сертификатов. Все выбранные данные могут быть представлены либо в виде данных ассоциации сертификатов (0), либо в виде хэша (1/2).
DANE означал бы гигантский скачок в направлении децентрализованного интернета, который сохраняет поддержку традиционной PKI, предоставляя своего рода цифровое самоопределение для владельца домена. В то же время это решило бы проблему того, что клиенты сейчас доверяют заранее определенной группе корневых центров сертификации, члены которой зависят от производителя клиентского приложения, независимо от того, что владелец домена доверяет только одному центру сертификации, который фактически выдал сертификат, используемый сервером. Поддерживающие DANE ограничения могут быть применены к ряду доверенных ЦС — включая число ноль, что означает, что владелец домена может решить полностью пропустить ЦС.
Слабые стороны
Несмотря на все преимущества DANE, есть один неизбежный недостаток, а именно отсутствие поддержки клиентских приложений, что делает DANE лишь теоретическим решением нескольких серьезных практических проблем.
Выводы
Учитывая серьезные недостатки старого доброго протокола передачи почты, настоятельно рекомендуется вооружить почтовые системы как можно большим количеством дополнительных механизмов безопасности, согласно NIST, который рекомендует организациям развернуть SPF, MTA-STS, DANE и DNSSEC, чтобы избежать получения почты от неаутентифицированных источников по ненадежному каналу. Тем не менее, между рассмотренными механизмами есть совпадения, все они необходимы для обеспечения полной конфиденциальности, целостности и подлинности получаемой почты, а также для того, чтобы знать о подозрительном поведении отправителей. Рассмотренные механизмы не требуют значительных затрат на внедрение или обслуживание, особенно учитывая их несомненную пользу. Организации должны объявлять политики, чтобы помочь друг другу принимать обоснованные решения. Эти политики касаются того, какие серверы являются авторитетными для отправки электронной почты по имени их доменов (SPF) и хотят ли они использовать шифрование (MTA-STS, DANE) для обеспечения конфиденциальности при получении почты, каковы доказательства того, что полученное письмо действительно было отправлено отправителем (DKIM), и как стороны могут информировать друг друга при возникновении ошибок или подозрительного поведения (DMARC, TLS-RPT). Они также должны подтверждать целостность и подлинность этих политик (DNSSEC). Это означает, что принцип «никогда не доверяй, всегда проверяй» модели безопасности Zero Trust Security Model необходим для отсеивания любых подозрительных отправителей и их обманчивого содержимого и вредоносных вложений, в идеале до того, как такое содержимое может привести к компрометации деловой электронной почты.
Лицензия выдана на условиях Creative Commons Attribution-ShareAlike 4.0 International (CC-BY-SA 4.0) License.
Фото Markus Winkler on Unsplash