= Сообщение: 177 из 2456 ==================================== RU.FTN.DEVELOP =
От : Pavel Gulchouck 2:463/68 18 Jan 14 13:35:18
Кому : Ivan Agarkov 18 Jan 14 13:35:18
Тема : Fido over SSL
FGHI : area://RU.FTN.DEVELOP?msgid=2:463/68+52da7700
На : area://RU.FTN.DEVELOP?msgid=2:5020/849.1+52da6370
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/849.1+52da7df7
==============================================================================
Hi Ivan!
18 Jan 14, Ivan Agarkov ==> Pavel Gulchouck:
IA>>> Проблема в том что ssh мы не контролируем. Ключи мы тоже не
IA>>> контролируем те, которые ssh генерит. И подписать их никак не
IA>>> можем например централизованно. А так - да, ssh это хорошо :-)
PG>> Если хочется централизованно подписывать, тогда вместо ssh нужно
PG>> что-то другое. Сходу не скажу - надо подумать/поискать. Распространять
PG>> - если нодлист не подходит, то есть ещё DNS.
IA> Давно придумали: pgp key server называется. А подписывать на key-sign встречах, как и в pgp мире.
gpg разве умеет кодировать поток, как это делает ssh? Я думал, что он только пакетно работает.
Key server - не более чем идея, но в готовом виде для нужд fido неприменим, потому что, опять же, для запроса и проверки подписей ключей нужна ручная работа и подтверждения, совсем автоматически это не получится. Так, чтобы я тебе позвонил, ты посмотрел мой адрес, выкачал ключ и всю цепочку ключей до общего координатора, для которого у тебя есть доверенный ключ, проверил всю цепочку, и продолжил общение, уже закодированное нашими ключами.
Если напишешь такую команду-пайп - да, это будет решением вопроса. Я не напишу, потому и сказал, что надо подумать/поискать.
Тут ещё, кстати, важно, чтобы все данные, переданные с одного конца, всегда были получены на другом конце, без какой-либо буферизации. Поэтому, например, gzip в этот пайп добавить нельзя, сессия залипнет, когда одна сторона передала что-то (например, пароль) и ждёт ответа, а вторая сторона этот пароль ещё не получила, потому что ждёт дополнительных данных.
PG>> То есть, не просто "обновил мейлер - получил ssl", а несколько
PG>> сложнее. Впрочем, генерировать/подписывать/распространять ключи ведь
PG>> всё равно нужно будет вручную.
IA> В общем что в итоге-то? Запилить rsa не так сложно, основное - разработать стандарт и вписать его внутрь binkp как
IA> extension.
Организация SSL-транспорта внешней утилитой не требует оформления его как binkp extension, потому что binkp работает внутри этого транспорта.
Примерно как передача файлов по zmodem over tcp не требовала расширения zmodem.
IA> Кстати еще один минус - binkp over <ssh/icmp/etc> работает через пайп и соответственно не имеет возможности фоллбека на
IA> обычный tcp в случае факапа.
То, о чём ты говорил вначале - отключил CRAM-MD5 и собрал все пароли? ;-)
Тут ведь лишь вопрос алгоритма мейлера и описания вариантов доступа в его конфиге.
Если можно написать ";*;1.2.3.4", то почему нельзя написать что-нибудь вроде "ssh:*;ssh:1.2.3.4;ssh:[1:2:3::4];*;1.2.3.4", т.е. пробуем через ssh на нодлистовый, если не получилось - через ssh на 1.2.3.4, потом по ssh на [1:2:3::4], потом по tcp на нодлистовый, и потом по tcp на 1.2.3.4?
IA> Своя реализация SSL втыкается как extension, аля startssl. Удаленный узел не понял - ну и хер
IA> с ним - ок, откатываемся на обычное соединение. В случае пайпа такое не получится - соединение просто не установится в
IA> случае, если на второй стороне пайп как-то по-другому сделан.
Нет, этот недостаток очень легко устраняется.
Скорее, наоборот: в этом случае можно пробовать разные транспорты для доступа к узлу, а если это binkp extension, то только tcp и никак иначе (даже ipv6 нужно отдельно реализовывать).
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
|
