Ремейлеры шифрпанков | |||||||||||
Шифрование электронной почты похоже на конверт для писем бумажных – оно делает содержание сообщений недоступным ни для кого, кроме адресата. Но любой почтовый служащий или злоумышленник может не распечатывая конверт определить и отправителя, и получателя, и даже составить некоторое представление о содержимом конверта по его толщине и весу, при этом оставаясь необнаруженным. Собрав достаточно подобной информации оппонент сможет судить уже и о характере вашей переписки с тем или иным адресатом, что позволит ему тщательнее спланировать свои дальнейшие действия. Такую методику пассивного сбора и оценки внешних признаков передаваемых сообщений называют анализом трафика; ей подвержено подавляющее большинство систем коммуникаций. Не исключение и электронная почта. Хотя шифрование делает её непроницаемой для любопытных глаз, всякий, кто имеет доступ к каналу передачи данных (интернет-провайдер, администратор корпоративной сети или почтового сервера, спецслужба, взломщик, затративший немало усилий и средств для подключения к линии связи) может незаметно собирать информацию о том, кому вы пишите и кто пишет вам, как часто, насколько объёмно то или иное сообщение и т.д. На заре Интернета в американском университете Беркли образовалась неформальная группа, позднее выросшая в движение, члены которого получили название шифрпанков. Они осознавали преимущества Интернета как средства для самовыражения и свободы слова, в то же время понимая его потенциал как инструмента контроля и слежки. Они хотели сохранить эту внутреприсущую анонимность и свободу Интернета и разработали для этой цели ряд механизмов, эволюционировавших на протяжении всех последующих лет. Одним из таких механизмов стали серверы-пересыльщики – ремейлеры. Назначение ремейлера напоминает задачу анонимного прокси-сервера: он принимает сообщение, удаляет из его служебных заголовков – хидеров – IP-адрес и другую идентифицирующую отправителя информацию и пересылает письмо получателю. Если этим функциональность ремейлера исчерпывается, он скроет личность отправителя только от адресата, но не защитит переписку от анализа трафика на сегменте "отправитель > ремейлер". Такие ремейлеры принято считать нулевым поколением, type 0. Другая проблема подобной схемы с одним промежуточным звеном пересылки заключается в её изначальной централизованности: если сервер (или его администратор) окажется тем или иным образом скомпрометирован, злоумышленник получит всю информацию о пересылаемых через него сообщениях. Такие прецеденты имели место в истории: в 1995 году администратор самого популярного ремейлера anon.penet.fi Йохан Хельсингьюс закрыл свой сервис после того, как под угрозой судебного преследования был вынужден выдать истинные координаты отправителей некоторых анонимных писем. Чтобы исключить эти угрозы, шифрпанками был разработан новый протокол анонимной пересылки, реализованный в первом (type 1) поколении ремейлеров. Они не решили всего комплекса проблем, но это был серьёзный шаг на пути к идеалу. (Следующим этапом развития стала стартовавшая в 1995 году работа над вторым поколением протокола, type 2, получившим название Mixmaster. Однако это руководство посвящено ремейлерам шифрпанков первого поколения по причине простоты их использования без помощи специализированных программных средств.) Сегодня сеть анонимных пересыльщиков представляет собой распределённую децентрализованную систему из почти четырёх десятков серверов, расположенных в Европе, Америке, Азии и Австралии и администрируемых независимыми энтузиастами, часть которых вышла из среды шифрпанков. Можно представить множество областей применения этой технологии. Кто-то обращается к ней, чтобы анонимно отправлять компрометирующие материалы, кто-то – чтобы не пострадать за исповедуемые идеи, кто-то – чтобы тайно вести переписку с теми, с кем её не следует вести... Право на анонимность нередко слишком тесно переплетается с правом на свободу слова. 13 сентября 2001 года Ленс Котрелл, автор протокола Mixmaster, оставил такое сообщение в списке рассылки шифрпанков: Принцип действия ремейлеров шифрпанков довольно прост. Отправитель составляет письмо, в тексте которого указывает адрес получателя, и последовательно зашифровывает сообщение открытыми ключами PGP нескольких произвольно (или намеренно) выбранных ремейлеров, начиная с последнего. Получившуюся конструкцию, схематично выглядящую как отправитель с помощью любимого мэйл-клиента пересылает серверу А. Сервер А расшифровывает сообщение своим закрытым ключом, как бы снимая первый слой обёртки, находит внутри директиву переслать сообщение серверу Б и выполняет её, предварительно удалив все служебные заголовки, содержавшиеся в исходном письме отправителя. Сервер Б, получив сообщение, знает только, что получил его от А, не имея ни малейшего представления, кто является фактическим отправителем и кому предназначено письмо, равно, не зная содержания послания. Он только видит, расшифровав его своим ключом, что должен переслать сообщение серверу В. Аналогично серверу А, он удаляет из письма все хидеры предыдущего звена и пересылает его дальше.
Сервер В не имеет никаких догадок, откуда пришло письмо, кроме того, что его прислал анонимный ремейлер Б. Но у него нет сведений, предшествовала ли Б цепочка других ремейлеров, и если да, то каких. Таким образом, логическая связь между отправителем и получателем оказывается полностью утеряна. Теперь В расшифровывает сообщение своим ключом, и поняв, что замыкает цепочку, пересылает письмо получателю, как и предыдущие сервера заменив хидеры отправителя (сервера Б) своими.
Ни один наблюдатель на любом из сегментов передачи не будет обладать информацией одновременно и о фактическом отправителе, и о фактическом получателе письма, равно, и получатель не будет знать, от кого пришло сообщение, если только отправитель сам это не укажет и не зашифрует письмо открытым ключом адресата (правильнее, однако, для этой цели использовать специальные ним-серверы). Положение не изменится, даже если приемлемый процент серверов в цепочке окажется скомпрометирован. Конечно, могущественный оппонент контролирующий крупные узлы и каналы связи Интернета может попытаться проследить за движением послания, анализируя трафик на входе в ремейлер и на выходе: по логике сервер должен переслать сообщение немедленно, кроме того, несколько уменьшив его объём, сняв свой слой "обёртки". Однако ремейлеры обладают некоторыми специальными возможностями, снижающими приемлемость подобных атак. Об этом будет рассказано ниже. Чтобы ремейлеры корректно выполняли необходимые операции с почтой, ваши сообщения должны быть составлены в определённом виде. Это не сложно, хотя следует быть внимательным, дабы не допустить досадной оплошности, из-за которой письмо просто потеряется в пути. Прежде всего вам как отправителю понадобятся открытые ключи ремейлеров цепочки... впрочем, не будут лишними и адреса серверов. И то, и другое можно получить на особых сайтах статистики сети пересыльщиков, ссылки на которые вы найдёте в одноимённом параграфе в конце этого руководства. Также ключ и конфигурацию конкретного сервера можно запросить у него напрямую, отправив на его адрес письмо со строкой remailer-key в качестве темы (если в ответ ничего не придёт, то лучше этим ремейлером и не пользоваться – слишком велика задержка). В действительности, такой способ даже предпочтительнее, хотя и гораздо сложнее. В вашем праве строить цепочки любой длины; вы можете заставить сообщение многими днями циркулировать по сети ремейлеров, даже возвращаясь на уже пройденные, пока оно не упадёт в ящик адресата. Разумеется, удлинение цепочки сильно затянет доставку и повысит риск исчезновения письма в пути – такое тоже случается по разным причинам, зависящим не только от ремейлеров, но и от объединяющих их каналов Интернета. Можете ориентироваться на такие показатели:
Предположим, что вы уже написали текст своего анонимного письма. Чтобы проинструктировать последний сервер цепочки, кому он должен переслать сообщение, дополните своё послание следующими строчками:
Учтите, точный формат очень важен! Сообщение должно начинаться с двух двоеточий на первой строке, директивы Anon-To:, пробела и адреса получателя на второй. Третья обязательно должна быть пуста, и только следом за ней должно располагаться само сообщение. Теперь зашифруйте полученный текст (директива + анонимное письмо) ключом последнего сервера, замыкающего цепочку, т.е. сервера В из приведённого выше примера. (Чтобы не оставлять следов, зашифровывайте только ключом сервера, убрав из списка получателей собственный "ключ по умолчанию", а также удалите из блока шифртекста строку Comment, если используете таковую.)
Сделав это, допишите перед заголовком BEGIN PGP MESSAGE ещё две директивы: Encrypted: PGP, инструктирующую сервер В, что далее следует зашифрованное для него сообщение, и Anon-To: remailer@server-v.com, которая заставит сервер Б (средний в цепочке) анонимно переслать полученное сообщение серверу В. Обязательно придерживайтесь такого формата:
Возможно, сначала манера запаковывания письма, начиная с конца цепочки, покажется неудобной, но это абсолютно необходимо. Представьте, что заворачиваете подарок в несколько слоёв обёрточной бумаги. Как раз сейчас придётся добавить ещё один. Впрочем, вы и сами, наверное, уже догадались, что теперь полученный текст нужно зашифровать ключом ремейлера Б (само сообщение при этом несколько увеличится) и дописать соответствующие инструкции для него и предшествующего ему пересыльщика: Encrypted: PGP и Anon-To: с адресом сервера Б.
Похожие действия предстоит повторить в третий раз для первого сервера, начинающего цепочку, с которого начнётся путешествие вашего письма к адресату. Однако, здесь обнаружится нюанс. Итак, зашифровываем приведённый выше текст ключом сервера А и дописываем директиву – только одну: Encrypted: PGP, поскольку то, что у нас получилось, отправлять серверу А будете уже вы сами. В итоге наше сообщение выглядит так:
Всё, что нужно, это вставить готовый текст в ваш мэйл-клиент (если сразу не составляли письмо именно там), указать в качестве получателя в строке Кому: (To:) почтовый адрес пересыльщика А и отправить сообщение; дальнейшее, как говорится, – дело техники. Кстати, что бы вы ни указали в строке Тема: (Subject:), первый же ремейлер это удалит вместе с остальными служебными заголовками письма. Единственный способ указать тему и другие хидеры – это "вложить" их в своё сообщение. Об этом, и не только, мы сейчас и поговорим. Итак, допустим, вы хотите, чтобы адресат видел в полученном письме тему, или желаете дополнить сообщение другими служебными заголовками, например, чтобы вместо адреса замыкающего цепочку ремейлера в строке От: (From:) значилось ваше имя (такую функцию поддерживают далеко не все пересыльщики). Все эти действия должен выполнить последний сервер в цепочке перед отправкой письма в ящик адресата, поэтому необходимые инструкции нужно вносить на самом первом этапе формирования и упаковки послания. Вспомним первый шаг:
Чтобы проинструктировать ремейлер В добавить в письмо заголовок темы и ваше имя, дополните сообщение так:
Как видите, вложенные хидеры дописываются между блоком директив и текстом самого письма, при этом им обязательно предшествует строка с двумя значками решётки. Также не забывайте отделять блоки сообщения (директивы, вложенные хидеры, текст письма) друг от друга пустыми строками. Дальнейшие действия по формированию и упаковке сообщения не имеют никаких отличий от изложенных в предыдущем параграфе. Кроме Subject:, From:, CC:, Bcc:, Content-Type:, Date:, Reply-To: можете указать любые служебные заголовки, которые хотели бы, чтобы адресат получил в сообщении. Однако же, как правило, потребности в этом не возникает, и будьте осторожны, чтобы не указать нечто, раскрывающее вашу личность. Как было отмечено в начале руководства, серьёзный противник может попытаться проследить за движением письма, анализируя и сравнивая поток входящих на сервер сообщений с потоком исходящих: если трафик небольшой, у взломщика есть шанс сопоставив время входа вашего сообщения с моментом его пересылки сервером установить их соответствие. Эта угроза особенно опасна, если пересылаете послания всего через один ремейлер, ибо у оппонента может получиться эффективно провести анализ трафика, определив и отправителя, и получателя письма. Тем не менее, даже в этом случае есть возможность свести опасность к приемлемому минимуму. Кроме директивы Anon-To: серверы принимают ряд других команд, дающих им инструкции на выполнение определённых операций с пересылаемым письмом. Всего их насчитывается около двух десятков, но исключая ряд весьма специфических, стоит остановиться на нескольких наиболее важных. Учтите, что некоторые директивы поддерживаются не всеми серверами; чтобы узнать, какие функции может выполнять тот или иной ремейлер, загляните на страницы статистики. Latent-Time: - Хотя каждый сервер имеет особую присущую ему задержку в пересылке сообщений, а некоторые ещё и перетасовывают входящие сообщения с другими, изменяя их последовательность отправки (ещё более усложняя жизнь вражине), вы можете заставить любой из серверов в цепочке переслать ваше сообщение спустя некоторый заданный лично вами промежуток времени. Этот промежуток нужно указать в качестве параметра директивы Latent-Time:. Скажем, если вы хотите, чтобы сервер "помариновал" письмо ровно в течение 50 минут, прежде чем отправлять дальше, директива должна выглядеть так: Latent-Time: +0:50. Более того, можно установить произвольный срок задержки, ограничив только его верхний предел, например, Latent-Time: +3:7r заставит сервер подержать письмо некоторое время, но не дольше трёх часов семи минут, перед пересылкой. Максимальный период задержки составляет 99:99. Можно также указать серверу точное время по Гринвичу, когда он должен будет переслать письмо; это делается в таком формате: Latent-Time: 17:35. На самом деле, это столь полезная и простая команда, что вам стоит пользоваться ею всякий раз для каждого звена пересылки; она поддерживается всеми без исключения серверами. Inflate: - Несмотря на то, что задержка пересылки сообщения крайне усложнит работу злоумышленника по нахождению соответствия между входящими и исходящими письмами (особенно, если их достаточно много и сервер сам осуществляет перемешивание), он всё же может попытаться найти некоторую корреляцию между объёмами писем, ведь если он знает объём сообщения, вошедшего на сервер, он может допустить, что пересылаемое дальше должно стать немного меньше, поскольку сервер снимет с него свой уровень шифрования. Дабы и здесь осложнить работу врагу, можно указать ремейлеру директиву Inflate:, заставляющую его добавить в тело письма перед отправкой заданное количества "мусора" – некоторых случайных данных. Например, Inflate: 6 увеличит сообщение на 6 килобайт, а Inflate: 15r – на произвольный объём в пределах 15 килобайт. Null: - В некоторых ситуациях, в частности, если за вашим исходящим каналом ведётся пристальное наблюдение, может потребоваться создать "дымовую завесу" из ложных сообщений. Если отправленное вами письмо вместо директивы Anon-To: на любом из этапов пересылки будет содержать Null: произвольный@почтовый.адрес, ремейлер удалит такое сообщение, не отправляя дальше. Max-Date: - Если отправляемое сообщение должно быть доставлено к определённому сроку, а незапланированное опоздание будет губительно, можно дать указание любому серверу (предпочтительнее, последнему) удалить сообщение и не пересылать дальше, если оно получено им позднее заданной даты. Используйте следующий формат команды: Max-Date: 12 May 2004 17:00:00 +0300. Трёхбуквенное английское сокращение названия месяца обязательно; если не указан часовой пояс, принимается время по Гринвичу, GMT. Имейте в виду, если дата указана в неверном формате, сервер просто удалит сообщение по получении. Anon-To: - Основная директива: анонимная пересылка. Стоит добавить, что если вам требуется переслать сообщение сразу нескольким получателям, перечислять их адреса необходимо через запятую без пробелов. Если в последнем блоке пересылки присутствуют вложенные хидеры CC: и Bcc:, они обрабатываются аналогично директиве: пересылка на них осуществляется анонимно. Формат директив - Все директивы кроме Encrypted: PGP должны быть указаны в соответствующем блоке сообщения: в верхней части после двух двоеточий с условием одной директивы на каждой строке.
Прежде чем отправить своё первое сообщение необходимы две вещи: актуальный список действующих ремейлеров и их открытые ключи. Первый проще всего получить на любой из многочисленных страниц статистики, где в сводной таблице приведены их почтовые адреса, качество работы за последние 10 дней (History), внутреприсущая задержка (Latency) и период работы онлайн (Uptime); обратите особое внимание на дату текущего отчёта: если ему больше пары суток, он безнадёжно устарел. Там же вы найдёте список функций и директив, поддерживаемых каждым сервером, и перечень ненадёжных сегментов передачи. Из списка функций стоит особо упомянуть следующие:
Ненадёжные сегменты пересылки представлены в виде пар серверов, где первый обозначает отправителя, а второй – получателя. Строя цепочку пересылки избегайте выбора таких пар: велика вероятность, что сообщение, высланное первым сервером пары, не доберётся до второго. Имейте в виду, это важно! Прежде чем строить цепочку пересылки, обязательно сверьтесь со свежим статистическим отчётом. Если что-то пойдёт не так, сообщение просто исчезнет в пути и не будет доставлено, и вы об этом даже не узнаете, поэтому
Кроме того, внизу страницы www.bananasplit.info/echolot/from.html можете найти список ремейлеров, поддерживающих вложенный хидер From:, заменяющий обратных адрес сервера псевдонимом отправителя. Как уже было отмечено, ключи ремейлеров можно скачать либо со специальных страниц, либо запросив текущую конфигурацию у самого сервера, отправив на его адрес сообщение с темой remailer-key. Первый вариант удобней, поскольку не придётся опрашивать каждый сервер индивидуально, однако второй более надёжен.
| 1 | 2 | «вверх» |
|||||||||||
Бабруйск©Inc. 2006-2007 |