The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлен SSH3, вариант протокола SSH, использующий HTTP/3

17.12.2023 09:58

Доступен первый официальный выпуск экспериментальной реализации сервера и клиента для протокола SSH3, оформленного в форме надстройки над протоколом HTTP/3, использующей QUIC (на базе UDP) и TLS 1.3 для установки защищённого канала связи и механизмы HTTP для аутентификации пользователей. Проект разрабатывает Франсуа Мишель (François Michel), аспирант Лувенского католического университета (Бельгия), при участии Оливье Бонавентуры (Olivier Bonaventure), профессора того же университета, известного разработкой подсистемы Multipath TCP и кода сегментной маршрутизации IPv6 для ядра Linux, а также соавтора 10 RFC и черновиков более 60 сетевых спецификаций. Код эталонной реализации клиента и сервера написан на языке Go и распространяется под лицензией Apache 2.0.

Разработка SSH3 стала результатом полного пересмотра протокола SSH, проведённого отдельной группой исследователей независимо от OpenSSH и других проектов, развивающих реализации классического протокола SSH. В SSH3 семантика классического протокола SSH реализована через механизмы HTTP, что позволило реализовать некоторые дополнительные возможности и обеспечить скрытие связанной с SSH активности среди другого трафика.

При использовании SSH3 сервер неотличим от HTTP-сервера и принимает запросы на 443 сетевом порту (HTTPS), а трафик SSH3 сливается с типовым HTTP-трафиком, что затрудняет проведение атак, связанных со сканированием портов и выявлением SSH-серверов для подбора паролей. Для усложнения совершения атак на серверы SSH3, кроме знания сведений о наличии сервера на заданном IP-адресе, может задаваться секретный путь-идентификатор SSH3-сервера. Без обращения с корректным идентификатором сервер обработает ответы как обычный HTTPS-сервер и не выдаст факт наличия возможности подключения по SSH3. Например, при задании идентификатора "e6ae772cbdaafd6918865cc2ce449dae" подключиться к серверу можно только по URL "https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae", а если идентификатор указан некорректно, сервер выдаст штатную ошибку "404".

Из расширенной функциональности SSH3 упоминается возможность использования для аутентификации сертификатов X.509 и методов OAuth 2.0/OpenID Connect, помимо классических методов SSH; поддержка перенаправления UDP-портов через SSH-туннель в дополнение к возможности перенаправления TCP-портов (например, для проброса QUIC, DNS и RTP); использование расширенных функций протокола QUIC, таких как миграция соединений без разрыва подключения и установка multipath-соединений для распараллеливания трафика по нескольким маршрутам.

Отдельно выделяется существенное сокращение времени установки соединения при использовании SSH3. При подключении к серверу SSH3 требуется выполнить всего 3 сетевых итерации (Round Trip), в то время как для SSHv2 выполняется 5-7 итераций обмена пакетами. Время реакции на клавиатурный ввод для уже установленных сеансов в SSH3 и SSHv2 находится на одном уровне.

Для шифрования канала связи в SSH3 задействован протокол TLS 1.3, а для аутентификации могут использовать классические методы на базе паролей и открытых ключей (RSA и EdDSA/ed25519). Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеров, например, для обеспечения входа с подтверждением через учётные записи в сервисах Google, Microsoft и GitHub. Для подключения к серверам по ключам, помимо SSH-ключей, можно применять сертификаты X.509, используемые для HTTPS.

Опубликованная реализация клиента и сервера SSH3 поддерживает многие базовые возможности OpenSSH, среди которых:

  • Поддержка файла ~/.ssh/authorized_keys с настройками ключей на сервере.
  • Возможность использования файла конфигурации ~/.ssh/config на стороне клиента. В настоящее время поддерживаются параметры Hostname, User, Port и IdentityFile, а остальные игнорируются.
  • Поддержка аутентификации подключения к серверу на базе сертификатов.
  • Поддержка механизма known_hosts (в ситуациях, когда не применяются сертификаты X.509).
  • Поддержка работы клиента с OpenSSH Agent (ssh-agent) и автоматическое использование агента для аутентификации по открытым ключам.
  • Поддержка функции перенаправления через SSH-агент для использования локальных ключей на внешнем сервере.
  • Прямой проброс TCP-портов.


  1. Главная ссылка к новости (https://github.com/francoismic...)
  2. OpenNews: Представлен проект Mosh, нацеленный на создание более совершенной альтернативы SSH
  3. OpenNews: Выпуск DNS-сервера KnotDNS 3.3.0 с поддержкой DNS поверх QUIC
  4. OpenNews: Релиз OpenSSH 9.5
  5. OpenNews: Воссоздание RSA-ключей через анализ SSH-соединений к сбойным серверам
  6. OpenNews: Протокол HTTP/3.0 получил статус предложенного стандарта
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60300-ssh3
Ключевые слова: ssh3, ssh, http, quic, http3
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (209) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, anonymos (?), 11:55, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я правильно понимаю, что теперь нужен  будет правильный сертификат, подписанный правильной конторой?
     
     
  • 2.2, Аноним (2), 11:58, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Нет, можно использовать RSA  и EdDSA/ed25519 ключи от SSH или самоподписанные сертификаты  X.509.

     
  • 2.3, анон (?), 12:03, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +9 +/
    А кто запрещает использовать корпоративный центр сертификации или самоподписанные сертификаты?
     
     
  • 3.61, pavlinux (ok), 17:28, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –21 +/
    Гуглу заплатишь чтоб твой карпаративнй центр добавили в список доверенных?
    Иль ты Сбербанк и народ вынужден изучать процедуру добавления твагхо центра в каждый браузер?
     
     
  • 4.65, lucentcode (ok), 17:41, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Какой браузер? Тут используется HTTP/3 для установления SSH-сессии, вместо браузера будет SSH3 клиент, это же SSH. Никакого браузера в этой связке не будет, а значит и добавление центра сертификации в браузер, для использования SSH3, не актуально совсем.
     
     
  • 5.103, _ (??), 23:03, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И что то в воздухе мне подсказывает что хоть ftp:// из браузеров выпилили, ssh3:// - скорее всего впилят.
     
     
  • 6.126, Аноним (126), 04:27, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы понимаете!
     
  • 6.192, rvs2016 (ok), 16:18, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > из браузеров выпилили,
    > ssh3:// - скорее всего впилят

    А каком смысле впилят?
    При запросе в браузере "ресурса" ssh3:// браузер будет внутри себя открывать "чёрный терминал"? 😃

     
     
  • 7.208, _ (??), 01:06, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а чего такого то?
    Полно же плагов чтоб обычный ssh из браузера юзать...
    Идеального нет, но с той или иной степенью костыльности юзать можно прямо сейчас.
     
  • 7.224, swarus (ok), 12:54, 21/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    зачем можно серверный локалхост пробрасывать, многие утилиты web-морду на локальном хосте без аутификации крутятся, приходится -L опцию ssh юзать, давно хочу в браузерах подобную фишку.
     
     
  • 8.225, rvs2016 (ok), 14:38, 21/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не очень сильно понял Приведи примерчики простые ... текст свёрнут, показать
     
  • 5.231, pavlinux (ok), 18:02, 22/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Новость изучай,  тут SSH3  как HTTPS сервер.
     
  • 4.88, Тот_Самый_Анонимус_ (?), 21:11, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –6 +/
    >народ вынужден

    Ну так свобода кого надо свобода. Или ты думал что сертификаты это про удобство и безопасность, а не про контроль?

     
  • 4.104, Аллах (?), 23:29, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ой да ладно. Нихрена не изучал. После того, как мне там какой-то пeдик в техподдержке на мои ссылки на законы стал тупо монотонно с издевкой повторять то что сказал до этого, пошел в офис, с болшьшим скандалом потребовал удалить все данные. Еще периодически скандалил на работе, когда начинали квакать, что неудобно мне переводить в банк незарплатного проекта, и уже XX лет вопросы зеленого филиала кащенки  меня не касаются. Еще потрясяюще наблюдать недоумевающие рожи во всяких такси и шиномонтажах с возгласами 'как это у вас нет зеленый дурдом онлайн'.
     
     
  • 5.193, rvs2016 (ok), 16:22, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Наёмный работник имеет право требовать от работодателя соблюдения прав работника.
    Работодатель имеет право не заключить с таким работником контракт после завершения срока действия контракта предыдущего.
     
     
  • 6.217, ivan1986 (?), 16:16, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так пусть тогда работодатель находит работника, который и сбер юзает, только тупой он будет, за примерами долго ходить не надо - все нормальные из госконтор разбежались, там как раз такие дебилы и сидят.
     
  • 3.191, rvs2016 (ok), 16:15, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А кто запрещает использовать корпоративный центр
    > сертификации или самоподписанные сертификаты?

    А зачем тут вообще заговорили про сертификаты?
    Без них этот SSH теперь работать не будет уж? 😲

     
     
  • 4.218, ivan1986 (?), 16:18, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так вообще и старый тоже не работал, только они сначала были dsa потом rsa сейчас ed
     
     
  • 5.219, rvs2016 (ok), 16:25, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Так вообще и старый тоже не работал,
    > только они сначала были dsa
    > потом rsa сейчас ed

    А старый не работал как, если я к своим хостам через SSH подключаюсь без всяких сертификатов?

     
  • 5.233, Sem (??), 07:00, 23/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://en.m.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate-based_Authenticat
     
  • 2.31, Аноним (31), 13:42, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Правильно, иначе любой впалит, что твой "веб-серер" ненастоящий.
     
  • 2.40, Аноним (40), 15:18, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, верно. Все мы знаем как отображаются самопописанные сертификаты. Конец вебу настал
     
     
  • 3.57, BSDSHNIK (?), 17:03, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже такое неправильное отображение самоподписанного серта лучше его отсутвия совсем.
     
     
  • 4.63, pavlinux (ok), 17:31, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Даже такое неправильное отображение самоподписанного серта лучше его отсутвия совсем.

    Самоподписной может дядя хацкер подсунуть, один xpeн вы забиваете на проверку  

     
  • 2.143, Пряник (?), 09:37, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А кто тебе мешал раньше использовать самоподписанные?
     

  • 1.4, Аноним (4), 12:04, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    старО
    https://github.com/moul/quicssh (POC 4 years ago)
     
     
  • 2.228, Sem (??), 20:54, 21/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, но это не то. Это прокси QUIC->SSH, сам он не умеет ssh вообще, передает все sshd. Это прямо там на картинке показано.

    А в топике именно SSH овер QUIC. Правда совсем сырой прототип, который они сами не рекомендуют использовать пока.

     
     
  • 3.229, Sem (??), 21:02, 21/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее стоило упомянуть вот это:
    Workgroup:Internet Engineering Task Force
    Internet-Draft:draft-bider-ssh-quic-01
    Published:7 July 2020
    Intended Status:Informational
    Expires:8 January 2021
    Author: d. bider Bitvise Limited

    Но автор так и не реализовал ничего кроме этого драфта.

     

  • 1.5, Аноним (5), 12:04, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    В общем, ломают совместимость непонятно ради чего
     
     
  • 2.204, Аноним (204), 22:39, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ради лидерства HTTP/3. Уже вытеснили Java Applet, Silverlight, Flash своим HTML/5,
    а теперь дело и до сокетов обычных и протоколов дошло.

    Вообще надо этот консорцим немного поразогнать!!!

     

  • 1.6, Аноним (6), 12:07, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Расскажите пожалуйста как демоны SSH3 и, например, nginx решают между собой вопрос о том, кому принадлежит порт 443.
     
     
  • 2.8, Аноним (8), 12:12, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +17 +/
    Принадлежит тому, кто раньше запустился
     
  • 2.11, Ананимус (?), 12:18, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В идеале через роутинг в nginx:

    myhost.lan/porn
    myhost.lan/ssh

     
  • 2.13, Аноним (13), 12:21, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    HAPROXY + SNI?
     
  • 2.18, Аноним (18), 12:30, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В своём nginx несколькими строчками делаешь реверс прокси и запросы на "https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae" перенаправляются на демон ssh, который висит на другом порту.
     
     
  • 3.71, Admino (ok), 19:02, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так это и сейчас можно сделать. Зачем городить QUIC?
     
     
  • 4.84, scriptkiddis (?), 20:24, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А как, можешь поделиться?
     
     
  • 5.101, BrainFucker (ok), 22:58, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://www.nginx.com/blog/running-non-ssl-protocols-over-ssl-port-nginx-1-15-
    Я пользуюсь, кстати.
     
  • 4.167, Абывыгда (ok), 11:31, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос был в том, как уместить http сервис на одном порту вместе с nginx, а не зачем это нужно.
    С другой стороны, не всем нужен nginx на сервере. Короче, если кто-то что-то пилит, значит, как минимум, ему это нужно. Если тебе не надо - проходи мимо.
     
  • 3.93, Аноним (93), 21:50, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +10 +/
    И если^W когда вдруг наступят проблемы с работой nginx, то я потеряю не только веб-сервис, но еще и шелл на сервере? Отличный план!
     
     
  • 4.102, BrainFucker (ok), 23:01, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну, чтобы уронить nginx это надо сильно постараться. Во-вторых, нормальный хостинг обычно предоставляет возможность зайти на сервак через свой терминал в панели управления даже в случаях если sshd упал.
     
     
  • 5.211, Аноним (93), 04:24, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Когда у меня вдруг упал/мисконфигнулся nginx, меньше всего хочется заниматься залезанием в систему через serial console или ikvm, пока сервис лежит.
     
     
  • 6.214, BrainFucker (ok), 05:11, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да всё решаемо. Можно запилить сервис, который открывает доступ к SSH напрямую, когда через nginx нет доступа.
     
  • 4.161, Аноним (18), 11:14, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если рассматривать все варианты, то у тебя и ssh демон может упасть. Что ты будешь делать?
    А на счёт nginx - используй две штуки. Один - для реверс прокси, второй - для вебсервисов. Тогда твои кривые веб-сервисы не будут ронять реверс проксю.
     
     
  • 5.170, hshhhhh (ok), 12:15, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > у тебя и ssh демон может упасть. Что ты будешь делать?

    подключусь по ssh2!

     
  • 5.212, Аноним (93), 04:26, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Если рассматривать все варианты, то у тебя и ssh демон может упасть. Что ты будешь делать?

    Разумеется, может. Но только вот обычно не вместе с веб-сервером, отдающим сайт, когда этот самый ssh больше всего нужен для того, чтобы зайти и починить проблему.

    > А на счёт nginx - используй две штуки. Один - для реверс прокси, второй - для вебсервисов. Тогда твои кривые веб-сервисы не будут ронять реверс проксю.

    И зачем городить такую конструкцию, когда можно вместо второго nginx-а + ssh3 просто поднять openssh (которые и так из коробки везде есть) и горя не знать?

     
  • 4.210, Петрович69 (?), 03:02, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    вдруг даже дети не появляются, им предшествует бурное времяпровождение. только в случае с nginx есть бекап и саппорт. а с детьми - только аборт...
     
     
  • 5.213, Аноним (93), 04:31, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > бурное времяпровождение

    Ты, видимо, никогда с продакшеном дел не имел, и уж, тем более, не разбирался с каскадными отказами.

    > только в случае с nginx есть бекап

    Ага, упал ssh3 - откатываемся из бэкапа. С переустановкой системы, видимо.

    > саппорт

    Саппорт чего? Облака, dedi-хостера или, вообще, датацентра, в котором ты клетку арендовал, что ли? Ты сам саппортишь свои системы, и за тебя проблемы никто решать не будет.

     
  • 2.19, Аноним (19), 12:32, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ALPN, вестимо.
     
  • 2.22, Аноним (22), 13:05, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Например вот так https://habr.com/ru/articles/412779/
     
  • 2.26, Аноним (26), 13:23, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе всё наврали, аноним. TLS termination для http3 пока не стандартизирован.

    Поэтому если у кого и работает, то благодаря грязным трюкам.

     
  • 2.47, Ivan_83 (ok), 15:50, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это просто: nginx примет соединение и дальше через proxy protocol отдаст куда надо.
    У меня так на 443 порту висит сайт, жаббер сервер, стун и опенссш уже сейчас.
    Они не все proxy protocol могут, поэтому кто не может не видит реального IP клиента.
     
  • 2.58, BSDSHNIK (?), 17:05, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    443 нужен только если ты хочешь маскироваться под валидный HTTP никто не мешает использовать тот же 22 напрямую без нжинксов.
     
     
  • 3.85, scriptkiddis (?), 20:26, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Никто кроме поехавших безопасников в компании.
     
  • 2.123, Neon (??), 03:29, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кто первый встал, того и тапки
     
  • 2.238, Alexander Gaiduk (?), 22:20, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кто обязывает демона SSH3 на 443 порту держать, есть много других портов, с виду косящих под web-сервер.
     

  • 1.7, penetrator (?), 12:11, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для шифрования канала связи в SSH3 задействован протокол TLS 1.3, а для аутентификации могут использовать классические методы на базе паролей и открытых ключей (RSA и EdDSA/ed25519). Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеров


    нинужно такое нам, а пароли можно запретить и заменить на аутенфикацию по ключу, конечно остаются вопросы постквантовой криптографии, но они более глобальны

     
  • 1.10, EuPhobos (ok), 12:17, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Теперь ssh гоняем по UDP, а давайте вообще отменим TCP и всё будем гонять по UDP, зачем нам приоритеты трафика, какие-то там sip-звонилки, онлайн игрушки, правильно я понимаю?
     
     
  • 2.12, Ананимус (?), 12:20, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +9 +/
    QUIC это тот же TCP, просто вся логика на уровне выше, что позволяет сделать кучу кейсов, которых не было при проектировании TCP, из коробки.
     
     
  • 3.48, Ivan_83 (ok), 15:51, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вася это Петя, просто имя другое.
     
  • 3.76, timur.davletshin (ok), 19:29, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для этого надо на стороне клиента установить софт... что в общем случае не очень сильно проще установки tcp_supper_algo.ko. QUIC пока что ничего такого не умеет, что было обещано изначально в категории "преимущества перед TCP" (сколько реализаций умеют multipath?). По факту юзаем, но на производительности серверов тех же он сказался негативно. По факту вынесли алгоритм, требующий фиксированного времени отклика (практически реального времени), в пространство пользователя. Я напомню, что основная критика в адрес OpenVPN, который делает то же самое управление потоком и шифрование поверх UDP, заключалась в том, что он реализован в пространстве пользователя и поэтому медленный. Я запутался. Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?
     
     
  • 4.81, Аноним (26), 20:07, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?

    Потому что openvpn не знает, что он передаёт, и потому не может дропать фреймы, а браузер знает, что он передаёт видео.

     
  • 4.109, Ананимус (?), 00:31, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Для этого надо на стороне клиента установить софт... что в общем случае не очень сильно проще установки tcp_supper_algo.ko.

    Чтобы сходить в интернет через tls тебе нужен  openssl, ca-certificates и еще куча срани. Так что ничего особо нового тут не появилось.

    >QUIC пока что ничего такого не умеет, что было обещано изначально в категории "преимущества перед TCP" (сколько реализаций умеют multipath?).

    Все rfc-compliant.

    > Я запутался. Помогите, почему в одном случае вынос в ядро является благом, а во втором злом?

    Не вижу проблемы затолкать quic в ядро. Это будет как sctp, тока на этот раз его кто-то поддержит.

     
     
  • 5.116, Ivan_83 (ok), 01:20, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы.
     
     
  • 6.138, Ананимус (?), 09:20, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Только не всегда это так, есть ещё куча мест где не нужно ходить в инет, всякие роутеры, коммутаторы.

    Роутеры и коммутаторы тоже ходят в интернет, там тоже есть целый ворох библиотек и сертификаты.

    Я не понимаю что ты пытаешься доказать. Что положить сишную либу размером в пару килобайт это проблема? Нет, это не проблема. Нигде, даже в embedded.

     
     
  • 7.146, timur.davletshin (ok), 09:44, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Разупорись, какие пару килобайт? Вы давно размер бинарников этих ваших lib*ssl.so видели? Сертификаты обновлять нужно. Плюс, маленький секрет, есть масса крупных сетей, в которых нет выхода в Интернеты по соображениям безопасности.
     
     
  • 8.176, Ананимус (?), 12:38, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не суй эту библиотеку туда, где не нужен выход в интернет D... текст свёрнут, показать
     
     
  • 9.178, timur.davletshin (ok), 12:59, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Будто я все прошивки сам делаю и OpenWrt уже готов для работы с трафиком небольш... текст свёрнут, показать
     
     
  • 10.183, Ананимус (?), 13:45, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тогда чего ты переживаешь Мейнтейнеры все положат ... текст свёрнут, показать
     
     
  • 11.186, timur.davletshin (ok), 14:35, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы они туда ложЫли, то я бы не переживал ... текст свёрнут, показать
     
  • 7.173, Ivan_83 (ok), 12:33, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я пытаюсь сказать что TLS, рабочая инфраструктура сертификатов и даже правильно выставленное время не очень то и нужны много где, учитывая что есть более простые и более легковесные решения.

    И это, вы попробуйте в 8мб флеша собрать OpenWRT с этим всем, потому что там задолбались и выкинули все такие устройства :)

     
     
  • 8.175, Ананимус (?), 12:38, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот OpenWRT du -sh usr lib libssl so 1 1 524 0K usr lib libssl so 1 1... текст свёрнут, показать
     
  • 3.100, Аноним (100), 22:15, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcongestion control и как его применять?
     
     
  • 4.108, Ананимус (?), 00:27, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему никто из можно-молодежно не может мне ответить где посмотреть на UDP Tcongestion control и как его применять?

    Его нет на уровне UDP, это вынесено на уровень самого QUIC. А дальше открываешь rfc и вперед.

     
     
  • 5.117, Аноним (100), 01:39, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дальше следующий вопрос возникает. Как мне ограничения сделать и разные congestion control на разный трафик? Именно как мне угодно на сервере, клиенте, промежуточном оборудовании? Можно пальчиком показать что трафик обновлений пускаем только на свободную полосу в данный момент, воип максимум быстро пропускаем, а оставшийся хттп не критичен к задержкам и его просто надо доставлять.
     
     
  • 6.129, Аноним (26), 05:38, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я не настоящий сварщик, но можешь попробовать примерно так:

    Во-первых, пускаешь процессы в нужной net_prio cgroup.
    Это должно правильно приоритизировать пакеты "локально".

    Во-вторых, пускаешь процессы в правильной net_cls cgroup, и через nftables выставляешь нужным процессам правильный DSCP код, и на свитчах-роутерах говоришь, каким flow с каким dscp выдавать больший приоритет.

    Поскольку quic шифрован, нельзя выдать разный приоритет разным quic flow, поэтому нужно будет открывать разный flow на разные приоритеты, но по идее, это не проблема.

     
     
  • 7.134, Аноним (26), 08:12, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле, разным connect, а не разным flow, конечно.
     
  • 4.147, timur.davletshin (ok), 09:46, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Кто как хочет, так и ... скачет. У всех свой велосипед придуман. За основу обычно берут стандартные Reno и Cubic. Только у bittorrent обычно LEDBAT (поправьте, если ошибся набором букв), а у VoIP вообще оригинальный велосипед.
     
  • 2.15, Аноним (15), 12:24, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > а давайте вообще отменим TCP и всё будем гонять по UDP

    А давайте. Все к этому и идет.

    > зачем нам приоритеты трафика, какие-то там sip-звонилки, онлайн игрушки, правильно я понимаю

    Неправильно. Никто не мешает настроить приоритеты для различных UDP-потоков.

     
     
  • 3.152, 1 (??), 10:18, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Неправильно. Никто не мешает настроить приоритеты для различных UDP-потоков.

    И как будешь различать "UDP-потоки" ? По IP ?

     
     
  • 4.165, Аноним (26), 11:26, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    По source порту.
     
  • 2.21, Анонус (?), 13:04, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > sip-звонилки

    Голосовой трафик и так по UDP ходит. А по стандарту можно и SIP over UDP настраивать.

     
  • 2.29, Аноним (26), 13:39, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты "почти" всё правильно понимаешь.

    Контроль потока на уровне ядра ОС был вынужденной мерой, когда хотелось просто открыть сокет и писать данные с помощью С write().

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

    Сейчас мир другой, и "прозрачная" (но дырявая) TCP абстракция "надёжного сокета" перестала отвечать реальности.

     
     
  • 3.37, Аноним (37), 14:56, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Спрошу тебя как эксперта по TCP Почему TCP или его преемник не реализован про... большой текст свёрнут, показать
     
     
  • 4.60, Аноним (26), 17:25, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    QUIC по большому счёту и является перепроектированием TCP поверх UDP Если его ... большой текст свёрнут, показать
     
  • 3.39, Аноним (39), 15:09, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Также спрошу, почему-бы не сделать TLS без портов вообще, раз только 443 используется. Вместо порта выбирать сервис по ключу через Diffie-Hellman. Ну в server hello сервер может анонсировать, какие у него есть сервисы. Клиент выполняет диффи-хэллмана, выведенный ключ хэширует той же функцией, что и в сертификате, после чего от хэша берёт остаток от деления на (количество сервисов + 1). Остаток даёт номер сервиса. Если номер сервиса не тот, что нужен - повторить. Сервер делает то же самое с выведенным ключом. Только без брутфорса.
     
     
  • 4.62, Аноним (26), 17:30, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе никто не мешает так сделать. Вернее, сейчас вообще так и делается, только без всякого Диффи-Хеллмана.

    Есть websocket. Подключаешься по https к https://webservice.com/service-name/, service-name пробрасывает websocket, и по этому websocket пиши что хочешь, он шифрован TLS-ом.

     
  • 3.51, Ivan_83 (ok), 16:08, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы себе и близко не представляете что такое современный TCP.

    Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.
    5 строчек в приложении, 8кб скомпиленый бинарник и оно уже работает. Извращенцы даже из баш скриптов научились этим напрямую пользоватся.

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

    Задержки при старте - ну это такое, сильно на любителя. У TCP для этого тоже есть много разного.
    Единственно что реально получилось улучшить это DTLS за счёт прибивания на гвозди размеров пакетов и выраснивания по размеру блоков алгоримов шифрования.

     
     
  • 4.64, Аноним (26), 17:36, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Невозможно оптимально реализовать работу TCP на канале с потерями 80 А мобил... большой текст свёрнут, показать
     
     
  • 5.89, Ivan_83 (ok), 21:23, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1. каналы у которых 80% - не рабочие, в принципе.
    2. в дикой природе это скорее исключение
    3. есть всякие RTSP/RTMP для видео и звука, и даже HLS делает примерно тоже самое по TCP.
    4. Приложений с описанной вами логикой работы по UDP я что то не видел :)
     
     
  • 6.124, Аноним (26), 03:59, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    1. Вы считаете, что нерабочие, и ничего не делаете, а другие люди пишут quic.
    2. Миллиарды людей сидят через каналы с десятками процентов потерь, но хотят смотреть тикток.
    3. Есть, но хочется открывать единственный сокет, и всё передавать через единственное соединение, не разводя зоопарк протоколов. A HLS такая, ну, кривоватая штука.
    4. Откуда вы знаете? Если у вас канал нормальный, скорее всего, вам и не требуется quic, и софт его никогда не включает.

     
     
  • 7.174, Ivan_83 (ok), 12:38, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1. quic написан гуглом ровно для того чтобы пихать рекламу потребителям, и не важно посмотрят они её или нет, главное что деньги гугл за показ спишет.

    2. Не сидят, не нужно сочинять. С таким процентом потерь у них даже DNS будет не очень комфортно работать, и этот ваш quic им опять же не поможет.

    3. Вам хочется - вы и прогайте. )

    4. Покажите примеры за пределами гугла где это используется.

     
     
  • 8.179, Аноним (26), 13:06, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Видите, как мало вы знаете о мире К сожалению, сидят-сидят DNS комфортно и не... текст свёрнут, показать
     
     
  • 9.189, timur.davletshin (ok), 15:53, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Угомонись уже Никак этот твой QUIC не поможет в борьбе с потерями, т к в серве... текст свёрнут, показать
     
  • 9.205, Ivan_83 (ok), 00:55, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я вижу у вас какой то свой мирок с плохим инетом и последней надеждой на чудо-гу... текст свёрнут, показать
     
  • 4.112, Ананимус (?), 00:43, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Обработка TCP в ядре удобна потому что это штатный функционал реализованный максимально оптимально.

    Ахаха нет. DPDK не просто так появился.

     
     
  • 5.206, Ivan_83 (ok), 00:59, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать углы чтобы получить нужную производительность.
     
     
  • 6.222, Ананимус (?), 21:18, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > DPDK, NetMAP и прочие - это очень специфичные решения, когда надо срезать
    > углы чтобы получить нужную производительность.

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

     
  • 4.121, Аноньимъ (ok), 03:25, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Есть ещё сетевухи с аппаратным(не совсем) TCP и tls, что неплохо разгружает ОС в определённых задачах.
     
  • 3.127, all_glory_to_the_hypnotoad (ok), 05:02, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Всегда будет нужно только открыть сокет и писать аналогом write независимо от того, какой мир. Потому что это просто и удобно и большего в приложении не нужно. Кроме того сокетный интерфейс предоставляет кучу ядерных оптимизаций. Когда QUIC взлеит, то и его завернут в обыкновенный сокетный интерфейс. QUIC в конце концов точно такой же надёжный TCP сокет. Реализация находится в юзер спейсе через UDP вовсе не потмоу, что появилось какое-то волшебное управление потоком, а только лишь из-за экспериментального состояния самого протокола и желания побыстрей начать его использовать. Финальная ядерная версия для всех скорее всего будет уже не на UDP, UDP здесь от ~нищеты.
     
     
  • 4.131, Аноним (26), 06:05, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >QUIC в конце концов точно такой же надёжный TCP сокет.

    Далеко не только. Там есть MASQUE extension, DATAGRAM extension.

     
  • 2.41, pda (ok), 15:23, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ещё хуже. Теперь всё гоняем по http. Через один порт. Смысл в остальных портах продолжает падать.

    Технологии куда-то не туда свернули...

     
     
  • 3.43, Аналоговнет (?), 15:36, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А куда ты денешься? Хоть туда, хоть не туда.
     
  • 2.42, Аноним (40), 15:34, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    UDP применяется из-за шифрования (а не размера пакета и подтверждения как можно подумать). Вы и так можете подтвердить приём пакета отправив обратно другой пакет. Вероятнее всего новое оборудование будет отличать разные типы новых протоколов, так-что у таких пользователей с приоритетом трафика ничего не будет. А на старом, оставляете HTTP/TCP более приоритетным и все будет норм с приоритетом http я лично думаю что долгое время.
     
     
  • 3.52, Ivan_83 (ok), 16:10, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А TCP шифровать низя?)
     
     
  • 4.67, Аноним (67), 18:16, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А зачем Вы по моему не понимаете разницу между TCP и UDP раз задаёте такой прос... большой текст свёрнут, показать
     
     
  • 5.69, Аноним (67), 18:41, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Забыл дописать про UDP: https://ru.wikipedia.org/wiki/UDP

    UDP использует простую модель передачи, без явных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных.

    т.е. UDP не обеспечивает надёжность и целостность передачи данных. Вы один запрос делаете в одну сторону и асинхронно обратно другой запрос UDP получите в другую. В отличии от TCP, который сделает внутри тоже самое, только одним запросом обеспечит надежность. И вот UDP в этом плане выигрывает в скорости, но проигрывает в надёжности. Так вот надёжность добавляет шифрование, т.к. прячет данные от мониторинга и MITM, если вы не владелец (американского) реестра сертификатов.

     
     
  • 6.70, Аноним (67), 18:47, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну или проще - вам предлагают кастрюлю с американской лапшой вместо крутых яиц из которых могут вырваться птицы гордо воспарив над интернетом, порождая свои идеи. Вы бы хоть пообсуждали необходимость создания локального реестра сертификаций, если настолько неспособны программировать и создавать железо.
     
  • 5.90, Ivan_83 (ok), 21:25, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Так это вы написали: "UDP применяется из-за шифрования" вот и поясните что не так с TCP в этом плане.
     
  • 2.79, Аноним (79), 20:02, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Всё у вас смешалось, кони, люди Давайте по пунктам 1 В сетях Ethernet по ум... большой текст свёрнут, показать
     
     
  • 3.91, Ivan_83 (ok), 21:36, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1 В сетях эзернет как раз таки есть Flow Control, он реализуется сетевыми адапт... большой текст свёрнут, показать
     
     
  • 4.99, Аноним (93), 22:06, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И работает так прилетает pause frame и передача всего трафика на порту, куда фр... большой текст свёрнут, показать
     
     
  • 5.105, Аноним (79), 23:39, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я немного уточню ваш ответ, с вашего позволения Ну только если брать свежайши... большой текст свёрнут, показать
     
  • 4.115, Аноним (79), 01:11, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    При помощи магии что ли Нет Это требует обязательной настройки QoS, потому что... большой текст свёрнут, показать
     
     
  • 5.118, Ivan_83 (ok), 01:46, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    да, я про него Даже как то пробовал его для DoS у себя в домашней локалке но чт... большой текст свёрнут, показать
     
     
  • 6.168, Аноним (79), 11:37, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А вы там точно сетью занимались Просто каждый провайдер меняет входящую пометку... большой текст свёрнут, показать
     
     
  • 7.172, Ivan_83 (ok), 12:30, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Забавно как вы обобщаете Провайдеры если и заморачиваются QoS то обычно это P... большой текст свёрнут, показать
     
     
  • 8.187, крокодил мимо.. (?), 14:52, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    так что в сухом остатке есть у нас RFC 3168 2001 , согласно которому ECN allo... большой текст свёрнут, показать
     
  • 3.128, all_glory_to_the_hypnotoad (ok), 05:19, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > RPC, удаленный вызов процедур порождает огромное количество соединений в которых служебных данных больше чем полезных. Если нет потока, то TCP мешает и лишний раз грузит ядро ОС глупым разбором заголовков.

    RPC бывает разный и в большинстве случаев с ним таких проблем нет. За многие годы существования сетей были разные попытки позаворвачивать RPC в UDP и никакие из них не были ощутимо лучше заворачивания в TCP. В основном только создавали дополнительный гемор с поддержкой сетевого стека в  пр-ве пользователя.

     
     
  • 4.169, Аноним (79), 12:09, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Всё что вы сказали - всё правда.

    А потом пришел транспорт QUIC и решил эту проблему. В Windows реализация QUIC находится на стороне ядра, TLS там исторически на стороне ядра. Нет никаких проблем. Что там в Linux с QUIC я не берусь судить, лучше вы мне расскажите.

     
     
  • 5.177, Ivan_83 (ok), 12:43, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что то я не припоминаю никаких API для TLS со стороны ядра в венде. Может где то в http.sys и есть, но оно не для всех соединений применимо.

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

     
  • 2.82, Аноним (82), 20:10, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    SIP - это как бы на udp работает, как правило.
     
  • 2.107, Tishka17 (?), 23:52, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дfвайте всё гонять по HTTP, а HTTP гонять по UDP
     

     ....большая нить свёрнута, показать (65)

  • 1.14, cloudchief (ok), 12:24, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    внуки наши скажут - дед, ты офигел ssh2 юзать - ssh3 деплоится с клавиатуры одной клавишей F283 ....
     
     
  • 2.68, Аноним (68), 18:33, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это же какой там уровень радиации что можно спокойно нажать F283?
     
     
  • 3.74, cloudchief (ok), 19:21, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    там всё просто - размер клавиатуры.
     

  • 1.16, Аноним (16), 12:26, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    1. неотличимость от h3-сервера будет только при наличии сертификата, признаваемого в браузерах
    2. протокол переусложнён: зачем-то втащили HTTP. Наверное чтобы "ssh"-сервер было легче ломать.
    3. начешуя вообще SSH поверх HTTP или вебсокет, если подобная задача решается обычным HTTP сервером, который вполне имеет стандартную функциональность для подключения своей серверной логики. После чего код шелла пишется в несколько строчек. На PHP на минималках вообще что-то вроде <?=system($_REQUEST["cmd"]);?> (доступ ограничивается не самим скриптом, а настройками веб-сервера по клиентскому TLS-сертификату)
     
     
  • 2.30, Аноним (26), 13:41, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По пункту 3, у вас тогда процессы будут работать под юзером www, что редко когда нужно.

    Нужно же pam, nsswitch.

     
     
  • 3.32, Аноним (32), 13:52, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не проблема, вместо пользовательской команды напрямую можно вызывать любой другой бинарь, в том числе suid, который задействует какие нужно механизмы, а ему уже передавать команду. Наверняка к ниджинксу и CGI прикрутить можно. Но зачем все эти извращения, включая те, что от авторов ssh3, если можно просто обычным ssh-демоном воспользоваться.
     
     
  • 4.66, Аноним (26), 17:47, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы можете сейчас пробросить TCP-порт через QUIC. Тогда ssh-клиент будет подключаться к локальному TCP порту, ssh будет инкапсулироваться, потом разворачиваться на сервере, и, опять же, локально подключаться к ssh2.

    Но это же нужно туннель на сервере дополнительно поддерживать.

     
  • 2.142, Аноним (-), 09:32, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >1. неотличимость от h3-сервера будет только при наличии сертификата, признаваемого в браузерах

    То есть, был у нас серт ssh, а теперь его будет выдавать регистратор, который одновременно будет оракулом. Ну а что, скот надо держать на цепи.

     

  • 1.17, Аноним (17), 12:29, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как он мультиплексируется с существующим сервером на 443 портом (и сайтами на нем) - непонятно. Если он этого не делает, а городит свой сервер - какое к чертям скрытое использование? Ткнулся на сервер - а там ошибка 404 и подпись ssh3/https. Без палева, да.
     
  • 1.23, Аноним (22), 13:07, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно. С модным QUIC станут ли файлы через всякое SCP передаваться с нормальной скоростью?
     
     
  • 2.86, Anononononon (?), 20:52, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да оно и сейчас нормально передается, если у тебя не 100 Гбп/с

    Ну а то что scp в один поток работает, ну или тот же sshd никак быстро ничинится ибо нинадо никаму

     

  • 1.24, Аноним (24), 13:10, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пакет OpenSSH можно ставить одним из первых. А тут зависимостей гораздо побольше будет. Это скорей дополнение, а не замена.
     
     
  • 2.73, OpenEcho (?), 19:20, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  А тут зависимостей гораздо побольше будет.

       ldd ssh3
    not a dynamic executable

     
     
  • 3.83, OpenEcho (?), 20:20, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя с сервером, - да, завязались на миньёны
     
  • 3.203, Аноним (203), 22:05, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе дае сказали: написано на Goвне
     
     
  • 4.209, _ (??), 01:42, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дык ить в последнее время всё стоящее в основном на нём и пишут... :)
     
  • 4.230, OpenEcho (?), 07:10, 22/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Тебе дае сказали: написано на Goвне

    Я не фаловер, принимаю решения - по факту, а не по тренду, хотя и тренд по ходу в сторону практичного, но ты можешь продолжать писать на QucikBasic

     

  • 1.27, Аноним (26), 13:31, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какой-такой "первый"?

    Уже был ietf rfc: https://datatracker.ietf.org/doc/draft-bider-ssh-quic/

    больше того, на багтрекере openssh его уже просили реализовать.

     
     
  • 2.28, Аноним (26), 13:32, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://bugzilla.mindrot.org/show_bug.cgi?id=3471

    Собственно, ссылка.

     

  • 1.33, An (??), 14:20, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не взлетит.  
     
     
  • 2.35, Sw00p aka Jerom (?), 14:55, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    скорее аукнется боком, ёж-уж
     

  • 1.34, Аноним (34), 14:47, 17/12/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     

  • 1.36, Аноним (36), 14:56, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Разработка SSH3 стала результатом полного пересмотра протокола SSH, проведённого отдельной группой исследователей независимо от OpenSSH и других проектов, развивающих реализации классического протокола SSH

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

     
     
  • 2.216, Второй из Кукуева (?), 09:28, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > известного разработкой подсистемы Multipath TCP и кода сегментной маршрутизации IPv6 для ядра Linux, а также соавтора 10 RFC и черновиков более 60 сетевых спецификаций

    Ничего так "теоретик"

     

  • 1.38, svsd_val (ok), 14:57, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Неплохо, посмотрим как на деле будет...
     
     
  • 2.46, Аноньимъ (ok), 15:47, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как земля.

    Для всех буквально пользователей ssh оно нафиг ненужно.

    Пригодиться может быть для маминых хакиров очень секретных серверов. Но, вот, есть же всякие ВПН и прокси! Незадача.

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

    Ну и перехват авторизации сторонним сервисом прямо в протоколе - просто шик.

     

  • 1.45, Аноньимъ (ok), 15:44, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Кроме того, в SSH3 могут применяться методы на основе протокола OAuth 2.0, позволяющие перекладывать аутентификацию на сторонних провайдеров

    Да, это класс!

    > В SSH3 семантика классического протокола SSH реализована через механизмы HTTP, что позволило

    Мда...

    > реализовать некоторые дополнительные возможности

    А без http уже никак дополнительный возможности не реализовать?

    > Без обращения с корректным идентификатором сервер обработает ответы как обычный HTTPS-сервер

    И для этого ненужно даже городить никакой огород. Ну ладно.

     
     
  • 2.49, Аноним (49), 15:56, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну по поводу авторизации было написано в документе U.S.
    Department of Defense Zero Trust Reference Architecture - DoD CIO, я как-то кидал ссылку (вконце там обычно пераметр с версией, берите последнюю). Так вот там все указано. А какие собственно проблемы? Западным соцсетям, почтовым и поисковым сервисам многие люди уже слили свои же данные ФИО, телефона, почты, порой паспорта, просто фото и геолокацию.
     
  • 2.151, Аноним (151), 10:15, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Да, это класс!

    да, какие проблемы, трепло?

     
     
  • 3.194, anonymous (??), 16:43, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Всегда мечтал об ssh сервере на который нельзя зайти если у кого-то из сторонних провайдеров зачесалась левая пятка.
     

  • 1.50, Ivan_83 (ok), 15:57, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Из новости я так и не понял какое это всё имеет отношение к SSH :)

    Если следовать логике авторов, то там не 3 а 100500 потому что повершелл, winrm, и ещё 100500 разных вебшеллов было изобретено до них.


    Как поделка это не шибко интересно.
    Если хочется мимикрировать под вебтраффик то проще на OpenSSH сервер добавить поддержку Proxy Protocol (Ha proxy авторы), а клиенту прикрутить TLS клиента.
    Дальше по ALPN вебсервер (HA, nginx и пр) смогут легко определять куда перегнать соединение по Proxy Protocol.

    Эта схема и сейчас работает, только без TLS оно палится, а nginx перегоняет весь трафик где TLS заголовка нет на OpenSSH, а OpenSSH не видит от кого реально трафик ибо не умеет Proxy Protocol.

     
  • 1.54, Аноним (54), 16:26, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >использующей QUIC (на базе UDP) и TLS 1.3 для установки защищённого канала связи и механизмы HTTP для аутентификации пользователей

    SSH over HTTPS. Ну что, смузихлёбненько!

     
  • 1.55, microsat (?), 16:51, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    telnet  всех переживет :))))))))))))
     
     
  • 2.198, Аноним (198), 17:30, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    telnet, также как http, безопасники давно побанили во всех более-менее серьезных конторах. Никто кроме васянов им давно не пользуется. С разморозкой.
     
     
  • 3.220, microsat (?), 19:11, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Всё новое не обеспечение безопасности :) Как секюретник вам говорю .. А забытое старое  иногда более безопасно .. не потому что там нет багов  а потому что  уже забыли  что они там были и все  0-day и скрип кидди  настроенны на новые  релизы ... А компилить старые  експлиты   даже  GCC нее дает )))  
    P.s  А так да  да даже Telnet  можно так  шифрануть что даже и неузнаешь что это Telnet  , кроме  того кому надо )))  
     

  • 1.72, InuYasha (??), 19:16, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Невекторный гипертекстовый ССШ. Ну, слушать порт ССЛ - это прям очень круто. Только теперь злоумышленники будут ровно на него и стучаться )
     
     
  • 2.77, OpenEcho (?), 19:30, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > -url-path string
    >     the secret URL path on which the ssh3 server listens (default "/ssh3-term")

    Good luck !

     

  • 1.75, cloudchief (ok), 19:26, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я в своё время, ещё в 90х наверное, видел на пиратке компакт-диск на которм была классная фраза - купить этот диск или не купить - любое ваше решение будет не правильным. Давайте просто посмотрим, как это зайдёт.
    А так - нормально, в nginx есть проксирование почтовых портов, tcp/udp - если nginx сможет отделять роуты от веба до бэкэндов на одном порту на другие сервисы ( наверное это уже есть ), ну профит - на веб-морде у вас сайт, а по роуту https://mysite/динныйнаборговна - проксирование на ssh3
     
     
  • 2.87, Anononononon (?), 21:00, 17/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    взбунтовались со своим ALPN/TLS чота все, как кусок олдовой логики вкину вам старую добрую мысль:


    Разделяй Control-Plane с Application = не вешай управление вместе с трафиком приложения, как firewall потом напишут? (злые сетевеки/безопасники), как подключатся если проксю уронил малолетний реврайтописатель?

    Поделка в целом интересная, но сугубо из за транспортного layer-а, нафига переписывать весь sshd нипонятно. Написали бы адаптер под quic - потом приплагинили бы где то

     
     
  • 3.110, cloudchief (ok), 00:40, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Брат - я очень хорошо понимаю контрол-плейн и дата-плейн, давай без этого?
     
     
  • 4.188, Anononononon (?), 15:12, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А я очень хорошо понимаю, почему эта поделка ненужна, и что ? давай без своего камента там тож (какнибудь)
     

  • 1.78, Аноним (78), 19:51, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Иногда складывается ыпечатление что протоколы отличные от HTTP канут в лету и всё будет через HTTP. Народ скажет что всё что не HTTP слишком сложно а HTTP кроме того что это просто так ещё имеет много других достоинств. Интересно, с чего бы это?
     
     
  • 2.111, cloudchief (ok), 00:41, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А что в этом плохо?
     
     
  • 3.141, Аноним (-), 09:29, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Плохого в этом оверхед и невозможность сколько-либо работать без библиотек http, а не на голых сокетах.
     
  • 2.130, all_glory_to_the_hypnotoad (ok), 05:41, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    HTTP сложный и неудобный протокол, ничего такого не будет только если не придётся обманывать какой-нибудь роскомпозор для мимикрии под обычный трафик
     
  • 2.234, Sem (??), 07:07, 23/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но QUIC вообще не HTTP. Вообще ничем не похож. Я бы сказал - он полная противоположность.
     

  • 1.80, OpenEcho (?), 20:06, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Все б ничего, но весь смак Го сломали с unsafe и Import "C" в сервере :(
     
  • 1.94, Аноним (94), 21:56, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А скачать большой файл можно будет? 150Гб? Меня когда дядя Гугль выставлял на мороз, разрешал забрать свои шмотки в коробках по 2 Гб или tar по 50 Гб. То есть даже у всесильного дяди были проблемы с передачей больших файлов. sftp подымается моментом, и большие файлы передать может.
     
  • 1.95, Аноним (95), 21:58, 17/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Не знаю зачем это вообще всё нужно. Telnet на 110% справляется со своими задачами. Всё равно никто не светит голые порты, всё удалённое администрирование осуществляется через VPN.
     
     
  • 2.119, Ivan_83 (ok), 01:48, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я SSH использую как VPN.
     
     
  • 3.163, InuYasha (??), 11:15, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Я SSH использую как VPN.

    А он VPN использует как SSH :D

     
     
  • 4.215, Аноним (-), 05:17, 19/12/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.145, Пряник (?), 09:40, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Скажи это тысячам ботов, долбящихся по SSH на любой внешний IP.
     

  • 1.113, cloudchief (ok), 00:45, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не вижу в этом ничего плохого. Если зайдёт - вы потом  датаплейном будете хвалить - я этот тред сохраню - я вижу лично плюсы - но использовать на текущий момент не буду. Это 0.1.0 - помните как беты? Да, клёво, но подождём)
    Я старпёр, 50+ но вижу профит. Извините.
     
  • 1.114, cloudchief (ok), 00:51, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Самое хреновое - это оставаться на ровной жопе. Не движешься - ты в дроп, ну или в реджект, что более болезненно.
     
  • 1.120, Имя Моё (?), 02:57, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Go. Очень жаль. Ф топку.
    Идея классная, поэтому ждём реализации на Си.
     
     
  • 2.125, Аноним (26), 04:21, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    На Си++
     
     
  • 3.199, Имя Моё (?), 19:21, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет. Вот почему https://www.google.com/search?q=c%252B%252B+vs+c+performance
     
  • 2.144, Пряник (?), 09:38, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Заодно и увидим, что в их представлении "эталон".
     
  • 2.164, InuYasha (??), 11:17, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Этого стоило ожидать при чтении "HTTP".
    HTTP & Go. Stop working, have a REST. Современный мир.
     

  • 1.132, Анонимщик (?), 06:08, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    На этом сайте мюсамое большое собрание нытиков Рунета. Чувак просто написал диплом, а местные эксперты уже начали его поделие прикладывать к своим локалхостам, как будто бы sshd с завтрашнего дня депрекейтят.
     
     
  • 2.133, Аноним (2), 07:56, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чувак лишь исполнитель и кодер прототипа, проект двигает Olivier Bonaventure, которому за один Multipath TCP уже можно памятник ставить.
     
     
  • 3.135, Аноним (26), 08:16, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У вас реально работает mptcp? Да ну, расскажите.
     
  • 2.140, Аноним (-), 09:28, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Чувак просто написал диплом

    Если бы он назвал его hssh - было бы ничего, а он замахнулся закопать ssh2.

     
     
  • 3.154, Аноним (151), 10:24, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    додододо, проблема именно в названии, а не тотальном лицемерии местных д3генератов
     

  • 1.136, Аноним (136), 09:04, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Сетевые протоколы свернули не туда.
     
  • 1.139, Аноним (-), 09:27, 18/12/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     
  • 1.148, Пряник (?), 09:53, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жесть. Предлагается сделать веб-сервер точкой входа администратора сервера? Или это SFTP для погромистов сайтов будет?
     
     
  • 2.235, Sem (??), 07:11, 23/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Господи, каким местом вы читаете? Каким думаете?
     
     
  • 3.236, Пряник (?), 11:59, 25/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А ты не понял? На 80 и 443 порту будет висеть и принимать SSH3 соединения один процесс - Web-сервер, то есть Nginx, например. Заниматься мультиплексированием соединений никто не будет. таким образом безопасность сервера зависит от веб-сервера. Конечно, root или sudo никто там не разрешит. А что ещё можно через SSH делать? Файлики сайта заливать.
     

  • 1.149, nox. (?), 10:09, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    http под root? Ну успехов.
     
     
  • 2.160, Аноним (160), 10:44, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в чем проблема?
     
     
  • 3.166, 1 (??), 11:29, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    вотименна !
    Диды в DOS сидели с полными правами и ничего !
     
     
  • 4.181, Аноним (181), 13:12, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    нет связи, http сам по себе ничем не хуже в плане безопасности, чем сырые сокеты
     
     
  • 5.223, Дмитрий (??), 08:49, 20/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как фаерволить этот трафик?
    Отделить админов от веб пользователей?
    В Энтерпрайзе у ssh3 на мой взгляд нету шансов.
     

  • 1.155, keydon (ok), 10:33, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Просто проект с модным названием и с таким же успехом mosh https://github.com/mobile-shell/mosh мог бы назваться ssh4
     
  • 1.190, rvs2016 (ok), 16:11, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > При использовании SSH3 сервер неотличим
    > от HTTP-сервера и принимает запросы
    > на 443 сетевом порту (HTTPS),
    > а трафик SSH3 сливается с типовым HTTP-трафиком,
    > что затрудняет проведение атак, связанных
    > со сканированием портов и выявлением
    > SSH-серверов для подбора паролей.

    А также приём запросов SSH "на 443 сетевом порту (HTTPS)" затрудняет приём запросов на этом же порту веб-сервером.

    Как теперь одновременно на этом порту принимать запросы и SSH, и обычного HTTPS?

     
     
  • 2.207, Ivan_83 (ok), 01:06, 19/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да легко.
    ssl_preread, дальше мап по версии тлс, если версии нет - отдаём в приложение по умолчанию которое жуёт данные без TLS.
     

  • 1.196, Аноним (198), 17:21, 18/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А разве SSH не стандартизован? Ну то есть разрабатывать его должна рабочая группа и выхлоп должен быть в виде RFC. А тут какой-то дьякон и его служка за всех решили.
     
     
  • 2.202, Аноним (202), 20:45, 18/12/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    этот дьякон стоит нескольких твоих рабочих групп
     

  • 1.221, uis (??), 20:39, 19/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень сомнительно. Если цель действительно скрыться, то надо использовать Pluggable Transport, а не эту порнографию которою после того как начинают обнаруживать надо переписывать заново стандарт.
     
     
  • 2.226, swarus (ok), 14:50, 21/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    согласен, но зачем называть порнографией если не стоит задачи скрываться
     

  • 1.227, Sem (??), 20:33, 21/12/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Попробовал. Совсем сыро, на уровне прототипа. Плюс, в текущей реализацией плохо с безопасностью: I want users to be aware of the risks of deploying public instances for sure and there may exist unknown issues with the current implem.

    Кто-то решил поиграться с QUIC  на go и его тут же потащили на опеннет.

     
     
  • 2.232, Аноним (232), 03:36, 23/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну концепт интересный потом кто серьезный может перепишет на Rust
     
     
  • 3.237, Аноним (237), 20:53, 26/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, желательно сделать так, чтобы шансов взлететь у этого в принципе не было.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру