Где лучше завести почтовый ящик.
Здравствуйте!
Вопрос такой: где лучше завести электронный почтовый ящик?
Уверен, что это довольно важно, ведь надёжный, защищённый ящик – одна из обязательных деталей Вашей целостной системы защиты информации.
Мелочей не бывает. "Мелочи" иногда дорого обходятся.
Если Вы знаете/используете ящик, который отвечает Вашему уровню требований безопасности – пожалуйста, напишите.
Расскажите о преимуществах.
Важен каждый комментарий.
комментариев: 9796 документов: 488 редакций: 5664
да
У меня есть идея, но она Вам наверное не понравится. Делается сеть по типу tor (клиент-серверного типа). Каждый желающий запускает свой сервер. А письмо отправленное в такую сеть храниться не на одном сервере, а на случайно выбранных. И не целиком, а кусками (разделение секрета, secret split). Каждый кусок по отдельности выглядит как псевдослучайные даные. Потеря части кусков некритична. Затем получатель и отправитель должны как-то обменяться информацией о том, с каких серверов получить письмо. Получатель его собирает, соединяет куски, добавляет к ним избыточные (скачанные со случайных серверов наугад, чтобы нельзя было определить какие из них истинные).
Это должно усилить схему псевдоним-серверов и снять с владельцев серверов возможность анализа траффика и содержимого писем, а также сделать невозможными юридические претензии к содержимому переписки, сделав правопринуждение бессмысленным (по аналогии с
сетью tor).
А у сети не будет единого владельца, которого было бы можно поставить под контроль.
Иначе говоря, хотелось бы видеть систему распределенной почты.
Потом я не уверен, что то, что вы задумали, следует выполнять на уровне почты. Мне кажется, что к универсальному распределенному хранилищу информации уже не сложно сделать почтовый интерфейс. Но удовлетворительного решения распределенного и безопасного хранения информации, AFAIK, пока нет. Несколько таких проэктов уже провалились (mojo nation и т. д.).
У меня планы менее амбициозные, но распределенные решения меня тоже интересуют. Еще меня заинтересовали решения с разделением полномочий. Например интересная модель, где в одном хранилище хранятся сами зашифрованные письма (потенциально без указания адресата), а в другом — зашифрованый индекс какое письмо кому адресовано.
В принцыпе, и то и другое хранилище может быть распределенным, но даже централизованная инфраструктура с двумя половинами в разных странах — достаточно крепкий орешек.
комментариев: 9796 документов: 488 редакций: 5664
Примерно также как и в сетях римэйлеров, tor, freedom и т.д.
Правда я сразу подумал, что Ваш проект будет скорее коммерческим, чем чисто академическим. И оплачивать ваш сервис в идеале пользователи должны через вашу систему E-point-cash ;-)
Что ж, это тоже интересное направление.
Что-то существует в сети freedom, но я в этом не разбирался.
Да, идея хорошая и есть почти готовые протоколы для баз данных.
Но как предоставить пользователю гарантии, что эта система не просто распределена территориально и топологически, но и на уровне владельцев?
Так чтобы бы было нереально этих владельцев двух (или более) хранилищ вычислить, собрать вместе или заставить сотрудничать против пользователя?
А если владелец один, то он может создать полную иллюзию независимого функционирования частей сервиса, а на самом деле иметь доступ к двум хранилищам и сопоставлять индексы.
Или пользователи системы должны будут иметь специальное ПО, а адрес в системе будет связан с открытым ключом. Но тогда это будет неуниверсальный сервис и больше как раз подходящий для распределенных систем.
К сожалению, не так же. Сохранять информацию на собственных накопителях значительно (на порядки) дороже, чем просто передавать ее. Когда речь идет о таких маленьких издержках, то трудно различить разницу между милли- и микро-копейками, но она весьма существена.
Многолетний опыт p2p-сетей показывает, что пользователи с удовольствием передают (ретранслируют) чужую информацию бесплатно, но хранить чужие данные так, что даже посмотреть нельзя — несогласны, если им от этого никакой пользы нет.
Еще не надо забывать DoS-атаки. Забить накопитель до отказа один раз значительно дешевле, чем постоянно забивать канал связи. А ущерб значительно больше: Как только атака кончается — линия связи освобождается. А накопитель еще надо очистить. Если вы даже не знаете, что на нем важно, а что мусор от атаки, то ничего не остается как приобрести новые мощности накопления или стерать информацию без учета ее ценности.
Не все так просто. Коммерческим я свой проэкт не называю, так как извлечение прибыли не является целью. Даже значительно более скромная цель — создать систему, которая просто работает — требует экономическую состоятельность. Например то, что тому, кто хранит у себя чужую информацию, надо чем-то (не обязательно деньгами) платить — достаточно очевидно.
Но и это еще не все. Деньги (в том числе и электронные) — не решение, а только инструмент. Либералы проповедующие идеологию, что все проблемы решаются передачей всех ресурсов в частную собственность и свободной куплей-продажей всего на свете, аргументирующие это красивыми теоремами о том, что свободный рынок обеспечивает оптимальную аллокацию ресурсов либо забывают, либо сознательно замалчивают то, что все эти теоремы верны только на полностью осведомленном рынке, с нулевыми издержками на транзакции. А это еще надо обеспечить, что совсем нетривиально.
Например, распределенная система храненеия информации mojo nation, основанная на простой схеме "плати mojo — получай место на диске" погибла из-за недостаточной информированности рынка: невозможно было найти самый дешевый накопитель, и по-этому те, кто повышали цены не лишались клиентов, а те, кто свои цены опускали — не приобретали их. В такой ситуации, некоторые участники начали тянуть одеяло на себя потихоньку поднимая цены. От этого образовался дефицит mojo, и для поддержания работоспособности системы происходила вынужденная эмиссия, которая тут же поглощалась инфляцией. Самораскручивающий маховик гиперинфляции вертелся на полных оборотах, и mojo фактически перестал работать как средство обмена (за заработанные mojo уже ничего нельзя было купить через очень короткое время, так что зарабатывать mojo было просто бессмыслено). И система развалилась.
А как обеспечить информированый рынок накопительных мощностей (аукционы мегабайтов), да еще так, что при этом издержки на транзакции слишком не поднимались, мне пока не ясно, хотя над проблемой интенсивно думаю. И в полне академическом русле. Если что-то придумаю — обязательно опубликую. Некоторые идеи уже есть.
Мне кажется, что тут опять стоит взглянуть на экономическую сторону вопроса. Бесплатной безопасности небывает. Если кто-то готов платить временем за то, чтобы анализ трафика стал невозможным, то он может положить сообщение в хранилище сообщений в одно время, а зашифрованную ссылку в хранилище индексов в совсем другое. Партнер по переписке извлекая и расшифровывая ссылку тоже не сразу достает сообщение. В таком случае почти безразлично, сотрудничает или нет сервис хранения и сервис индексов против пользователей. А тех, кого анализ трафика не беспокоет, не надо загружать. Даже для них анализ трафика становится дороже, чем если все на одном сервере, и даже это незначительное повышение издержек делает тотальную слежку заметно дороже, что уже сам по себе положительный результат.
комментариев: 9796 документов: 488 редакций: 5664
Д. Надь, я Вас узнал ;-)
Вот только я размечтался, пофантазировал немного, а на самом деле это оказывается все сложнее чем в космос полететь. :-)
Придется спускаться с небес на землю.
Ну начнем тогда с простого. Почему бы параллельно с почтовым сервером не запустить на нем же сервер ключей PGP?
Только с односторонней синхронизацией – ключи с него попадали бы в сеть серверов ключей PGP, а обратно из сети – нет.
Это не слишком какая серьезная защита, но дополнительный повод быть уверенным, что данный открытый ключ на данном сервере мог разместить только владелец данного почтового ящика.
Конечно, пользователь должен быть уверен в сертификате сервера, что сертификат что-то значит, что сервер не взломали, что не было "человека-посредине", что тот, кто выкладывает ключ, сделал все правильно и защитил свою машину (ну против этого все бессильно) и т.д.
Но все равно, получение ключей с самого почтового сервера немного повышает к ним доверие.
Другая игрушечная идея – таймер "я еще живой". Если человек в течении периода времени не вводит пароль, то с его ящика происходит рассылка какого-то материала. Для серьезного применения тоже не подходит. Так, баловство.
Именно так оно и происходит. Уже протестировал нескоьлко ключевых серверов, и пока остановился на SKS (кстати, с удовольствием поделюсь горьким опытом в другом топике — серверы ключей из-за того, что они рассматриваются как средства вне периметра безопасности значительно хуже по качеству чем другое ПО связанное с PGP)
Первый вариант сервиса будет примерно такой: при регистрации вы указываете какой-то другой адрес (рекомендовать буду safe-mail, так как большого ящика там не нужно), куда вам будут посылаться ссылки на сообщения, которые будут храниться на http-сервере у меня, все в месте.
На данный момент готово следующее:
Сервер ключей и регистрация: http://pgp.epointsystem.org
Интетрфейс для шифрования: http://pgp.epointsystem.org/tool
Условные обозначения: http://pgp.epointsystem.org/tool-help
комментариев: 9796 документов: 488 редакций: 5664
Да, мы обсуждали как-то эту штуку. Вокруг меня нету явы...
Тогда у Вас и hushmail не работает. К сожалению, это еще самый приемлимый способ шифровать на клиенте. Можно еще в javascript, но это такая гадость, что противно писать реализации OpenPGP в нем.
Яву не устанавливаете из принципа? Вообще-то там модель безопасности достаточно продуманная.
комментариев: 9796 документов: 488 редакций: 5664
В порядке оффтопика – да, скорее из принципа и за ненадобностью. Да потому же принципу, по которому java, flash и прочие штуки не включены в Debian.
Потому как не совместимо с GNU/GPL, является собственностью фиры Sun и не может свободно использоваться сборщиками дистров по своему усмотрению.
А обновлять стороннее приложение, которое не собрано пакетом, вручную отслеживая сообщения о дырках неудобно.
Кроме того, никакой особой потребности использования этой технологии у меня нет.
комментариев: 9796 документов: 488 редакций: 5664
http://onenetbeyond.org/en/index.html
http://resist.ca/
http://help.riseup.net/mail/security/measures/
(^ здесь посмотрите еще на список ссылок к аналогичным сайтам).
комментариев: 44 документов: 3 редакций: 0
Большинство проблем как с hushmail тут тоже возникают. В том числе и совершенно неуравновешенная безопасность: некоторые меры значительно легче преодолеть, чем другие.
комментариев: 49 документов: 2 редакций: 0
Держу там ящик. В воскресение смотрю – ожили несколько папок и писем, которые, как мне казалось, я безвозвратно удалил еще в декабре'05!
Так сказать, несколько папкок возникли заново и наполнились письмами.
Говорят, подобное однажды произошло и на Mail.ru
В любом случае, не ожидал подобного от Pochta.ru. Что они там – почту копят?
Интересно, никто в ближайшее время не сталкивался с подобным?
комментариев: 510 документов: 110 редакций: 75
Еще один + за шифрование почты. Пусть забивают сервера нечитаемыми сообщениями.
комментариев: 49 документов: 2 редакций: 0
Интересный вопрос, почему письма где-то там сохранились? Разве они (РосБизнесКонсалтинг) могут копить всю почту на серверах?