> На ноде должен быть доступ ко всем открытым ключам абонентов сети idec.

Хотя это вот, реальное ограничение. Но нода может выдавать по запросу public ключи своих поинтов, что возвращает нас к схеме "шифрования на клиентах". Не знаю, как то не идеально. :)

Peter> В любом случае, описанные атаки, не совсем атаки. Так как любая нода может забрать netmail если она доверена.

Если вдруг нода скомпрометирована, то она может вылавливать нетмейл чужих нод и вывешивать его публично.

Peter> Доверенность подтверждается ЭЦП. Так что я не понял суть твоего примера до конца. Если я доверяю твоей ноде, и убеждаюсь с помощью ЭЦП в аутентичности твоих запросов, почему бы мне и не слить тебе netmail?

Мы совершенно про разные вещи говорим. При схеме

                      abcde
                        |
нода1(from) > нода2 > нода3 > syscall (to)

нода 2 может организовывать атаку MITM, подменяя части сообщений. Например, подменив адрес получателя, она может добиться того, что нода3 отправит сообщение не получателю syscall, а левой ноде abcde. А если она подменит адрес отправителя, то может сама отлавливать чужую почту. Поэтому схемы без шифрования обречены на провал.

Возвращаясь к полю адреса, мы уже высказывали когда-то идею, что в поле адреса можно вписывать открытый ключ или ID этого ключа (неважно, для станции или для самого человека). При этом ЭЦП должна применяться не только для текста сообщения, но и для этого самого поля адреса, чтобы остальные ноды во время синхронизации не смогли подделать "обратный адрес" следования.

И теперь насчёт того, делать шифрование + ЭЦП на ноде или на клиенте.

1. На клиенте
+ не надо доверять сисопам
+ не надо сильно переделывать код станций
+ юзверь может получить свою почту с любой станции, с какой захочет
- надо совершенствовать клиенты
- нужен актуальный keystore для базы данных поинтов

2. На станции
+ не надо переделывать клиенты
+ реализация проще и легковеснее
- юзверь может получить почту только со своей станции
- поинт должен доверять своему "боссу"
- все ноды/юзвери должны знать, на какой станции живёт получатель, чтобы сообщение расшифровалось там, где это надо

Difrex> Мне кажется, что сначала, нужно решить проблему синхронизации поинтов.

Да ни к чему, как по мне.

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

Это было бы актуально при аутбаундах.

Difrex> Либо можно придумать скрытоэху, которая синкается всеми. В ней можно устроить e2e шифрование, например с GPG ключами. На ноде хранить сообщения от туда по-минимуму. Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

Вот шифрование штука такая. С одной стороны дополнительные зависимости, с другой стороны, сисоп уже не может отвечать за траффик, идущий через его ноду.

Peter> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.

Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.

Также любые метаданные сообщений можно подменять на пути следования. И отправителя, и получателя, и адреса, и всё остальное. То есть я тупо захожу в админку на станции, ввожу msgid и меняю любые данные в сообщении. Если уложился в 10 минут - атака MITM сработала. Иногда мне приходится очепятки так править, если случайно загнал сообщение, не подумав =)

Нас спасёт только шифрование, потому что именно оно может гарантировать сохранность переписки. И это гораздо надёжнее в плане транспортов, потому что подойдёт под любую схему синхронизации, какую только можно придумать.

> Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.

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

Ну то есть:
На ноде должен быть доступ ко всем открытым ключам абонентов сети idec.
На ноде должны быть приватные ключи своих поинтов.

В таком случае, внешне, для поинтов вопрос шифрования вообще не стоит. Они могут дополнительно делать что угодно.

Почему то мне такой вариант нравится больше. А вам? :)

>Ключи может нагенерировать сисоп и просто выдавать пару поинту вместе с authstr при регистрации.
Плохая идея.

>При желании юзверь может дать сисопу собственный открытый ключ, если его такой вариант не устраивает.
На самом деле никому ключ передавать не нужно. Можно воспользоваться тем же pgp.mit.edu. Либо, чтобы сисоп поднял sks и грузить ключик туда. Это не сложно =)

Peter> Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

Ну так ЭЦП ведь действует независимо от шифрования. Так что читать чужие письма всё равно сисопы смогут.
Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

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

>> Нас спасёт только шифрование
> Вероятно, так и есть. :( Для меня, это выглядит скорее как отсутствие перспектив на netmail.

Вот! Хоть кто-то меня понимает.

AL> Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

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

Мне личные сообщения нужны скорее в рамках "КЛУБА", есть ли смысл делать их хотя бы в пределах одной ноды? Тогда все упрощается.

Peter>> В принципе, адреса то у нас есть. Это имя ноды и номер поинта. В качестве примера, если сообщение адресовано <syscall,1> - то это netmail ко мне.
vit01> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.

В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю? Это позволит создать "круг доверия" между узлами и позволит ходить личной переписке между ними без этой уязвимости. Ведь внутри сети у нас не повторяются имена узлов.

vit01> Также любые метаданные сообщений можно подменять на пути следования. И отправителя, и получателя, и адреса, и всё остальное. То есть я тупо захожу в админку на станции, ввожу msgid и меняю любые данные в сообщении. Если уложился в 10 минут - атака MITM сработала. Иногда мне приходится очепятки так править, если случайно загнал сообщение, не подумав =)

Ну и долой такого сисопа при первом палеве из сети. Все так радеют за безопасность, всё время забывая, что это просто шутка. Не бывает информационной безопасности.

vit01> Нас спасёт только шифрование, потому что именно оно может гарантировать сохранность переписки. И это гораздо надёжнее в плане транспортов, потому что подойдёт под любую схему синхронизации, какую только можно придумать.

Тогда я пас.

vit01>> Адреса не уникальны. Мы можем подключить в сеть ещё хоть 10 узлов под названием syscall и отлавливать твою почту.
AL> В сеть то их кто пустит? А я не предлагал разве между узлами обмениваться нетмейлом только по отдельному паролю?

vit01>> Также любые метаданные сообщений можно подменять на пути следования.
AL> Ну и долой такого сисопа при первом палеве из сети.

Ну, если существует два варианта развития событий: хороший или дурацкий, то ситуация обязательно пойдёт по второму сценарию. Пока нас мало, мы можем не читать чужую почту и жить честно. Как только узлов станет больше, будут и сисопы, которым захочется потешить своё любопытство.

AL> Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

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

Когда мы пытаемся договориться по поводу чего-то, надо учитывать и плюсы, и минусы. Так что надо приводить примеры и с MITM, потому что кому-то это может не понравиться.

> Ну, если существует два варианта развития событий: хороший или дурацкий, то ситуация обязательно пойдёт по второму сценарию. Пока нас мало, мы можем не читать чужую почту и жить честно. Как только узлов станет больше, будут и сисопы, которым захочется потешить своё любопытство.

Разве это сильно отличается от обычной почты в интернете? Почему ты думаешь, что уровень доверия к ноде по ЭЦП недостаточная мера?

Идея личной переписки мёртворождённая. Потому что без шифрования она никому кроме меня не нужна, а с шифрованием мы теряем простоту технологии.

Не работает почему-то authstr, который ты мне выдавал с mira station.
И еще, в idec-mobile, как раз при вводе этой самой authstr, почему бы не сделать строку видимой при первом вводе, потом можно и точками ее закрывать, при настройке эхо станции. Потому как не видно и сравнить нельзя правильно ли ввел посимвольно. И кнопки просмотреть pass нету.

>Так что ради соответствия сделал file ok:<hash> по аналогии с msg ok:<hash> в обычном /u/point. Ну и, конечно же, error: no auth
> Очень странно, что это было пропущено при проектировании, в iing и в стандарте.

Потому что я болван =) Спасибо. В ближайшее время внесу соответствующие правки в iing.

А ещё я это сообщение набрал одним пальцем =)

Peter> Мне личные сообщения нужны скорее в рамках "КЛУБА", есть ли смысл делать их хотя бы в пределах одной ноды? Тогда все упрощается.

Если нужны, то почему бы не сделать? Главное, чтобы остальной стандарт поддерживался. Причём по большей части достаточно ii-03 =)

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

Но почему-то нет доверия между сисопами. Мы ж кого попало не берём =)

Надо понимать, что вся сеть у нас строится на доверии и так и надо продолжать. Интернет и правительства государств стремятся к разделению людей, а мы же стремимся к обратному. Посмотрите на картинку на http://ii-net.tk/ она передаёт суть idec - сеть людей. Это то немногое, что отличает нас от остального интернета. И важно это не потерять со временем.

Выдохнул.

> Так что читать чужие письма всё равно сисопы смогут.

Те сисопы, кому мы доверим. А если поинт параноит, может и PGP поверх юзать.

> Да и с точки зрения зависимостей один фиг добавлять больше компонентов придётся.

ЭЦП можно и без pcrypto реализовать, прямо на питоне =)

> В общем, я пока займу опять выжидательную позицию.

Если еще идеи возникнут, пиши. У меня пока тоже нет 100% ясности, что делать и делать ли вообще.

Просматривая документацию фэх, обнаружил, что при использовании f/p совершенно нет никаких кодов ответов
Так что ради соответствия сделал file ok:<hash> по аналогии с msg ok:<hash> в обычном /u/point. Ну и, конечно же, error: no auth
Очень странно, что это было пропущено при проектировании, в iing и в стандарте.

На станции мира в экспериментальном режиме теперь работают фэхи. Правда, я f/list.txt забыл сделать, но это не критично. Зато f/blacklist.txt не забыл =)

vit01> Только что добавил в клиент очень вкусную фичу - обновление отдельных сообщений с сервера

Реквестирую СОХРАНЕНИЕ черновика сообщения!!!!!!!!!!!!!!!!!!!!!!!
Выбесило просто, два раза пытался написать сабж в music.14, в ответ Andrew Lobanov, рекомендации и проч, что послушать, да погонять под настроение.

Первый раз -- упало новое сообщение в ii.14, собственно я его сам и написал до этого, прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts, вижу есть 1мессдж, фух, думаю сохранилось, написал уже много. Открываю, а там просто квотированный текст и заголовки мессдж ответа.

Ладно думаю, напишу еще раз, начал, пишу. Писал писал. Опять расписал уже кучу инфы. Ну думаю, щас то, сохраниться, и что-то сделал связанное с обновлением эх, и короче опять ничего не сохранилось.
Не бывать тому сабжу..

jmaks>> Реквестирую СОХРАНЕНИЕ черновика сообщения

vit01> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

Похоже нужно ещё и в onPause сохранять.

vit01> Всем обновиться!
Я конечно может занудствую, но хотелось бы хоть знать какая теперь версия,
что искать для обновления, а то найдешь, да не то.

jmaks> Не работает почему-то authstr, который ты мне выдавал с mira station.

Напиши мне на me@ii-net.tk , разберёмся

jmaks> И кнопки просмотреть pass нету.

Сделаю кнопку

vit01>> Всем обновиться!
jmaks> Я конечно может занудствую, но хотелось бы хоть знать какая теперь версия, что искать для обновления, а то найдешь, да не то.

1. Заходишь на https://ii-net.tk, там есть кнопка
2. Или в самом клиенте в Navigation Drawer'e в списке есть кнопка "Обновиться", она приведёт сразу на APK

jmaks> Реквестирую СОХРАНЕНИЕ черновика сообщения

Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

jmaks> прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts

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

Кстати. Можно сделать ЛС и без шифрования и без общей эхи.

Например, методы <POST|GET> /i/username

Т.е поинт отсылает сообщение в свою ноду на поинта с другой ноды.

node1user:$ curl -XPOST /i/node2user -d '{"auth": "authstring"}'

И оно становится доступно для фетча для доверенной ноды. На другой ноде, где юзер хочет почитать почту, делается запрос на получение своей почты. Вторая нода делает запрос на все ей известные ноды, ну и фетчит почту своих поинтов.

Так протокол остается простым и может быть реализован хоть на файлах.

Вот как-то так.

vit01>> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.

btimofeev> Похоже нужно ещё и в onPause сохранять.

Да уже сообразил, чётко видно в исходниках. Но потом, сегодня занят.

jmaks>> Не работает почему-то authstr, который ты мне выдавал с mira station.
vit01> Напиши мне на me@ii-net.tk , разберёмся
Пишу.

jmaks>> И кнопки просмотреть pass нету.
vit01> Сделаю кнопку
Отлично.

vit01>>> Всем обновиться!
jmaks>> Я конечно может занудствую, но хотелось бы хоть знать какая теперь версия, что искать для обновления, а то найдешь, да не то.
vit01> 1. Заходишь на https://ii-net.tk, там есть кнопка
vit01> 2. Или в самом клиенте в Navigation Drawer'e в списке есть кнопка "Обновиться", она приведёт сразу на APK
Да, я уж нашел. Вспомнил где брал. Просто у тебя пакет называется всегда app-debug.apk и непонятно, какая версия, какое что.
Было бы понятней если идет ченджлог и версия пакета... типа idec-mobile-1.2.5.apk

jmaks>> Реквестирую СОХРАНЕНИЕ черновика сообщения
vit01> Он и так должен сохраняться, если ты кнопку "назад" нажимаешь.
Так-то да, но вот сегодня поймал странное поведение, и черновик написанный не сохранился, а только созданный.

jmaks>> прошло 15мин, обновилось, упало уведомление, что есть новый мессдж, открыл верхний фолд, нажал, смотрю, ага, работает уведомлялка. Открываю Drafts
vit01> Очень странное поведение. Однако я понял примерно, куда копать, спасибо за багрепорт.
Не за что.

Даже поле Echo можно оставить. Разрешить его быть пустым, например.
Если поле не пустое, то получится, что-то типа канала во всяких irc, только не im :).

Еще можно сразу нескольким юзерам разрешить писать: /x/i/<to_username>/<to_username2>.

Сейчас с утра прочитал свое сообщение -- в общем мне нравится эта идея.

Вынести это все куда-нибудь в расширения, типа, /x/i/<to_username>.
Нода может, как по крону фетчить почту своих поинтов, так и напрямую ходить к соседям при запросе от поинта.

Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

Годнота же.

Давайте сделаем. =)
Еще у меня возникла мысль, что чтобы не переделывать клиентский софт, можно слать и получать приватные сообщения в обычную эху но такую:

netmail.<authstr> -- по сути это одновременно авторизация и софт не надо менять

>Я примерно это и предлагал, но Виктора смущает MITM, и доступ сисопов доверенных нод к переписке.

Если зохочется шифрование, то в такой схеме ничего не мешает использовать PGP, либо просто кидая armor сообщение, либо реализовав поддержку в клиенте.

Сейчас, мне кажется, что это не проблема сети совсем. Необязательно же каждую ноду включать в сеть для переписки.

Difrex(mobile)> Кстати. Можно сделать ЛС и без шифрования и без общей эхи.
Difrex(mobile)> Например, методы <POST|GET> /i/username
Difrex(mobile)> Т.е поинт отсылает сообщение в свою ноду на поинта с другой ноды.
Difrex(mobile)> node1user:$ curl -XPOST /i/node2user -d '{"auth": "authstring"}'
Difrex(mobile)> И оно становится доступно для фетча для доверенной ноды. На другой ноде, где юзер хочет почитать почту, делается запрос на получение своей почты. Вторая нода делает запрос на все ей известные ноды, ну и фетчит почту своих поинтов.
Difrex(mobile)> Так протокол остается простым и может быть реализован хоть на файлах.
Difrex(mobile)> Вот как-то так.

Я примерно это и предлагал, но Виктора смущает MITM, и доступ сисопов доверенных нод к переписке.

>Лучше вписать туда что-нить типа net.mail.

Не, фишка в том, что если оставить поле пустым, то будет периписка между двумя пользователями, а если в echo вписать что-то, то туда можно наинвайтить много пользователей и писать на All.

Получится что-то вроде приватной эхи.

Difrex> Нода может, как по крону фетчить почту своих поинтов, так и напрямую ходить к соседям при запросе от поинта.

Тогда придётся лепить полносвязку, а хотелось бы этого избежать.

Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

Это сабо самой.

>То есть, доверенные ноды тоже забирают по authstr?
Да.

>Как доверенная нода забирает бандл со всем net.mail?
Примерно так:

for node in neighbords:
  for username in node_users:
    r = requests.get('https://' + node '/x/i/' + username)
    for msg in r.content.split("\n"):
      if msg.split(':')[0] not in point_mails():
        store_to_pointmail(base64.d64decode(msg.split(':')[1]))

Difrex> Даже поле Echo можно оставить. Разрешить его быть пустым, например.

Лучше вписать туда что-нить типа net.mail.

> Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.

> Это сабо самой.

То есть, доверенные ноды тоже забирают по authstr? Как доверенная нода забирает бандл со всем net.mail?

>> Лучше вписать туда что-нить типа net.mail.
> Не, фишка в том, что если оставить поле пустым, то будет периписка между двумя пользователями, а если в echo вписать что-то, то туда можно наинвайтить много пользователей и писать на All.
> Получится что-то вроде приватной эхи.

Не понял зачем это может быть нужно. В стандарте чётко прописана структура сообщения и нигде не допускается пустых полей, ЕМНИП. А приватные эхи тем более не нужны. Есть скрытоэхи.

На mira station есть ещё фэха pr0n.share

Да, это именно то, что вы подумали, название говорит само за себя :)

Более чем уверен, что её наполнять никто не будет, но пусть останется на всякий случай.

Peter> Еще у меня возникла мысль, что чтобы не переделывать клиентский софт, можно слать и получать приватные сообщения в обычную эху но такую:

Peter> netmail.<authstr> -- по сути это одновременно авторизация и софт не надо менять

Это гениально! =) Отличная идея. Только тут надо помнить, что название эхи - это lowercase, но тут невелика проблема, можно преобразовать.

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

Насчёт "эх внутри нетмейла". Идея неплохая, но это можно реализовать проще: через теги, т.е. тем же способом, каким у нас сейчас ставится repto.

Сабж теперь может отображать эхи в виде лент (отображение по-умолчанию, переключение в профиле) и передавать содержимое конференций в RSS.

Теперь тяну эту эху тоже. :) С idec.spline-online.tk

В таверне на данный момент есть следующий фэхи:

* pictures - картинки, скриншоты, всякое такое;
* books.tech - техническая литература, включая учебники и справочники;
* mlp.pictures - картинки с поняшами;
* mlp.special - ещё картинки с поняшами.

Последнюю фэху я думаю в последствии удалить, наверное. Всё таки очень специальный контент =)

Все фэхи на данный момент фетчатся с mira station.

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

Фетч двухсторонний.

>> Difrex> Поинтовое сообщение ничем не отличается по структуре от сообщения в эху.
>> Это сабо самой.
> То есть, доверенные ноды тоже забирают по authstr? Как доверенная нода забирает бандл со всем net.mail?

Идея моя состоит в том, что нода для забора нетмейла использует парольный запрос. То есть доверенная нода регистрируется на ноде-аплинке в роутинге нетмейла (их может быть сколько угодно вплоть до полносвязки) и получает бандл нетмейла по паролю. Так нетмейл не утечёт за пределы доверенной сети.

Проанализировал логи и зметил, что фэхи с меня узлы не тянут (или тянут с отличным от эх периодом). А между тем я собрал все фэхи, включая сомнительные. Включайтесь в файлообмен =)

Итак, IDEC Mobile получает начальную поддержку файловых эх

Обновляться всем обязательно!

1. Заходите в настройки станции, ставите галку "Поддержка файловых эх"
2. Фетчите сообщения как обычно
3. В NavDrawer'е идёте на вкладку "Файловые эхи"

По клику на файле он скачается. Если тыкнуть по нему второй раз, то откроется в соответствующем приложении
Длинный тап == показать полностью описание и хэш

Багов ещё много, но это уже хотя бы что-то. Занимался сегодня клиентом целый день, даже еде внимания меньше уделял. Так что прошу feedback!

AL>> Проанализировал логи и заметил, что фэхи с меня узлы не тянут (или тянут с отличным от эх периодом).
vit01> Станция мира фетчит фэхи на таверне раз в 20 минут.
vit01> Но я решил сделать проверку и увидел, что фетчер отказывается скачивать оттуда 3 файла.
vit01> У меня на станции стоят строгие регулярки, по которым имя файла разрешается только в lowercase (как имя эхи). Вроде бы, мы именно так по стандарту и договаривались, не?

Я был уверен, что любые буквы латиницы =)

vit01> // IDEC Mobile автоматически преобразует имя файла через toLower(), поэтому через него грузить безопасно.

> Проанализировал логи и зметил, что фэхи с меня узлы не тянут (или тянут с отличным от эх периодом). А между тем я собрал все фэхи, включая сомнительные. Включайтесь в файлообмен =)

Я фехи не буду тянуть (на постоянной основе). Разве что как поинт только. В том числе и потому, что у меня жесткие лимиты по объему на моем сервере.