30 марта 2023 года Mozilla закрыла баг 135636 и исправила ошибку по автоматическому включению/отключению шифрования почтовых сообщений в зависимости от текущей конфигурации отправителя и получателя (режимы OpenPGP и S/MIME). В этом не было бы ничего странного, если бы не одна деталь: тикет открыт 21 год назад. В связи с этим возникает вопрос: почему закрытие такого простого бага заняло больше двух десятилетий?
История бага
5 апреля 2002 года пользователь Маркус Герстель (Markus Gerstel) обратил внимание на некоторое неудобство настроек шифрования в менеджере аккаунтов (Account Manager) почтового клиента MailNews в Netscape 4. Там было два режима: 1) никогда не шифровать сообщения или 2) требуется шифрование (отправка незашифрованного письма невозможна).
Режим с включённым шифрованием:
Режим с выключенным шифрованием:
Это на самом деле неудобно, потому что нужно было отключать настройку шифрования каждый раз, когда вы хотите отправить письмо пользователю, не имеющему сертификата или публичных ключей. Или наоборот, каждый раз включать её, когда хотите отправить зашифрованное письмо. Автор выразил пожелание реализовать третью альтернативную опцию «Шифровать, когда это возможно», не требующую от пользователя включать/отключать шифрование вручную.
Таким образом, шифрование будет включаться автоматически при составлении письмо для адресата, который предоставил открытые ключи. Действительно, очень удобно. Есть ключи или сертификат — шифруем. Нет ключей — не шифруем.
Разработчики согласились, что такую опцию нужно реализовать, но сама реализация заняла ровно 21 год. Почему?
Сначала один из мейнтейнеров Чарльз Розендаль (Charles Rosendahl) посчитал, что данный баг предполагает регрессию, то есть требует исправления другой связанной функции. Хотя другие с ним не согласились, но это привело к задержке примерно на семь лет.
Затем вопрос с регрессией сняли, но сама тема потеряла актуальность, потому что в целом шифрование почты с помощью OpenPGP перестало восприниматься как нечто необходимое и обязательное. Частично это произошло из-за сложностей интерфейса и потому что ни один почтовый клиент не обеспечил первоклассную удобную реализацию шифрования.
Два года назад Mozilla заново подняла эту дискуссию, она переросла в споры о дизайне, и только в 2023 году наконец-то опция была реализована.
Шифрование почты должно стать стандартом
История с багом в почтовом клиенте Mozilla наводит на подозрение, что разработчикам как будто кто-то мешает реализовать нормальное шифрование электронной почты. С технической точки зрения совершенно понятно, как должна работать стойкая криптография и PGP, какие шифры использовать. Но вот с точки зрения интерфейсов как будто кто-то посторонний постоянно ставил палки в колёса и мешал развернуть эту функциональность на широкую аудиторию.
Довольно распространено мнение, что шифрование электронной почты было и остаётся неудобной процедурой. Всё можно было сделать гораздо понятнее для простых пользователей. Тем более для важной функции. Это просто удивительно, что настолько важная технология до сих пор не стала мейнстримом, и многие люди до сих отправляют конфиденциальные письма, не используя стойкую криптографию.
Почему ни один почтовый клиент за многие годы не сделал удобную реализацию PGP или S/MIME — это открытый вопрос. Такое ощущение, что им как будто кто-то специально мешал это сделать. В самом деле, если посмотреть на десятилетия развития PGP и шифрования почты, то мы видим множество неудачных реализаций, отсутствие должной разработки, ужасный UI, которым невозможно пользоваться, всевозможные задержки внедрения, распространение различных труднореализуемых стандартов.
В то же время было реализовано шифрование в вебе (TLS), есть прогресс для мгновенных сообщений. А вот что происходит с электронной почтой — вызывает недоумение, словно кто-то реально мешает со стороны.
Разработчики популярных ОС могли бы организовать распространение сертификатов S/MIME, реализовать хранилища сертификатов для удобства шифрования почты. Но не сделали этого. Конечно, управление персональными сертификатами пользователями в большом масштабе сложнее, чем управлением сертификатами веб-сайтов, но это решаемая задача.
В идеале, на почтовых серверах весь архив должен храниться в зашифрованном виде, и если провайдер/хостер попытается прочитать текст письма, то увидит что-то вроде такого:
-----BEGIN PGP MESSAGE----- hF4DiRYQNnty8w4SAQdAdiM2arHOheTBYTJriZZQOarZJy39Hs2Hl2tbAM/n5yMw 3DrQEjbJtP2LAm1oxaKPI3cyL05OFMU4p5ZKzbNLChEgNG7dxrUZJ9/0aS1P/8hl 0lkBHVB0DPdgxtLk7tl23iozcnoP4Heua1Lvqf831Cy51409FHk4UX/hUPwg2E/O mRczP2UVrbBB90CA0L0wRFfXZpPTtq0UusAtPZ4evtzEgcH4pDK5LV7hog== =vlQ3 -----END PGP MESSAGE-----
Наверное, это тоже одна из причин, почему крупные почтовые провайдеры не стремятся реализовать стойкую криптографию для всех по умолчанию. Ведь тогда они лишаются возможности внедрять контекстную рекламу и дополнять профили пользователей.
Хотя это немного похоже на параноидальную теорию заговора, но нельзя отрицать того факта, что внешние силы тоже противодействуют внедрению стойкой криптографии. По мнению отдельных спецслужб, простым людям нельзя давать в руки этот инструмент, потому что тогда его начнут использовать преступники. Даже сегодня в наши дни наличие криптографических мессенджеров типа Signal на телефоне человека может стать поводом для подозрений. Конечно же, ситуацию нужно исправлять. Многие специалисты по безопасности говорят, что шифрование электронной почты должно стать стандартом, ведь тайна почтовой переписки защищена Конституцией и является одним из основных прав человека.
Подробнее о защите электронной почты для организаций на сайте GlobalSign
Комментарии (37)
DMGarikk
20.04.2023 13:14+5ведь тайна почтовой переписки защищена Конституцией и является одним из основных прав человека.
вроде уже в прошлом или позапрошлом году в РФ решили, что почтовая переписка = бумажная переписка, а то что вы там байтики шлете — это не почта
ну это лирика, а вообще как я понял все заткнулось на сложности реализации. я по долгу работы много общался через зашифрованную почту и… и это геморрой, адресату надо както отправить открытый ключ, надо получить ключ от него, надо настроить адекватно клиента, гдето хранить ключи, чтото делать если ключ потерялся, в моем случае ключи вообще хранились в usb токене а потом еще на срвере надо было обрабатывать такие письма и там както правильно хранить эти ключи и обновлять их… а люди не способны какимто одним способом это делать… то в аське то через личную почту… разве что голубями их не присылали
а потом с определенной версии OpenPGP её перестали в РФ поставлять и переход на OpenGPG дался крайне болезнено из-за некой… скажем так кривизны плагинов для оутлука с волшебными кнопочкамивобщем история мне конечно эта вся очень нравилась, но поскольку я учавтсвовал в настройке этого всего и траблшутинге проблем в стиле "я не могу письмо от вас прочитать почемуто, вчера мне компьютер поменяли… как надо было открытый ключ по новой отправить?" (а в переписке 15 адресатов половина которых их больших компаний за бугром которые работают по ночам для нашего пояса… и трое суток все друг другу ключи шлют вместо работы… когда вы уговорите Сьюзи из Атланты что у вас ключ поменялся… она его поменяла и ушла в отпуск… а вы уже тоже самое начинаете Мери объяснять… при этом вы не админ, а менеджер
а потом ктото забыл кнопку шифрования тыркнуть и последние 4 письма в открытом виде ходят… ББезопасностьвот кмк по этому оно и не взлетело
aborouhin
20.04.2023 13:14Ну отправка открытых ключей индивидуально каждому получателю - это уж какой-то совсем извращённый способ. Есть же key server'ы, на которых они публикуются/отзываются, и есть протокол WKD для выдачи ключей для определённого домена. Что позволяет отправителю, если всё это настроено, просто по адресу почты при отправке письма автоматически подтянуть актуальный в данный момент публичный ключ получателя.
А вот кривость софта, отсутствие единых стандартов - да, проблема. Хранение приватного ключа так, чтобы его применять и в десктопном клиенте, и в мобильном, и в веб-интерфейсе, и при этом это было удобно и понятно самому тупому пользователю (а иначе не взлетит), - проблема в квадрате.
DMGarikk
20.04.2023 13:14-1Есть же key server'ы, на которых они публикуются/отзываются
отличная точка атаки, да, ломанул такой сервер через который банки общаются и такой митм можно устроить, закачаешься
делать его внутрикорпоративным = поиметь проблем с интеграцией с теми кто с вами переписывается потому что полюбому оно будет не совместимо со всем сразу
=====
ну это конечно все рассуждение на тему "А вот кривость софта, отсутствие единых стандартов — да, проблема."
так что все верноaborouhin
20.04.2023 13:14+3Ну для того же HTTPS риском "а вот ломанул такой сервер доверенного корневого центра и устроил MITM-атаки вообще всем" как-то управляют :) Не вижу причин, почему бы так же и тут не могло получиться. Так что да, единые стандарты... ладно эти серверы, так ведь даже на уровне формата. Более или менее всё работает с OpenPGP. Но MS в Outlook при этом запилила свой велосипед с S/MIME. Google не пилил ничего, но если бы взялся - тоже 100% это был бы не PGP, а нечто своеобычное.
rsashka
20.04.2023 13:14А его и ломать ненужно. Достаточно попросить нужной конторе и все сами сделают.
aim
20.04.2023 13:14key server это шит. это убивает саму идею того что ключ - это идентификатор пользователя. и не имея гарантии что это именно тот ключ именно того пользователя вы не можете утверждать что послали письмо тому кому хотели.
вся концепция "web of trust" держится только на знакомствах. то есть первоначально вы должны каким-то способом "привязать" ключ к человеку.
aborouhin
20.04.2023 13:14Так оно не взлетит никогда. Пользователи не будут совершать лишних телодвижений. Даже в варианте Autocrypt, где ключ передаётся в заголовке незашифрованного сообщения. Целевая схема - чтобы 100% сообщений по умолчанию были сразу зашифрованы и пользователь для этого не предпринимал никаких усилий. А она без того или иного механизма централизованного хранения публичных ключей не взлетит. Чтобы снизить риски - такое хранение, IMHO, может осуществляться либо на ограниченном количестве всячески аудируемых доверенных серверов, которым будут верить почтовые клиенты / сервисы, а при любом инциденте - доверие будет утеряно (по модели корневых центров сертификации). Либо - на сервере получателя, и тогда тот сам несёт риски. А вот с приватными ключами гораздо сложнее...
DMGarikk
20.04.2023 13:14может осуществляться либо на ограниченном количестве всячески аудируемых доверенных серверов
общедоступная спам-база угу
aborouhin
20.04.2023 13:14Чем с т.зр. удобства формирования спам-баз возможность постучаться на key server и спросить "есть ли ключ для адреса foo@bar.com?" отличается от возможности постучаться на mail.bar.com и спросить "хочу отправить почту пользователю foo, есть такой?"
DMGarikk
20.04.2023 13:14mail.bar.com и спросить "хочу отправить почту пользователю foo, есть такой?"
тем что туда стучатся сервера которые в банлисты спамеров попадают
а на ключевые сервера почты будут ходить все подряд со своих компов, в штатном режиме (не у всех же домен будет с централизованным обменом ключей… прям dns получается)
aborouhin
20.04.2023 13:14Я, честно говоря, в методологии сбора спам-баз полный чайник :) А что, сейчас их не собирают через ботнеты, которые именно что с нигде не засвеченных пользовательских адресов делают "telnet mail.bar.com 25; HELO imnotspammer.fake.com; MAIL FROM:foo@fake.com, RCPT TO:ivanov@bar.com" и записывают результат?.. Вроде ж все проверки на обратную запись, наличие в DNSBL и т.п. обычно после этого происходят, уже в ответ на DATA...
Да и вообще, ещё есть смысл их таким способом собирать именно для спама (а не для целевой фишинговой атаки на определённую контору, скажем), если можно бесплатно или за скромные деньги купить набор утечек с миллионами живых адресов?..
aim
20.04.2023 13:14я могу лишь повторить - все "автомагические" штуки не дают доверия. обязательно кто-то должен проверить.
когда pgp делали сеть была относительно маленькая и идея состояла в том что все друг с другом знакомы. если бы подключить pgp к соц-сетям. вот тогда такой ключстор мог бы иметь смысл.
что-то такое сделано в рамках keybase.io
santjagocorkez
20.04.2023 13:14+2Пишет системный администратор служебную записку, мол, так и так, вот, я сделал, смотрите, оно всё само:
Тут вот у нас сервер ключей, все, как в удостоверяющих центрах, аппаратные хранилища неизвлекаемых ключей
Тут вот плагины под все возможные почтовые клиенты, даже веб
Тут вот домен, политики, ключи приватные сами создаются, пользователь лично придумывает пароль, привязывает 2FA на личном телефоне или аппаратный генератор, ключи пишутся на сервер ключей
Тут вот для внешних контрагентов интерфейс, оно даже всё само подхватывает их MTA и по самому последнему стандарту с ними договаривается о ключах и способах эмбеддинга писем, с переконвертацией полей в письме, если MTA получателя сообщает, что у них по-другому принято
...
В общем, дайте премию. Директор, конечно, отписывает безопасникам, мол, видите, как теперь всё безопасно, а вы, бестолочи, за три года вдесятером не смогли.
А те ему и отвечают: а вот, допустим, менеджер Иванов захотел продать бесценных коммерческих тайн на сторону. И исполнил свою часть сделки с конкурентами по электронной почте. А там всё само и зашифровалось, а где не само, подсказало, как сделать первый раз, чтоб дальше уж точно само. И вот там долгая и длинная цепочка электронной переписки, которую мы даже промаркировать не можем. Понятно, что мы уже в заднице, но даже при полной уверенности, что это дело рук Иванова, нам его хотя бы к ответственности, например, уголовной, как привлечь? Да ладно привлечь, уволить хотя бы как законно? Нам вот этот, купленный всего лишь в прошлом году, DLP куда лучше отдать: в столовую, чтоб ложки сушились, или лучше в упаковочный цех, чтоб упаковщики примерно половину палеты не на глаз меряли, а уже удобнее по подходящему типоразмеру прикладывали?Это там, где ещё более-менее бардак в процессах. А там, где процессы выставлены, системный администратор получит реджект ещё на этапе обсуждения идеи и до всяких r&d.
aborouhin
20.04.2023 13:14+1Ну вот это как раз решается тем, что приватный ключ менеджера Иванова согласно групповым политикам домена хранится централизованно. Но отдельно от почтового севера, само собой, где-нибудь подальше. А директору рассказывают другую историю - что если почтовый сервер завтра изымут в рамках "маски-шоу", заказанного конкурентом, то прочитать смогут примерно ничего. И это куда больший риск, чем ущерб от сколь угодно коварного менеджера.
santjagocorkez
20.04.2023 13:14Если маски шоу изымают почтовый сервер, они изымают и централизованный сервер с приватными ключами. А, поскольку там всё хранится так, что софт имеет доступ к содержимому без воли владельца ключа, то конкурентные маски шоу все нужные им данные отлично прочитают.
aborouhin
20.04.2023 13:14Ну разносить сервера по локациям тоже надо. И шифровать диски, и бекапы, и много чего ещё. В общем, моделируем все угрозы, все риски и пытаемся закрыть максимальное количество сочетаний первых с вторыми. Понятно, что многое и без шифрования писем решается, а многое и с ним не решить - но дополнительный инструмент был бы для этой задачи не лишним.
Как минимум, шифрование почты уникально в том, что позволяет быть чуть спокойнее, если тем или иным способом получат доступ не к вашему серверу (предположим, вы его и так защитили от всех угроз), а к серверу вашего контрагента, с которого вам отправляли конфиденциальные письма (и вот за него вы уже не можете быть так спокойны).
santjagocorkez
20.04.2023 13:14Вместе с сервером контрагента изъяли и компьютеры из офиса контрагента. А на них те самые ключи. Ключи, возможно, даже запаролены, а пароли знают только конкретные пользователи. Вот только беда: пользователь компьютера наделяется статусом свидетеля, а свидетель, в отличие от обвиняемого или подозреваемого, не наделён правом отказа от предоставления свидетельств. И это не только в РФ так, если что.
Итак, какую проблему решает эта техническая связка? Я подчеркну: решает.
aborouhin
20.04.2023 13:14У контрагента публичные ключи от ваших ящиков. Которые даже изымать не надо, на то они и публичные. На сервере контрагента зашифрованные этими ключами сообщения в Ваш адрес, которые можно расшифровать только вашими приватными ключами, которых у контрагента нигде нет. В почтовых клиентах пользователей контрагента - вероятно, да, есть и незашифрованные копии (как-то же пользователь свои отправленные должен видеть).
Но, во-первых, в почтовых клиентах не всё (очень часто предметом интереса являются весьма старые истории).
Во-вторых, сервер, вероятно, стоял в ЦОДе, и пришли туда, а не в офис. Если этот сервер - ещё и виртуалка, то, возможно, просто владельцу ЦОДа показали ордер, по которому тот тихо сделал и скопировал снэпшот так, что наш контрагент ничего и не узнал (потому что за неразглашение тайны следствия владелец ЦОДа тоже расписался). А если это не сервер, а облачный почтовый сервис - так там и приходить ни к кому иногда не надо...
В-третьих, не всё изъяли (есть удалённые сотрудники, кого-то просто нет на месте, ну и при нормально работающей охране большинство уже давно вышли с ноутами через аварийный выход, т.к. по рядовым делам, коих большинство, все маски-шоу тупо ломятся через центральный вход, где у них долго проверяют документы).
В-четвёртых, не всё изъятое смогли прочитать. И в РФ, и в большинстве других стран ни у свидетеля, ни у кого другого нет обязанности представлять ключ расшифровки / пароль от своего ноута, а количество дел, когда силовики отмораживаются и применяют меры силового воздействия, всё же пока незначительно на фоне тех, где прессуют, но без откровенного беспредела.
Если что - как минимум "в-третьих" и "в-четвёртых" - на личном опыте.
ifap
20.04.2023 13:14+1Позвольте, а где (в чем) Mozilla исправила ошибку? Вместо MailNews сегодня Thunderbird, там была та же самая ошибка?
mentin
20.04.2023 13:14+1Мозилла вообще произвольно с багами обращается. Лет 15 назад то ли открыл, то ли присоединился к открытому багу, что кеш браузера на виндах сохраняется в roaming часть профиля - убивая локальную сетку и производительность. Там были комментарии что кому-то это мешает развернуть Мозиллу на нескольких тысячах компов в универе. На исправление ушло 10 лет, хотя просто дефолтовый конфиг исправить.
NN1
20.04.2023 13:14Так и есть. Банальные баги, открытые несколько лет назад так и не чинят причиняя боль тем, кто пишет код работающий одновременно везде.
this !== window 8 лет
saipr
20.04.2023 13:14Многие специалисты по безопасности говорят, что шифрование электронной почты должно стать стандартом, ведь тайна почтовой переписки защищена Конституцией и является одним из основных прав человека.
Какое шифрование? Кто или что мешает шифровать пользователям почту перед отправкой в почтовом клиенте, например, в Thunderbird, Kmail и другие, и использовать при этом любую криптографию.
Revertis
20.04.2023 13:14Конечно, управление персональными сертификатами пользователями в большом масштабе сложнее, чем управлением сертификатами веб-сайтов, но это решаемая задача.
Ждём статью об этом.
dartraiden
Всё проще: фича почти не востребована пользователями, поэтому и тратить время разработчики предпочитают на что-то такое, чем пользователи хотят и будут пользоваться.
Например, в нашем продукте сейчас точно такая же ситуация применительно к шифрованию в XMPP: либо оно принудительно включено, либо принудительно отключено. Сами мы им не пользуемся, отчего оно уже много лет пребывает в состоянии "экспериментальная возможность". Пользователи тоже не просят. Раз это никому не интересно, то оно так и будет жить в экспериментальном и неудобном виде.
aborouhin
Пользователями в массе своей и HTTPS был не востребован (более того, они как раньше не знали, что это такое, так и сейчас не знают), однако согласованные усилия разработчиков браузеров привели к тому, что HTTP без S практически вымер.
Но то браузеры, которых, несмотря на все браузерные войны, общераспространённых всегда только несколько штук было. А с почтой нужно, чтобы и почтовые сервисы, и почтовые клиенты проталкивали шифрование, пока не наберётся критическая масса пользователей оного. Если бы какой-нибудь Gmail с начала запуска по умолчанию создавал и публиковал сертификаты - может, к текущему моменту и взлетело бы.
Tangeman
В случае HTTPS всё просто и прозрачно для пользователя, ему не нужно делать никаких телодвижений - браузеры проверяют сертификаты, а сами сертификаты это головная боль владельцев сайтов.
В случае же с почтой всё совсем не так - во-первых, сертификаты (или ключи в случае PGP) нужны самим пользователям, их нужно где-то брать и что-то за это платить, а если не платить (PGP & co) то придётся заморачиваться цепочками доверия, как-то проверять подлинность и вот это всё - это не очень приятно и времязатратно даже для понимающих людей, что уж говорить про условных сантехников и флористов.
Шифрование почты станет мейнстримом только если (и это большое "если") кто-то придумает систему аналогичную HTTPS когда у пользователя реально будет "один клик" для отправки зашифрованного письма и проверки подлинности полученных, без возни с приватными ключами и прочим, и при этом не придётся всё это повторять при смене адреса email, причём не только своего но и всех с кем идёт переписка.
aborouhin
Так я и пишу, что кто-то из больших игроков должен был сделать удобно и по умолчанию. Условно говоря, после регистрации в Gmail сразу сообщать - "мы создали вам ключевую пару, приватный ключ сохранён в Гугл-аккаунте, публичный опубликован в Гугл-каталоге, пользуйтесь" (само собой, не такими словами, а понятными для пользователя). Для продвинутых ссылочка "advanced options", где что-то можно поменять. А потом автоматически подсказывать, что у получателя тоже есть сертификат и не хотите ли зашифровать. Или "судя по тексту письма, в нём чувствительные данные, не хотите ли сначала предложить получателю бесплатно и одним кликом завести свой сертификат". Ну и т.п. И при этом обеспечить совместимость и совместную работу своих стандартов с другими, кто захочет подтянуться.
Тут скорее другой вопрос, что приватные ключи можно хранить либо удобно, либо безопасно. Если он будет храниться на стороне почтового сервиса - то это не сильно добавит безопасности в чём бы то ни было. А если на стороне клиента - то да, нужны нетривиальные телодвижения, которых обычный пользователь никогда совершать не будет...
ollisso
А для чего это нужно большим игрокам? Например google и microsoft?
Они уже давно (как минимум года 3 назад) реализовали возможность отправлять письма в режиме конфеденциальности. Это даёт даже больше возможностей пользователю чем подпись с помощью шифрования, в частности:
возможность ограничить, сколько письмо будет доступно (например через 3 дня письмо невозможно будет открыть
возможность заблокировать скачивание, печать(относительно) и тп письма.
Видел так же системы где можно даже отозвать письмо, после его отправки.
Во всех случаях, фактически письмо даже не уходит с серверов отправителя, то есть, "перехватить" содержание намного сложнее.
Так же есть DKIM ключи, которые подписывают что да, это ваш сервер отправил это письмо, а не сторонее лицо.
Ещё один важный вопрос стоит учесть: Как много людей пользуются только 1 почтовым клиентом? Очень многие пользуются тем же Outlook на компьютере, на телефоне и иногда заходят через веб. Как сделать чтобы подпись работала на всех устройствах (где будем шифровать, на клиенте или на сервере? ) И чтобы каждый из клиентов знал у кого из получателей есть возможность читать зашифрованную почту? Опять получается что это всё происходит на стороне сервера, и о какой безопасности мы говорим? Как минимум почтовый сервис может читать все ваши письма.
И да, судя по всему в Outlook есть эта функция, но она скорее всего мало кому интересна.
aborouhin
Для чего это нужно Гуглу и Майкрософту - я не знаю. Наверное, ни для чего, и в этом вся причина. Хотя забота о privacy и конфиденциальности неплохо продаётся.
"Режим конфиденциальности" Gmail - это вообще не про почту, в самом письме нет "защищённого" содержимого. С таким же успехом можно отправлять ссылки на зашифрованные файлы или эти же файлы во вложениях... или вообще общаться в мессенджерах с end-to-end шифрованием. Последний вариант в основном и выбирают, забивая на почту вообще.
DKIM - это про другую историю, он содержимое письма никак не защищает. Шифрование почты зачем нужно? Чтобы если товарищ майор с ордером (или без оного, но с убедительными аргументами) придёт к хостеру почтового сервиса и либо изымет сервер, либо убедит того самогó скопировать ящик нужного пользователя, - означенный товарищ текста сообщений всё равно не увидел бы. Ну или чтобы того же не сделал ваш собственный сисадмин, "мотивированный" вашими недоброжелателями. При хранении ключа на стороне сервера эта задача решается только частично, да - если получили доступ к Вашему серверу, прочитают Ваши входящие, но не Ваши исходящие. Слабое утешение в большинстве случаев. Поэтому я и пишу, что хранение приватных ключей - главная архитектурная проблема во всей этой истории. Можно или безопасно, или удобно, но не одновременно.
В Outlook шифрование есть, я его даже использовал в своё время. Но это ещё более недружественная пользователю система, чем PGP (с плагином под Outlook или Thunderbird). Там вообще сложно
без бутылкипонять, откуда тот сертификат должен взяться... В корпоративной среде, где всё преднастроено и зашито в групповые политики, оно, может, и взлетит, но в общем случае крайне неудобно.aim
проблема в том что вот такая вот "шифрованая" почта создаёт иллюзию безопасности.
что мешает google передать приватные ключи кому угодно?
aborouhin
То, что гуглу на Вас с Вашими ключами наплевать. Особенно, кстати, после того, как российская дочка у них закрылась и последние стимулы хоть как-то реагировать на формальные или неформальные просьбы российских властей очевидно исчезли. Бояться надо на АНБ с Гуглом и Метой, а коррумпированного оперативника из родного УВД, к которому ваш конкурент / оппонент придёт. Если, у Вас, конечно не стратегический / международный бизнес, но тогда Вы сами и так прекрасно знаете, чего Вам бояться и как защищаться. А остальным достаточно руководствоваться простым правилом - никакие чувствительные данные не хранить в той стране, в которой ведёшь бизнес.
DMGarikk
Это вы сейчас рассуждаете как физлицо-индеец Джо, в данном случае можно письма вообще в открытом виде слать, они реально не нужны никому
А вот если вы какаянить огромная международная корпорация и у вас есть конкурент похожих размеров… то тут можно начинать бояться например инсайдеров в гугле направленных против вас
Это может звучит диковато, но это огромный теневой сектор и он существует, утечки не только у яндекса с мейлом в РФ происходят и тренинги с аудитами безопасности в крупных компаниях не просто так. например нужно алертится даже если коллега просит тебя переслать тебе документ который вроде как ему по его должности не нужен (я например всегда уточняю у руководства правомерность таких запросов, как раз после опыта работы в крупной забугорной корпорации из финсектора)
основывать свою безопасность на факторе "из РФ эта компания ушла — значит мне ничего плохого сделать не может" — крайне наивно
aborouhin
Я не сомневаюсь, что международные корпорации с построением своей безопасности справятся без чтения комментов на Хабре :) А вот российских бизнесов, которые и друг на друга уголовки заводят, и в судах в корпоративных конфликтах бьются, и сами же услугами пробива не брезгуют, - и при этом держат почту на Яндексе/Мейле, я вижу предостаточно.
aim
я думаю тут наверняка были люди которые помнят что openrelay когда то был СТАНДАРТОМ. все удивлялись - КАК это нельзя передать письмо через любую почтовую систему?!
однако пара важных узлов запретила open relay и теперь в общем в голову никому не придёт его открывать.
короче кто-то должен начать.