Можно ди построить сервер, основанный на абсолютном недоверии к администратору? Например, чтобы каждому IP-адресу был присвоен уникальный идентификатор, чтобы, тем не менее, можно было запретить доступ с нежелательного хоста? Смысл всего этого - обеспечить анонимность пользователей для администратора, при этом настолько возможную, чтобы в час Х определение пользователей было бы очень затруднено? Создаю тред, чтобы можно было перерасти в нечто большее
Невозможно, если администратор — это администратор машины с правами на рут и всеми вытекающими. Если это просто администратор веб-ресурса, имеющий доступ только к веб-админке, то возможны варианты. Тот факт, что системе все равно будут нужны реальные айпи, все осложняет: достаточно грамотный в криптографии может расколоть шифр твоего "идентификатора". Ну, или я не могу придумать достаточно безопасного способа, все может быть.
>>15085 Наверное, возможно, но это потребовало бы анонимной сети наподобие TOR, но со специальным протоколом маршрутизации, обеспечивающим выполнение твоего условия.
>>15087 >достаточно грамотный в криптографии может расколоть шифр твоего "идентификатора". crypt(3) потребует перебора для каждого ip в предполагаемой области поиска, например. Другое дело, что область поиска может быть достаточно узкой, если или на сервере или у провайдера пробить логи ip и начать соотносить по времени с нужными постами.
>Можно ди построить сервер, основанный на абсолютном недоверии к администратору? >Например, чтобы каждому IP-адресу был присвоен уникальный идентификатор, чтобы, тем не менее, можно было запретить доступ с нежелательного хоста? Нет. Так не бывает. В любом пакете вместе с данными прилетает IP клиента, а если ты эти данные расшифровываешь прямо на сервере, то и секретный ключ администратор вытянет. Сейчас появляются зачатки шифрованных вычислений (вычислитель ничего не знает о том, что он вычисляет, но всё равно вычисляет) (гугли), но от присутствия IP в пакетах это не спасает. Организовать анонимность, используя лишь один недоверенный сервер, пока что невозможно.
>>15089 > crypt(3) потребует перебора для каждого ip в предполагаемой области поиска, например. Ну зачем же crypt(3)? Можно вычислять идентификатор как хеш от некоторой коминации IP и секретного ключа, к которому имеет доступ только администратор сервера, но не модераторы. При достаточно больших длине и энтропии этого ключа успешный брутфорс станет практически невозможным.
>>15091 Вот только при изъятии сервера на сложность ключа будет начхать. И это, вроде, планируется быть онлайн-ресурсом, так что вычисление должно быть в пределах пары секунд максимум, чтобы пользователь не стал ныть о скорости отправки сообщений.
>>15092 Да, но здесь я имел в виду ситацию, когда > это просто администратор веб-ресурса, имеющий доступ только к веб-админке То есть, по сути, не администратор, а модератор, имеющий ограниченный кредит доверия. Недоверие к настоящему администратору сервера возможно только в анонимной сети, в которой, например, сообщение передаётся частями через два или более входных TCP-соединения, и входные узлы формируют этот самый идентификатор для различения клиентских хостов.
>>15085 Всё уже придумано. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.186.3530 http://www.ijser.org/paper/Blocking-of-Mischievous-Users-in-Anonymizing-Networks-using-Nymble-System.html
Вы какие то странные. Достаточно дополнительного проксирующего сервера вне зоны компетенции админа, перенаправляющего всех пользователей на основной. Подразумевается что заголовки и пакеты будут подчищенны, а идентификаторы идти в комплекте.
>>15151 >идентификаторы идти в комплекте Как?
>>15152 А это уже кому какие извращения больше по душе. Можно просто новые IP внутри полученной локалки раздавать.
>>15151 Очевидный минус такого решения в том, что полное доверие к администратору сервера заменяется на полное доверие к администратору прокси.
>>15158 Даже если бы у админа был компьютер с OS специально заточенной на то чтобы не дать увидеть IP, он бы всё-равно нашёл способ. На крайний случай взломал бы роутер. Единственный способ этого избежать - установить зашифрованный туннель и пустить все соединения через него. Но на другой его стороне всё-равно IP можно будет увидеть. Так что в результате мы имеем неразрешаемую проблему доверенного узла. Мы обязаны доверять узу который собираемся подставлять. И это в идеальных условиях, а на практике все подключены через операторов связи. Те же тор и p2p имеют ту же проблему. Другими словами, в любых отношениях между 2 и более людьми где требуется личностная идентификация, невозможно остаться анонимным доверяя только себе.
>>15159 https://cgi.soic.indiana.edu/~kapadia/nymble/securityFAQ.php > мы имеем неразрешаемую проблему доверенного узла. Можно сделать более одного узла, каждый из которых будет доверенным только для одной из операций в цепочке. Легче доверять распределённой системе из нескольких машин, в которой достаточно наличия только одного неcкомпрометированного и не состоящего в сговоре с остальными узла.
>Достаточно дополнительного проксирующего сервера вне зоны компетенции админа, перенаправляющего всех пользователей на основной. Подразумевается что заголовки и пакеты будут подчищенны, а идентификаторы идти в комплекте. >Можно сделать более одного узла, каждый из которых будет доверенным только для одной из операций в цепочке. Мы привлекаем все больше и больше доверенных лиц, чтобы обойти одного недоверенного, притом что этот админ не может не обнаружить проксирования запросов в какой-то момент и решить его заблокировать (у него могут быть причины, он же "темный" и недоверенный). Ну, или это недоверенное лицо является также частью круга доверенных лиц, осуществляющих проксирование. Возникает один вопрос: что это вообще за хуйня? Чем это может быть лучше, чем tor или даже банальный прокси третьих лиц с клиентской стороны?
>>15174 > он же "темный" и недоверенный Сам-то по себе он может быть и доверенным, но кто может гарантировать сохранение им контроля над сервером и его логами? > все больше и больше доверенных лиц Нет. Доверие к одному лицу заменяется на доверие к отсутствию сговора между администраторами различных узлов системы, а также между администратором сервера и теми, кто контролирует какой-то из узлов. > Чем это может быть лучше, чем tor Tor не даёт возможности эффективно банить. Естественно, что система с недоверием к администратору может работать только поверх анонимизирующей сети, например того же tor. > даже банальный прокси третьих лиц с клиентской стороны? >>15158
>>15175 >Сам-то по себе он может быть и доверенным, но кто может гарантировать сохранение им контроля над сервером и его логами? А что может гарантировать сохранение контроля над всей группой серверов? Это уже придирки, конечно, но если допускать взлом/изъятие, то делать это до конца? >Нет. Доверие к одному лицу заменяется на доверие к отсутствию сговора между администраторами различных узлов системы, а также между администратором сервера и теми, кто контролирует какой-то из узлов. Что-то вроде "распределенный сервер"? Вообще, неплохо, но для "абсолютного недоверия" все же слабее tor, в силу малого количества вовлеченных узлов. >Tor не даёт возможности эффективно банить. Мне казалось, что нас интересует все же безопасность/анонимность клиента. В конце концов, если мы НЕ доверяем администратору какого-то ресурса, какого рожна нам вообще верить тому, что он якобы поднял анонимизирующую систему? По крайней мере, в такой формулировке "сервер" звучал в ОП. >Очевидный минус такого решения в том, что полное доверие к администратору сервера заменяется на полное доверие к администратору прокси. Во всей подобной (распределенной) системе все равно будет одна точка входа — наш клиент с его реальным или подставным ойпи. Для компрометации подобной системы все равно достаточно скомпрометировать одну машину.
>>15167 >достаточно наличия только одного неcкомпрометированного и не состоящего в сговоре с остальными узла И чем это отличается от той цитаты на которую ты отвечаешь? Чтобы опровергнуть утверждение, нужно предложить систему где доверять ты можешь только своему компьютеру, а лучше даже и ему не доверять. >>15174 И что? Ну перестанет работать. А может вообще сервер целиком удалить или физически из окна его выбросить. Мы настолько ему не доверяем? Тогда лучше даже не подпускать. >>15176 Ты всё правильно понял. Лишние нагромождения приводящие к такому же результату.
>>15176 > А что может гарантировать сохранение контроля над всей группой серверов? > Это уже придирки, конечно, но если допускать взлом/изъятие, то делать это до конца? В случае группы сервером в разных странах с различающимися законами произвести взлом/изъятие сложнее. Полной и абсолютной гарантии, конечно, быть не может. > для "абсолютного недоверия" все же слабее tor, в силу малого количества вовлеченных узлов Согласен, поэтому в идеале узлов должно быть больше, и сама система анонимного blacklisting должна быть интегрирована в архитектуру анонимизирующей сети, а не быть надстройкой над ней. Nymble c двумя серверами из статей по ссылкам выше - это скорее proof of concept. > какого рожна нам вообще верить тому, что он якобы поднял анонимизирующую систему Анонимизирующая система должна быть независима от администратора сервера, он не должен её поднимать. >>15177 > Чтобы опровергнуть утверждение, нужно предложить систему где доверять ты можешь только своему компьютеру, а лучше даже и ему не доверять. Очевидно, что не может быть такой системы. Взамен предлагается усиление защиты от компрометации путём разделения доверия на множество расположенных в разных юрисдикциях и независимо администрируемых серверов.
Когда мы не доверяем конкретному админу в конкретной части обработки сетевых операций, простым и очевидным с точки зрения логики шагом, будет вынесение этой самой части подальше от админа. У вас же какой то глобальный антирептилоидный заговор получается. Так даже метода сбора костюма бэтмена из обрезков продукции фабрик разбросанных по всему миру будет явно недостаточно. Отправляйте сервер тайно на Плутон под видом метеозонда приделов модуль самоуничтожения. Но боюсь и там до него доберутся.
>>15178 >Анонимизирующая система должна быть независима от администратора сервера, он не должен её поднимать. Это уже в сторону, НО: Клиент заходит на подобную систему. Он ожидает безопасности. Как ему знать, что он не на обычном веб-сервере, например? Ну и: >Во всей подобной (распределенной) системе все равно будет одна точка входа — наш клиент с его реальным или подставным ойпи. Для компрометации подобной системы все равно достаточно скомпрометировать одну машину. >>15179 >Когда мы не доверяем конкретному админу в конкретной части обработки сетевых операций, простым и очевидным с точки зрения логики шагом, будет вынесение этой самой части подальше от админа. Сюда: >Во всей подобной (распределенной) системе все равно будет одна точка входа — наш клиент с его реальным или подставным ойпи. Для компрометации подобной системы все равно достаточно скомпрометировать одну машину. Конечно, то, что можно назвать решением, уже названо, но ОП сам сказал "абсолютное недоверие". Правильный ответ: невозможно.
>>15180 > Как ему знать, что он не на обычном веб-сервере, например? Он ставил клиентское ПО этой системы.
>>15183 А, ок.
>>15183 Тогда ITT изобретают велосипед. Сам протокол сети строится на нужных механизмах. Сорта промежуточных узлов меняющих IP повсеместно. От чести именно потому потребовалось вводить заголовки для записи сортов "реальных IP", для предотвращения утери этих данных при передаче. ассортимент широк - от роутеров до проксей. Классический пример подключения к сети через подставной компьютер, который действует от своего лица - VPN.
>>15194 > Сорта промежуточных узлов меняющих IP повсеместно. От чести именно потому потребовалось вводить заголовки для записи сортов "реальных IP" От этих заголовков есть толк только при доверии добавляющему их. В удовлетворяющей требованиями ОПа системе агент, выдающий токен по IP-адресу, должен быть доверенным и не иметь при этом доступа к содержанию передаваемых клиентом с использованием этого токена пакетов данных. Один из возможных способов достижения доверия заключается в том, чтобы реализовать этот агент как группу из двух или более случайным образом выбранных серверов, участвующих в системе достаточно долго и находящихся в разных странах. >>15179 > Когда мы не доверяем конкретному админу в конкретной части обработки сетевых операций, простым и очевидным с точки зрения логики шагом, будет вынесение этой самой части подальше от админа. Да, в этом случае см. >>15091. Но ОП же хочет, чтобы при изъятии серверов "определение пользователей было бы очень затруднено". Для удовлетворения таких требований как раз и нужны распределённость и архитектура, обеспечивающая высокий уровень доверия к системе в целом при низких априорных уровнях доверия к отдельным составляющим её узлам.
Было бы гораздо интереснее посмотреть на админку для АИБ основанную на полном недоверии к модераторам.
>>15270 Ну это-то легко. 1) Вместо IP пользователей использовать хеши (уже есть в vichan) 2) Не удалять посты и файлы, а только помечать в базе как удаленные 3) Сделать модераторские сессии В итоге всё можно будет откатить.
>>15324 Основная проблема - сохранить анонимность. В режиме модератора сразу видно кто какой пост оставил. А даже если и нет, можно косвенно судить по делолам и банам. А без банов нельзя.
- wahaba + wakaba 3.0.9 + futaba + futallaby -
