Jaka jest różnica między SSL a SSH? Który jest bezpieczniejszy?

SSL i SSH zapewniają kryptograficzne elementy do budowy tunelu do transportu poufnych danych ze sprawdzoną integralnością. W tym przypadku używają podobnych technik i mogą być narażone na tego samego rodzaju ataki, więc powinny zapewniać podobne bezpieczeństwo (tj. dobre zabezpieczenia), zakładając, że oba są prawidłowo zaimplementowane. To, że oba istnieją, jest rodzajem syndromu NIH : programiści SSH powinni byli ponownie użyć SSL dla części tunelu (protokół SSL jest wystarczająco elastyczny, aby pomieścić wiele odmian, w tym nie używaj certyfikatów).

Różnią się one tym, co jest wokół tunelu. SSL tradycyjnie używa certyfikatów X.509 do ogłaszania kluczy publicznych serwera i klienta; SSH ma swój własny format. Ponadto, SSH zawiera zestaw protokołów dla tego, co dzieje się wewnątrz tunelu (multipleksowanie kilku transferów, przeprowadzanie uwierzytelniania opartego na hasłach w tunelu, zarządzanie terminalami …), podczas gdy w SSL nie ma czegoś takiego lub dokładniej, gdy takie rzeczy są używane w SSL, nie są uważane za część SSL (na przykład podczas uwierzytelniania HTTP opartego na haśle w tunelu SSL mówimy, że jest to część „HTTPS”, ale to naprawdę działa w sposób podobny do tego, co dzieje się z SSH).

Koncepcyjnie możesz wziąć SSH i zastąpić część tunelu częścią z SSL. Możesz także wziąć HTTPS i zastąpić SSL przez SSH-with-data-transport i hook, aby wyodrębnić klucz publiczny serwera z jego certyfikatu. Nie ma naukowej niemożliwości, a jeśli zostanie wykonana prawidłowo, bezpieczeństwo pozostanie takie samo. Jednak nie ma powszechnego zestawu konwencji ani istniejących narzędzi do tego.

Więc nie używamy SSL i SSH do tych samych celów, ale to z powodu narzędzi, które historycznie pojawiały się wraz z implementacjami tych protokoły, nie ze względu na różnice związane z bezpieczeństwem. A kto wdraża SSL lub SSH, powinien sprawdzić, jakiego rodzaju ataki zostały wypróbowane na obu protokołach.

Komentarze

• Dobra robota. Faktycznie, ponieważ SSH jest łatwiejsze do skonfigurowania niż SSL, wiele osób tuneluje http (nie https) wewnątrz SSH, np. aby zdalnie administrować systemem za pomocą sieci Narzędzie GUI, takie jak ebox lub webmin.
• Aby zaznaczyć, ' nie jest do końca prawdą, że faceci z SSH ” powinien ” używał SSL: protokół SSH został specjalnie zaprojektowany, aby mieć niewielką powierzchnię ataku i być bardzo bezpieczny. SSHv2 nie ma żadnych problemów i pułapki w SSL / TLS, więc idąc z mniejszą rzeczą, że u dobrze rozumiejąc, z mniejszą złożonością, wyszli z czymś znacznie lepiej dopasowanym do ich sytuacji. To zależy od tego, jak bardzo jesteś paranoikiem: SSL nie jest ' nie nadaje się do użytku w zależności od aplikacji, ale SSH ' jest akceptowalny w sytuacjach / społeczności bezpieczeństwa, w których SSL po prostu nie jest zaufany.
• @NicholasWilson ” SSH ' jest akceptowalny w sytuacjach / społecznościach bezpieczeństwa, w których SSL po prostu nie jest zaufany ” taki jak …
• SSL i SSH zostały opracowane równolegle (oba zostały wydane w 1995 roku), więc czy SSH nawet mógł użyć SSL nie jest jasne. To, czy powinno używać współczesnego SSL 2.0, jest również bardzo wątpliwe 🙂
• Cóż, SSH 2.0 było całkowitym przepisaniem protokołu i pojawiło się około 1999 roku, więc można było ponownie wykorzystać SSL 3.0 lub nawet TLS 1.0. Ale oczywiście TLS wydaje się być powiązany z X.509, co odstrasza programistów.

Nie jest to rozsądne porównanie. SSL to ogólna metoda ochrony danych przesyłanych w sieci, podczas gdy SSH to aplikacja sieciowa do logowania się i udostępniania danych komputerowi zdalnemu.

Ochrona warstwy transportowej w SSH jest podobna pod względem możliwości do SSL, więc to, która jest „bezpieczniejsza”, zależy od tego, czego wymaga Twój konkretny model zagrożenia i czy implementacje każdego z nich rozwiązują problemy, z którymi próbujesz sobie poradzić.

SSH ma wtedy warstwę uwierzytelniania użytkownika, której brakuje SSL (ponieważ nie potrzebuje go – SSL musi tylko uwierzytelnić dwa interfejsy łączące, co może również zrobić SSH). W sztuce UTF-8:

 SSL SSH +-------------+ +-----------------+ | Nothing | | RFC4254 | Connection multiplexing +-------------+ +-----------------+ | Nothing | | RFC4252 | User authentication +-------------+ +-----------------+ | RFC5246 | | RFC4253 | Encrypted data transport +-------------+ +-----------------+ 

Jeśli chodzi o problem, na który jest więcej potencjalnych ataków, wydaje się jasne, że SSH ma większą powierzchnię ataku. Ale to tylko dlatego, że SSH ma całą aplik acji wbudowanej: powierzchnia ataku SSL + niezależnie od aplikacji, którą musisz dostarczyć , nie może zostać porównana, ponieważ nie mamy wystarczających informacji.

Komentarze

• -1 To rozsądne porównanie. Błędnie założyłeś, że OP porównuje SSL z programem unixowym ssh (1) . W rzeczywistości SSH jest kolejnym protokołem zapewniającym bezpieczeństwo warstwy transportowej, który tak się składa, że ma specjalne przepisy dotyczące zdalnych powłok i zdalnego wykonywania.
• +1 @jpillora Zgadzam się, że porównanie tych dwóch ma sens, termin SSH to nie jest zwykle używany w odniesieniu do podzbioru protokołu SSH, który obsługuje zabezpieczenia warstwy transportowej, które byłyby bezpośrednio porównywalne z SSL / TLS. Jest używany prawie wyłącznie w odniesieniu do protokołu warstwy aplikacji, który różni się od SSL / TLS sposobem opisanym w tej odpowiedzi.
• @freb sposób, w jaki ' ponowne odniesienie się ogólnie nie zmienia prawdy w tej sprawie. SSH to protokół używany jako warstwa transportowa dla narzędzia ssh. Zaakceptowana i najczęściej głosowana odpowiedź odzwierciedla ten fakt.
• @jpillora Po prostu miałem na myśli, że ' nie sądzę, że protokół warstwy transportowej SSH jest tym, co większość ludzi miałaby na myśli biorąc pod uwagę sformułowanie pytania. Jednak biorąc pod uwagę odpowiedź, która została zaakceptowana jako poprawna, to musiało być to, o co pytał OP.
• @freb Tak, większość ludzi uważa, że biorąc pod uwagę sformułowanie, jeszcze ważniejsze jest poprawienie tego częstego błędne przekonanie.

Ze ścisłego kryptograficznego punktu widzenia oba zapewniają uwierzytelnione szyfrowanie, ale w dwóch różne sposoby.

SSH używa tak zwanego Encrypt-and-MAC, to znaczy zaszyfrowanej wiadomości jest zestawiona z kodem uwierzytelniania wiadomości (MAC) przejrzystej wiadomości w celu dodania integralności. Nie udowodniono, że jest to zawsze w pełni bezpieczne (nawet jeśli w praktycznych przypadkach powinno wystarczyć).

SSL używa MAC-then-Encrypt: adres MAC jest zestawiony z czystym tekstem, a następnie oba są zaszyfrowane . To też nie jest najlepsze, ponieważ w przypadku niektórych trybów szyfru blokowego części MAC można odgadnąć i ujawnić coś na szyfrze. Doprowadziło to do powstania luk w zabezpieczeniach TLS 1.0 (atak BEAST).

Obie mają więc potencjalne teoretyczne słabości. Najsilniejszą metodą jest Encrypt-then-MAC (dodaj MAC zaszyfrowanej wiadomości), która jest zaimplementowana np. W IPsec ESP.

Komentarze

• SSH ' binarnym protokołem pakietów jest szyfrowanie i MAC, gdzie dla każdej wiadomości w postaci zwykłego tekstu (m) wysyła szyfrowany tekst E (m) ++ MAC (m) (łączenie zaszyfrowane wiadomość z MAC), w porównaniu z SSL, który robi E (m ++ MAC (m)). Jednak SSH to znacznie więcej niż tylko binarny protokół pakietowy (zarządzanie kluczami, zdalny klient / serwer powłoki, transfer plików itp.), Podczas gdy SSL (obecnie nazywany TLS) to tylko protokół warstwy transportowej, który jest używany w innych protokołach, które dodają w niezbędnej funkcjonalności (np. HTTPS, FTPS, IMAPS itp.). Zobacz także porównanie EtM, E & M, MtE pod adresem: crypto.stackexchange.com / questions / 202
• W pełni się zgadzam, jest o wiele więcej niż to, co napisałem; że ' miałem na myśli, mówiąc o moim incipit ” ze ścisłego kryptograficznego punktu widzenia „.
• BEAST nie jest związane z MtE i jest spowodowane znanym IV z CBC (w SSL3 i TLS1.0) – co też robi SSH2 i nie poprawiło, chociaż otrzymał CTR jako alternatywę, zanim zarówno on, jak i TLS otrzymały AEAD = GCM (TLS również CCM) (i oba ChaCha / Poly) jako lepszą alternatywę. Ataki oparte na wypełnieniu MtE + CBC to POODLE i Lucky13.
• Mam rozwiązanie, które sprawia, że MAC-then-Encrypt jest bezpieczny dla każdego szyfru, który ma rozmiar wyjściowy = rozmiar wejściowy i brak słabych danych wejściowych do szyfru core.
• ta odpowiedź jest nieaktualna, ponieważ nie jest to tym, co robi dzisiaj TLS.

Myślę, że jest jeden aspekt tego porównania, który został przeoczony. user185 zbliżył się, ale nie do końca tam dotarł. Zgadzam się, że są to jabłka i pomarańcze i uważam, że lepsze porównanie jabłek z jabłkami to HTTPS i SSH. HTTPS i SSH wykorzystują różne warstwy modelu OSI i dlatego szyfrują dane w różnych razy w transmisji. Wtedy prawdziwe pytania, które należy zadawać, będą brzmiały następująco: kiedy te dane są zaszyfrowane i niezaszyfrowane podczas transmisji. To ujawni potencjalne powierzchnie ataku. Dzięki HTTPS, gdy pakiet zostanie odebrany przez urządzenie w sieć docelowa (serwer WWW, router brzegowy, system równoważenia obciążenia itp.) jest niezaszyfrowana i spędza resztę swojej podróży w postaci zwykłego tekstu. Wielu twierdzi, że nie jest to wielka sprawa, ponieważ ruch odbywa się wewnątrz tym razem, ale jeśli ładunek zawiera poufne dane, jest przechowywany w postaci niezaszyfrowanej w plikach dziennika każdego urządzenia sieciowego, przez które przechodzi, aż dotrze do miejsca docelowego. W przypadku protokołu SSH zwykle określa się urządzenie docelowe, a transmisja jest szyfrowana, dopóki nie dotrze do tego urządzenia. Istnieją sposoby ponownego zaszyfrowania danych HTTPS, ale są to dodatkowe kroki, o których większość zapomina podczas implementowania rozwiązania HTTPS w swoim środowisku.

ssh jest jak klucz (prywatny), a zamek (publiczny)

ssl jest jak drzwi i cegły.

ssl zapewnia bezpieczne połączenie między dwa serwery komputerowe. np. Twój i ten, z którym się łączysz.

ssh to sposób, w jaki łączący się komputer może zweryfikować się i uzyskać dostęp.

Komentarze

• W ogóle nie wyjaśniasz komentarza ” drzwi i cegieł „. SSL ma również klucze publiczne i prywatne. SSL może być również używany do uwierzytelniania klienta. SSH zapewnia również bezpieczne łącze między klientem a serwerem.

SSL to warstwa protokołu, która jest wyodrębniony z tunelowanej treści. SSH to bezpieczna wersja powłoki (SH), nie została zaprojektowana do umieszczania pod nią warstwy abstrakcyjnej, została zaprojektowana specjalnie do przenoszenia ruchu powłoki. Więc chociaż operacje kryptograficzne są używane w obu, a te operacje kryptograficzne mogą być nawet takie same, cel i ogólny projekt są zupełnie inne.

Pamiętaj, że istnieją pewne różnice (jak wspomniano powyżej ), ale większość, jeśli nie wszystkie, różnice wynikają z przeznaczenia różnych protokołów.

Komentarze

• -1 Błędnie przyjmujesz założenie ten OP porównuje SSL z programem unixowym ssh (1) . W rzeczywistości SSH jest kolejnym protokołem zapewniającym bezpieczeństwo warstwy transportowej, który ma specjalne przepisy dotyczące zdalnych powłok i zdalnego wykonywania.

Jeśli naprawdę szukasz połączenia SSH i SSL (TLS), odpowiedzią jest SSH.

Jednym z powodów, dla których SSH wygrywa nad SSL, jest sposób przeprowadzania uwierzytelniania. Z tego powodu podczas korzystania z FTP należy używać protokołu SSH (SFTP) zamiast FTPS (FTP przez SSL).

SSH jest używany w sieciach korporacyjnych do:

• zapewnienie bezpiecznego dostępu dla użytkowników i zautomatyzowanych procesów
• interaktywne i automatyczne przesyłanie plików
• wydawanie poleceń zdalnych

źródło: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

Komentarze

• ” Z jednego powodu SSH wygrywa z SSL to sposób, w jaki przeprowadza uwierzytelnianie ” Czy masz źródło lub wyjaśnienie tego stwierdzenia?
• W SSH masz dwie opcje połączenia z serwerem. W przypadku opcji uwierzytelniania opartego na kluczach należy najpierw wygenerować klucz prywatny SSH i klucz publiczny. To niewiele dodatkowej pracy. Należy również wziąć pod uwagę najlepsze praktyki bezpieczeństwa. SSL ma tak wiele wersji, że najnowsza to TLS1.2.Co oznacza, że ' nie jest jeszcze tak bezpieczny, ale jest w trakcie ulepszania.
• TLS również ma certyfikaty po stronie klienta. Nie wyjaśniasz, dlaczego SSH ” wygrywa „.
• Jeśli masz zamiar kopiować / wklejać skądś, upewnij się, że cytujesz swoje źródło.
• ” SSL ma tak wiele wersji ” Tak więc 6 wersji to ” tak wielu „? OpenSSH działa w wersji 7.7. ” Co oznacza, że ' nie jest jeszcze tak bezpieczne, ale jest w trakcie ulepszania. ” Twoja logika nie ma tu sensu.

Problem jest dwojaki. to nie tylko siła i słabość szyfrowania, ale także łatwość i wygoda dostarczania. Z biznesowego punktu widzenia SSL / TLS jest wygodniejszy i łatwiejszy, ponieważ wymaga tylko przeglądarki i publicznego lub prywatnego certyfikatu.

A SSH wymaga zainstalowania aplikacji lub cienkiego klienta, aby z niego korzystać. Jest to większy problem z punktu widzenia i obsługi klienta internetowego użytkownika.