Что именно шифрует SSL/TLS в электронной почте?

По сути всё а не что то конкретно.

будет доступно его содержание или нет?

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

SSL/TLS

по идее это L4, поправьте меня если я не прав.
примерно app->crypto->net<-crypto<-app

По сути ничего ибо шифруется канал передачи данных - не больше, но и не меньше !

Для шифрования тела письма используются другие методы - например s/mime.

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

Шифрование протокола соединения и обмена данными ничего общего с шифрованием писем не имеет, внутри шифрованного канала двигается незашифрованное письмо. Если в обмене почтой участвует промежуточный сервер (relay, aka «сервер пересылки») прочитать его там может любой обладающий нужными правами на этом сервере. А так же отправить его копию куда угодно, сохранить её локально, модифицировать как угодно и т.п.

Если ещё проще — канал шифрован до сервера пересылки и после сервера, на самом сервере письмо не шифруется.

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

Пока ответы диаметрально противоположные, как и у нас :-)

Но если Jameson прав и содержание письма доступно для просмотра, тогда вопрос - зачем вообще эти SSL/TLS, если они ничего не защищают?

Они защищают канал обмена почтой от чтения на роутерах например, путём перехвата трафика и анализа пакетов. Ну нельзя же быть НАСТОЛЬКО неграмотным?

Можно, можно :-) И что же получается - письмо нельзя прочитать в канале Интернет, поскольку сам канал зашифрован, но зато его можно прочитать на диске почтового сервера?

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

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

Возможно тебе не очень понятно в каких случаях будет использоваться «сервер пересылки», а в каких случаях — нет.

Вот предположим у тебя «почтовый клиент» (MUA, mail user agent, в «правильной» терминологии). В его настройках тебе требуется прописать smtp сервер (MTA, mail transfer agent), который и будет заниматься отправкой твоего письма на smtp сервер получателя.

Во первых твоё письмо может читать администратор этого smtp сервера. И грубо говоря не только читать, но и что угодно с ним делать, например отослать копию «безопасникам» на проверку и хранение. Если это «скрытая копия» (BCC, blind carbon copy), получатель письма не узнает что письмо отослано куда то ещё, так как в заголовках это не отразится. Если этот smtp сервер может напрямую соединиться с smtp сервером получателя — письмо доставлено.

Во вторых, может получиться так что smtp сервер который ты в настройках прописываешь — внутренний, корпоративный. И ты не можешь прописать другой, так как на уровне файрволла почтовый протокол заблокирован наружу. И этот единственный доступный тебе «внутренний» сервер тоже не может «ходить в интернет» напрямую, он для обмена почтой внутри конторы в первую очередь предназначен. Но в его настройках указан «relay» — то бишь «сервер пересылки», который уже может с «внешним миром» общаться. В этом случае твоё письмо пойдет через этот сервер, и ты никак не можешь на это повлиять или изменить.

В третьих, может быть так что MX записей сервера получателя в DNS несколько, обычно так оно и есть. Это нужно на случай если «основной» сервер окажется по каким либо причинам недоступен, тогда твоё письмо уйдёт на один из «резервных» серверов, которые собсно тоже могут быть «серверами пересылки». На это ты тоже повлиять не в состоянии.

Вывод — письма стоит шифровать.

Вывод — письма стоит шифровать.

В смысле, помимо SSL/TLS, дополнительно, например GPG?

Ты ещё спроси, зачем шифровать Wi-Fi, если используешь TLS. В сторону Tor просто не гляди, вдруг мозг рванет.

В смысле не путаем тёплое с мягким, я же писал. Забудь про SSL/TLS, это касается канала. Ты не можешь никак повлиять на «прохождение» или «непрохождение» своего письма через промежуточные сервера, на них с твоей почтой можно что угодно делать.

Для уверенности в том что содержимое письма конфиденциально нужно шифровать его «тело», с помощью s/mime или GPG. Но для этого тебе и получателю сначала нужно обменяться «открытыми» ключами по «безопасному» каналу.

Хорошо, а если сузить возможность перлюстрации писем таким образом:

1) создаю почтовый сервер, доступ к которому (физический и логический) буду иметь только я, например, домашний @chukcha.ru
2) моих удаленных приятелей регистрирую на этом сервере
3) нашу переписку ведем только через этот сервер

В этом случае никто не сможет читать нашу переписку?

Или такие наши письма все равно будут проходить через произвольные чужие транзитные/релейные сервера, где админы их смогут прочитать?

Если получатель @chukcha.ru то нет. Другие не увидят.

Если получатель @chukcha.ru то нет.

Ок, а если получателями будут все члены этого кружка? :-)

Т.е. pupkin@chukcha.ru, petrov@@chukcha.ru, sidorov@chukcha.ru и т.д.


Upd. Или если вы немного ошиблись в написании, и хотели написать -

Если получатели @chukcha.ru

но ошибочно написали

Если получатель @chukcha.ru ?

Если все твои приятели смогут своими MUA (почтовыми клиентами) напрямую подключиться к твоему smtp серверу используя шифрование, то бишь прописать в настройках его адрес и указать протокол, то да, это будет безопасно, потому что ваши письма по сути не будут пересекать границы твоего сервера. Но кроме MTA (smtp сервер) тебе ещё и MDA на нём настроить придётся, чтобы почта по папочкам раскладывалась, а так же что либо отдающее её почтовым клиентам через IMAP\POP3 (тоже с шифрованием ессно).

Но если тебе нужно ещё с кем то переписываться кроме этих конкретных приятелей — придётся настроить DNS с «честным» резолвингом «обратной записи», то бишь чтобы запрос по IP выдавал «chukcha.ru», а не <что то случайное>.you_provider.ru, озаботиться наличием MX записи, прохождением проверок на «подлинность» этих записей (DNSSEC, SPF, DKIM, DMARC) и ещё много страшных слов. Иначе всё отправленное с твоего сервера будет автоматически отвергаться или улетать в спам. Ну и IP должен быть «чистый», не запалившийся в спамлистах.

Короче почта это НЕ просто.

придётся настроить DNS с «честным» резолвингом «обратной зоны», то бишь чтобы запрос по IP выдавал «chukcha.ru», а не <что то случайное>.you_provider.ru, озаботиться наличием MX записи, прохождением проверок на «подлинность» этих записей (DNSSEC, SPF, DKIM, DMARC) и ещё много страшных слов.

Как ни странно, я умею это делать, и делал не раз.

Но вот что такое в данном контексте MDA - не понял...

Знаю только MUA и MTA.

MDA раскладывает почту по ящикам собсно, в каком бы виде те ящики не находились, в виде файлов, каталогов на ФС или записей в БД. Просто сейчас функциональность MDA и MTA часто в рамках одной софтины находится, например postfix MTA и MDA одновременно, но технически можно и альтернативные MDA использовать.

Просто сейчас функциональность MDA и MTA часто в рамках одной софтины находится, например postfix MTA и MDA одновременно

Ну, поскольку в основном пользуюсь postfix (реже exim), то не удивительно, что эту аббревиатуру и не слышал.

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

(опять-таки, случаи взлома. подмены DNS и прочие хакерские хитрости не рассматриваем, считаем, что их не будет)

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

Да, если сам сервер не взломают.

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

Подразумевал домен. Relay не производится.

Да, если сам сервер не взломают.

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

Всем спасибо за помощь и соучастие! :-)

Пошел ваять очередной почтовик...

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

Идейно ещё бы отрубить у всех чукч все входящие и исходящие вне этого домена, но это другая тема

но это другая тема

Тема хорошая, и недавно отыскал для этого классную игрушку! :-)
Появится время, опубликую впечатления

Соединение между серверами и соединение между сервером и клиентом

Соединение между серверами и соединение между сервером и клиентом

- это вообще о чем? Фраза без глагола, не несущая смысла

Это ответ на вопрос в заголовке: «Что именно шифрует SSL/TLS в электронной почте?»

(c) Ну, так бы сразу и сказал :=)

Мы хотим gpg, но нам проще «Пошел ваять очередной почтовик...».

Дорогуша, тот почтовый клиент, который будет отправлять письма на почтовый сервер, является непрограммируемым, т.е. аппаратным устройством.
Но разве тебя это остановит? :=)

Трафик передаваемый по сети. Шифрование решает проблему человека по середине. В самом безобидном случае провайдер тебе пихает свою рекламу на чужие сайты.

Но разве тебя это остановит? :=)

Лично меня это не остановит, потому что я в таком случае заверну его во что-то, к чему у меня есть доступ и пошифрую там. Это явно проще, чем писать «свой почтовик».

Дорогуша

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

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

В почте? оО

imap/pop3 зашифрованы почти всегда

submission тоже

smtp между серверами, могут быть и открытыми мне кажется чаще, но если речь о крупный почтовиках, то при пересылке письма например с gmail на какой-нибудь яндекс оно может быть прочитано админами gmail и яндкеса и теми кому они это письмо сольют

для шифрования почты пир ту пир есть pgp и s/mime

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

Шифруется канал между сервером и клиентом. Провайдер ничего не увидит. Админ сервера к письмам доступ имеет полный.

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

Я прост не понял, провайдер почты или провайдер твоей сети до почты:) если второе, то tls от этого и нужен. От первого не спасет ничего кроме шифрования на клиенте.

Алсо, глянь тред DoubleContact: поломанные зависимости в Debian testing (комментарий)

Наш модератор там уже год не может себе сертификат на сайт сделать.

ЗЫ - почта говно и не нужна, я считаю. Как и жабер. Идея хорошая была, но в текущих реалиях не работает. Подтверждение доставки если и есть, то может не работать (и ты об этом не узнаешь). Твою подсеть закинут в бл, и будешь скакать кабанчиком потом, чтоб ее достать оттуда. Централизованные блеклисты и прочее, в том числе те, кто шантажирует.

Матрикс и телеграм наше все. Оба сдохнут со временем, конечно, но хорошо что есть какое-то развитие.

Конкретно сейчас мне например проще слать http запрос к апи матрикс/тг серверу от мониторингов (и обработать потом ответ или тайм-аут), чем корячиться с отправкой мыла, которое может ещё и не дойти в заданный срок.

smtp между серверами, могут быть и открытыми мне кажется чаще

Только у самых отсталых такое осталось. Я вот у себя на сервере серьёзно подумываю отключить fallback на нешифрованный smtp.

Лично меня это не остановит, потому что я в таком случае заверну его во что-то, к чему у меня есть доступ и пошифрую там.

Ну-ка, ну-ка, и во что ты завернешь и как?
Посмотрим, что проще - почтовик или твое «заворачивание»? :-D

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

В итоге это кончается одинаково - мы тебе даём несколько вариантов решений, ты сидишь как королева и выбираешь наиболее удобное для твоих целей. При этом (не знаю, зачем), оскорбляя остальных.

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

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

Ну иди нажалуйся снова. «Ой, мой вопрос не стали решать».

Ты - паразит.

easybreezy (c ) Шо, опять выгнали??
И поделом - нечего гадить на форуме!

Итак, почтовик давно поднял, работает как колокольчик.
Сегодня занялся железякой для нее, однако столкнулся с проблемой:
- хотя все опробованные почтовые клиенты по шифрованному каналу, т.е. по SSL/465, с ним прекрасно взаимодействуют и рассылают письма, но эта клятая железяка по нему упорно не хочет отсылать письма.
По открытому 25-му отсылает без проблем, но надо-то как раз по шифрованному, иначе за что боролись?.

Переизучил все эти SL/TLS/STARTTLS и поигрался настройками POSTFIX, но только туману в голове больше прибавилось :=)

Кто желает помочь решению это простой, но для меня сложной задачи?

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

А что за железка? Совсем тупая и непрошиваемая?

Может, в одной локальной сети с ней поставить релей, который будет от неё принимать по 25-му порту без шифрования (то есть риск компрометации остаётся только в рамках одного свитча), а дальше уже слать по шифрованному каналу куда нужно?

О, мне тут шифропанковский вариант в голову пришёл.

1. Железка коннектится к компу в одной локалке с ней по 25-му порту
2. На компе 25-й порт слушает тупо HAProxy
3. В качестве бекенда у ентого хапрокси указан внутренний адрес почтовика, до коего он коннектится по, например, VPN или Yggdrasil, или i2p… Нутыпонел. :)

Да, железка давно снята с производства и не поддерживается.
Так что новых прошивок нет и не предвидится.
Можете называть ее видеокамерой.
Один косяк в ней разгадал - оказалось, что она в упор не понимает длинные пароли и пароли со спецсимволаами, ну эт ладно, проехали.

Насчет релея тоже думал, но те, которые знаю, т.е. ssmtp и msmtp, должны стоять в этой же железке, чего сделать, конечно, невозможно.
А насчет «удаленных» релеев пока не в курсе.

А твои п.п. 1,2, 3 понять должен .... но не понял :-)
Уж очень лихо они закручены! Можно ли как-то попроще, по-чукчински?

Можно ли как-то попроще, по-чукчински?

Как-то так:

• 10.0.0.2 - железка
• 10.0.0.13 - комп рядом с ней
• на 10.0.0.13:25 слушает haproxy (в режиме tcp)
• там же на 10.0.0.13 поднято что-нибудь шифрующее (впн, иггрдасиль, ш2з… Оно же должно быть и на почтовом сервере)
• в конфиге haproxy указываем в качестве бекенда адрес почтаря в этом самом «чём-нибудь». на 25-й порт.
• ???
• PROFIT! Трафик с местонахождения железяки до почтаря идёт по шифрованному каналу. Единственное место, где можно вклиниться - между железякой и компом с haproxy

из википедии:

В многоуровневой модели OSI протокол SSL располагается между протоколом транспортного уровня (например, TCP), и протоколом прикладного уровня (чаще всего HTTP).

Таким образом можно сделать вывод, что у тебя шифруется «все»(весь пакет данных) и хедеры и тело. По сути твой провайдер может увидеть только IP(или домен) того, кому ты делаешь запрос(удаленный сервер)

По сути твой провайдер может увидеть только IP(или домен) того, кому ты делаешь запрос(удаленный сервер)

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

Как-то так:

Если так, то идея предельно ясна, сам вначале примерно так же прикидывал, но отверг ввиду сложности инфраструктуры, а она тут не подходит.
Поясню почему: когда ухожу из дому и камера направлена на калитку, мне хотелось бы знать, кто приперся на мой двор.
Камера реагирует на движение и отсылает в «облака», т.е. в почтовый сервер, снимки или целое видео.
И вот тут очень важно, чтобы все это хозяйство:
а) Было надежным, а поэтому должно быть предельно простым
б) Потребляло минимум э/энергии, чтобы при ее пропадании переходило на аккумулятор и от него проработало как можно дольше.

Поэтому для этой затеи даже роутер подобрал, который потребляет всего 80 мА.
Так что какие-то домашние компы и сервера тут увы, не проходят.
Надо извернуться так, чтобы в этом деле участвовало всего два устройства -
- видеокамера
- роутер.

Так что хотелось бы, как говорится, перейти к истокам, т.е. к почтовому серверу, в котором POSTFIX брыкается и не принимает SSL от железяки - а ведь должен!

Имхо, там надо что-то подкрутить в main.cf и master.cf
Крутил уже как умел, логи анализировал, но тут настоящий знаток Постфикса нужен...