Окей, Гугл, опубликуй свои секретные ключи DKIM

в 8:55, , рубрики: dkim, Domain Keys Identified Mail, gmail, google mail, smtp, Блог компании VDSina.ru, информационная безопасность

Окей, Гугл, опубликуй свои секретные ключи DKIM - 1

Интернет даже в лучшие свои годы был опасным местом. Иногда архитекторы Интернета находили способы снижения угроз, иногда терпели неудачу. Однако постоянно повторяется ситуация, когда крупная Интернет-компания находит решение, которое на самом деле ухудшает ситуацию почти для всех. Сегодня я хочу поговорить об одном из таких случаев, а также о том, как большая компания наподобие Google могла бы найти способ исправить ситуацию.

В этом посте раскрывается вопрос Domain Keys Identified Mail (DKIM), безвредного крошечного антиспам-протокола, который каким-то образом превратился в монстра. Моя просьба проста, вкратце её можно сформулировать так:

Уважаемый Google: пожалуйста, реализуйте периодическую ротацию и публикацию ваших секретных ключей DKIM. Благодаря этому весь Интернет станет намного безопаснее, ведь у преступников пропадёт сильный стимул кражи электронных писем и организации их утечек. Исправление практически не будет вам ничего стоить и выбьет из рук воров мощнейший инструмент.

Это краткая версия. Ниже представлена более подробная.

Что это за DKIM, и как он защищает мою электронную почту?

Электронная почта была создана в те времена, когда Интернет ещё назывался ARPANET. Это были гораздо более спокойные дни, когда современные меры безопасности, да и, честно говоря, само понятие того, что Интернету потребуется безопасность, оставались далёким, научно-фантастическим будущим.

Первые протоколы электронной почты (типа SMTP) работали на основе системы доверия. Электронные письма могли поступать на ваш почтовый сервер непосредственно с почтового сервера отправителя или передаваться через посредников. Как бы то ни было, если в письме указано, что оно пришло от вашей подруги Алисы, то вы верите, что оно действительно от Алисы. Зачем кому-то вообще лгать о подобном?

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

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

Решение задачи авторизации источника, как и почти остальные исправления базовых Интернет-протоколов, напоминало ремонт изолентой. Поставщиков услуг почты попросили подключить (дополнительное) новое криптографическое расширение под названием Domain Keys Identified Mail, или DKIM. DKIM «запекает» в каждое отправленное почтовым сервером письмо цифровые подписи. Когда почтовый сервер получателя принимает подписанное DKIM письмо, заявляющее, что оно, допустим, поступило от Google, то сначала он при помощи Domain Name System (DNS) находит публичный ключ Google. Получатель теперь может проверить подпись, чтобы убедиться, что письмо аутентично и не модифицировано, ведь подпись связана с содержимым и большинством заголовков. После этого такое знание можно использовать в качестве входных данных для фильтрации спама. (Подобные гарантии обеспечивает похожий протокол под названием ARC.)

Разумеется, такое решение неидеально. Поскольку DKIM необязателен, злонамеренные посредники могут «вырезать» подписи DKIM из письма, чтобы убедить получателей, что оно никогда не было подписано DKIM. Похожий протокол под названием DMARC, использует DNS, чтобы позволить отправителям почты передавать свои предпочтения, принуждающие проверять подписи их электронных сообщений. Совместное использование этих двух протоколов, по сути, должно полностью избавить Интернет от спуфинга.

Окей, Гугл, опубликуй свои секретные ключи DKIM - 2

Пример подписи DKIM одного из полученных мной сегодня автоматизированных писем.

В чём проблема DKIM/ARC/DMARC и что такое «оспоримость»?

В качестве меры защиты от спама DKIM, ARC и DMARC не имеют никаких особых проблем. Сложность в том, что подписывание DKIM обладает неожиданным побочным эффектом, распространяющимся дальше, чем изначальная задача фильтрации спама. Если вкратце:

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

Эта новая особенность отсутствия возможности аннулирования изначально не задумывалась как цель DKIM. Проектировщики не планировали её, никто не обсуждал, будет ли это хорошей идеей, и большинство она застала врасплох. Хуже того — эта неожиданная особенность имела весьма серьёзные последствия: она делает нас более уязвимыми к вымогательству и шантажу.

Чтобы понять, в чём проблема, стоит рассмотреть цели DKIM.

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

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

До недавнего времени никто об этом не задумывался. На самом деле, первые конфигурации DKIM походили на дурную шутку: поставщики услуг почты выбирали ключи подписи DKIM, которые было очень легко взломать нападающему с достаточной мотивацией. В 2012 году исследователь систем безопасности Закари Харрис выяснил, что Google и множество других компаний использовали для подписывания DKIM 512-битный RSA. Он показал, что такие ключи на арендованном облачном оборудовании можно взломать за считанные часы, а затем использовать их для фальсифицирования писем от Ларри и Сергея.

Реакцию Google и других поставщиков услуг электронной почты на весь этот конфуз с «Ларри и Сергеем» предсказать несложно. Не обдумав хорошенько последствия, они быстро усилили ключи, повысив их до 1024-битного или 2048-битного RSA. Это предотвратило фальсификации, однако непреднамеренно превратило безобидный протокол антиспама в пожизненный штамп криптографической аутентичности, который можно использовать для подтверждения любого дампа электронной почты вне зависимости от того, как он попал в руки подтверждающего.

Ты сошёл с ума, никто не использует DKIM для аутентификации писем.

Как бы там ни было, штамп аутентификации по DKIM широко использовался прессой, в основном в контексте взлома электронной почты политиков. Это реально, важно и значимо.

Самый знаменитый пример, вызвавший в то же время серьёзные разногласия: в 2016 году Wikileaks опубликовал набор писем, украденных из аккаунта Google Джона Подеста. Поскольку источник этих писем был мутным, WikiLeaks столкнулся с тяжкой задачей подтверждения подлинности этих сообщений. Изящным решением стал DKIM: каждое письмо, представленное на страницах Wikileaks, публично указывает статус подтверждения прикреплённых подписей DKIM. Также сайт предоставляет полезную страницу ресурсов для журналистов, объясняющих, как DKIM доказывает реальность писем.

Однако письмами Подеста история с DKIM не закончилась. В 2017 году ProPublica использовал DKIM для проверки аутентичности писем, предположительно отправленных критику личным адвокатом президента Трампа Марком Касовицем. В 2018 году Associated Press снова использовала его для проверки подлинности утечки писем, связывающих российского юриста с Дональдом Трампом-младшим. И это же произошло снова в этом году, когда получатели предполагаемого «ноутбука Хантера Байдена» передали Робу Грэму для проверки по DKIM одного письма 2015 года, чтобы преодолеть скептицизм журналистов относительно источников их информации.

Кто-то может сказать, что верификация по DKIM не важна, и что верить или не верить в утёкшие письма можно только на основании их содержимого. Однако то, что многочисленные новостные организации решили положиться на DKIM, чётко демонстрирует, насколько ошибочно такое предположение. Новостные организации, в том числе и Wikileaks, косвенно признают, что спорные источники получения писем приводят к сомнениям: вероятно, к таким сильным, что убедительная публикация в национальной новостной организации оказывается из-за этого невозможной. DKIM позволяет обойти эту проблему и устранить подобные помехи.

Агентство Associated Press даже выложило инструмент для проверки DKIM.

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

Но он не даёт никаких преимуществ вам.

Что же можно с этим поделать?

DKIM никогда не предназначался для долговременной аутентификации писем. Обеспечиваемые им гарантии безопасности важны, но должны существовать только в течение нескольких часов (возможно, дней) с момента передачи письма почтовым сервером. Сам факт, что DKIM по-прежнему может использоваться для доказательства подлинности украденного письма, написанного ещё в 2015 году, по сути, является провалом: результатом неправильного использования и настройки поставщиками услуг почты, которые должны были думать головой.

К счастью, существует простое решение.

DKIM позволяет поставщикам периодически выполнять «ротацию», или замену ключей, используемых для подписывания исходящих писем. Частота такой ротации немного ограничена кэшированием инфраструктуры DNS, но эти ограничения не особо строги. Даже крупный поставщик наподобие Google с лёгкостью может менять ключи подписи как минимум каждые несколько недель, не мешая при этом передаче почты. Подобная замена ключей в любом случае является хорошей практикой, и представляет собой часть решения.

Разумеется, простая замена пар ключей DKIM сама по себе ничего не решит: хитрецы из Интернета постоянно архивируют публичные ключи DKIM. На самом деле, именно так было подтверждено в 2020 году письмо на ящик Google из 2015 года: ключ, который Google использовал для подписывания писем DKIM в тот давно прошедший период (с 2012 по 2016 год использовался один и тот же ключ — серьёзно, Google, что это за раздолбайство!), уже больше не используется, но был кэширован во многие места в Интернете.

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

(Те, у кого есть собственные почтовые сервера, могут реализовать это автоматически при помощи этого замечательного скрипта.)

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

(Читатель-параноик может также учесть возможность того, что мотивированные нападающие могли уже украсть у Google старые секретные ключи DKIM. В конечном итоге, ключи подписи DKIM не являются «королевскими драгоценностями» экосистемы Google, поэтому Google вряд ли прикладывает максимальные усилия для обеспечения их безопасности. В таком случае сохранением секретности ключей Google просто создаёт ситуацию, в которой определённые акторы могут безнаказанно фальсифицировать письма.)

Но аутентификация по DKIM — отличная штука! Разве мы не хотим иметь возможность проверки утекшей у политиков почты?

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

Но плохое случается и с хорошими людьми. Если ты создаёшь механизм, стимулирующий к преступлениям, то рано или поздно преступление совершат против тебя.

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

Тот факт, что мне приходится спорить об этом, очень меня печалит.

Временные метки, улучшенная криптография и другие формальные возражения

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

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

Кто-то даже предложил возможность хитрой атаки, при которой получатели (или хакеры, имеющие постоянный доступ к вашему аккаунту электронной почты) используют публичный сервис создания временных меток, например, блокчейн, для надёжного «штемпелевания» на любом получаемом ими письме времени получения. Это позволяет таким получателям доказать, что они подписали письмо до публикации секретного ключа DKIM — шах и мат.

Это отличный умный теоретический хак, но он, по сути, не относится к нашей теме в том смысле, что обращается к более сильной модели угроз. Самая критическая проблема DKIM сегодня заключается в том, что подписи DKIM находятся внутри вашего архивированного почтового ящика. Это означает, что хакер, взломавший мой аккаунт Gmail сегодня, сможет продемонстрировать подписи DKIM на письмах, которые я отправлял/получал годы назад. Публикация старых секретных ключей DKIM мгновенно решит эту проблему. Решение теоретической проблемы «хакера в реальном времени» может подождать своей очереди.

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

Кроме того, существует вопрос, можно ли будет решить проблему оспариваемости DKIM при помощи новой криптографии. Я, как исследователь криптографии, отношусь к этому с энтузиазмом. На самом деле, мы с моими соавторами Майком Спектером и Сану Парком недавно написали статью о том, как может работать долговременное решение проблемы DKIM. (Майк написал об этом замечательный пост.) Я не буду заявлять, что наше решение обязательно является лучшим, но надеюсь, что оно вдохновит кого-то на дальнейшие исследования.

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


На правах рекламы

Виртуальный сервер от VDSina с защитой от DDoS-атак позволит разместить любой проект — всё будет работать без сбоев и с высоким uptime! Подобрать параметры сервера можно самостоятельно с помощью удобного конфигуратора.

Автор: Mikhail

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js