LINUX.ORG.RU
ФорумTalks

Почему вы любите эл. почту?

 


4

4

Мои претензии к почте:

  1. Это устаревшее корпоративное блоатваре

  2. Сервер собеседника может читать всю вашу переписку.

  3. Поскольку предвижу проблемы с чтением предыдущего пункта, повторяю: сервер собеседника.

  4. Сервер собеседника в 99% случаев яндекс, гугл и т.п.

  5. TLS не позволяет настоящую защиту: любой дурак, получивший доступ к ЦС, может читать вашу переписку

  6. …а телега и вотсапп, не говоря же у матрикс, позволяют полноценное EE шифрование

  7. минус нормальные уведомления, аудиовидео, +спам ну и так по-мелочи

  8. из-за пункта 4, 100500 ограничений на передачу файлов: у многих бесплатных до сих пор файлы по 12 Мб приходится нарезать, например

★★★★★

Последнее исправление: next_time (всего исправлений: 1)
Ответ на: комментарий от skiminok1986

У мессенджеров есть область применения. Просто она не пересекается с почтой.

Зато почту при желании можно использовать как месенджер - писать однострочные письма никто не запрещает. И сейчас, а не тридцать лет назад, они доставляются также быстро как сообщения в месенджере. Собственно, DeltaChat так поверх почты и сделан.

watchcat382 ★★
()
Ответ на: комментарий от skiminok1986

Это гораздо удобнее пароленного зипа.

С запароденым зипом обращаться умеют все. Пользованию GnuPG или PGP - вам придется своих корреспондентов учить. Человеку удобно то, чем он умеет пользоваться.

watchcat382 ★★
()
Ответ на: комментарий от skiminok1986

Подтверждение о доставке это не гарантия доставки.

А что же это? Если не получили подтверждение в разумное время - отправьте еще раз или свяжитесь по другому каналу.

watchcat382 ★★
()
Ответ на: комментарий от skiminok1986

Почему люди резко перестали понимать шифрование?

Его вообще очень мало кто понимает если оно сложнее запароленного зипа. Даже у программистов с пониманием не очень - настолько что были неоднократные случаи когда секретные ключи оказывались на гитхабе вмесе с исходниками.

watchcat382 ★★
()
Ответ на: комментарий от skiminok1986

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

И кто помешает злоумышленнику взять такой ключ и расшифровать перехваченное сообщение?

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

А с зипом надо как-то безопасно передать пароль.

Надо. Или один раз договориться по какому правилу формируются пароли если скрытые сообщения приходится пересылать достаточно часто.

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

И это хорошо, потому что об инциденте всё равно уведомлять надо и это повысит бдительность всех участвующих в переписке.

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

watchcat382 ★★
()
Ответ на: комментарий от skiminok1986

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

watchcat382 ★★
()
Ответ на: комментарий от skiminok1986

А как нынче принято ставить софт на смарты?

Самый простой и удобный способ для тех у кого есть комп - adb install file.apk Скачать apk-файл можно с сервисов типа apkpure. Причем там есть возможность выбрать нужную версию, а не только последнюю как обычно в «магазинах».

watchcat382 ★★
()
Ответ на: комментарий от anc

С imap idle почта тоже «гоняется за тобой

Я пробовал несколько сочетаний «бесплатный почтовик + сотовый оператор» - imap idle не заработало нигде. Там же tcp-соединение должно постоянно висеть, так вот оно быстро обрывается. Видимо операторский nat не понимает что это такое.

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

watchcat382 ★★
()
Ответ на: комментарий от oxo

email имеет юридическую силу.

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

watchcat382 ★★
()
Ответ на: комментарий от anc

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

И кто помешает злоумышленнику взять такой ключ и расшифровать перехваченное сообщение?

Выкладывают открытый ключ, им зашифровывают, расшифровывают закрытым. Смысл асимметричной криптографии именно в том, что тем ключом, которым зашифровал, нельзя расшифровать.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Выкладывают открытый ключ, им зашифровывают, расшифровывают закрытым.

Это применимо только если всё уже настроено и налажено. А я говорю о случае когда нужно достаточно внезапно послать что-то другому человеку. У него нет ни открытого ни закрытого ключа, ни умения их создать и использовать. Вот и представьте что вам придется обучать его как это всё настроить и использовать. Еще и уговорить его чтобы он так заморочился. А бесплатный распаковщик zip есть на почти каждом компе. Остается только как-то передать пароль к посланному архиву. Что явно проще чем обучить использованию асимметричной криптографии. Разумеется, какие-то совсем страшные секреты такому способу передачи доверять нельзя, а для бытового применения - вполне приемлимо потому что просто.

Смысл асимметричной криптографии именно в том, что тем ключом, которым зашифровал, нельзя расшифровать.

Всё это хорошо когда используется квалифицированными персоналом.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Я пробовал несколько сочетаний «бесплатный почтовик + сотовый оператор» - imap idle не заработало нигде.
бесплатный почтовик

Удивительно… прям удивительно…

Видимо операторский nat не понимает что это такое.

операторский nat тут не приделах, там тупое соединение.

Ну и в почтовых клиентах уведомления можно не включать если не нужны.

Их скорее включать нужно если нужны.

anc ★★★★★
()
Ответ на: комментарий от Somebody

email имеет юридическую силу

Это где это??..

Во всяком случае в us ca и вроде у нас в виде распечатки с подписями, прописями, отпечатками пальцев.

anc ★★★★★
()
Ответ на: комментарий от watchcat382

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

Ну чертежи вундервафли наверное действительно не стоит.

anc ★★★★★
()
Ответ на: комментарий от anc

операторский nat тут не приделах, там тупое соединение.

Так я не поленился пронаблюдать что происходит. Специальный плагин в sylpheed устанавливает соединение. Ему даже можно включить чтобы он «холостую» команду периодически отправлял - именно для поддержания соединения это в нём сделано. И несколько раз он даже отправит и ответ на нее получит. А потом при очередной отправке соединение оказывается разорванным. Плагин эту ситуацию обрабатывает, создает новое, и всё повторяется. Проверял и на gmail.com и на aol.com где у меня нынешняя почта. Кроме как на операторский nat грешить вроде не на что.

уведомления можно не включать если не нужны.

Их скорее включать нужно если нужны.

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

watchcat382 ★★
()
Ответ на: комментарий от anc

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

А как нынче принято ставить софт на смарты?

Самый простой и удобный способ для тех у кого есть комп - adb install file.apk Скачать apk-файл можно с сервисов типа apkpure.

Даже пробовать не буду, что-то мне подсказывает что на фрукте не взлетит… да и на симбе и шинде тоже.

anc ★★★★★
()
Ответ на: комментарий от anc

вроде у нас в виде распечатки

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

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

Еще нотариус может заверить распечатку, сделаную на его компьютере. Но не каждый нотариус и не всё согласится заверять. Почту на каком-нибудь бесплатном почтовике - может и отказаться. А например юридически значимый документ на дом я так себе и делал когда мне отказались выдать «свидетельство о собственности» на гербовой бумаге, а дали простую бумажку с «выпиской из реестра недвижимости». Сначала даже бумагу давать не хотели, предлагали на почту прислать:( Я пошел к нотариусу, попросил его тоже получить такую выписку про мой дом и официально заверить. Теперь будет что предъявить если наши власти последуют примеру южнокорейских и утратят свои базы данных.

watchcat382 ★★
()
Ответ на: комментарий от anc

Даже пробовать не буду, что-то мне подсказывает что на фрукте не взлетит…

Тоже думаю что не взлетит. Владельцам айфонов можно посочувствовать - у них недоступны всякие полезные и удобные возможности. К примеру вытащить или положить файлы (например музыку в mp3) с/на андроидный девайс - одна команда adb pull / push. Фруктовый девайс подключить к компу - намного больше заморочек. Есть правда обходной путь - записать файлы на флешку и подключить ее к яблочному смартфону через переходник OTG, потом средствами самого смарта оттуда скопировать. Но это только для тех айфонов у которых интерфейс usb-c. Как раз неделю назад я таким способом делился музыкой с соседкой.

и шинде тоже.

У меня в коллекции есть Asus P535 с WinMobile. При подключении к компу виден как просто mass storage device и никаких ухищрений не требует. Можно скопировать в смонтированный «диск» любые файлы, в том числе установщики софта.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Владельцам айфонов можно посочувствовать

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

CrX ★★★★★
()
Ответ на: комментарий от anc

надо озвучивать длину пароля.

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

А бесплатный распаковщик zip есть на почти каждом компе. Остается только как-то передать пароль к посланному архиву.

Если у него есть почтовый клиент и он смог его настроить, то сквозное шифрование в том же Thunderbird настраивается не сложнее, чем само подключение к IMAP (искать по словам «Настройка Thunderbird» по ссылке https://habr.com/ru/articles/565212/).

И после этого не надо плясать с бубном при каждой передаче архива.

monk ★★★★★
()
Ответ на: комментарий от CrX

Они сделали свой выбор и знали, на что шли.

К сожалению - знали не все и не всегда. Реклама любит врать,преукрашать и преувеличивать.

сочувствовать мазохистам.

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

К сожалению - знали не все и не всегда. Реклама любит врать,преукрашать и преувеличивать.

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

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

Садистам в этом плане, пожалуй, сложнее. Мазохисту же не нужен партрён тоже мазохист, ему нужен тот, кто сможет удовлетворить его эту потребность. А с этим попроще.

CrX ★★★★★
()
Ответ на: комментарий от monk

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

не надо плясать с бубном при каждой передаче архива.

В разных архивах можно использовать разные пароли. Например договорившись что к паролю добавляется часть, создаваемая из текущей даты каким-то способом. Соответственно, утекший единственный пароль не позволит расшифровать всю переписку. А в Thunderbird ключ шифрования привязывается к сохраненному адресу корреспондента и менять его каждый раз существенно неудобнее. Опять же не говорю что совсем невозможно. Но создать новую пару ключей должны не вы, а тот кому вы хотите послать письмо, после этого отправить вам открытый ключ. Если же секретный ключ утечет то может быть расшифрована вся переписка в которой он использовался. Это равноценно использованию одного пароля на все пересылаемые zip-файлы.

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Но как показывает практика - заморачивают этим единицы людей.

Как же надоел этот нелепый аргумент…

Со сколькими миллионами людей тебе требуется приватная переписка? Или может с тысячами? Неужели с сотнями?

Ну не с единицами же, правда?

CrX ★★★★★
()
Ответ на: комментарий от anc

и вроде у нас

Нет, не так всё это просто.... Там очень много «но» имеется...

Somebody ★★★★
()
Ответ на: комментарий от CrX

жизнь показывает, что многие ни с первого, ни со второго, ни с третьего раза не учатся…

К сожалению это действительно так :(

Садистам в этом плане, пожалуй, сложнее.

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

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

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

CrX ★★★★★
()
Ответ на: комментарий от CrX

Как же надоел этот нелепый аргумент…

Не такой уж он и нелепый.

Со сколькими миллионами людей тебе требуется приватная переписка?

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

Технически какую-то степень приватности можно было бы организовать и в почте. Для этого надо чтобы большинство популярных почтовых клиентов сами генерировали пару ключей, а каждый почтовый сервер хранил бы у себя публичные ключи своих пользователей и отдавал по запросу через какой-то общепринятый протокол. Вот тогда шифрование писем можно было бы действительно включить одной кнопкой, а то и сделать включенным по умолчанию (кому не надо - выключат). Прислал мне кто-то письмо - мой клиент сам запрашивает публичный ключ у его почтового сервера и сохраняет у меня в адресной книге. Если я буду на это письмо отвечать то написанное мной уже может быть зашифровано. Но увы - за несколько десятков лет существования почты никто такое не сделал. Возможно не сделали потому что раньше почта могла ходить часами через медленные линки и запрос публичного ключа у сервера отправителя был бы очень долгим.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Не такой уж он и нелепый.

Один из самых нелепых среди тех, что часто всплывают на этом форуме.

Лично я бы хотел чтобы вообще вся личная переписка по умолчанию была приватной.

Да много кто бы хотел. Кроме корпораций, которые зарабатывают на твоей переписке и госструктур, которые хотят её контролировать.

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

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

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

CrX ★★★★★
()
Ответ на: комментарий от watchcat382

Всё равно ведь публиковать надо, то есть как-то отправлять серверу…

Никто не мешает в первом нешифрованном сообщении слать свой публичный ключ, который получатель установит в свой почтовый клиент (например, Thunderbird). И тогда никакой поддержки от сервера не надо, всё уже есть.

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

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

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от watchcat382

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

А вот это вообще даёт почтовому серверу MITM: он может отдать свой публичный, получить письмо, расшифровать, зашифровать публичным пользователя, отдать пользователю.

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

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Лично я бы хотел чтобы вообще вся личная переписка по умолчанию была приватной.

Для этого надо, чтобы у каждого была усиленная квалифицированная электронная подпись с токеном с неизвлекаемым закрытым ключом (как ИФНС выдает). Тогда отправляешь свой сертификат, его корректность и твоё ФИО подтверждает подпись МинЦифры, если токен украдут, есть возможность отозвать сертификат. И можно шифровать или им самим (тогда риск расшифровки при краже токена) или на каждую сессию (блок сообщений) создавать подчинённый сертификат, подписанный своим, тогда кража закрытого даст расшифровку только этой сессии.

monk ★★★★★
()
Ответ на: комментарий от CrX

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

Ну мы же не спрашиваем поддерживает ли клиент стандарт RFC на оформление заголовков письма. Или вот MIME в свое время как-то смогли внедрить. А я еще помню как надо было вырезать из текста письма кусок с UUencod`ом и скармливать его отдельной программе-декодеру. Потом большинство почтовых клиентов научились сами обрабатывать нетекстовые объекты в письмах и сейчас присоединенный к письму файл выглядит именно как файл, а не как несколько [десятков] страниц ууенкода в окне. Исключения наверно есть, но совсем малочисленны, может на каких-то портативных девайсах только остались. Вот и описанный мною вариант с передачей публичных ключей можно было бы внеднить. Но видимо слишком мало кому приватность настолько нужна и поэтому такого запроса к авторам софта нет. Да, корпораты может быть и воспротивились бы внедрять такое в свой закрытый софт, но очень много же почтовых серверов работает на открытом софте.

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

Можно и упрощенный вариант придумать, чисто за счет клиентского софта. Например почтовый клиент автоматически по умолчанию присоединяет к письму открытый ключ. При нынешних объемах трафика от этого никто бы не пострадал. Однако вот слать письма из двух кусков когда один текстовый, а второй тоже самое в html - это пожалуйста, хотя места занимает больше. А открытый ключ послать - никак. Соответственно и на принимающей стороне увидев в полученном письме открытый ключ - почтовый клиент мог бы сам его сохранить без дополнительных телодвижений со стороны юзера и использовать для шифрования ответа. Неудобство если и остается то только в том что перед пересылкой секретов надо обменяться нешифрованным письмами чтобы с ними были доставлены открытые ключи. Но если выделение и сохранение ключей из писем будет происходить «само» в клиенте то неудобство не критичное.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

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

Не можно, а только так это и делается. Никакая поддержка со стороны сервера тут не требуется. Со стороны клиента в принципе тоже, но клиент добавляет удобства/автоматизации.

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

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

CrX ★★★★★
()
Ответ на: комментарий от monk

Никто не мешает в первом нешифрованном сообщении слать свой публичный ключ, который получатель установит в свой почтовый клиент (например, Thunderbird). И тогда никакой поддержки от сервера не надо, всё уже есть.

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

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

Технически - безусловно да. Но для управления большим количеством ключей в клиенте надо реализовать соответствующую «автоматику», ибо человек запутается. А ее по сей день нет.

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

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

Можно расширением к почтовому клиенту сделать. Специально трактуемое сообщение с запросом открытых ключей (кодовое слово + количество). Перед отправкой писем клиент отправляет письмо-запрос, получает Н ключей для шифрования, отправляет письма.

Для предотвращения MITM открытые ключи должны быть подписаны электронной подписью (сертификатом) пользователя.

monk ★★★★★
()
Ответ на: комментарий от watchcat382

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

(habrastorage.org)

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

это вообще даёт почтовому серверу MITM: он может отдать свой публичный, получить письмо, расшифровать, зашифровать публичным пользователя, отдать пользователю.

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

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

Через что ни отправляй - это опять вопрос доверия к способу отправки. В пределе приходим к необходимости передать открытый ключ на флешке при личной встрече. Что не отличается от передачи пароля к zip-архиву. Именно из-за таких казусов я выше и писал что доверять особо важные секреты обычным «гражданским» способам связи нельзя. Никаким, ни почте, ни телефону, ни месенджерам. А вот что-нибудь типа интимной переписки с женой - вполне можно, если вы не какой-нибудь там видный политический деятель или кто-то подобный. Понятно что не хотелось чтобы ее кто-то читал кроме объекта вожделения, но если к примеру прочитают спецслужбы то вобщем-то не критично. А кто попроще - уже не прочитают даже при не слишком «зверских» мерах безопасности.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

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

Это нормально. Обмен «удобства» на приватность. Иначе никак. Любая лишняя автоматика здесь только повышает уверенность непосвящённых и необходимость объяснять им, почему встроенными механизмами пользоваться небезопасно, а также повод называть тебя (объясняющего) параноиком.

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

CrX ★★★★★
()
Ответ на: комментарий от monk

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

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

Вот честно скажу — я рад.

CrX ★★★★★
()
Ответ на: комментарий от watchcat382

Это вопрос доверия к почтовому серверу, аналогичный вопросу доверия к сертификатам в https

Не совсем. Сертификаты в https выдают одни, а канал от пользователя до веб-сервера выдают другие. Аналогией было бы, если бы в https были только самоподписанные сертификаты и всем пришлось бы доверять интернет-провайдерам.

А вот что-нибудь типа интимной переписки с женой - вполне можно, если вы не какой-нибудь там видный политический деятель или кто-то подобный.

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

Кстати, я поэтому против https. Он даёт ложное ощущение безопасности и заставляет устаревать страницы (если их постоянно не обслуживать). При том, что для действительно безопасной передачи его недостаточно (надо ещё контролировать DNS, хостера, провайдера Интернета, где DNS сервер…).

monk ★★★★★
()
Ответ на: комментарий от CrX

Обмен «удобства» на приватность.

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

Совершенно нормально и правильно осуществлять обмен множественными ключами по независимому каналу отдельно

На такое неудобство согласятся только истинные параноики:) Да и то они скорее что-нибудь другое вместо почты выберут для передачи своих секретных посланий.

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

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

Вот для этого достаточно Уголовного Кодекса.

monk ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)