> то что 3des или arcfour стоит рассматривать к применению если под
> рукой есть chacha20. Ну а если под рукой нужных алгоритмов нет - это как раз то чем стоило бы озаботиться.
> Мой point лишь в том что допустим у человека нет достаточно современного SSH-сервера
Мой пойнт в том что если некто не контролирует свое окружение НАСТОЛЬКО - какая там нафиг безопасность? Кивания на стандарты и прочая показали что те кто выбирают стандарты - как правило отказываются от безопасности.
> не годно: годно, но тормознуто и так далее.
Морально устаревший и потенциально проблемный по ряду пунктов вариант, имхо. Ну то-есть если выбор какой кактус грызть - этот как бы не самый колючий, но зачем грызть кактусы - загадка природы.
> зная что посторонние к нему не подойдут
При таких допущениях можно хоть телнет использовать. Со своей стороны я думаю что алгоритм должен по возможности создавать минимум проблем и минимум возмущений во внешней среде. Иначе будет много трудноучитываемых факторов которые долбанут в лоб.
> ноутбуке), а доверять Wifi шифрованию конечно же просто нельзя и приходится
> делать какой-нибудь канал шифрованный.
С wi-fi все довольно забавно:
- Во первых, подставную точку доступа сделать не так уж сложно.
- Во вторых, фабричные прошивки роутеров редкий крап, начиная от наличия там бэкдоров и заканчивая реализацией какого-нибудь WPS, позволяющего сунуться в сеть с ним за полдня кому угодно.
> любимого SSH обновить то не сложно должно быть.
Да и не в домашних - тоже. Если кто не может даже это - как они остальной софт разворачивают?
> Если, как вы и говорите, мало ли где этот SSH-сервер находится/используется,
Ну как бы случаи когда на сервере есть только ssd и более нишиша - достаточно редки. Поэтому на мой взгляд лучше использовать алгоритмы ориентированные на регистровую арифметику - так будет меньше неожиданностей.
> Не, я имел в виду под анализом трафика -- его статистический анализ,
> то бишь размеры и частота/время прохождения пакетов.
Если честно я не вижу принципиальной разницы как именно декодируют мой траффик. Лобовым ли расшифровыванием или косвеной реконструкцией. Результат одинаковый.
> Про TLS: если это TLS канал между собственно настроенным сервером и клиентом,
> где вырезаны все legacy алгоритмы (хотя бы на уровне строк приоритетов
> GnuTLS/OpenSSL), где чётко явно задаётся как и с чем он должен
> работать -- не вижу ничего опасного в этом,
В целом и протокол и либы - полное г-но! Почему?
- Разобраться каким ауторити кто доверяет по дефолту без поллитры невозможно. И любая доверяемая ауторити может выписать правдоподобно выглядящий и рабочий сертификат.
- Уйма легаси, несекурного и проблемного. Зачастую дающего возможность даунгрейда и подстав.
- Очень сложный протокол, с кучей явно лишних опций. Обречен иметь много проблем безопасности в реализациях. Большой либе - куча багов.
- Редкий апликушник заморачивается какие там алгоритмы и версии протокола. Он думает что ему сделют безопасно. А оказывается - фиг!
- Более того, половина апликушников вообще не делают самых базовых вещей. Скажем запомнить и проверить совпадение фингерпринта (стандартно для любого клиента ssh) в TLS допирают только особо избранные. Я из таких видел целый пиджин. И ... всё?!
- Получить лучшие свойства которые может предоставить современная криптография - гемор и рокетсайнс.
А с другой стороны у нас есть какой-нибудь tweetnacl дяденьки Бернштейна. Его можно прочитать глазами, там мизер кода. Там по дефолту нормальная подборка алгоритмов. По дефоту все безопасно. Апи примитивное и лохануться там еще надо суметь. Крутейший diffie-hellman на эллиптических кривых - "почти без key exchange". Да и сами ключи столь компактны что их можно напрямую передавать вместо fingerprint. А perfect forward secrecy на основе этого может сделать даже неглупый школьник. А кому хочется готовое - CurveProtect есть. Но вот почему-то это - не стандарт. Но - здорово лучше стандартов, имхо.
> если есть доверие к реализации.
Не вижу оснований доверять переросточной либе и переусложненому протоколу лишний раз. Огромный код в протоколе с кучей костылей гарантирует кучу багов. Последнее что нужно в конструкции призванной кого-то от чего-то защищать. Heartbleed не должен был существовать - потому что этой фичи не должно было быть в протоколе, для начала. А если в протокол напхать хлама "чтобы было" - будет как-то так.
> я согласен без сомнений что если есть чем заменить TLS, то
> лучше это сделать.
А тут уж каждый за себя решает что ему. Или стандарты толку с которых ноль, или фактическая результативность.
> знаю насколько качественные там реализации, но всяких chacha/25519 там не видно.
В правильном направлении смотрели вон те граждане - https://www.opennet.ru/opennews/art.shtml?num=39752
> Зато приятно что сделали SRP поддержку.
Не знаю чего в этом такого приятного.
