Шифруются ли письма, передаваемые по IMAP/SMTP?

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

993 - это TLS

Для smtp убедись, что starttls обязательна.

Конечно всё шифруется, и никто кроме тебя не может читать твою почту.

Windows Mobile 8 не существует.

иногда шифруются

mail.ru
WP8

безопасность уровня б/

Нет. Все передается открытым текстом, только по безопасным и не совсем безопасным протоколам транспортного уровня. Пока ты сам не зашифруешь свою почту ручками или костылями на уровне приложения, никто тебе ее за тебя не зашифрует.
Надеюсь понятно обьяснил, старался как проще.

Твои письма будут доступны владельцу сервера, которым ты пользуешься, владельцу сервера, которым пользуется получатель, всем промежуточным (и это при условии, что ты юзаешь SSL/TLS).

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

Все, кто выше написал, что всё шифруется - это просто тупой стёб.

Я, возможно, объяснил не совсем понятно.

Попробую спросить проще: соединение между моим телефоном и почтовым сервером зашифровано? Гипотетически, если моя компания (работодатель) запросит траффик-логи интернет с моего мобильного телефона (все, что касается почты и портов 993 и 465), что они там увидят? Открытый текст или зашифрованный текст?

Гипотетически, если моя компания (работодатель) запросит траффик-логи интернет с моего мобильного телефона

откуда и у кого запросит?

Вполне, спасибо. Странно, конечно, что базового шифрования нет.

Запросит у оператора мобильной связи (Билайн, МТС, МегаФон)

а почему оператор должен согласиться?

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

Шифрование может быть включено, а может и нет. Зависит от настроек/возможностей клиента и сервера.

Обычно в почтовых клиентах по умолчанию стоит опция типо «использовать шифрование если возможно, если нет, то слать открытым текстом».

Для пущей надёжности нужно поставить типо «использовать шифрование всегда, иначе не пущать».

Настройки для IMAP и SMTP скорее всего в разных местах находятся.

что также мешает им по запросу выдавать расшифровку интернет-траффика

Жуткая дороговизна реализации этой фичи.

Непонятно что именно шифруется: только пароль или заголовки писем или все письма при загрузке или всё вместе?

Когда я ставлю «использовать шифрование», на что это распространяется.. вот главный вопрос

Или я не понимаю как работает TCP/IP? Стандартный порт SMTP это 25. А SMTP порт с шифрованием - 465. По логике, если открывается коннект на 465 порту, то все информация проходящая через этот порт (внутри этого туннеля) у клиента и идущая к серверу шифруется. Но я не уверен: меня смущают какие-то дополнительные опции протоколов, как-то «безопасный пароль», например. Разве, открывая соединение на 465 зашифрованном порту пароль не передается уже в зашифрованном виде? Или шифрование включается не сразу, а только после аунтефикации, то есть, пароль по умолчанию передается открытым текстом? А если используется так называемый «безопасный пароль», то есть зашифрованный пароль (если я правильно понимаю), то каким образом сервер его расшифровывает? Если он его расшифровывает, видимо есть какой-то универсальный ключ, присущий этому протоколу, зная который любой может этот пароль расшифровать? Что это вообще такое - «безопасный пароль»?

Куча вопросов, хотелось бы конечно услышать компетентный ответ того, кто хорошо понимает механизм работы TCP/IP и протоколов SMTP/IMAP в часности..

для ответа на все эти вопросы надо прочитать какие механизмы аутентификации есть в smtp/imap (они примерно одинаковые, так что в принципе можно прочитать только один) + узнать что такое starttls и когда он применяется. а что в твоем винфоне понимают под «безопасным паролем» - нужно искать в документации на винфон или почтовый клиент, там наверняка написано.

Если телефон корпоративный, никто не мешает читать письма уже на нём

Это как передать письмо в сейфе, но получаетель откроет сейф и публично зачитает письмо вслух

Или я не понимаю как работает TCP/IP? Стандартный порт SMTP это 25. А SMTP порт с шифрованием - 465.

Не мучайся. Подключись телнетом к своему почтовому серверу на 465 порт и попробуй заслать письмо открытым текстом. Почти уверен, что у тебя ничего не выйдет.

Оператор выдает детализацию звонков, но не запись разговора.

В данном контексте рашифровка траффика как раз и есть запись разговора, оператор ведь не даст вам записи всех разговоров если конечно вас не поставили на прослушку, но и тогда у оператора нет этих записей они у соответствующих органов.

Телепатирую что ТС читает личную почту через корпоративный вайфай и опасается что админ сети сможет все просмотреть. В данном конкретном сценарии при желании админ сети сможет посмотреть.

В данном конкретном сценарии при желании админ сети сможет посмотреть

Как? Можно примерный сценарий, чтобы перехватить TLS?

wireshark уже давно имеет опцию расшифровать ssl (при наличии полного дампа естественно), админ корп. сети вполне может такой дамп снять.

Я потому и написал при желании т.е. надо пожелать, настроить все, снять дамп.

Также тут видел темы про squid с подменялкой сертификата для https сайтов, при желании для почты несложно адаптировать.

С траффиком я погорячился, нужно знать private key сервера чтобы расшифровать handshake, но вариант с подменой сертификатов вполне рабочий, особенно на телефонах которые даже не пытаются тольком проверять их валидность.

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

особенно на телефонах которые даже не пытаются тольком проверять их валидность

Телефоны не проверяют цепочки сертификатов? Откуда информация?

Apple: https://gotofail.com/

Android: http://threatpost.com/101912/77131

Про WP не скажу, особо не интересовался.

Уязвимость у яблочников - забавно. Но админу придется эксплоит писать, там вроде просто подменой сертификата не отделаешься... а вот про андроид на 4.2 смахивает - касперский, какие-то парни проверившие 15000 приложений из маркета и нашедшие 1000 с кривой реализацией SSL.. шел 2012 год... сколько из этой тысячи было боузерами и почтовыми клиентами? А сколько, кривой игрой с 1,5 пользователя, отправляющей рейтинг на сервер через SSL?

Я вот честно не в курсе, в андроиде что нет openSSL? Там что вообще нет вменяемой библиотеки реализующей ssl, что парням приходиться творить кривые лисапеды? Вот мне становится действительно интересно.. неужели там все так уныло? В гугле не умеют вменяемую ось собрать?

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

Насчет использования SSL цитата из PDF:

76,435 URLs (39.1%) pointing to 4,526 hosts (17.4%) al- lowed a valid HTTPS connection to be established, using Android's default trust roots and validation behavior of cur- rent browsers. This means that 9,934 (73.6%) of all 13,500 tested apps could have used HTTPS instead of HTTP with minimal effort by adding a single character to the target URLs.

40% запрашиваемых адресов (в 73% от общего числа приложений) используют HTTP хотя хосты позволяют HTTPS.

UsingMalloDroid, we found 1,074 apps (17.28% of all apps that contain HTTPS URLs) that include code that either bypasses effective SSL verification completely by accepting all certificates (790 apps) or that contain code that accepts all hostnames for a certificate as long as a trusted CA signed the certificate (284 apps).

Из тех кто все же использует, 17% либо не проверяют цепочку, либо проверяют ТОЛЬКО цепочку и не проверяют что хост совпадает.

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

Тебя посодют, а ты не воруй.

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

И конечно же это все теория. На практике, чтобы послушать почту ТС'а админу нужно выделить трафик с этих 17% уязвимых приложений (иначе он поломает ssl в не уязвимых, попадется, и в худшем варианте пойдет сидеть тюрьма - УК не любит когда читают чужую почту). Таки не тривиальная задача - понять схавает клиент поддельный сертификат или нет, и при этом не спалится. И конечно, чтобы злодейство админа сработало, почтовый клиет ТС'a должен попасть в эти 17%.

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

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

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

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

и это корпоративная сетка где работник подписался что за ним могут следить

Тут очень скользкий вопрос. С юридической точки зрения работник не может разрешить работодателю нарушать УК - это преступление не только против работника, но и общества. Корпоративную почту - да могут читать. Личную - нет. Как на счет того что работадателю принадлежит вся информация в сети? Не знаю. Вот если магистрал начнет удить личные данные из проходящего через него трафика - это законно? Оборудование вроде бы его.

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

Вот если магистрал начнет удить личные данные из проходящего через него трафика - это законно?

Нет. Я же с ним ничего не подписывал и разрешение ему не давал. Работник же в явном виде дает согласие и подписывается.

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

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

Открой wireshark, да посмотри, мало ли какие там у тебя настройки...

IMAP порт 993 и SMTP порт 465 - принудительный SSL

IMAP порт 143 и SMTP порт 25 - опциональный StartTLS

993 - это TLS

993 и 143 это принудительный SSL (imap over ssl и smtp over ssl). Шифруется всегда.

Это терминология. SSL мёртв, а слово осталось.

TLS 1.0 впервые был определен в RFC 2246 в январе 1999 года в качестве обновления версии SSL 3.0.

да хоть сапогом назови, но на 993 и 465 поток всегда шифрован :-)

993 и 143 это принудительный SSL (imap over ssl и smtp over ssl). Шифруется всегда.

Теоретически, если клиент сказал серверу EHLO открытым текстом что мешает ему трактовать соединение как нешифрованное и отвечать также плэйнтекстом? Прекрасно понимаю, что все зависит от того, как сам сервер реализован. Но что является гарантией что на 993 ждут именно шифрованного соединения?

Шифруются ли письма, передаваемые по IMAP/SMTP?

...
Мобильный телефон работает под управлением Windows Mobile 8
...

а что-то такого ты там пишешь секретного? :-)

обмениваешься кряками и серийными номерами — с друзьями? :-D

Теоретически, если клиент сказал серверу EHLO открытым текстом что мешает ему трактовать соединение как нешифрованное и отвечать также плэйнтекстом?

State machine ему помешает. При попытке подать EHLO он закроет соединение поскольку оная последовательность не соответствует ожидаемому хэндшейку: «Originally SSL support was added to protocols by giving them a separate „SSL port“ (imaps, pop3s, etc.), where the SSL handshake starts immediately when client connects, and only after the session is encrypted the regular protocol handling begins.»

SSL/TLS handshake не произойдет, если клиент начнет гнать всякую фигню типа ehlo и т.п.

Во-вторых, клиент имеет право начать согласование SMTP/IMAP только после получения подтверждения от сервера (каким является 220 ... от SMTP-сервера и +... от IMAP-сервера). Поскольку (опять таки по спецификации) на портах 993/465 оное сообщение отправляется сервером только ПОСЛЕ согласования SSL/TLS, клиент тупо не начнет сессию, поскольку начального приглашения от сервера он не увидит (если, конечно, клиент хоть сколь-нибудь вменяемый).

Достаточно прозрачно?

Достаточно прозрачно?

Не совсем. Что такое State machine? Что мешает серверу обождать, скажем секунду, и если клиент не хочет начинать хэндшейк, то сказать ему 220, услышать в ответ HELO и начать принимать почту плэйнтекстом?

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

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

Допустим, есть этот злополучный телефон и есть ноутбук с онтопиком и своим Wi-Fi, по которому раздается интернет от кабеля, подключенного к ноутбуку.

И если мы подключим телефон к беспроводной сети ноутбука, то как будет проще всего настроить ноут для «Man-in-the-Middle»? В данном случае, для сниффинга почтового траффика.

Это надо копать в сторону Wireshark, или нужны другие утилиты?

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