Następna wersja eksperymentalna implementacji serwera i klienta dla protokołu SSH3 jest już dostępna, zbudowana na protokole HTTP/3, wykorzystująca QUIC (oparty na UDP) i TLS 1.3 do nawiązywania zabezpieczonego połączenia oraz mechanizmy HTTP do autoryzacji użytkowników. Projekt jest rozwijany przez François Michela, doktoranta Katolickiego Uniwersytetu Lyońskiego (Belgia), przy współpracy z Olivierem Bonaventure, profesorem tego samego uniwersytetu, znanym z rozwoju podsystemu Multipath TCP oraz kodu segmentacji routingu IPv6 dla jądra Linux, a także współautora 10 RFC i roboczych wersji ponad 60 specyfikacji sieciowych. Kod referencyjnej implementacji klienta i serwera został napisany w języku Go i jest rozpowszechniany na licencji Apache 2.0.
Rozwój SSH3 jest wynikiem gruntownego przeglądu protokołu SSH, prowadzonego przez niezależną grupę badawczą, niezwiązaną z OpenSSH ani innymi projektami rozwijającymi implementacje klasycznego protokołu SSH. W SSH3 semantyka klasycznego protokołu SSH została zrealizowana za pomocą mechanizmów HTTP, co umożliwiło wprowadzenie dodatkowych funkcji oraz ukrycie aktywności związanej z SSH wśród innych danych.
Podczas korzystania z SSH3 serwer nieodróżnialny jest od serwera HTTP i przyjmuje żądania na porcie sieciowym 443 (HTTPS), a ruch SSH3 zlewa się z typowym ruchem HTTP, co utrudnia przeprowadzanie ataków związanych z skanowaniem portów oraz wykrywaniem serwerów SSH w celu łamania haseł. W celu zwiększenia trudności ataków na serwery SSH3, poza znajomością istnienia serwera na danym adresie IP, może być podany sekretna ścieżka identyfikacyjna serwera SSH3. Bez poprawnego identyfikatora serwer zareaguje na zapytania jak zwykły serwer HTTPS i nie ujawni możliwości połączenia przez SSH3. Na przykład, mając identyfikator „e6ae772cbdaafd6918865cc2ce449dae”, można połączyć się z serwerem tylko przez URL „https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae”, a w przypadku podania niepoprawnego identyfikatora, serwer zwróci standardowy błąd „404”.
W zaawansowanej funkcjonalności SSH3 wspomniano o możliwości używania do uwierzytelniania certyfikatów X.509 oraz metod OAuth 2.0/OpenID Connect, oprócz klasycznych metod SSH; wsparcie dla przekierowywania portów UDP przez tunel SSH obok możliwości przekierowywania portów TCP (na przykład, do przekazywania QUIC, DNS i RTP); wykorzystanie rozszerzonych funkcji protokołu QUIC, takich jak migracja połączeń bez przerywania połączenia i ustanawianie połączeń multipath w celu rozłożenia ruchu na wiele tras.
Osobno podkreślono znaczne skrócenie czasu na nawiązanie połączenia przy użyciu SSH3. Przy łączeniu z serwerem SSH3 konieczne jest wykonanie tylko 3 iteracji sieciowych (Round Trip), podczas gdy dla SSHv2 przeprowadza się 5-7 iteracji wymiany pakietów. Czas reakcji na wpisywanie z klawiatury dla już nawiązanych sesji w SSH3 i SSHv2 jest na tym samym poziomie.
Do szyfrowania kanału komunikacyjnego w SSH3 wykorzystano protokół TLS 1.3, a do uwierzytelniania można stosować klasyczne metody oparte na hasłach i kluczach publicznych (RSA i EdDSA/ed25519). Co więcej, w SSH3 mogą być stosowane metody oparte na protokole OAuth 2.0, pozwalające przenieść uwierzytelnianie na zewnętrznych dostawców, na przykład do logowania z potwierdzeniem przez konta w usługach Google, Microsoft i GitHub. Przy łączeniu z serwerami za pomocą kluczy, oprócz kluczy SSH, można stosować certyfikaty X.509 stosowane dla HTTPS.
Opublikowana implementacja klienta i serwera SSH3 wspiera wiele podstawowych funkcji OpenSSH, w tym:
- Wsparcie dla pliku ~/ .ssh / authorized_keys z ustawieniami kluczy na serwerze.
- Możliwość korzystania z pliku konfiguracyjnego ~/ .ssh / config po stronie klienta. Obecnie wspierane są parametry Hostname, User, Port i IdentityFile, a pozostałe są ignorowane.
- Wsparcie dla uwierzytelniania połączenia z serwerem na podstawie certyfikatów.
- Wsparcie dla mechanizmu known_hosts (w sytuacjach, kiedy nie używane są certyfikaty X.509).
- Wsparcie dla pracy klienta z OpenSSH Agent (ssh-agent) oraz automatyczne wykorzystanie agenta do uwierzytelniania za pomocą kluczy publicznych.
- Wsparcie dla funkcji przekierowywania przez SSH-agent w celu wykorzystania lokalnych kluczy na zewnętrznym serwerze.
- Bezpośrednie przekazywanie portów TCP.
Źródło: opennet.ru
