Pull to refresh

Comments 42

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

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

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


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

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

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


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

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

Откуда дровишки? Прям в вашем 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 невозможно использовать для этой цели?

Вот только ключ храниться на серверах google. А надеюсь в HSM. У вас не может быть RSA 2048 d=gmail.com… ну а если это ваш сервер, тогда да…
когда все таки наоборот нужно именно доказать, что ты отправлял письмо

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


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

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

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


Поправка: Не прав… Действительно подписывается фактически все письмо.
При проверке DKIM проверяется хэш тела письма. Вроде он же участвует и в формировании подписи. Да, подписывающая сторона может указать сколько байт из тела хэшировать и тогда возможна атака на дополнение сообщения.
Упс. Да, а слона параметр bh я как-то не заметил. Вы правы.
Хешируется не всё тело письма, а только, что указано в h:

h=subject:from:content-type:message-id:date:to:content-transfer-encoding:mime-version;
Но ведь DKIM доказывает только лишь то, что письмо в таком виде ушло с отправляющего сервера. Поэтому с помощью DKIM нельзя доказать, что
1. Письмо именно в таком виде пришло на отправляющий сервер
2. Письмо именно в таком виде ушло с клиента
3. Письмо написано именно владельцем аккаунта, а не кем-то, узнавшим пароль.

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

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


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


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


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

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

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

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


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

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

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

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

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

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

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


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

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


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

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


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


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

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


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

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

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

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


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


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

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

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


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

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


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


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


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

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

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


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

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


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

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

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

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

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


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

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

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

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

Даже если согласиться с авором статьи, что невозможность отказа от авторства долговременно хранимого письма является значимой угрозой, все равно предлагаемые автором меры несовершенны чисто с технической стороны, как минимум, по трем причинам:
во-первых, они не предотвращают невозможность отказа от авторства письма до момента обнародования закрытого ключа;
во-вторых, если есть возможность удостоверения времени посылки письма (ну, к примеру по логам чего-нибудь типа СОРМ-2), то они вообще не предотвращают невозможность отказа от авторства;
в-третьих, автор игнорирует тот факт, что DKIM может использоваться (и реально используется) не только крупными почтовыми службами типа Google Mail, но и другими почтовыми службами — предприятий, учреждений, и даже частных лиц — которых очень много; и организовать раскрытие секретных ключей всех этих служб по истечении времени засекречивания — задача весьма затруднительная (мягко говоря).
С моей, чисто технической, точки зрения решение этой проблемы (если это проблема — как вижу, тут многие не согласны с таким видением автора статьи) должно выгдядеть по-другому: почтовые серверы (MTA) получателей должны быть обязаны удалять заголовок DKIM-Signature сразу после верификации сервера отправителя, но до помещения сообщения в почтовый ящик получателя. При этом возможность аутентификации сервера отправителя (для чего и был изначально предназначен DKIM) никуда не денется, а так беспокоящая автора статьи невозможность отказа от авторства при долговременном хранении в п/я пропадет.
Технически это сделать вряд ли сложно: MTA в любом случае работают с заголовками, добавляя(тот же Received:) и, зачастую, удаляя их (к примеру, в MS Exchange в собщениях, передаваемых внутри почтовой организации, есть много служебных заголовков, которые в п/я пользователя или во внешний мир не попадают). И, например, в том же MS Exchange для этого не придется ждать, когда MS обновит его код: задачу вполне можно решить модулем расширения (он там называется Transport Agent).
Так механизм, насколько я понимаю, позволяет идентифицировать сервер, с которого ушло письмецо, а не фактического отправителя. Периодическая смена ключей, конечно, хорошая штука, но направлена она как раз на другое — на случай если приватный ключ DKIM будет взломан. Раз в неделю, конечно, это сильно, но смена ключа раз в полгода-год вполне себе адекватная практика. А на счет политиков — ну и пусть они отправляются в пешее эротическое, если мозгов хватило отправлять компрометирующие сообщения с официальной почты открытым текстом
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
vdsina.ru
Employees
11–30 employees
Registered
Representative
Mikhail