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

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

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

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

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

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

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

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

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

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

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

>При желании юзверь может дать сисопу собственный открытый ключ, если его такой вариант не устраивает.

> Адреса не уникальны.

> Нас спасёт только шифрование

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

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

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

Difrex> Но тут нужно развитие клиентов. Чтобы они генерили ключи. Ключи можно синкать по надам в SKS.

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

> Просто в этом случае, ЛЮБОЙ сможет прочитать эти сообщения. В моей схеме (которая мне тоже до конца не нравится пока) -- только доверенная нода.

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

Peter> С шифрованием, конечно, частично все упрощается. Но по моему, все таки, делать его частью стандарта не очень...

> Это противоречит самым основам IDEC (да и ii), а именно:

> Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Peter> поинт -> нода поинта -> целевая нода
Peter> То есть, нет никакой сложной маршрутизации, сообщение от ноды поинта сразу коннектится к целевой ноде и отправляет сообщение на нее. Я считаю это нормальным, так как нода по определению доступна в сети интернет, и нет смысла делать какую то хитрую маршрутизацию

Peter> есть специальная скрытая эха netmail. При ее фетчинге -- клиент получает только те сообщения, которые адресованы именно ему. В качестве адреса -- имя ноды и номер поинта (то, что у нас есть). Авторицация по authstr. Но вот как сообщение доходит до ноды, отдельный разговор. Итак, первый способ.

Peter> 1) Сообщение распостроняется путем фетчинга как и сейчас. При этом, нужно решить 2 проблемы

> a) фетчить netmail могут только те ноды, которым мы доверяем;
> b) сообщение в netmail должны убиваться после доставки;

Мне нравится идея с "убиваться после доставки". Но предлагаю реализовать её немного по-другому.

Опишу целиком.

Основа: есть единый реестр поинтов, у каждого - свой открытый ключ, который записывается в общую корзину и есть на всех станциях

1. Есть публичная эха netmail, которую может фетчить каждый. Все сообщения в netmail зашифрованы.
2. Все ноды открыто забирают друг у друга netmail и смотрят на поле получателя. Если получатель числится на ноде, то сообщение сохраняется там навечно (ну или на очень долгое время вроде 3 месяцев). Иначе (если нода ведёт транзит, т.е. такого поинта на ней нет) - держится около 5-10 дней, на усмотрение сисопа.
3. Шифрование всё end-to-end, сервера в нём не участвуют. Смог расшифровать - сообщение твоё. Не расшифровал - значит не твоё.

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

> В очередной раз задумался о расширении стандарта.

> Первое (уже озвученное ранее) это нетмейл. То есть личная переписка.

> Удобного и действительно безопасного варианта я так и не придумал. Или привлекать PGP и монстрячить способ распросстранения открытых ключей или доверять всем сисопам сети личную переписку, отдавая поинтам только их сообщения. Если честно, мне оба варианта не нравятся. Может, у кого есть идеи получше?

Хочу озвучить мысли по нетмылу.

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

Сначала, очевидные вещи.

Я вижу 2 способа реализации netmail. В обоих случаях есть специальная скрытая эха netmail. При ее фетчинге -- клиент получает только те сообщения, которые адресованы именно ему. В качестве адреса -- имя ноды и номер поинта (то, что у нас есть). Авторицация по authstr. Но вот как сообщение доходит до ноды, отдельный разговор. Итак, первый способ.

1) Сообщение распостроняется путем фетчинга как и сейчас. При этом, нужно решить 2 проблемыЖ

a) фетчить netmail могут только те ноды, которым мы доверяем;
b) сообщение в netmail должны убиваться после доставки;

Про b) решить можно радикально. Просто заложить в стандарт время жизни таких сообщений. Например 2 дня. Если за 2 дня сообщение не дошло -- все равно это какая-то проблема. Считаю, приемлемым.
Про a) к сожалению, единственный нормальный способ, это механизм ЭЦП. Нода, которой мы доверяем фетч, дает нам открытый ключ, который мы используем для проверки подписи запроса. Реализовать можно прямо на питоне, без сторонних библиотек. Еще один вариант -- тупо по ip запроса, но мне он не нравится. Вариант с авторизацией по authstr не нравится вообще.

Теперь переходим к варианту 2)

Идея в том, что сообщение идет так:
поинт -> нода поинта -> целевая нода

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

a) кто может посылать таким образом сообщения нашим поинтам?
Варианты ответа.
1) все, кто угодно.
2) ????

вариант 1 неуниверсален.
а вариант 2 - мне не понятен. Так как в общем случае, я не знаю от кого получу запрос.

В итоге, вариант 1 с фетчингом мне нравится больше.

Кто что думает?

vit01> Что на сегодня:

vit01> 1. Учтены замечания Петра
vit01> 2. Попытался починить очередной баг с падением

vit01> Всем обновиться!

Обновился! Полет нормальный.

vit01> Он и так добавляется. Просто предупреждение выдаётся, дабы человек запомнил. Но могу его убрать.

Peter> Из замечаний: все таки стоит добавлять / к урлу станции, если его не ввели, имхо.