Comments 16
С подключением! В RFC 6376, который про DKIM, ещё в 2011 можно было перечислять заголовки, для которых указывалась криптографическая подпись.
Плюсую.
Сейчас, чтобы рядовой энд юзер заметил подмену должна зафейлится прооерка DMARC. А значит либо обе DKIM and SPF аутентификации failed, либо их alignment failed.
При подмене подписанного DKIM-ом Subject, DKIM auth будет failed, а значит необходима успешная SPF аутентификация + alignment. А для этого придется подменять IP при MITM.
Простите за мою необразованность, но не могу понять, кто реально мог использовать это всё и какую получать пользу? Вот я, Вася Пупкин, получаю письмо от Вити Пальчикова, но в это влезает злобный Бо́рис и меняет заголовок письма, хотя само письмо и ссылки в нём неизменны. Как это используют? Как работает такая фишинговая атака? From и То можно менять? А с новым способом можно будет менять?
Если From можно менять, то это беда - бухгалтер при Reply ответит не тому человеку. А изменённый Subject может направить реально важные письма в спам, например. А уж как это можно скомбинировать, наверное..
Статья странная.
Как Subject (а также другие заголовки), так и тело письма можно подписать. Можете прочитать про DKIM. Если домен из RFC5322.From настроен корректно, то при MITM и изменении подписанных данных письма, DMARC проверка будет неуспешна и письмо не попадет в inbox (можете почитать подробнее об этом в материалах по DMARC).
Я правильно понимаю что все эти годы (и до сих пор) любой владелец роутера видит кто, кому и на какую тему через него отправляет письма? Тут и без подмены по-моему с безопасностью всё плохо.
если оба mta поддерживают TLS то нет. Но у моих подопечных компаний сотни контрагентов все еще без TLS, хотя его настройка даже не требует валидного сертификата, достаточно сгенерить самоподписной, и в большинстве систем и это уже сделано из коробки, надо лишь раскомментить конфиг или прописать что-то типа tls=force
Короче, статья фиговая, пришлось влезть в сам стандарт и скормить его ИИ.
В итоге, это стандарт для E2E защиты (шифрования и подписи) писем, который фиксит старую проблему в PGP и S/MIME. Раньше они защищали только тело письма, но не заголовки.
А сейчас будут копировать все важные заголовки (From, Subject и т.д.) в зашифрованную/подписанную часть письма (payload), а внешние, незащищенные заголовки — санитизировать (например, Subject: [...]).
Поэтому если кто-то по пути подменит незащищенный заголовок, почтовый клиент типа Thunderbird сразу увидит несоответствие с защищенной копией внутри и предупредит об атаке.
Для бизнеса давно уже работает ЭДО. Там всё шифровано ЭП и её же расшифровывается. Содержимое видят только отправитель, государство и получатель.
Email защищали с 90-х, но заголовки оставались голыми
Это полная чушь. Если на принимающем сервере настроено шифрование, то он практически сразу после получения EHLO от отправителя шлёт команду STARTTLS, после чего выполняется "рукопожатие" и весь дальнейший трафик идёт шифрованным. Никакие заголовки никакой митм прочитать и подправить после этого не может.
Вот для примера лог отправки письма с нашего почтового сервера (пример, разумеется, подправлен так, чтобы не сливать конфиденциальную информацию):
Mon 2025-09-22 14:34:45.765: Waiting for protocol to start...
Mon 2025-09-22 14:34:45.841: <-- 220 mail-nwsmtp-mxfront-production-main-74.sas.yp-c.yandex.net Ok 1758533566-kZMIZUOFA9c0
Mon 2025-09-22 14:34:45.841: --> EHLO mail.example.com
Mon 2025-09-22 14:34:45.899: <-- 250-mail-nwsmtp-mxfront-production-main-74.sas.yp-c.yandex.net
Mon 2025-09-22 14:34:45.899: <-- 250-8BITMIME
Mon 2025-09-22 14:34:45.899: <-- 250-PIPELINING
Mon 2025-09-22 14:34:45.899: <-- 250-SIZE 53477376
Mon 2025-09-22 14:34:45.899: <-- 250-STARTTLS
Mon 2025-09-22 14:34:45.899: <-- 250-DSN
Mon 2025-09-22 14:34:45.899: <-- 250 ENHANCEDSTATUSCODES
Mon 2025-09-22 14:34:45.899: --> STARTTLS
Mon 2025-09-22 14:34:45.956: <-- 220 Go ahead
Mon 2025-09-22 14:34:46.079: Обмен данными SSL выполнен успешно (TLS 1.2, 256 bit key exchange, 128 bit AES encryption)
Mon 2025-09-22 14:34:46.184: Действительный сертификат SSL (совпадает с mx.yandex.net и подписано признанным CA)
Mon 2025-09-22 14:34:46.184: --> EHLO mail.example.com
Mon 2025-09-22 14:34:46.242: <-- 250-mail-nwsmtp-mxfront-production-main-74.sas.yp-c.yandex.net
Mon 2025-09-22 14:34:46.242: <-- 250-8BITMIME
Mon 2025-09-22 14:34:46.242: <-- 250-PIPELINING
Mon 2025-09-22 14:34:46.242: <-- 250-SIZE 53477376
Mon 2025-09-22 14:34:46.242: <-- 250-STARTTLS
Mon 2025-09-22 14:34:46.242: <-- 250-DSN
Mon 2025-09-22 14:34:46.242: <-- 250 ENHANCEDSTATUSCODES
Mon 2025-09-22 14:34:46.242: --> MAIL From:<user@example.com> SIZE=677119
Mon 2025-09-22 14:34:46.478: <-- 250 2.1.0 <user@example.com> ok 1758533567-kZMIZUOFA9c0-ovAQaWsf
Mon 2025-09-22 14:34:46.478: --> RCPT To:<user10@yandex.ru>
Mon 2025-09-22 14:34:46.550: <-- 250 2.1.5 <user10@yandex.ru> recipient ok 1758533567-kZMIZUOFA9c0-obAQcWsf
Mon 2025-09-22 14:34:46.550: --> DATA
Mon 2025-09-22 14:34:46.729: <-- 354 Start mail input, end with <CRLF>.<CRLF>
Mon 2025-09-22 14:34:46.729: Sending <pd3501000020981.msg> to [77.88.21.249]
Mon 2025-09-22 14:34:48.013: Transfer Complete
Mon 2025-09-22 14:34:48.882: <-- 250 2.0.0 Ok: queued on mail-nwsmtp-mxfront-production-main-74.sas.yp-c.yandex.net 1758533569-kZMIZUOFA9c0-obAQcWsf
Mon 2025-09-22 14:34:48.882: --> QUIT
Mon 2025-09-22 14:34:48.940: <-- 221 2.0.0 Closing connecton
Mon 2025-09-22 14:34:48.940: SMTP session successful (Bytes in/out: 5719/689356)
Так что не морочьте людям голову.
Почта не всегда напрямую передаётся
Претензия, я так понял, в том, что всё это до сих пор опционально. Достаточно одному из абонентов иметь сервер, который Ельцина застал - и общение радостно пойдёт открытым текстом. А если админ это запретит - то его задолбают: почему нам Пал Петрович написать не может ?!
Email защищали с 90-х, но заголовки оставались голыми. Теперь это исправили