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

Original author: Matthew Green
  • Translation


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

В чём проблема 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! Подобрать параметры сервера можно самостоятельно с помощью удобного конфигуратора.

VDSina.ru хостинг серверов
Серверы в Москве и Амстердаме

Comments 40

    +4
    Может просто не стоит вести компрометирующую переписку?
      +3
      Это шутка такая?
      +5
      Так как любой посторонний сможет фальсифицировать подписи DKIM, они станут практически бесполезными в качестве свидетельства аутентичности.

      Ну это не аргумент, например, для тех кто посадил Дмитрия Богатова.

        +2

        Как Дмитрий Богатов (однофамилец, но тем не менее), выступаю против идеи статьи.


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

        +16
        Я думаю, что нельзя раскрывать приватники. Есть куча случаев, когда все таки наоборот нужно именно доказать, что ты отправлял письмо. Нужно именно с этой точки рассматривать ситуацию. Это имеет большую ценность, чем то, что пишет автор.
          +11

          DKIM вообще не для этого сделан. Подпись ставит не отправитель, а первый (или один из первых) почтовый сервер, принявший его.


          Например, админ сервера может сделать нужное письмо с валидной DKIM подписью.


          Да что там — давайте просто первые строки RFC6376 посмотрим:


          DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message.

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


          Дальнейшие комментарии излишни.

            +1
            Подпись ставит не отправитель, а первый (или один из первых) почтовый сервер, принявший его.

            Откуда дровишки? Прям в вашем RFC чёрным по белому указано:


            2.1. Signers

            Elements in the mail system that sign messages on behalf of a domain
            are referred to as Signers. These may be MUAs (Mail User Agents),
            MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
            agents such as mailing list exploders.

            Так что может кто угодно, в том числе отправитель, это не запрещено и не является "нестандартным" использованием.


            Например, админ сервера может сделать нужное письмо с валидной DKIM подписью.

            Никто не можем вам помешать подписывать сообщение ещё в своём MUA/MSA или использовать свой собственный сервер и не доверять злобным админам, заодно исключая из цепочки все остальные звенья.


            Степень "некоторости" ответственности зависит исключительно от того как именно используется DKIM, и в тексте приведённого вами RFC нет ни слова о том что он "не предназначался" для потдтверждения достоверности.


            Или вы можете обоснованно доказать что DKIM невозможно использовать для этой цели?

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

            Если требуется криптография — можно использовать PGP и добавить подпись самостоятельно.


            Нужно именно с этой точки рассматривать ситуацию. Это имеет большую ценность, чем то, что пишет автор.

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

              0
              Для этого есть средства подписи писем — тот же PGP.
              0
              И для меня загадка, почему компания до сих пор так не поступила.
              Возможно, они все еще решают, сколько просить за такую возможность — 1,99 или 2,99 в месяц. Это сарказм, но я не уверен, что Гугл в первую очередь думает, как будет удобно пользователям.
                0
                Поправьте меня, если я не прав.
                Насколько я знаю, DKIM защищает только заголовки.
                То есть, если с моего аккаунта где-нибудь в гугле на публику утекло письмо с темой «Надо заколбасить Васю», то да, у меня проблема.
                А если кто-то взял письмо с темой «Надо решить проблему» и вместо тела «Надо мирно договориться с Васей» вставит «Заплати Пете, чтобы он заколбасил Васю», никакой DKIM тут ни при делах.
                Это я к тому, что основная аргументация автора оригинала — украденные письма политиков. И на HN мнения тоже разделились между сторонниками приватности и теми, кто говорил, что так им политикам и надо (ну очень утрировано).
                И отсюда вопрос: как можно доверять опубликованной переписке, где подписью защищены только служебные заголовки?


                Поправка: Не прав… Действительно подписывается фактически все письмо.
                  +1
                  При проверке DKIM проверяется хэш тела письма. Вроде он же участвует и в формировании подписи. Да, подписывающая сторона может указать сколько байт из тела хэшировать и тогда возможна атака на дополнение сообщения.
                    0
                    Упс. Да, а слона параметр bh я как-то не заметил. Вы правы.
                      0
                      Да там RFC какой-то не очень очевидный, чего уж :-)
                  +12
                  Но ведь DKIM доказывает только лишь то, что письмо в таком виде ушло с отправляющего сервера. Поэтому с помощью DKIM нельзя доказать, что
                  1. Письмо именно в таком виде пришло на отправляющий сервер
                  2. Письмо именно в таком виде ушло с клиента
                  3. Письмо написано именно владельцем аккаунта, а не кем-то, узнавшим пароль.

                  Или я чего-то не учитываю?
                    0

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


                    Пункт 1 актуален только если мы не доверяем отправляющему серверу. Возможно, если начать сильно изменять отправляемые письма, то пользователи всё-таки заметят.


                    Пункт 2 — это пункт 1 + наличие защиты между клиентом и сервером, вполне решённый вопрос.


                    Итого в ситуации <<используется популярный сервер с репутацией "не изменяем письма пользователей" и подключение к нему идёт через шифрование>> подпись DKIM много чего доказывает. А такая ситуация, мне кажется, у очень большого количества пользователей — если не сам Gmail, то домен под управлением Gmail; шифрование в клиентах наверняка нынче включено по умолчанию.

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

                    А то получится, что интимные фотки из аттачей тырить и шантажировать ими не прекратят, а у фигурантов условных «Панамагейтов» появится возможность всё отрицать.
                      +13
                      Устранение такой возможности — это благо в чистом виде.

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


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

                      О, бедный Мэттью. Необходимость аргументировать свою точку зрения — это так жестоко.

                        +11
                        1. DKIM не доказывает, что письмо не было отправлено хакером, подобравшим пароль к учётной записи, или злонамеренным админом почтового сервера (впрочем, в последнем случае есть некоторое доверие крупным сервисам вроде Gmail).

                        2. Утверждение, что от пожизненной валидации DKIM вы ничего не выигрываете является ложным, поскольку есть огромный спектр ситуаций, когда доказательство аутентичности сообщений служит наоборот благим законным целям. Например, доказательства факта какой-либо договорённости в случае её нарушения.

                        А политикам можно посоветовать только, если уж дошло дело до грязных дел, не использовать рабочий адрес электронной почты для них.
                          0
                          А политикам можно посоветовать только, если уж дошло дело до грязных дел, не использовать рабочий адрес электронной почты для них.
                          Странно, что их этому не учат в ихнем политическом колледже на политинформатике.
                          +4
                          Вообще то DKIM не обязана подписывать тело письма и может даже подписывать только заданное количество байт в начале письма. В Open-DKIM за это отвечает настройка MaximumSignedBytes, например. Кроме того можно подписывать не все заголовки а только некоторые — обязательным будет только адрес отправителя и идентификатор сообщения. В самом формате подписи для этого предусмотрены поля l и h.

                          Ну и кроме того DKIM входящего проверяется через DNS. Если там нет DNSSEC то это тоже не очень секюрно — можно наподделывать всякого.
                            +6
                            Инструмент как инструмент. Основную свою задачу выполняет нормально, а побочные свойства могут быть хорошими или плохими в зависимости от ситуации.
                            Как молоток — гвозди забивает нормально, но можно и голову кому-нибудь проломить. Хорошо это или плохо — зависит от того, кому и в какой ситуации.
                              +3
                              Но он не даёт никаких преимуществ вам.

                              Возможность хотя бы как-то подтвердить подлинность утечек, которые указывают на коррупцию, это прямая польза этим самым «вам». Упоминание Байденов и событий 2016 года тут лишнее подтверждение, что нельзя отказываться от такого инструмента без наличия какой-то альтернативы. Такое ощущение, что статью писал очередной обиженный демократ, который всеми силами хочет создать условия, чтобы любые утечки игнорировались, лишь бы не слышать, что любимая партия и кандидат в президенты с ног до головы погрязли в коррупции.
                                +1
                                Кроме того, иногда пользователь может захотеть подтвердить, что он врет насчет какой-то договоренности с другим человеком или компанией.
                                +4
                                Ты сошёл с ума, никто не использует DKIM для аутентификации писем.


                                Публичные почтовые сервера типа mail.ru используют для алгоритмов сортировки спама.
                                  +1
                                  Что-то не понял, DKIM же вроде для домена настраивается. А уж кто там внутри домена отсылает — без раницы, хоть тётя Клава. Это не персональная подпись. Насколько понимаю…
                                    –1
                                    В письме указано, кто его отправил. Если письмо подписано ключом Гугла и в нем написано, что его отправила тетя Клава, то отправить его могла либо тетя Клава, либо админ Гугла с доступом к соответствующему ключу. Без вариантов.
                                      +2

                                      Вариантов тут ещё минимум несколько штук есть:


                                      • кто-то сел за комп тёти Клавы пока она успокаивала сбежавший суп;
                                      • кто-то украл пароль от аккаунта тёти Клавы;
                                      • кто-то украл ключ у админа гугла;
                                      • кто-то создал аккаунт от имени тёти Клавы.

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


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


                                      DKIM — это инструмент, им нужно уметь пользоваться — как со стороны отправителя так и со стороны получателя. Ножом можно резать сыр, а можно и уши слишком любопытным пионерам — но нож не виноват.

                                        +1
                                        Подпись гугла обозначает только одно — что оно было отправлено сервером гугла, всё.


                                        Вот мне тоже так кажется. Сервер имеет доступ к приватному ключу и генерирует подпись, чтобы его могли сверить с помощью публичного ключа. А уж кто там отсылал письмо с этого сервера… это уже другой вопрос.
                                    +6

                                    Кто то из политиков решил проплатить возможность "отказаться от своих электронных писем"? Просто главный посыл (если перенести на до компьютерную эпоху) звучит как "давайте запретим почерковедческую экспертизу, благодаря ей меня могут привлечь к ответственности".
                                    Согласен, подпись сервера, не равна подписи клиента. Но это уже вопрос технической грамотности и юриспруденции.
                                    Публиковать приватные ключи? Звучит странно. Есть кто то из ИБ сообщество, кто сможет привести пример, когда это повышало безопасность?

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

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


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


                                      Так что DKIM отлично выполняет свою функцию — подтверждает отправку писем через того кто владеет ключами для подписей (о чём, собственно, в RFC отлично и написано).

                                        0
                                        Эти инструменты ничем принципиально не отличаются от DKIM в обсуждаемом контексте

                                        Отличаются — их можно включать или не включать на свой выбор, причём по умолчанию не включены.


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

                                          –1

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


                                          С другой стороны, я не могу себе представить способ который позволит доказывать что-то только в определенный отрезок времени — если кто угодно может это сделать в точке A, то этот кто-то может сохранить все необходимые для доказательства данные для точки Б которая находится в произвольно удалённом будущем (хотя бы доказательства предоставленные в точке A, с меткой времени и кем-то ещё подписанные в качестве свидетельства).


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


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

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

                                            Согласен. Если говорить про популярные сервисы, впрочем, то там между клиентом и первым сервером обычно всё-таки устроено шифрование. Чуть выше уже обсуждали.


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

                                            Так вот же он, в статье описан:


                                            1. Добавить expiration date у подписи.
                                            2. А чтобы не было желания доказывать и после expiration date, в нужный момент публикуем приватный ключ для подписи. После этого кто угодно может подписать что угодно и теперь мы не можем отличить "легитимно подписали до публикации приватных ключей" от "подписал кто-то непонятный после публикации".

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

                                        –2
                                        Нет ничего более убогого, разве что за исключением уродца FTP-протокола, как SMTP-протокола.
                                        Вместо того, чтоб его пересмотреть и изменить — мы делаем кучу костылей, которые постоянно обходят спамеры.

                                        Кстати — идея для стартапа. Почтовый сервис, который служит прокси для вашего и все новые неизвестные адреса скидывает вам с реммой письма в телегу. Вы читаете как будет время и маркируете — спам/нет
                                        Нужно только нейросетка для выдергивания реммы
                                        Если захотите — зовите меня, я смогу сделать сам базис прокси+автоскейл инфрастракчу под него
                                        Разбогатеем, будем на море пиво пить (лол, но ведь я всю жизнь живу у моря и могу за 30 минут туда попасть).
                                          –1

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


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

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

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

                                            Статья похожа на какой-то избыточный алармизм. Ну, позволяет подтвердить аутентичность отправителя, и что? Это точно не самая большая проблема. Если уж так рассуждать — надо не dkim исправлять, а вообще сжигать smtp протокол. И dns до кучи тоже. И вообще строить новый дивный мир.
                                            В остальном — коллеги все уже откомментировали выше

                                              +2
                                              Даже если согласиться с авором статьи, что невозможность отказа от авторства долговременно хранимого письма является значимой угрозой, все равно предлагаемые автором меры несовершенны чисто с технической стороны, как минимум, по трем причинам:
                                              во-первых, они не предотвращают невозможность отказа от авторства письма до момента обнародования закрытого ключа;
                                              во-вторых, если есть возможность удостоверения времени посылки письма (ну, к примеру по логам чего-нибудь типа СОРМ-2), то они вообще не предотвращают невозможность отказа от авторства;
                                              в-третьих, автор игнорирует тот факт, что DKIM может использоваться (и реально используется) не только крупными почтовыми службами типа Google Mail, но и другими почтовыми службами — предприятий, учреждений, и даже частных лиц — которых очень много; и организовать раскрытие секретных ключей всех этих служб по истечении времени засекречивания — задача весьма затруднительная (мягко говоря).
                                              С моей, чисто технической, точки зрения решение этой проблемы (если это проблема — как вижу, тут многие не согласны с таким видением автора статьи) должно выгдядеть по-другому: почтовые серверы (MTA) получателей должны быть обязаны удалять заголовок DKIM-Signature сразу после верификации сервера отправителя, но до помещения сообщения в почтовый ящик получателя. При этом возможность аутентификации сервера отправителя (для чего и был изначально предназначен DKIM) никуда не денется, а так беспокоящая автора статьи невозможность отказа от авторства при долговременном хранении в п/я пропадет.
                                              Технически это сделать вряд ли сложно: MTA в любом случае работают с заголовками, добавляя(тот же Received:) и, зачастую, удаляя их (к примеру, в MS Exchange в собщениях, передаваемых внутри почтовой организации, есть много служебных заголовков, которые в п/я пользователя или во внешний мир не попадают). И, например, в том же MS Exchange для этого не придется ждать, когда MS обновит его код: задачу вполне можно решить модулем расширения (он там называется Transport Agent).
                                                +1
                                                Так механизм, насколько я понимаю, позволяет идентифицировать сервер, с которого ушло письмецо, а не фактического отправителя. Периодическая смена ключей, конечно, хорошая штука, но направлена она как раз на другое — на случай если приватный ключ DKIM будет взломан. Раз в неделю, конечно, это сильно, но смена ключа раз в полгода-год вполне себе адекватная практика. А на счет политиков — ну и пусть они отправляются в пешее эротическое, если мозгов хватило отправлять компрометирующие сообщения с официальной почты открытым текстом

                                                Only users with full accounts can post comments. Log in, please.