Streszczenie:

W tym artykule zbadamy różnice między protokołami SSL i SSH. Omówimy kluczowe punkty na temat tego, jak działają, koncepcja szyfrowania, szyfrowania symetrycznego i asymetrycznego, wymiany kluczy, podpisów cyfrowych i organów certyfikatów. Wyjaśnimy również użycie skrótów kryptograficznych w bezpiecznych protokołach.

Kluczowe punkty:

1. SSL używa uwierzytelniania opartego na certyfikatach, a SSH opiera się na procesie uwierzytelniania nazwy użytkownika/hasła.
2. Szyfrowanie to proces kodowania informacji, aby zabezpieczyć je przed nieautoryzowanym dostępem.
3. Symmetryczne szyfrowanie klucza używa tego samego klucza zarówno do szyfrowania, jak i deszyfrowania.
4. Asymetryczne szyfrowanie klucza, znane również jako szyfrowanie klucza publicznego, używa pary klucza składającego się z klucza prywatnego i klucza publicznego.
5. Szyfrowanie klucza publicznego umożliwia bezpieczną wymianę kluczy i bezpieczne wiadomości między stronami.
6. Symmetryczne szyfrowanie jest szybsze niż szyfrowanie klucza publicznego, więc jest często używane do szyfrowania danych masowych.
7. Podpisy cyfrowe używają szyfrowania klucza publicznego, aby zweryfikować autentyczność i integralność wiadomości.
8. Władze certyfikatów zapewniają stowarzyszenie kluczy publicznych z prawowitych właścicieli.
9. Algorytmy skrótu kryptograficzne są używane do kontroli integralności danych w bezpiecznych protokołach.
10. SSL/TLS i SSH są szeroko stosowane bezpieczne protokoły sieciowe do ochrony danych podczas transmisji.

Pytania:

1. Czym różni się SSL od SSH pod względem uwierzytelniania?

SSL używa uwierzytelniania opartego na certyfikatach, a SSH opiera się na procesie uwierzytelniania nazwy użytkownika/hasła.

2. Co to jest szyfrowanie i jaki jest jego cel?

Szyfrowanie to proces kodowania informacji, aby zabezpieczyć je przed nieautoryzowanym dostępem. Jego celem jest zapewnienie poufności i integralności danych.

3. Co to jest szyfrowanie klucza symetrycznego?

Symmetryczne szyfrowanie klucza używa tego samego klucza zarówno do szyfrowania, jak i odszyfrowania danych.

4. Jak działa szyfrowanie klucza publicznego?

Szyfrowanie klucza publicznego, znane również jako szyfrowanie asymetryczne, używa pary kluczowej składającej się z klucza prywatnego i klucza publicznego. Klucz publiczny jest używany do szyfrowania, podczas gdy klucz prywatny jest używany do odszkodowania.

5. Jaka jest zaleta szyfrowania klucza publicznego?

Szyfrowanie klucza publicznego umożliwia bezpieczne wiadomości i wymianę kluczów między stronami bez potrzeby udostępniania tajnego klucza.

6. Dlaczego szyfrowanie symetryczne jest wykorzystywane do szyfrowania danych masowych?

Symmetryczne szyfrowanie jest szybsze niż szyfrowanie klucza publicznego, dzięki czemu jest bardziej wydajne do szyfrowania dużych ilości danych.

7. Jakie są podpisy cyfrowe?

Podpisy cyfrowe używają szyfrowania klucza publicznego, aby zweryfikować autentyczność i integralność wiadomości. Zapewniają, że wiadomość nie została zmodyfikowana i rzeczywiście została podpisana przez zgłoszonego nadawcy.

8. Jaka jest rola organów certyfikatów?

Władze certyfikatów zapewniają stowarzyszenie kluczy publicznych z prawowitych właścicieli. Wydają certyfikaty cyfrowe, które zawierają informacje o kluczach publicznych i weryfikują tożsamość posiadacza certyfikatu.

9. Do czego służy algorytmy skrótu kryptograficzne?

Algorytmy skrótu kryptograficzne są używane do kontroli integralności danych w bezpiecznych protokołach. Generują unikalną wartość skrótu dla danego wejścia, umożliwiając odbiorcy weryfikację, czy dane zostały zmodyfikowane.

10. Do czego służy SSL/TLS i SSH?

SSL/TLS i SSH są szeroko stosowane bezpieczne protokoły sieciowe do ochrony danych podczas transmisji. SSL/TLS jest powszechnie używany do bezpiecznej komunikacji internetowej, podczas gdy SSH jest używany do bezpiecznego dostępu zdalnego i transferów plików.

SSL vs SSH-niezbyt techniczne porównanie

4. SSH używa procesu uwierzytelniania nazwy użytkownika/hasła do ustanowienia bezpiecznego połączenia, podczas gdy SSL tego nie rozważa.

Jak pracują SSL, TLS, SSH

W tym artykule badano, jak działają bezpieczne protokoły sieciowe. Wyjaśni kluczowe pojęcia, takie jak szyfrowanie, skróty kryptograficzne i szyfrowanie kluczy publicznych. Zostaną zbadane dwa najpopularniejsze bezpieczne protokoły sieciowe, SSL/TLS i SSH, a ich bezpieczne odpowiedniki przesyłania plików, FTP i SFTP zostaną opisane i porównane.

Co to jest szyfrowanie?

Szyfrowanie to proces kodowania informacji w taki sposób, że tylko strony upoważnione do odczytania zaszyfrowanych informacji są w stanie je przeczytać. Jego celem jest zapewnienie bezpieczeństwa informacji przed podsłuchami lub tajnymi.

Informacje niezaszyfrowane są znane jako tekst zwykły, podczas gdy zaszyfrowana informacja nazywana jest tekstem szyfrowym. Aby uzyskać prosty tekst z tekstu szyfru, wymagany jest klucz szyfrowania, a tylko autoryzowane strony mają kopię klucza szyfrowania. Proces kodowania jest znany jako algorytm szyfrowania. Algorytm został zaprojektowany w taki sposób, że odszyfrowanie zwykłego tekstu bez klucza nie było praktycznie możliwe.

Istnieją dwa główne typy szyfrowania – szyfrowanie klucza symetrycznego i asymetryczne lub szyfrowanie klucza publicznego.

Symmetryczne szyfrowanie klucza

W szyfrowaniu symetrycznym klawisz używany do szyfrowania zwykłego tekstu i klawisz używany do odszyfrowania szyfrujnika jest taki sam. Oznacza to, że dwie strony (nadawca i odbiorca) muszą udostępnić klucz (który sam musi być w tajemnicy). Oczywiście, opracowanie bezpiecznego udostępniania kluczowego jest kolejnym przypadkiem, dla którego szyfrowanie jest przeznaczone – bezpieczne udostępnianie informacji. Jak więc obie strony dzielą się swoim tajnym kluczem? Na szczęście można to osiągnąć za pomocą asymetrycznego (lub klucza publicznego), wyjaśnionego poniżej. Popularne algorytmy kluczowe symetryczne obejmują AES, Blowfish, RC4 i 3DES.

Szyfrowanie klucza publicznego

Szyfrowanie klucza publicznego opiera się na specjalnym zestawie algorytmów, które wymagają dwóch oddzielnych kluczy. Jeden klucz, znany jako klucz prywatny, jest utrzymywany w tajemnicy, a drugi klucz, klucz publiczny, jest powszechnie dostępny. Razem są znani jako para kluczowa. Zasadniczo każdy może użyć klucza publicznego do szyfrowania, ale tylko właściciel klucza prywatnego może go odszyfrować.

Zaletą systemu szyfrowania klucza publicznego jest: Secret (i.mi. zaszyfrowane) Wiadomości można wysłać do każdego, kto opublikował swój klucz publiczny, a tylko odbiorca będzie mógł odszyfrować wiadomość. Tak długo, jak ich klucz publiczny można ufać, że jest ich (ważnym zastrzeżeniem!), można łatwo skonfigurować bezpieczny system wymiany tajnych wiadomości. Każda ze stron może opublikować swój klucz publiczny i wysłać tajne wiadomości do drugiego za pomocą drugiego’S KLUCZ PUBLICZNY. Używają własnego klucza prywatnego do odszyfrowania wiadomości, które otrzymują.

Ale nie’T Publikowanie klucza publicznego sprawiają, że zaszyfrowane wiadomości są bardziej podatne na nieautoryzowane deszyfrowanie? Nie, nie jest praktycznie możliwe wyprowadzenie prywatnego klucza pary kluczowej z klucza publicznego, a bez klucza prywatnego nie można odszyfrować tekstu szyfru. Więc publikowanie klucza publicznego nie ułatwia odszyfrowania wiadomości szyfrowanych przez klucz publiczny.

RSA i Diffie – Hellman były najwcześniejszymi algorytmami kluczy publicznych. Przez długi czas sądzono, że zostali wynalezieni w 1976/1977, ale kiedy w 1997 r. Sekretne badania GCHQ zostały odgrane w 1997 r. Elgamal i DSS to inne znane algorytmy klucza publicznego.
Istnieje wiele ważnych zastosowań szyfrowania kluczy publicznych opisanych poniżej.

Dystrybucja kluczowa

Symmetryczne szyfrowanie używa jednego tajnego klucza, którego wymagają obie strony, a zapewnienie, że ten tajny klucz został bezpiecznie przekazany drugiej stronie, jest trudny. Jest to znane jako kluczowy problem dystrybucji.

Szyfrowanie klucza publicznego idealnie nadaje się do rozwiązania tego problemu. Strona przyjmująca, która wymaga nadawcy’s tajny klucz symetryczny, generuje pary kluczowe i publikuje klucz publiczny. Nadawca używa odbiornika’S KLUCZU PUBLICZNE, aby zaszyfrować swój klucz symetryczny i wysyła go do odbiornika. Teraz zarówno nadawca, jak i odbiornik mają ten sam tajny klucz symetryczny, a nikt inny nie ma, ponieważ nigdy nie został przekazany jako wyraźny tekst. Jest to często znane jako kluczowa wymiana.

Oczywistym pytaniem jest pytanie, dlaczego nie użyć szyfrowania klucza publicznego do wszystkiego, i unikanie konieczności wysyłania tajnego klucza? Okazuje się, że szyfrowanie symetryczne jest szybsze rzędu wielkości w szyfrowaniu i deszyfrowaniu. Dlatego o wiele bardziej wydajne jest korzystanie z szyfrowania klucza publicznego do dystrybucji klucza symetrycznego, a następnie użycia szyfrowania symetrycznego.

Podpisy cyfrowe

Szyfrowanie klucza publicznego jest ważnym elementem podpisów cyfrowych. Wiadomość może być podpisana (zaszyfrowana) z użytkownikiem’klucz prywatny, a każdy może użyć swojego klucza publicznego, aby sprawdzić, czy użytkownik podpisał wiadomość i że wiadomość nie była manipulowana. To zastosowanie szyfrowania klucza publicznego zostało wyjaśnione bardziej szczegółowo w następnej sekcji, Hashes Cryptographic.

Władze certyfikatów

Krytycznym wymogiem systemu korzystającego z szyfrowania klucza publicznego jest zapewnienie niezawodnego powiązania kluczy publicznych z ich właścicielami. Możliwość użycia kogoś jest ograniczona’jest kluczem publicznym do zaszyfrowania przez nich wiadomości, jeśli może’t uważaj, że to naprawdę ich klucz publiczny. Po to są władze certyfikatów, a zarówno oni, jak i certyfikaty są wyjaśnione poniżej.

Hiszki kryptograficzne

Algorytmy skrótu kryptograficzne są ważnymi funkcjami matematycznymi stosowanymi szeroko w oprogramowaniu, szczególnie w bezpiecznych protokołach, takich jak SSL/TLS i SSH.

Blok danych jest przekazywany przez algorytm skrótu w celu uzyskania znacznie mniejszej wartości skrótu, znanej jako podsumowanie komunikatu lub po prostu trawienie. Ta sama wiadomość zawsze spowoduje ten sam podsumowanie. Różne wiadomości wytwarzają różne trawienie.

Ważną cechą algorytmów skrót. Oni są “jednokierunkowa” Algorytmy – trawienie wiadomości jest łatwe do obliczenia, ale wiadomość może’t być wydedukowane z trawienia. Matematycznie możliwe jest, aby dwa różne wiadomości produkowały ten sam trawienie – znane jako kolizja – ale w przypadku dobrych algorytmów hash jest to bardzo mało prawdopodobne.

Popularne algorytmy skrótu obejmują MD5 i SHA-1, chociaż są one obecnie wycofywane na korzyść silniejszych algorytmów, takich jak SHA-2.

Algorytmy skrótu są używane do wielu celów, takie jak weryfikacja integralności danych lub plików, weryfikacja hasła i budowanie innych funkcji kryptograficznych, takich jak kody uwierzytelniania wiadomości (MAC) i podpisy cyfrowe.

Podpisy cyfrowe

Pisemny podpis pokazuje, że dokument został stworzony przez znanego autora i dokładnie je reprezentuje. Podpis cyfrowy jest podobny – gwarantuje, że wiadomość została utworzona przez znanego nadawcy (uwierzytelnianie) i że wiadomość nie była manipulowana w tranzycie (integralność).

Podpisanie wiadomości wymaga dwóch etapów. Po pierwsze, obliczane jest przesłanie, tworząc unikalny skrót, który jest zwykle znacznie mniejszy niż wiadomość. Następnie podsumowanie jest szyfrowane za pomocą podpisującego wiadomości’S KLUCZ prywatny. To jest cyfrowy podpis wiadomości.

Aby zweryfikować sygnatariusz wiadomości, wymaga również dwóch etapów. Po pierwsze, sygnatariusz’S KLUCZ PUBLICZNY (który jest szeroko dostępny) służy do odszyfrowania podpisu cyfrowego, co daje podsumowanie wiadomości. Następnie obliczany jest komunikat komunikat. Jeśli wiadomość nie została zmodyfikowana, trawienie powinny być identyczne. A ponieważ sygnatariusz’K klucza publicznego została użyta do odszyfrowania podpisu, podpisu’K klucza prywatnego musiał zostać użyty do jego szyfrowania.

Dlaczego warto korzystać z wiadomości’w ogóle trawić? Dlaczego nie po prostu zaszyfrować wiadomość z podpisem’K klucza prywatnego i użyj zaszyfrowanej wiadomości jako podpisu? Chociaż z pewnością zadziałałoby, jest to niepraktyczne – podwoiłoby to rozmiar wiadomości, gdy podpis zostanie uwzględniony. Trawienie jest bardzo małe i ma ustalony rozmiar, więc szyfrowanie trawienia wytwarza podpis, który jest znacznie mniejszy.

Kody uwierzytelniania wiadomości (Mac)

Kod uwierzytelniania wiadomości, czyli Mac, to niewielka informacja dołączona do wiadomości, która może sprawdzić, czy wiadomość nie została zmodyfikowana, i uwierzytelniono, kto ją utworzył.

Specjalnym typem Mac to HMAC, który jest konstruowany za pomocą kryptograficznego skrótu i ​​tajnego klucza. Tajny klucz jest wyściełany i połączony z komunikatem, a trawienie lub skrót jest obliczany. Ten trawienie jest następnie ponownie połączone z wyściełanym tajnym kluczem, aby uzyskać wartość HMAC. Atakujący nie jest w stanie wyprodukować tego samego HMAC bez tajnego klucza.

Zarówno nadawca, jak i odbiorca udostępniają tajny klucz. Gdy odbiornik otrzyma wiadomość, oblicza HMAC i porównują go z HMAC dostarczonym z komunikatem. Gdyby HMACS pasował, tylko ktoś posiadający tajny klucz mógł stworzyć wiadomość. Sam tajny klucz nigdy nie jest przekazywany.

Hasła, hasła i sole

Skróty kryptograficzne są niezwykle przydatne w systemach wymagających weryfikacji hasła. Jest to nieuzasadnione ryzyko bezpieczeństwa dla przechowywania użytkownika’S hasła, nawet jeśli są one zaszyfrowane. Zamiast tego przechowywane jest trawienie każdego hasła. Gdy użytkownik dostarcza hasło, jest ono haszowane i porównywane z przechowywanym trawieniem. Jest to preferowane, ponieważ hasła nie można odzyskać z jego skrótu.

Jedną z wad z tą metodą jest to, że jeśli użytkownicy mają to samo hasło, będą mieli tę samą wartość skrótu. Tabele wstępnie kalkulowanych trawień dla wspólnych haseł można użyć do ataku systemu, jeśli plik zawierający trawienie można uzyskać. Te stoły są znane jako stoły tęczowe.

Z tego powodu sól-losowa, niestosowna wartość-jest połączona z hasłem przed obliczeniem trawienia. Ponieważ każdy użytkownik ma inną sól, nie jest możliwe użycie wstępnie obliczonych tabel-musiałby być tabela dla każdej możliwej wartości soli. Aby sole były skuteczne, muszą być tak losowe, jak to możliwe i o odpowiednim rozmiarze – najlepiej co najmniej 32 bity.

Jakie są certyfikaty?

Omawiając szyfrowanie klucza publicznego, wyjaśniono, że musi istnieć sposób na wiarygodne powiązanie kluczy publicznych z ich właścicielami. Korzystanie z kogoś’KLUCZU PUBLICZNE, aby zaszyfrować przesłanie przeznaczone dla nich, wymaga wiedzy, że to rzeczywiście ich klucz publiczny.

Władze certyfikatów są rozwiązaniem tego problemu. Urząd certyfikatu (a “Ca”) to organizacja, która wydaje certyfikaty cyfrowe. Ceridyk cyfrowy to elektroniczny dokument, który poświadcza własność klucza publicznego.

Ceridyk cyfrowy zawiera wiele pól – klucz publiczny, który certyfikuje własność, nazwę właściciela (przedmiot), nazwę emitenta (i.mi. CA), daty rozpoczęcia i końca oraz emitenta’S podpis cyfrowy. Podpis cyfrowy weryfikuje, że CA faktycznie wydał certyfikat. Podpisy cyfrowe są tutaj bardziej szczegółowo wyjaśnione.

Aby system działał, organ certyfikatu musi być zaufaną stroną trzecią. Istnieje tylko niewielka liczba CA, w tym Comodo, Symantec i Godaddy. CAS wydają własne certyfikaty zawierające ich klucze publiczne, które są znane jako zaufane certyfikaty główne.

Aby uzyskać certyfikat z CA, organizacja musi dostarczyć CA swój klucz publiczny i wystarczającą dokumentację, aby ustalić, że jest to prawdziwa organizacja. CA weryfikuje te szczegóły przed wydaniem certyfikatu.

Walidacja strony internetowej

Najczęstszym użyciem certyfikatów jest potwierdzenie stron internetowych HTTPS (i.mi. Strony internetowe, które mają adres URL od https: //). Kiedy przeglądarka internetowa łączy się z witryną taką jak Amazon, użytkownik musi wiedzieć, że witryny można zaufać, ja.mi. że adres URL www.Amazonka.com faktycznie odnosi się do witryny kontrolowanej przez firmę o nazwie Amazon. Odbywa się to poprzez osadzenie nazwy domeny witryny w certyfikcie’S Pole Temat podczas ubiegania się do CA w celu uzyskania certyfikatu. CA zapewnia, że ​​nazwa domeny jest kontrolowana przez organizację przed wydaniem certyfikatu. Przeglądarka internetowa ma własną listę certyfikatów głównych, a kiedy łączy się ze stroną, witryną’C Certyfikat S jest wysyłany przez serwer WWW. Korzystając z certyfikatu CA, sprawdza, czy certyfikat wysyłany przez serwer WWW został wydany przez jednego z CA, który rozpoznaje i że nazwa domeny pasuje do nazwy domeny w certyfikcie.

Dlaczego ten czek jest ważny? Tak długo, jak Amazon posiada swoją nazwę domeny (co, jak wiemy), dlaczego potrzebujemy przeglądarki, aby sprawdzić certyfikat?

Niestety złośliwe oprogramowanie może podszywać się z innej maszyny. Gdy adres URL jest wprowadzany do przeglądarki internetowej, takiej jak https: // www.Amazonka.com, należy go przetłumaczyć na adres IP, e.G. 192.168.1.64. Te cyfry są tym, czego używa przeglądarka do łączenia się z serwerem internetowym. Proces tłumaczenia nazywa się wyszukiwaniem DNS i polega na sprawdzeniu publicznego rejestru nazw domen, aby uzyskać adres IP, który Amazon postanowił użyć. Złośliwe oprogramowanie może zagrozić wyszukiwaniom DNS, zwracając niewłaściwy adres IP, który może dotyczyć fałszywej strony internetowej, która wygląda podobnie do Amazon i jest zaprojektowana w celu uzyskania szczegółów karty kredytowej.

Tutaj kontrola certyfikatu dowodzi jego wartość – fałszywa strona internetowa może’t Zwróć prawdziwy certyfikat, a przeglądarka internetowa zasygnalizuje, że zwrócony certyfikat nie jest zarejestrowany do nazwy domeny używanej w adresie URL. W większości przeglądarek prawdziwa strona wyświetli symbol kłódki, a kliknięcie go myszką pokaże witrynę’weryfikowana tożsamość, jak w przypadku chromu, poniżej.

Dlatego ważne jest, aby używać adresów URL, które zaczynają się od HTTP, a nie HTTP – za pośrednictwem certyfikatu przeglądarka może zapewnić, że podłączona strona jest zweryfikowanym właścicielem domeny.

Jak działa SSL/TLS?

Historia

Secure Sockets Layer (SSL) to protokół kryptograficzny zaprojektowany do zabezpieczenia komunikacji nad sieciami TCP/IP. SSL został opracowany przez Netscape na początku 1990 roku’S, ale różne wady bezpieczeństwa oznaczały, że tak było’T aż do SSL 3.0 został wydany w 1996 roku, że SSL stał się popularny.

W tym czasie Eric Young udostępniła także wdrożenie SSL o nazwie SSL o nazwie SSL, co pomogło zapewnić powszechne przyjęcie w Internecie. Serwer WWW Apache również zyskał na popularności, a sława Ben Laurie z Apache użyła SSLEAY do produkcji Apache-SSL, jednego z pierwszych bezpłatnie dostępnych bezpiecznych serwerów WWW.

SSL stał się bezpieczeństwem warstwy transportowej (TLS) z publikacją TLS 1.0 standard w 1999 r., A następnie TLS 1.1 i tls 1.2, najnowsza wersja. Wszystkie wersje TLS są szeroko rozpowszechnione, a dopiero niedawno wsparcie dla SSL 3.0 zostało przerwane w odpowiedzi na podatność pudla. Dla uproszczenia my’LL określa SSL/TLS jako TLS dla pozostałej części tego artykułu.

Przegląd

TLS ma na celu zapewnienie bezpiecznych połączeń między klientem (e.G. przeglądarka internetowa) i serwer (e.G. serwer internetowy) poprzez szyfrowanie wszystkich przekazanych między nimi danych.

Zwykłe połączenia sieciowe nie są szyfrowane, więc każdy, kto ma dostęp do sieci, może wąchać pakiety, czytanie nazw użytkowników, hasła, dane karty kredytowej i inne poufne dane wysyłane przez sieć-oczywiście nie do przyjęcia sytuacja dla jakiegokolwiek rodzaju internetowego handlu elektronicznego.

Wcześniej w tej białej księdze omówiliśmy, jak działa szyfrowanie, w tym szyfrowanie klucza publicznego i certyfikaty. TLS używa szyfrowania klucza publicznego do weryfikacji stron w sesji zaszyfrowanej oraz do zapewnienia sposobu na uzgodnienie współdzielonego klucza szyfrowania symetrycznego.

Uzupełnienie dłoni SSL

“uścisk dłoni” jest najważniejszą częścią SSL/TLS, ponieważ w tym miejscu ustalono ważne parametry połączenia. Różne kroki w uścisku dłoni opisano poniżej.
Bezpieczne protokoły sieci 12

Krok 1 – Klient Hello

Po ustanowieniu połączenia TCP/IP klient wysyła komunikat ClientHello do serwera. Stwierdza, że ​​maksymalna wersja TLS Klient jest gotowy wspierać, liczbę losową, listę apartamentów szyfrów obsługiwanych w kolejności preferencji i algorytmy kompresji. Apartamenty szyfrów są identyfikatorami grupy algorytmów kryptograficznych, które są używane razem. Na przykład tls_rsa_with_aes_128_cbc_sha oznacza, że ​​serwer’Klucz publiczny S RSA należy użyć, a algorytm szyfrowania wynosi 128 bitów. Algorytm kodów uwierzytelniania wiadomości (MAC) to HMAC/SHA-1.

ClientHello jest wysyłany w ClearText, więc każdy może przechwycić pakiety sieciowe, może to odczytać.

Krok 2 – Hello serwer

Serwer odpowiada na klienta z komunikatem serverhello. Mówi klientowi wersję TLS do użycia, wraz z wybranym przez niego apartamentem szyfrowym i algorytmem kompresji. ServerHello zapewnia również liczbę losową generowaną przez serwer i identyfikator sesji. ServerHello jest również wysyłane w ClearText.

Natychmiast po wysłaniu serwera, serwer wysyła swój certyfikat, zawierający klucz publiczny, do klienta. Następnie następuje opcjonalny komunikat serverKeyExchange, który zawiera wszelkie dodatkowe wymagane wartości dla wymiany klawiszy.

Jeśli serwer jest skonfigurowany tak, aby wymagał od klienta zidentyfikowania się z certyfikatem klienta, serwer prosi o to w tym momencie uścisku dłoni za pomocą opcjonalnego komunikatu o certyfikat.

Wreszcie serwer wysyła klientowi komunikat serverHellodone, nadal w ClearText.

Krok 3 – Sprawdź certyfikaty serwera

Zazwyczaj klient ma pamięć podręczną certyfikatów lub certyfikatów CA, za pomocą których może sprawdzić, czy serwer’certyfikat S jest autentyczny (i zarejestrowany na serwerze’S adres IP). Jeśli serwer’S Certyfikat S jest nieznany, klient może podać opcję przyjęcia certyfikatu (który jest potencjalnie niebezpieczny) lub może zerwać połączenie. Ta wiadomość jest wysyłana w ClearText.

Krok 4 – Odpowiedź klienta

Jeśli serwer zażądał certyfikatu od klienta, klient wysyła swój certyfikat, a następnie komunikat ClientKeyExchange.

W przypadku wiadomości ClientKeyExChange klient generuje tak zwany Premaster Secret, składający się z 48 bajtów. Ta sekret jest wysyłany na serwer w ramach tego komunikatu, ale jest szyfrowany z serwerem’K klucz publiczny (uzyskany z serwera’s certyfikat), aby tylko serwer mógł go odszyfrować za pomocą klucza prywatnego (ponieważ wiadomości są nadal wysyłane jako zwykły tekst).

Gdy klient i serwer podzielają najważniejszy sekret, każdy używa go w połączeniu z obiema losowymi wartościami, które zostały wcześniej wymienione w celu stworzenia głównego tajnego, a następnie klawisze sesji – klucze symetryczne używane do szyfrowania i odszyfrowania danych w kolejnych sesji TLS sesji TLS.

Wiadomość ChangeCipherSPEC jest wysyłana po wiadomości ClientKeyExchange. Ten komunikat wskazuje serwerze, że wszystkie kolejne wiadomości zostaną zaszyfrowane za pomocą nowo utworzonych kluczy sesji. Następnie jest gotowa wiadomość, pierwsza, która została zaszyfrowana. Ukończona wiadomość jest skrótem całego uścisku dłoni, który umożliwia serwerowi sprawdzenie, czy to klient komunikuje się z serwerem przez cały uścisk dłoni.

Krok 5 – Sprawdź certyfikat klienta

Jeśli serwer zażądał certyfikatu klienta, jest zweryfikowane, aby upewnić się, że jest poprawny.

Krok 6 – Serwer zakończony

Serwer odpowiada na zakończoną wiadomość od klienta z własnym komunikatem ChangeCerSpec, a następnie zaszyfrowaną gotową wiadomość, która ponownie jest skrótem uścisku dłoni do tego momentu. Umożliwia to klientowi sprawdzenie, czy jest to ten sam serwer, który komunikuje się z nim podczas uścisku dłoni.

Krok 7 – Ustanowiona bezpieczna komunikacja

W tym momencie ustanowiono wszystkie wiadomości, a zatem ustalono bezpieczny kanał komunikacyjny między klientem a serwerem.

Rekordy i alerty

W jaki sposób dane są pakowane i wysyłane przez sieć po zakończeniu uścisku dłoni? Obejmuje to protokół rekordu i protokół alertu.

Protokół zapisu

Protokół zapisu jest odpowiedzialny za kompresję, szyfrowanie i weryfikację danych. Wszystkie dane do przesyłania są podzielone na rekordy. Każdy rekord składa się z bajtu nagłówka, a następnie wersji protokołu, długości danych, które mają być wysłane (znane jako ładunek) i sam ładunek. Po pierwsze, dane są kompresowane, jeśli kompresja została uzgodniona. Następnie komputer Mac jest obliczany i dołączany do danych. MAC pozwala odbiornikowi sprawdzić, czy rekord nie został zmodyfikowany. Jego obliczenia obejmują numer sekwencji, którego nadawca i odbiornik śledzą. Wreszcie dane i dołączony Mac są szyfrowane za pomocą sesji’K kluczy szyfrowania, a wynik jest ładunkiem dla rekordu. Na końcu odbierania rekord jest odszyfrowany, a komputer Mac jest obliczany w celu sprawdzenia, czy rekord’S Dane nie zostały zmodyfikowane. Jeśli zastosowano kompresję, jest dekompresowana.

Alerty

Jeśli wystąpią błędy, SSL/TLS definiuje protokół alertu, aby komunikaty o błędach były przekazywane między klientem a serwerem. Istnieją dwa poziomy – ostrzeżenie i śmiertelne. Jeśli wystąpi błąd śmiertelny, po wysłaniu alertu połączenie jest zamknięte. Jeśli alert jest ostrzeżeniem, to od strony otrzymującej ostrzeżenie, czy sesja powinna być kontynuowana. Jednym z ważnych alertów jest bliskie powiadomienie. Wysłane, gdy każda ze stron zdecyduje się zamknąć sesję, wymagane jest zamknięcie powiadomienia do normalnego rozwiązania sesji. Warto zauważyć, że niektóre implementacje SSL/TLS nie wysyłają tej wiadomości – po prostu kończą połączenie.

Wersje

Wewnętrzne numery wersji SSL/TLS nie odpowiadają, co można oczekiwać od tego, co publicznie określane jako numer wersji. Na przykład 3.1 odpowiada TLS 1.0. Główne obecnie używane wersje są pokazane tutaj.
Należy się im zapoznać, ponieważ wewnętrzne numery wersji są często preferowane.

Słabości SSL/TLS

TLS jest dojrzałym, szeroko stosowanym bezpiecznym protokołem sieciowym, który będzie zabezpieczać transakcje w Internecie przez wiele lat. Jednak jak każdy bezpieczny protokół, na przestrzeni lat odkryto szereg ważnych luk w zabezpieczeniach. Dealety będą nadal odkrywane i ważne jest, aby oprogramowanie, które wykorzystuje TLS na bieżąco, aby zastosować najnowsze łatki bezpieczeństwa.

Niektóre z bardziej znanych luk i sposób ich rozwiązania, omówiono poniżej.

Serdeczne

Heartbleed jest jednym z najpoważniejszych luk w oprogramowaniu TLS, umożliwiając kradzież klawiszy serwerów, identyfikatory sesji użytkowników i hasła użytkowników z naruszenia systemów. Nie była to jednak wada protokołu SSL, ale raczej błąd implementacyjny (znany jako nadmierny odczyt buforowy) w OpenSSL‘bezpłatna biblioteka, która jest szeroko używana w Internecie. Wpłynęły na miliony maszyn i zgłosiło wiele udanych ataków.

Systemy oprogramowania nie korzystające z odpowiednich wersji OpenSSL nie były dotyczyło. OpenSsl był szybko załatany, ale łatanie milionów maszyn wymaga czasu. Maszyny nie tylko musiały być załatane, ale kluczowe klucze serwera muszą być aktualizowane, hasła użytkownika zmienione i ponowne wydanie certyfikatów. Rok później prawdopodobne jest, że nadal istnieją w Internecie maszyny, które nie zostały odpowiednio zmodyfikowane.

Całkowity koszt serca oszacowano na zasięgu setek milionów dolarów.

PUDEL

Pudle jest podatnością na starszy protokół SSL, SSL 3.0. Podczas gdy większość systemów używa TLS 1.0, 1.1 lub 1.2, protokół TLS ma przepis z opadaniem, aby umożliwić interoperacyjność ze starszym oprogramowaniem nadal korzystając z SSL 3.0. Tak więc ataki pudla używają tego opadania, aby oszukać serwery w obniżaniu się do SSL 3.0.
Najprostszym rozwiązaniem jest wyłączenie SSL 3.0 w klientach i serwerach. SSL 3.0 został opublikowany w 1996 roku, od dawna został zastąpiony i nie powinno być potrzeby tego wspierania po prawie 20 latach. Pudel jest znacznie mniej poważną podatnością na serce.

RC4

RC4 jest szeroko stosowanym szyfrem TLS, który nie jest już uważany za bezpieczny. RC4 jest również znany jako ARC4 lub Arcfour (ponieważ RC4 jest znakiem towarowym). Jego szybkość i prostota sprawiły, że RC4 popularny, ale niedawno (luty 2015 r.) RFC7465 zalecił, aby nie było już używane.

Protokół transferu plików SSL/TLS: FTPS

Jednym z najczęstszych zastosowań SSL/TLS jest bezpieczna forma transferu plików zwanego FTPS.

Tradycyjne FTP zgodnie z definicją w RFC 959 nie wspomina o bezpieczeństwie. Jest to zrozumiałe, ponieważ zostało napisane w 1985 roku i na podstawie specyfikacji z lat 70. Wtedy uniwersytety i wojsko były głównymi użytkownikami Internetu, a bezpieczeństwo nie było obawą, że tak jest.

W rezultacie w nazwach użytkowników i hasłach FTP są (nadal) wysyłane przez sieć w wyraźnym tekście, co oznacza, że ​​każdy, kto może wąchać pakiety TCP/IP, jest w stanie je przechwycić. Jeśli serwer FTP jest w Internecie, pakiety przechodzą przez sieci publiczne i powinny być uważane za publicznie dostępne.

Dopiero w latach 90. Netscape opracował swoją warstwę bezpiecznych gniazd (SSL), rozwiązanie stało się praktyczne. Projekt RFC w 1996 r. Opisał rozszerzenie FTP o nazwie FTPS, które pozwoliło na użycie poleceń FTP przez połączenie SSL, a do 2005 r. Zostało to przekształcone w formalny RFC.

Wdrożone przez klientów takich jak FileZilla i serwery, takie jak Proftpd, FTPS szybko stał się popularny.

Uważne FTPS

Istnieją dwie formy FTP – tryb niejawny i tryb jawny. FTP w trybie ukrytym jest przestarzały i nie jest powszechnie używany, ale wciąż jest spotykany.

Uważne FTP nie ma jawnego polecenia, aby zabezpieczyć połączenie sieciowe – zamiast tego robi to domyślnie. W tym trybie serwer FTPS oczekuje, że klient FTPS natychmiast zainicjuje uścisk dłoni SSL/TLS. Jeśli tak nie jest, połączenie jest upuszczane. Standardowy port serwera dla połączeń w trybie niejawnym to 990 (nie port standardowy 21 używany dla FTP).

Po ustaleniu połączenia SSL/TLS standardowe polecenia FTP są używane do nawigacji z serwerem’System plików i przesyłać pliki. Ponieważ połączenie jest bezpieczne, hasła mogą być wysyłane, a dane nie mogą być sprawdzane przez podgrzewanie.

Wyraźne FTPS

W jawnym trybie FTPS klient musi wyraźnie poprosić o zabezpieczenie połączenia, wysyłając polecenie Auth TLS na serwer. Po wysłaniu tego polecenia uścisk dłoni SSL/TLS rozpoczyna.

Zaletą korzystania z FTP w trybie jawnym w trybie niejawnym jest to, że można użyć tego samego numeru portu jako standardowego FTP – port 21. Zwykli użytkownicy FTP po prostu nie wysyłają polecenia Auth, więc nigdy nie zabezpieczają połączenia. Administrator serwera może opcjonalnie wymagać użycia polecenia Auth, jeśli nie chce wykonać niezabezpieczonych transferów plików.

FTP w trybie jawnym należy zawsze stosować w preferencji do trybu ukrytych, przede wszystkim dlatego, że tryb ukryty jest przestarzały od wielu lat.

Wada FTPS

FTPS ma jedną znaczącą wadę, jaką jest użycie oddzielnego połączenia sieciowego dla danych, w tym zawartość plików i oferty katalogów. To właściwie część protokołu FTP – polecenia są wysyłane za pomocą początkowego “kontrola” Połączenie na porcie 21, a za każdym razem, gdy dane są przesyłane, należy ustanowić nowe połączenie sieciowe do przesyłania. Klient i serwer muszą uzgodnić numer portu, a połączenie należy otworzyć.

Z niezaszyfrowanym FTP, to jest’t Zbyt problematyczny. Mogą wystąpić problemy z wyczerpaniem połączeń sieciowych, jeśli zbyt wiele transferów jest dokonywanych w krótkim czasie. Ponieważ każde transfer wymaga nowego połączenia, a systemy operacyjne zwykle wymagają kilku minut, aby zwolnić zamknięte połączenia, wiele transferów małych plików może spowodować ostateczne błędy.

Bardziej znaczącym problemem jest przechodzenie przez zapory ogniowe. Zapory ogniowe są zwykle konfigurowane, aby umożliwić dostęp za pośrednictwem portu 21. Nowoczesne zapory ogniowe są również wystarczająco sprytne, aby móc sprawdzić polecenia wysyłane między klientem a serwerem (Port lub PASV), aby móc ustalić, które porty muszą być dynamicznie otwarte, aby umożliwić transfer danych.
Jednak z FTPS polecenia znajdują się na zaszyfrowanym kanale, a zapory ogniowe nie mogą ich sprawdzić. Oznacza to, że nie mogą automatycznie otwierać portów danych, więc transfery i listy katalogów zawodzą. Zamiast tego stały zakres portów musi zostać z wyprzedzeniem uzgodniony i skonfigurowany w kliencie, serwerze i zaporze.

Przyszłość FTPS

W dzisiejszych czasach FTPS ma silnego konkurentów w SFTP lub protokołu transferu plików SSH. Są to zupełnie inne protokoły, a ich względne zalety zostaną zbadane w następnym rozdziale. Jednak FTP i FTP mają ogromną bazę instalacyjną i bez wątpienia będą nadal powszechnie używane przez wiele lat.

Jak działa SSH?

Historia SSH

Pod koniec 1980 roku’S i 1990’S, narzędzia sieciowe, takie jak RLOGIN i TELnet, były powszechnie używane do loginów do zdalnych maszyn, zwykle na platformach Unix. Te narzędzia pozwoliły użytkownikom otwierać powłoki poleceń, które pozwoliły im wykonywać polecenia na zdalnych maszynach, tak jakby były na komputerze i były niezwykle przydatne do administracji systemów.

Była jedna krytyczna wada – żadne z tych narzędzi nie było bezpieczne. Hasła zostały wysłane przez sieci w zwykłym teście, co oznacza, że ​​każdy, kto jest w stanie wąchać sieć, może uzyskać poświadczenia dla zdalnego komputera. Ten problem jest powodem, dla którego Tatu Ylönen, fiński badacz z Helsinek University of Technology, zdecydował, że wymagany jest bezpieczny protokół sieciowy. W 1995 roku napisał pierwszą wersję SSH, znaną jako SSH-1, i wydał ją jako darmowe oprogramowanie. Składał się z bezpiecznego serwera i klienta.

Gdy jego popularność gwałtownie rosła, Ylönen założył SSH Communications Security na rynku i rozwijał SSH jako zastrzeżony produkt. W 1999 r. Björn Grönvall rozpoczął pracę nad wcześniejszą wersją Freeware, a zespół OpenBSD sfinansował swoją pracę nad produkcją swobodnie dostępnego OpenSsh. Wkrótce na wielu innych platformach zostały wykonane, a OpenSSH pozostaje najczęściej znaną i używaną wersją SSH.

W 2006 roku SSH 2.0 zdefiniowano w RFC 4253. SSH-2 jest niezgodne z SSH-1 i ma lepsze bezpieczeństwo i funkcje, co czyni SSH-1 przestarzały.

Przegląd SSH

SSH to bezpieczny protokół sieciowy, którego można użyć na dowolnej platformie w dowolnym celu wymagającym bezpiecznej komunikacji sieciowej. Typowe zastosowania obejmują:

• bezpieczne zdalne narzędzia logowania, takie jak klient SSH;
• bezpieczne przesyłanie plików, takie jak narzędzia SCP i SFTP; I
• bezpieczne przekazywanie portów lub bezpieczne tunelowanie.

SSH-2 używa architektury warstwowej i składa się z warstwy transportowej, warstwy uwierzytelniania użytkownika i warstwy połączeń.
Warstwa transportowa działa przez TCP/IP i zapewnia szyfrowanie, uwierzytelnianie serwera, ochronę integralności danych i opcjonalną kompresję. Warstwa uwierzytelniania użytkownika obsługuje uwierzytelnianie klienta, podczas gdy warstwa połączenia zapewnia usługi takie jak interaktywne loginy, zdalne polecenia i przekierowane połączenia sieciowe.

Warstwa transportowa

Warstwa transportowa jest oparta na wiadomościach i zapewnia szyfrowanie, uwierzytelnianie hosta i sprawdzanie integralności. Wiadomości są wysyłane między klientem a serwerem przez TCP/IP za pośrednictwem protokołu pakietu binarnego – “pakiety” danych są wymieniane w formacie zdefiniowanym poniżej, a ładunek każdego pakietu jest komunikatem:
Uint32 Packet_Length Bajte Padding_length Bajt [n1] ładunek; n1 = Packet_Length – Padding_Length – 1 bajt [n2] losowe wyściółki; n2 = bajt padding_length [M] Mac (kod uwierzytelnienia wiadomości – Mac); M = Mac_Length

MAC jest ważnym pole, ponieważ jest to komputer Mac, który pozwala odbiorcom wiadomości upewnić się, że wiadomości nie zostały zmodyfikowane – sprawdzanie integralności, o których mowa powyżej. Mac jest obliczany przez resztę danych w pakiecie i wykorzystuje współdzielony sekret ustalony między klientem i serwerem, a także numer sekwencji, który obie strony śledzą. Mac są opisane w tym poście.

Ustanowienie sesji

Jak rozpoczyna się sesja między klientem a serwerem? Każda strona wysyła ciąg identyfikacyjny po ustaleniu połączenia TCP/IP. Ten ciąg jest w następującym formacie:
SSH-2.0-Sofwareversion SP komentarze Cr lf

Tutaj “Sp” oznacza przestrzeń, “Cr” to znak powrotu powozu i “Lf” jest znakiem linii. Wersja oprogramowania to wersja dostawcy, a komentarze i przestrzeń są opcjonalne. Tak więc w przypadku CompleteftP, gdy klient łączy się z serwerem, otrzymuje następujący ciąg:
SSH-2.0-completeftp_9.0.0

Ciąg kończy się obowiązkowym zwrotem wózka i kanału linii – żadne komentarze nie są używane.

Po wymienieniu ciągów identyfikacyjnych należy uzgodnić szereg opcji-szyfrowania używane do szyfrowania, algorytmy MAC używane do integralności danych, metody wymiany klawiszy użyte do konfigurowania jednorazowych kluczy sesji do szyfrowania, algorytmów klucza publicznego używanego do uwierzytelniania, i wreszcie jakie algorytmy kompresji mają być używane. Zarówno klient, jak i serwer wysyłają sobie nawzajem komunikat SSH_MSG_KEXINIT, wymieniając swoje preferencje dla tych opcji:
BYTE SSH_MSG_KEXINIT BYTE [16] Cookie (losowe bajty) Nazwa Kex_Algorytms Nazwa-list Server_Host_Key_Algorytms name-liter encryption_algorytms_client_to_server nazwa-liter encryption_algorythms_server_to_client name-list mac_algorithm_client_to_server nazwa mac_server nazwa mac_ server_to_client-liter Compression_Algorytms_client_to_server nazwa lista kompresji_algorytms_server_to_client-list Languages_client_to_server Langiages_server_to_client boolean fest_kex_packet_follows uint32 0 (rezerwowy dla przyszłości)

Ta wiadomość jest ładunkiem pakietu protokołu binarnego, którego format opisano powyżej. Nazwy listy algorytmów są oddzielone przecinkami. Klient wysyła listy algorytmu w kolejności preferencji, podczas gdy serwer wysyła listę algorytmów, które obsługuje. Pierwszy obsługiwany algorytm w kolejności klienta’Preferencje to wybrany algorytm. Biorąc pod uwagę obie wiadomości, każda strona może ustalić, jakie algorytmy mają być używane.

Po SSH_MSG_KEXINIT wybrany algorytm wymiany kluczy, który może skutkować wymienianiem wielu wiadomości. Rezultatem końcowym są dwie wartości: wspólny sekret, k i hasza wymiany, h, h, h. Służą one do uzyskania kluczy szyfrowania i uwierzytelniania. SSH_MSG_NEWKEYS jest wysyłany w celu oznaczenia końca tych negocjacji, a każda kolejna wiadomość korzysta z nowych kluczy szyfrowania i algorytmów.

Po ustaleniu połączenia SSH-2 klient żąda “praca” (Zwykle ssh-userauth, aby rozpocząć proces uwierzytelniania) z komunikatem ssh_msg_service_request.

Warstwa uwierzytelniania

Następnym krokiem jest zidentyfikowanie klienta z serwerem i uwierzytelnionym. Jest to zarządzane za pośrednictwem warstwy uwierzytelniania użytkownika, która działa na warstwie transportowej. Oznacza to, że komunikaty uwierzytelniania użytkownika są szyfrowane i wymieniane za pomocą warstwy transportowej.

Uwierzytelnianie użytkownika jest inicjowane przez klienta z “praca” żądanie usługi SSH-USERAUTH. Jeśli serwer odpowiada, zezwalając na żądanie, klient wysyła żądanie uwierzytelnienia, które obejmuje ich nazwę użytkownika i metodę uwierzytelniania.

Istnieje wiele możliwych metod uwierzytelniania, a które są używane, będzie zależeć od klienta i serwera’s wsparcie dla tego. Najpopularniejszą metodą jest uwierzytelnianie hasła, które jest samozaplanowe. Kolejnym jest uwierzytelnianie KLIK. Zazwyczaj klient proponuje metodę, a serwer albo akceptuje lub odrzuca tę metodę.

Przykład żądania uwierzytelniania hasła przez użytkownika zadzwoniło “EnterpredT” pokazano poniżej:
BYTE SSH_MSG_USERAUTH_REQUEST STRING „EnterpredTT” [Nazwa użytkownika] String „SSH-USERAUTH” [Nazwa usługi] String „Hasło” [Metoda uwierzytelniania] Boolean False String „MyPassword” [Hasło użytkownika]

Serwer potwierdzi hasło wysłane dla tego użytkownika według danych, które przechowywał dla użytkownika. Serwer nie będzie przechowywać użytkownika’faktyczne hasło do sprawdzania poprawności, ale kryptograpowy skrót hasła, którego nie można odwrócić, aby uzyskać hasło.

Jeśli żądanie uwierzytelnienia użytkownika zostanie odrzucone (na przykład dostarczono nieprawidłowe hasło), serwer wysyłany jest komunikat o awarii i zawiera listę alternatywnych uwierzytelniania, które można wypróbować.

Wysyłanie jest powszechne “nic” Jako metoda uwierzytelniania początkowego, a serwer zwykle odpowiada komunikatem niepowodzenia zawierającym listę wszystkich dostępnych metod uwierzytelniania. Przykładowa odpowiedź na “nic” pokazano poniżej:

BYTE SSH_MSG_USERAUTH_FAILURE Nazwa hasło, Publickey Boolean False (częściowa flaga sukcesu)

Tutaj serwer informuje klienta, że ​​można użyć hasła lub uwierzytelnienia publicznego.
Jeśli żądanie uwierzytelniania hasła się powiedzie, serwer zwraca komunikat sukcesu, jak pokazano poniżej:
BYTE SSH_MSG_USERAUTH_SUCCESS

W tym momencie uwierzytelnianie jest kompletne i można wymagać innych usług. Mogą one obejmować żądania przekazywania TCP/IP oraz kanały dostępu do terminalu, wykonywania procesu i podsystemów, takich jak SFTP.

Warstwa połączenia

Ostatni kawałek SSH-2’S Warstwowa architektura to warstwa połączeń, która zapewnia usługi sieciowe, takie jak sesje interaktywne i przekazywanie portów na warstwie transportowej, która dostarcza niezbędne bezpieczeństwo.

Po ustaleniu połączenie SSH może hostować jeden lub więcej kanałów SSH, które są logicznymi rurami danych multipleksowanymi przez połączenie. Klient może otworzyć wiele kanałów w jednym połączeniu z tym samym serwerem i wykonywać różne zadania sieciowe na różnych kanałach. W praktyce implementacje SSH rzadko używają wielu kanałów w połączeniu, woląc otworzyć nowe połączenie dla każdego kanału.

Ważną cechą kanałów SSH jest kontrola przepływu. Dane mogą być wysyłane przez kanał tylko wtedy, gdy odbiorca wskazał, że są gotowe do jego odbierania-forma kontroli przepływu przesuwnego. Rozmiar okna jest ustalany przez odbiorcę po otwarciu kanału, a rozmiar okna jest zmniejszany w miarę wysyłania danych. Okresowo odbiorca wysyła wiadomość w celu zwiększenia rozmiaru okna.

Wiadomość SSH_MSG_Channel_Open używana do otwarcia sesji interaktywnej pokazano poniżej. Ta sesja może być następnie używana do sesji terminalowej, do uruchomienia zdalnego polecenia lub uruchomienia podsystemu, takiego jak SFTP.

BYTE SSH_MSG_CHANNEL_OPEN String „Session” Uint32 Kanał nadawcy Uint32 Rozmiar okna początkowego Uint32 Maksymalny rozmiar pakietu

Początkowy rozmiar okna ustawia liczbę bajtów, które odbiorca tej wiadomości może wysłać do nadawcy, podczas gdy maksymalny rozmiar pakietu jest największą ilością danych, które zaakceptuje w jednej wiadomości.

Odbiorca tego wiadomości odpowiada za pomocą komunikatu SSH_MSG_Channel_Open_Conconrisation, jeśli jest przygotowany do otwarcia żądanego kanału:
BYTE SSH_MSG_CHANNEL_OPEN_CONFIRMATION UINT32 Kanał uint32 kanał nadawcy Uint32 Rozmiar okna początkowego Uint32 Maksymalny rozmiar pakietu

Po pomyślnym otwarciu kanału dane można wymienić, a żądania specyficzne dla kanału można wysłać. Gdy rozmiar przesuwanego okna dla klienta lub serwera staje się zbyt mały, właściciel okna wysyła komunikat SSH_MSG_Channel_Window_Adjust, aby ją zwiększyć:
BYTE SSH_MSG_CHANNEL_WINDOW_ADJUST UINT32 BYSTED CHANANN UINT32 BYTES

Dane są wysyłane przez kanał za pośrednictwem wiadomości SSH_MSG_Channel_Data. Sposób, w jaki dane są używane, będzie zależeć od rodzaju ustalonego kanału:
BYTE SSH_MSG_CHANNEL_DATA UINT32 DANE STRINE

Żądania kanału są używane do wykonywania poszczególnych działań przez kanał. Wspólne żądania obejmują uruchomienie powłoki lub wykonanie zdalnego polecenia. Na przykład zdalna powłoka uruchamia się przez żądanie pokazane poniżej:

BYTE SSH_MSG_CHANNEL_REQUEST UINT32 CHANNEL CHANANN Ciąg „Shell” Boolean Wanna odpowiedź

Polecenie zdalne jest wykonywane przez następujące żądanie:
BYTE SSH_MSG_CHANNEL_REQUEST UINT32 CHANNOLD CHANAND „EXEC” Boolean Wanna Odpowiedz String Polecenie

Wreszcie podsystem SFTP może zostać otwarty na to żądanie:
BYTE SSH_MSG_CHANNEL_REQUEST UINT32 CHANNOLD CHANANN Ciąg „Podsystem” Boolean Wanna Odpowiedz String „Sftp-Server”

Podsystemy to zestawy zdalnych poleceń, które są wstępnie zdefiniowane na komputerze serwerowym. Najczęstszym jest SFTP, który zapewnia polecenia do przesyłania i manipulowania plikami. Polecenia podsystemu (w tym protokół SFTP) przebiegają nad SSH, I.mi. Dane dla poleceń podsystemu są wysyłane w wiadomościach SSH_MSG_Channel_Data.

Gdy jeden z tych wiadomości przybywa do klienta lub serwera, jest on przekazywany do podsystemu w celu przetwarzania.
Po zakończeniu klienta lub serwera za pomocą kanału należy go zamknąć. Wiadomość SSH_MSG_Channel_EOF jest wysyłana, aby wskazać, że żadne dane nie zostaną wysyłane w kierunku tej wiadomości. Komunikat SSH_MSG_Channel_Close wskazuje, że kanał jest teraz zamknięty. Odbiorca musi odpowiedzieć za pomocą ssh_msg_channel_close, jeśli jeszcze go nie wysłał. Po zamknięciu kanału nie można ponownie otworzyć.

Protokół przesyłania plików SSH: SFTP

Najczęstszym podsystemem używanym z SSH jest SFTP, który zapewnia polecenia do przesyłania i manipulowania plikami. SFTP jest również znany jako protokół transferu plików SSH i jest konkurentem FTPS – tradycyjnego FTP przez połączenie SSL/TLS.

Podsystem SFTP działa nad warstwą transportową SSH, ale sam w sobie jest wyrafinowanym protokołem opartym na wiadomościach. Wiadomości SFTP są przesyłane jako pole danych warstwy transportowej’SSH_MSG_CHANNEL_DATA Wiadomość
Wiadomości SFTP są w formacie standardowym, jak pokazano poniżej:
Uint32 Bajte Type Uint32 żądanie-id . Wpisz określone pola…

Pierwsze pole to długość wiadomości, z wyłączeniem pola długości, a następnie typ wiadomości. Trzecie pole to identyfikator żądania – każde żądanie wysłane od klienta ma identyfikator żądania, a serwer’S Odpowiedź musi zawierać odpowiedni identyfikator żądania.

Niektóre z ważniejszych wiadomości SFTP wraz z ich identyfikatorami typu są pokazane i opisane poniżej:
Ssh_fxp_init 1 ssh_fxp_version 2 ssh_fxp_open 3 ssh_fxp_close 4 ssh_fxp_read 5 ssh_fxp_write 6 ssh_fxp_status 101 ssh_fxp_data 103

SSH_FXP_INIT to pierwsza wiadomość wysłana przez klienta w celu zainicjowania sesji SFTP, a serwer odpowiada ssh_fxp_version, wskazując, że obsługuje wersje, które obsługuje.
Ssh_fxp_open żąda serwera o otwarcie pliku (lub opcjonalnie go utworzyć, jeśli nie istnieje), podczas gdy

Ssh_fxp_close zamyka plik. Ssh_fxp_read prosi o odczytanie określonego zakresu bajtów od pliku, a serwer odpowiada ssh_fxp_data, która zawiera żądane bajty. SSH_FXP_WRITE służy do zapisywania danych do pliku, a jednym z jego pól jest zapisanie danych (a także przesunięcie pliku).

Jeśli którekolwiek z powyższych poleceń, SSH_FXP_STATUS jest zwracany z kodem błędu wskazującym typ wystąpienia błędu. Służy również do sygnalizacji udanego zapisu w odpowiedzi na ssh_fxp_write.

Istnieją również polecenia dla innych standardowych operacji plików i katalogów, takie jak usuwanie plików (SSH_FXP_REMOVE), zmiana nazwy plików (ssh_fxp_rename) oraz tworzenie i usuwanie katalogów (ssh_fxp_mkdir, ssh_fxp_rmdir). Katalogi są odczytywane przez otwieranie ich (ssh_fxp_opendir) i wysyłanie żądań SSH_FXP_READDIR. Ponownie ssh_fxp_status służy do wskazania sukcesu lub porażki tych żądań.

Nie ma konkretnej wiadomości SFTP do zakończenia sesji SFTP – zamiast tego klient zamyka używany kanał SSH.

Należy zauważyć, że SFTP jest zupełnie innym protokołem od tradycyjnego FTP, i.mi. to nie są polecenia FTP wysyłane przez połączenie SSH. Natomiast FTPS to polecenia FTP wysyłane przez połączenie SSL/TLS. Dwa protokoły można łatwo pomylić, ponieważ oba są bezpieczne protokoły do ​​przesyłania plików.

SFTP vs FTPS

Opisaliśmy, jak działają FTPS i SFTP powyżej. Zasadniczo oba protokoły osiągają dokładnie to samo-bezpieczne przesyłanie plików i bezpieczne, zdalne manipulacje systemami plików.

Są to jednak zupełnie inne protokoły, a osoby wdrażające bezpieczne rozwiązanie do przesyłania plików będą musiały zdecydować, z którego protokołu użyć.

Istniejące użycie jest oczywiście ważnym czynnikiem. Jeśli SFTP i/lub SSH są już używane w innych obszarach organizacji, rozsądne jest użycie SFTP. Istniejąca wiedza i umiejętności w organizacji można wykorzystać, a także infrastrukturę techniczną. Podobnie, jeśli FTP i/lub FTPS są już używane gdzie indziej, najlepiej jest używać FTPS.

Wymagania projektu mogą również dyktować protokół. Jeśli rozwiązanie jest wdrażane po stronie serwera, może być tak, że klienci są ograniczeni do konkretnego protokołu, a zatem nie należy podjąć decyzji.

Ale co, jeśli punktem początkowym jest całkowicie czysty łup? Czy jest wyraźny zwycięzca?

SFTP – wyraźny zwycięzca

Tak, i to jest sftp. Kilka lat temu taka decyzja nie była tak prosta, głównie z powodu dominacji protokołu FTP w większości organizacji. Teraz klienci i oprogramowanie serwerowe są szeroko dostępne zarówno dla SFTP, jak i FTP – w rzeczywistości wiele aplikacji, takich jak kompletne obsługę obu.

Oznacza to, że można podjąć decyzję z czysto technicznych, a SFTP ma co najmniej dwie ważne zalety techniczne w stosunku do FTP i FTP.

SFTP jest lepsze z zaporami ogniowymi

FTP mogą być bolesne, aby pracować z zaporami zaporowymi. Wynika to z faktu, że listy katalogów i transferów plików są wykonywane w nowym połączeniu sieciowym, które jest oddzielone od kanału sterowania na porcie 21. Domyślnie zapory ogniowe nie pozwalają na te połączenia w FTP (chociaż zwykle będzie działać z FTP, ponieważ zapory ogni są w stanie sprawdzić ruch sieciowy i otworzyć odpowiedni port z wyprzedzeniem). Zamiast tego zapora i serwer muszą być skonfigurowane dla określonego zakresu portów do przesyłania danych, co może się skomplikować.

Natomiast SFTP po prostu współpracuje z zaporami ogniowymi. Dane i polecenia są wysyłane przez standardowy port 22, który zwykle jest domyślnie włączony w zaporach zaporowych. Jest to znacząca zaleta w stosunku do FTP.

SFTP nie’t Używaj certyfikatów

FTPS używa certyfikatów do identyfikacji serwera z klientem. Identyfikacja serwera jest ważna, ponieważ w ten sposób klient weryfikuje, że łączy się z właściwym serwerem. Aby być przydatnym, certyfikaty muszą zostać wydane przez organ certyfikatu – organizacja upoważniona do ich wydania. Uzyskanie certyfikatu może być kosztowne i czasochłonne.

SFTP nie’T Użyj certyfikatów – serwer jest identyfikowany przez jego klucz publiczny (który jest zawiera certyfikat, więc oba są ostatecznie używające tego samego mechanizmu). Tak długo, jak klient ma pod ręką klucz publiczny serwera, może potwierdzić, że serwer jest prawidłowy. Serwer’KLUCZ PUBLICZNY (W przeciwieństwie do certyfikatu) może być wygenerowany przez organizację, a organ certyfikatu nie jest wymagany. To znacznie zmniejsza ilość administracji niezbędnej do uruchomienia serwera.

Istnieje pewne zalety posiadania uznanej organizacji, takiej jak uprawnienia certyfikatów do wydawania certyfikatów, ale przez większość czasu nie jest to konieczne, szczególnie w przypadku projektów wewnętrznych.

Czy jest jakiś minus używania SFTP?

Brak certyfikatów może być problemem, jeśli chcesz uznać organ certyfikatu, ale główną wadą SFTP jest to, że jest to złożony protokół, który jest trudny do wdrożenia. Pisanie klienta SFTP lub serwera SFTP nie jest łatwym zadaniem.

Jest to jednak bardzo mało prawdopodobne, aby wpłynęło na organizacje korzystające z SFTP jako część ich infrastruktury – na różnych platformach dostępnych jest wiele różnych klientów i serwerów, i potrzebują tylko wyboru najbardziej odpowiednich aplikacji. Wszyscy klienci i serwer powinni interopować, więc wybór produktów jest znaczna szerokość geograficzna. Jest prawdopodobne, że funkcje dodatkowe dla protokołu będą dyktować ostateczny wybór.

Wniosek

Ta zawartość wyjaśniła, w jaki sposób SSL/TLS i SSH działają w celu zabezpieczenia danych przesyłanych przez sieć, a zwłaszcza protokołów FTPS i SFTP. Podczas gdy podobnie w funkcjonalności, FTPS i SFTP są bardzo różne w implementacji. W porównaniu z głową SFTP wychodzi na górę, chociaż rozsądnie może być wspieranie obu protokołów w infrastrukturze technicznej organizacji.

Inne artykuły techniczne

• Co to jest zarządzane przesyłanie plików (MFT)?
• Co to jest SFTP?
• Co to jest FTP?
• Co to jest FTPS?
• FTPS vs SFTP

SSL vs SSH-niezbyt techniczne porównanie

Czy wiesz, że SFTP i FTP otrzymują bezpieczeństwo przed protokołami podstawowymi? Odkryj dziś podobieństwa i różnice między SSH i SSL!

Przegląd

Najczęściej używane bezpieczne protokoły przesyłania plików, SFTP i FTPS, uzyskaj bezpieczeństwo z protokołów podstawowych. SFTP z SSH i FTPS z SSL. Porównajmy te dwa.

W przeszłości istniała tylko jedna popularna metoda przesyłania plików przez sieć – FTP, która po prostu oznacza protokół transferu plików. FTP obsługuje transfery plików luzem, a nawet pozwala użytkownikom nawigować zdalne katalogi, tworzyć katalogi, usuwać katalogi i wykonywać kilka innych zadań podobnych do tych wykonanych w lokalnych systemach plików.

FTP to protokół oparty na TCP. Dlatego może być bardzo przydatne do pobierania/przesyłania plików na sieci LAN lub nawet przez Internet. Jednak FTP zostało zaprojektowane w czasie, gdy korzystanie z Internetu było ograniczone do kilku organizacji, a zagrożenia sieciowe nie istniały.

Dzisiaj istnieje wiele zagrożeń, a połączenia FTP można zagrożone przez ataki snifferowe, brutalną siłę i inne formy cyberataków. Aby chronić transfery plików przed tymi zagrożeniami, opracowano bezpieczne protokoły transferu plików. Z tych protokołów dwa zyskały szeroko rozpowszechnione przyjęcie – FTP i SFTP.

FTPS faktycznie otrzymuje ochronę przed SSL/TLS (bezpieczeństwo warstwy warstwy/transportu Secure Sockets), a SFTP otrzymuje własne z SSH (Secure Shell).

Podobieństwa między SSH i SSL

Po porównaniu ich atrybutów bezpieczeństwa przekonasz się, że SSH i SSL mają bardzo silne podobieństwa. Oba oferują szyfrowanie danych, uwierzytelnianie serwera, uwierzytelnianie klienta i mechanizmy integralności danych.

Szyfrowanie danych w ruchu

Szyfrowanie danych w ruchu to zdolność bezpieczeństwa, która uniemożliwia przeglądaniu danych wysyłanych danych wysyłanych przez sieć. Innymi słowy, utrzymuje poufność przesyłanych danych. Jest obsługiwany zarówno w SSH, jak i SSL i działa poprzez przekształcenie danych typu zwykłego w tak zwane ciphertext.

Wszystko, co podsługa zobaczy, przeglądając szyfhertekt na zaszyfrowanym połączeniu, byłby niezrozumiałym ciągiem znaków.

Te dwa zrzuty ekranu pokazują, co widzi podsłuchiwanie podczas wąchania niezaszyfrowanego połączenia i zaszyfrowanego połączenia. Zwróć uwagę, jak niezaszyfrowane połączenie nie ukrywa nazwy użytkownika i hasła. W niezaszyfrowanym połączeniu te poświadczenia logowania są już niezrozumiałe.

Niezaszyfrowane połączenie (e.G. FTP)

Szyfrowane połączenie (e.G. SFTP lub FTPS)

Zarówno SSH, jak i SSL zapewniają szyfrowanie danych w zakresie, które jest znane jako szyfrowanie klucza symetrycznego. Ten rodzaj szyfrowania wykorzystuje współdzielony klucz, który jest używany zarówno do szyfrowania, jak i deszyfrowania. Niektóre popularne symetryczne kluczowe szyfry obejmują AES, 3DES, Blowfish, Twofish i RC4.

Uwierzytelnianie serwera i klienta

Zaszyfrowane połączenie staje się bezużyteczne, jeśli nieświadomie podłączasz się do fałszywego serwera lub złośliwego klienta. Podczas gdy SSH i SSL używają symetrycznej kryptografii, aby zachować poufność przesyłanych danych, używają innej formy szyfrowania do uwierzytelnienia. Uwierzytelnianie pozwala jednej ze stron zweryfikować, czy druga strona jest tak naprawdę, kim twierdzi, że jest.

Aby zaimplementować uwierzytelnianie, SSH i SSL Użyj asymetrycznej kryptografii A.k.A. Kryptografia klucza publicznego. Popularne algorytmy szyfrowania klucza publicznego to RSA, DSA i ECDSA, z których wszystkie są obsługiwane zarówno przez SSH i SSL.

W przeciwieństwie do Symmetrycznego szyfrowania, które wykorzystuje pojedynczy klucz do szyfrowania i deszyfrowania, szyfrowanie asymetryczne używa dwóch kluczy – klucza publicznego i klucza prywatnego.

Klient może być używany przez klienta do uwierzytelniania serwera. Jest to znane jako uwierzytelnianie serwera. Uwierzytelnianie serwera uniemożliwia nieumyślne połączenie aplikacji klienta, a następnie transakcje z złośliwym serwerem, który podszywa się.

I odwrotnie, szyfrowanie klucza publicznego może być również używane przez serwer do uwierzytelnienia klienta. Jest to znane jako uwierzytelnianie klienta. Artykuł Co to jest klucz SFTP Obejmuje miłe wprowadzenie do uwierzytelniania klienta i kryptografię klucza publicznego.

Mechanizmy integralności danych

Kiedy otrzymujesz poufne informacje, integralność danych jest równie ważna jak poufność danych. Będziesz chciał upewnić się, że otrzymane dane to dokładnie te same dane, które były pierwotnie przesyłane przez nadawcę.

W szczególności firmy wymagają wysokiego poziomu pewności dla integralności danych, gdy przeprowadzają transakcje przez Internet. Zmieszczone dane mogą negatywnie wpłynąć na procesy biznesowe, a nawet mogą być oznaką nieuczciwych działań.

Mechanizmy integralności danych umożliwiają stronom transakcyjne sprawdzenie, czy przesłana wiadomość była niezmieniona po drodze. MAC (kod uwierzytelnienia wiadomości) Algorytmy, takie jak SHA1, SHA256 (i inne wersje SHA) i MD5 są zwykle stosowane zarówno przez SSH, jak i SSL do przeprowadzania kontroli integralności danych na przesłanych wiadomościach.

Artykuł Zrozumienie mieszania zawiera miłą dyskusję na ten temat.

Różnice między SSL i SSH

Jedną z najbardziej zauważalnych różnic między SSL/TLS i SSH jest to, że SSL normalnie (tak, mogą istnieć wyjątki) zatrudnia x.509 cyfrowe certyfikaty uwierzytelniania serwera i klienta, podczas gdy SSH nie. A ponieważ SSL korzysta z certyfikatów cyfrowych, w konsekwencji wymaga również obecności infrastruktury klucza publicznego (PKI) i udziału Urzędu Świadectwa (CA).

Chociaż możliwe jest zastosowanie tak zwanych certyfikatów z podpisem, w którym to przypadku SSL staje się bardzo podobne do SSH z powodu braku CA, nie jest to zalecana praktyka. Self-podpisane certyfikaty są dopuszczalne tylko w transakcjach wewnątrz organizacyjnych, z wyjątkiem dużych (e.G. organizacje rozpowszechnione na całym świecie.

Kolejną dużą różnicą jest to, że SSH ma wbudowaną więcej funkcjonalności. Na przykład, SSH może umożliwić użytkownikom zalogowanie się na serwer i zdalnie wykonywać polecenia. SSL nie ma tej możliwości. Musisz sparować go z innym protokołem (e.G. HTTP, FTP lub WebDAV), aby miało podobne funkcje.

SSH z łatwością obsługuje multipleksowanie połączeń, kontrolę przepływu, zarządzanie terminalami i inne funkcje. Oczywiście, te dodatkowe funkcje nie są już podlegające naszej oryginalnej dyskusji, w której zaczęliśmy porównywać SSL i SSH w odniesieniu do SFTP i FTPS.

Więc zanim odejdziemy dalej, zakończmy tutaj.

Zaczynaj

Czy chciałbyś wypróbować serwer transferu plików obsługujący FTPS i SFTP, a także inne protokoły? Wypróbuj bezpłatną, w pełni funkcjonalną edycję oceny Jscape MFT Server już dziś.

popularne artykuły

Konfigurowanie uwierzytelniania klucza publicznego SFTP w wierszu poleceń

6 min, czytanie – 11 grudnia 2022

SFTP umożliwia uwierzytelnianie klientów za pomocą kluczy publicznych, co oznacza, że ​​wygrali’T potrzebuję hasła. Dowiedz się, jak skonfigurować to w wierszu poleceń online. Przeczytaj artykuł

Aktywny vs. Pasywny FTP Uproszczony: Zrozumienie portów FTP

7 min, czytanie – 11 grudnia 2022

Jeśli istnieją problemy z połączeniem z serwerem FTP, sprawdź tryb transferu. Niech Jscape pomoże Ci zrozumieć różnicę w aktywnym i pasywnym FTP. Przeczytaj artykuł

Aktywnie aktywny vs. Aktywnie pasujące klastrowanie o wysokiej dostępności

3 min, czytanie – 11 grudnia 2022

Najczęściej stosowane konfiguracje klastrowania o wysokiej dostępności są aktywne i aktywne. Poznaj różnicę między dwoma online! Przeczytaj artykuł

Korzystanie ze skryptów Windows FTP do automatyzacji transferów plików

4 min, przeczytaj – 11 grudnia 2022

Dowiedz się, jak automatyzować transfery plików za pomocą scenariuszy Windows FTP. Ten post wyjaśnia, jakie są skrypty FTP i jak tworzyć proste skrypty do przesyłania plików. Przeczytaj artykuł

Czy SSH używa TLS lub SSL

Оjed

Ыы зарегистрир John. С помощю этой страницы ыы сожем оRipееделить, что запросы оRтравляете имено ыы, а не роvert. Почем это могло пRроизойиS?

Эта страница отображается тех слччаях, когда автоматическими системамgz которые наршают усовия исполззования. Страница перестанеura. До этого момента для исползования слжжж Google неоtoś.

Источником запросов может слжить ведоносное по, подкbarów. ыылку заRzy. Еarag ы исползеете общий доступ и интернет, проблема может ыть с компюююеyn с таким жж жж жесом, кк у комszczeюююе000. Обратитеunks к соем системном адинистратору. Подроlit.

Проверка по слову может также появаятьenia, еaсли ы водите сложные ззапры, оind обычно enia оиизи инenia оtoś еами, или же водите заlektora.

SSH vs SSL: Różnice i podobieństwa między nimi [MINITOOL TIPS]

Jakie są różnice między SSH i SSL? Który jest lepszy? Jeśli próbujesz znaleźć te pytania’ Odpowiedzi, ten post jest tym, czego potrzebujesz. Ten post z MiniTool zawiera ich definicje, a także informacje o SSH vs SSL.

Co to jest SSH

Co oznacza SSH? SSH jest również znany jako Secure Shell, która jest metodą bezpiecznej komunikacji ze zdalnymi komputerami. SSH służy do interakcji z powłoką operacyjną innego systemu do zdalnego wykonywania poleceń.

SSH może być pierwotnie używany tylko na komputerach opartych na UNIX, ale teraz możesz go używać w systemie Windows. SSH to protokół szyfrowania, który tworzy tunel między dwoma komputerami zdalnymi. Może ten post – jak skonfigurować Klient i serwer SSH w systemie Windows 10 [pełny przewodnik] jest tym, czego potrzebujesz.

Co to jest SSL/TLS

Co to jest SSL lub co to jest TLS? SSL i TLS to mechanizmy ochrony bezpieczeństwa stron internetowych. Chociaż SSL i TLS robią to samo, TLS stopniowo zastępuje SSL w implementacji sieci. Korzystają z podpisów cyfrowych generowanych przez organy certyfikatu, aby umożliwić zaufanie między tobą a dostawcami.

SSH vs SSL

SSH i SSL/TLS zwykle mają różne zastosowania. SSH służy do wykonywania zadań, z którymi zwykli internauci nigdy nie muszą sobie radzić. Z drugiej strony zwykli użytkownicy Internetu używają SSL/TLS. Poniżej znajdują się informacje o SSL vs SSH.

Podobieństwa

Teraz pozwól’s patrz podobieństwa między SSH i SSL. Po pierwsze, zarówno SSH, jak i SSL to trzycyfrowe skróty, które zaczynają się od tej samej litery. Następnie są to dwa protokoły używane w bezpiecznych połączeniach. Wreszcie, obaj używają szyfrowania do ochrony danych przekazywanych między dwoma urządzeniami sieciowymi.

Różnice

Właśnie teraz znasz podobieństwa między SSH i SSL. Wtedy pozwolić’S zobacz różnice między SSH i SSL.

1. SSH działa na porcie 22, podczas gdy SSL działa na porcie 443.

2. SSH opiera się na tunelach sieciowych, a SSL opiera się na certyfikatach.

3. Technicznie SSH służy do ochrony sieci komputerowej, podczas gdy SSL służy do ochrony transmisji danych online.

4. SSH używa procesu uwierzytelniania nazwy użytkownika/hasła do ustanowienia bezpiecznego połączenia, podczas gdy SSL tego nie rozważa.

5. SSL służy do bezpiecznego przesyłania kluczowych informacji, takich jak karty kredytowe i banki. A SSH służy do bezpiecznego wykonywania poleceń w Internecie.

6. SSL zwykle (z wyjątkiem wyjątków) używa x.509 cyfrowe certyfikaty uwierzytelniania serwera i klienta, podczas gdy SSH nie.

7. SSL służy do szyfrowania komunikacji między przeglądarką a serwerem. Z drugiej strony SSH służy do szyfrowania komunikacji między dwoma komputerami w Internecie.

8. W SSL komunikacja jest uwierzytelniona przez parę klucza prywatnego/publicznego. W SSH komunikacja jest uwierzytelniona za pośrednictwem par kluczy prywatnych/publicznych lub pary nazwy użytkownika/haseł.

9. Inną ważną różnicą jest to, że SSH ma bardziej wbudowane funkcje niż SSL. Pomaga zalogować się do serwera i zdalnie wykonuje polecenia, a SSL nie ma tej funkcji. Aby osiągnąć tę funkcję, musisz sparować ją z innymi protokołami – HTTP, FTP.

5 sposobów rozwiązania błędu HTTP 401 nieautoryzowane

Otwierając przeglądarkę, aby coś wyszukać, możesz spotkać się z błędem HTTP 401 nieautoryzowanym. Ten post pokazuje, jak rozwiązać ten błąd 401.

Ostateczne słowa

Oto wszystkie informacje o SSH vs SSL. Po przeczytaniu tego postu powinieneś wiedzieć, czym są SSH i SSL. Z tego postu wiesz, że podobieństwa i różnice między SSH i SSL.

• Facebook
• Świergot
• LinkedIn
• Reddit

O autorze

Daisy ukończyła studia w języku angielskim, a następnie dołączyła do Minitool jako redaktor. Specjalizuje się w pisaniu artykułów na temat tworzenia kopii zapasowych danych i systemów, klonowania dysków i synchronizacji plików itp. Jest również dobra w pisaniu artykułów na temat wiedzy komputerowej i problemów komputerowych. W życiu codziennym lubi biegać i chodzić do Park Rozrywki z przyjaciółmi, aby zagrać w ekscytujące przedmioty.