можно ли перехватить и расшифровать почтовый трафик?

SMTP не зашифрован(по умолчанию).

GPG не расшифровать.

А что там расшифровывать то? Можно конечно.

мнения разделились:)

Да. TLS есть TLS.

И кстати, причем здесь Development?

ну, криптография относится. Я просто подумал, что это ближе все таки к программированию, чем к администрированию. Алгоритмы же.

В зависимости от того, используется TLS\SSL соединение для SMTP\IMAP\POP3 или нет. Если нет - plain text, даже расшифровывать не надо, так всё читается. Но спецслужбы этим не будут заморачиваться, они изымут почтовый сервер и вынут письма напрямую. Если сама переписка зашифрована GPG прочитать не смогут, но имеют полное право требовать ключ у участника переписки. Отказ предоставить ключ сам по себе может быть оформлен как состав преступления.

А ещё часто путают приватность и анонимность. Электропочту при использовании шифрования транспорта и переписки можно считать приватной, но не анонимной. Анонимные сети приватность тоже могут не гарантировать, exit ноды Tor например. Короче эти два объёма понятий могут как пересекаться, так и нет.

Электропочту при использовании шифрования транспорта и переписки можно считать приватной, но не анонимной

ну да, еще и айпишники могут быть залогированы, лишняя доказуха.

айпишники могут быть залогированы, лишняя доказуха.

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

Насколько я себе представляю TLS, он умеет шифровать только весь трафик сплошняком, кроме «CONNECT 12.34.56.78 HTTP/1.1».

Ну вот смотри.

ClientA → Server1 → Server2 → Server3 → ClientB
       TLS      plain      TLS       TLS

Клиент А и Б очень ответственные и используют TLS.

Но расширение TLS не является обязательныем для SMTP. Т.е. если оно не доступно (и если вообще настроено), будет использоваться plain text заместо.

А теперь угадай, где можно перехватить сообщение? :)

TLS есть TLS.

К сожалению это заблуждение. TLS не работает End-to-End, он работает Hop-to-Hop. И некоторые Hop'ы могут быть и без.

Таки оно шифрует всё целиком. В том числе и «CONNECT 12.34.56.78 HTTP/1.1»

Но если в HTTP для этого есть отдельный порт и там дело сразу начинается с handshake. То с SMTP это немного по другому.

Отдельный порт конечно есть, но чаще приходишь с plain text на 25 и говоришь STARTTLS. Сервер тебе отвечает «Ok, пошли» или «Не, не умею». Тогда твой клиент отвечает «Ну ладно, чёрт с тобой. Всё равно никто не увидет. Давай тогда по-старинке.» ;)

TLS есть TLS.

К сожалению это заблуждение.

В чем заблуждение?

TLS не работает End-to-End, он работает Hop-to-Hop

Вопрос был «поддается ли предача почтового трафика обычным уязвимостям вроде MITM». Ответ - «да, поддается, потому что им поддается TLS». Какая разница, hop-to-hop или end-to-end?

Ну, значит неправильно твой ответ разпарсил. А end-to-end (aka PGP) таки помогает. Перехватить то смогут. А вот прочесть — ещё вопрос.

www.linux.org.ru/forum/security/

то есть, поддается ли почтовый трафик всяким уязвимостям, типа, человек посередине и тп?

Короткий ответ — да.

Длинный ответ — как правило, да, но иногда нужно применить дополнительные усилия. SMTP по своей природе — протокол с открытым текстом. Основной способ обеспечить безопасность передаваемого трафика — механизм STARTTLS. Работает это так: клиент (будь то MUA пользователя или любой MTA по пути следования письма) подключается к серверу (в первом случае это должно происходить по tcp/587, а во втором — происходит по tcp/25) и, если он представится, как понимающий ESMTP (командой EHLO вместо HELO) и сервер тоже это умеет (в XXI веке вероятность 99%), то сервер покажет список capabilities.

Вот так это выглядит:

telnet smtp.yandex.ru 587
Trying 2a02:6b8::38...
Connected to smtp.yandex.ru.
Escape character is '^]'.
220 smtp14.mail.yandex.net ESMTP (Want to use Yandex.Mail for your domain? Visit http://pdd.yandex.ru)
EHLO linux.org.ru
250-smtp14.mail.yandex.net
250-8BITMIME
250-PIPELINING
250-SIZE 42991616
250-STARTTLS
250-AUTH LOGIN PLAIN XOAUTH2
250-DSN
250 ENHANCEDSTATUSCODES

Дальше, если клиент скажет STARTTLS, то в этой сессии начнется обычное согласование TLS и дальше всё будет зашифровано.

Проблем есть три:

• далеко не все серверы умеют STARTTLS;
• среди тех, кто умеет STARTTLS, далеко не все используют валидируемые сертификаты;
• на server-to-server взаимодействии нет стандартного механизма обязать использовать STARTTLS;

На практике это приводит к тому, что даже если клиент подключается к серверу и правильно использует STARTTLS для отправки письма (клиент может это проверить), то что происходит дальше, клиент не знает и повлиять на это никак не может.

На деле, меньше трети принимаемых и около 20% отправляемых писем в статистике Яндекса проходят через STARTTLS при серверных взаимодействиях.

Но то, что сказали в твоём ролике — действительно, утка, потому, что настоящие шпионы США пользуются gmail. У gmail есть hsts, hpkp и если им пользоваться из chrome, расшифровать трафик довольно сложно. А почта на gmail создает plausible deniability, которая очень важна для шпионов.