QuickSilver и Mixmaster

Kent:
QuickSilver и Mixmaster
http://www.quicksilvermail.net/

Насколько я понял, для каждодневного практического использования это ни в коем случае не годится.
– Во первых – нет SSL. Т.е. через администратора локальной сети/провайдера идёт вполне открытый трафик.
– Работает исключительно через Web-интерфейс.
– Письмо доставляетяется в течении суток

Резюме: не слишком ли много хлопот, для того, чтобы отправить одно-единственное письмо, замаскировав от его получателя свой IP?

Не лучше ли просто работать обычным почтовым клиентом через цепочку прокси? К тому же по SSL?

Как альтернативный вариант, можно рассмотреть использование локального SMTP-сервера, работающего через прокси/цепочку прокси.

На страницу: 1, 2, 3 След.

Комментарии

—	SATtva (12/04/2004 23:35) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Если я верно помню механику Миксмастера, о которой читал сто лет тому назад, клиент (QuickSilver в нашем случае) самостоятельно зашифровывает исходящее сообщение, в том числе и хидер "To:", открытым ключом PGP первого сервера в цепочке, так что открытым текстом сообщение проходит только от последнего миксовского сервера в ящик получателя.

Поправьте, если ошибаюсь.

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

—	Kent (13/04/2004 01:45) профиль/связь <#> комментариев: 437 документов: 30 редакций: 15

Ghola, всё абсолютно неверно. Вы с чем-то спутали.

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

—	SATtva (13/04/2004 12:45) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

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

1. Не использовать асимметричных ключей. С каждым таким корреспондентом очно согласовать парольную фразу, которой будут шифроваться сами сообщения. Пароль должен быть абсолютно случайным и уникальным.
2. В конце каждого сообщения указывается новая парольная фраза, которой получатель должен будет шифровать свой ответ.
3. Отправляемое сообщение зашифровывается текущей парольной фразой (Conventional Encryption), что обеспечивает и защиту от прочтения, и идентифицирует автора.
4. Сообщения публикуются в конференции alt.anonymous.messages через систему Миксмастер.

Критика, дополнения?

—	SATtva (14/04/2004 20:05) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Дополнение. Для опознавания переписки в ньюс-группе ей необходима тема. Тема первого сообщения согласовывается на этапе 1. Перед отправкой сообщения в конференцию на этапе 3 из текста темы по алгоритму MD5 HMAC вычисляется имитовставка, в качестве ключа используется согласованный для данного сообщения пароль. Полученное значение имитовставки используется как тема сообщения.

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

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

—	SATtva (16/04/2004 01:59) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Перечитал информацию по Mixmaster'у. Уточнение относительно протокола. Не вдаваясь в детали, с которыми при желании можно познакомиться на http://obscura.com/~loki/remailer-essay.html, клиент формирует сообщение в особый пакет, всегда равный 28 килобайтам (большие сообщение дробятся, меньшие — удлиняются) и последовательно зашифровывает его открытыми ключами для каждого сервера в цепочке, начиная с последнего, и отправляет первому. Тот помещает сообщение в пул, произвольно перетасовывает последовательность находящихся там сообщений и после задержки на некоторый случайный промежуток времени достаёт их из пула и переправляет следующему серверу в цепочке (адрес которого получил, сняв первый уровень шифрования). Каждый последующий сервер повторяет те же действия. Последний сервер, сняв свой уровень шифрования и прочитав в хидере, что замыкает цепь, отправляет фактическое сообщение получателю.

—	SATtva (19/04/2004 00:38) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Дополнение к предпоследнему сообщению о шифровании заголовков (subject) сообщений, публикуемых в USENET. После детального изучения QuickSilver и ремейлеров первого поколения стало ясно, что QS поддерживает esub, т.е. шифрованные темы сообщений. Таким образом, достаточно открыть аккаунт на ним-сервере, указав в reply block'е для последнего сервера цепочки (любого cpunk mail2news) название темы и пароль шифрования. Аналогичная комбинация выставляется в news-клиенте QS, и программа сможет самостоятельно скачать нужный блок конференции и сверить все заголовки на соответствие заданному. Алгоритм такой: K ( MD5 ( Subj ) ). Если находит подходящий, сообщение сохраняется, лишний хлам — нет.

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

В этом случае нужно учитывать важный момент: если угрозы (или степень паранои) требуют повышенного уровня безопасности, с news-сервера необходимо выкачивать ВЕСЬ блок сообщений, появившихся с последней проверки, а не только те, которые соответствуют заданному subject'у. Иначе тривиальный анализ трафика приведёт оппонента прямиком к вашей двери.

—	*Гость* (10/06/2004 14:03) <#>

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

Но вообще, сам факт существования в природе такого сервиса – кажется мне отрадным! ;)

—	SATtva (10/06/2004 14:28) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

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

"Прозрачные" системы защиты — это идеал всех разработчиков систем ИБ. Но, зачастую, чем более "прозрачной" и необременительной для пользователя становится система, тем более грешит она прорехами в безопасности. Касаемо систем обеспечения анонимности, то здесь мне этот идеал кажется совершенно недостежимым...

В принципе, QuickSilver очень прост в использовании, я им пользуюсь регулярно. Его нужно только немного освоить, чуть-чуть настроить под себя, а дальше всё идёт, как по маслу. По крайней мере, это действительно проще, чем работа с гибридными серверами вручную с помощью команд вроде www.pgpru.com/manuals/cypherpunk/ .

—	blitz (15/06/2004 14:43) профиль/связь <#> комментариев: 4 документов: 2 редакций: 1

Ушк:

Но вообще, сам факт существования в природе такого сервиса – кажется мне отрадным! ;)

если еще знать что некоторые срвера админятся голубыми,,
то не все в розовом цвете .. ЛОЛ

писали в Usenet`е про такого админа одно из самых известных ремайлеров
как онО не пропускало майлы на свое усмотрению .. human factor

да и самих ремайлров не так и много и всем извстны
и думается у провайдеров они помечены .. а логи – они ведутся

—	SATtva (15/06/2004 16:31) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

blitz, ссылку на руководство в моём последнем постинге видите? Советую почитать. Кстати, и Вам был бы благодарен за ссылку на упомянутое обсуждение в юзнете.

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

Всего серверов около четырёх десятков. Найти надёжные узлы входа и узлы выхода можно всегда. И последнее... Не верьте всему, что пишут в юзнете, особенно в alt.privacy.anon-server. ;) Флейма и троллинга слишком много... И от кого? От анонимных участников, публикующих посты через сеть ремейлеров. Отследить не удаётся. Вот и подтверждение надёжности.

—	SATtva (14/10/2004 12:57) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

В последнее время участились атаки на сервер статистики ремейлеров Mellontraffickers, и его данные стали терять точность, а пользователи QuickSilver стали часто сталкиваться с ошибкой no reliable remailers. Len Sassaman (сам!), оператор сервера, слишком часто в разъездах и лекциях, чтобы следить за ситуацией.

В связи с этим рекомендуется перейти на сервер aarg.

—	*Гость* (23/05/2005 22:19) <#>

u mena trubl s QUISKSILVER nedavno na4al izu4at kak s nej rabotat poka daze ne mogy zabrat po4tu s pop3 pri konekte pishet Proxy: <none>
Connecting to rambler.ru...
Error: 500 -ERR ESocketException: Error 10061 in function Connect
Connection refused
ili tipa togo,, v 4em moget bqt trubl? Apolnil pop account pravilno proxy ne vvodil prosto hotel protestit dla na4alo kak zabrat po4tu? V 4em trubl 4to to nuzno esho po mimo nastoiki pop3 accounta ili delo v provajdere ? Ili 4em to esho ?

—	*Гость* (23/05/2005 22:21) <#>

ja tak ponal quick silver otnositsa k 2 pokoleniu remailerov ? I mogno doverat ?

—	*Гость* (19/06/2005 22:02) <#>

Не могу отправить сообщение. Пишу

Fcc: outbox
Host: mail.hotbox.ru
From: 123@hotbox.ru
Chain: *,*
To: 123@rambler.ru
Subject: Привет

~

Если напишу по умолчанию Host: mail.myusual.net, то же не могу отправить. Наверное из-за того что провайдер закрыл 25 порт. Если указываю mail-сервер провайдера то же не получаится. Что мне можно сделать в моей ситуации?

—	*Гость* (19/06/2005 22:15) <#>

Вот что он пишит когда указываю mail-сервер провайдера:

Mixmaster Chain 1 of 1
Connecting...
220 mail.мой_провайдер.ru ESMTP Postfix
250-mail.мой_провайдер.ru
250-PIPELINING
250-SIZE 30485760
250-VRFY
250-ETRN
250 8BITMIME
502 Error: command not implemented
Aborting...
Connection closed!

ERROR: 7 unsent messages in PROBLEM Queue!
Session finished

На страницу: 1, 2, 3 След.

Ваша оценка документа [показать результаты]