Bezpieczeństwo sieci - warstwa transportowa

Bezpieczeństwo sieci polega na zabezpieczaniu danych przed atakami podczas ich przesyłania w sieci. Aby osiągnąć ten cel, zaprojektowano wiele protokołów bezpieczeństwa w czasie rzeczywistym. Istnieją popularne standardy protokołów bezpieczeństwa sieci w czasie rzeczywistym, takie jak S / MIME, SSL / TLS, SSH i IPsec. Jak wspomniano wcześniej, protokoły te działają na różnych warstwach modelu sieci.

W ostatnim rozdziale omówiliśmy kilka popularnych protokołów zaprojektowanych w celu zapewnienia bezpieczeństwa warstwy aplikacji. W tym rozdziale omówimy proces osiągania bezpieczeństwa sieci w warstwie transportowej i powiązane protokoły bezpieczeństwa.

W przypadku sieci opartej na protokole TCP / IP warstwy fizyczne i łącza danych są zwykle implementowane w terminalu użytkownika i sprzęcie karty sieciowej. Warstwy TCP i IP są zaimplementowane w systemie operacyjnym. Wszystko powyżej TCP / IP jest implementowane jako proces użytkownika.

Potrzeba zabezpieczenia warstwy transportowej

Omówmy typową internetową transakcję biznesową.

Bob odwiedza witrynę Alice, aby sprzedawać towary. W formularzu na stronie internetowej Bob wpisuje rodzaj towaru i żądaną ilość, swój adres i dane karty płatniczej. Bob klika „Prześlij” i czeka na dostawę towaru, obciążając jego konto kwotą ceny. Wszystko to brzmi dobrze, ale w przypadku braku zabezpieczeń sieci Bob może spotkać się z kilkoma niespodziankami.

  • Jeśli transakcje nie wykorzystywały poufności (szyfrowania), osoba atakująca mogłaby uzyskać informacje o swojej karcie płatniczej. Atakujący może wtedy dokonać zakupów na koszt Boba.

  • Jeśli nie jest stosowana żadna miara integralności danych, osoba atakująca może zmodyfikować zamówienie Roberta pod względem rodzaju lub ilości towarów.

  • Wreszcie, jeśli nie jest używane żadne uwierzytelnianie serwera, serwer może wyświetlać słynne logo Alicji, ale witryna może być złośliwą witryną utrzymywaną przez atakującego podszywającego się pod Alicję. Po otrzymaniu rozkazu Boba mógł zabrać pieniądze Boba i uciec. Albo może dokonać kradzieży tożsamości, zbierając imię i nazwisko Boba oraz dane karty kredytowej.

Schematy zabezpieczeń warstwy transportowej mogą rozwiązać te problemy, ulepszając komunikację sieciową opartą na protokole TCP / IP o poufność, integralność danych, uwierzytelnianie serwera i uwierzytelnianie klienta.

Zabezpieczenia w tej warstwie są najczęściej używane do zabezpieczania transakcji internetowych opartych na protokole HTTP w sieci. Jednak może być używany przez dowolną aplikację działającą przez TCP.

Filozofia projektowania TLS

Protokoły Transport Layer Security (TLS) działają powyżej warstwy TCP. Konstrukcja tych protokołów wykorzystuje popularne interfejsy programów użytkowych (API) do TCP, zwane „gniazdami” do łączenia się z warstwą TCP.

Aplikacje są teraz połączone bezpośrednio z Transport Security Layer zamiast TCP. Transport Security Layer zapewnia proste API z gniazdami, które jest podobne i analogiczne do API TCP.

Na powyższym diagramie, chociaż technicznie TLS znajduje się między aplikacją a warstwą transportową, z powszechnej perspektywy jest to protokół transportowy, który działa jako warstwa TCP wzbogacona o usługi bezpieczeństwa.

TLS został zaprojektowany do działania przez TCP, niezawodny protokół warstwy 4 (nie na protokole UDP), aby projekt TLS był znacznie prostszy, ponieważ nie musi martwić się o „przekroczenie limitu czasu” i „ponowne przesłanie utraconych danych”. Warstwa TCP nadal robi to w zwykły sposób, co zaspokaja potrzebę TLS.

Dlaczego TLS jest popularny?

Powodem popularności korzystania z zabezpieczeń w Transport Layer jest prostota. Projektowanie i wdrażanie zabezpieczeń w tej warstwie nie wymaga żadnych zmian w protokołach TCP / IP zaimplementowanych w systemie operacyjnym. Jedynie procesy i aplikacje użytkownika wymagają projektowania / modyfikacji, co jest mniej złożone.

Secure Socket Layer (SSL)

W tej sekcji omówimy rodzinę protokołów zaprojektowanych dla TLS. Rodzina obejmuje SSL w wersji 2 i 3 oraz protokół TLS. SSLv2 został teraz zastąpiony przez SSLv3, więc skupimy się na SSL v3 i TLS.

Krótka historia SSL

W roku 1995 Netscape opracował SSLv2 i użył go w Netscape Navigator 1.1. Wersja SSL 1 nigdy nie została opublikowana ani używana. Później firma Microsoft ulepszyła SSLv2 i wprowadziła inny podobny protokół o nazwie Private Communications Technology (PCT).

Firma Netscape znacznie ulepszyła protokół SSLv2 w zakresie różnych kwestii związanych z bezpieczeństwem i wdrożyła protokół SSLv3 w 1999 r. Następnie Internet Engineering Task Force (IETF) wprowadziła podobny protokół TLS (Transport Layer Security) jako otwarty standard. Protokół TLS nie współpracuje z SSLv3.

TLS zmodyfikował algorytmy kryptograficzne do rozszerzania klucza i uwierzytelniania. Ponadto protokół TLS zasugerował użycie otwartego krypto Diffie-Hellmana (DH) i standardu podpisu cyfrowego (DSS) zamiast opatentowanego krypto RSA używanego w SSL. Jednak ze względu na wygaśnięcie patentu RSA w 2000 r. Nie było mocnych powodów, dla których użytkownicy mieliby odejść od szeroko rozpowszechnionego SSLv3 na TLS.

Istotne cechy SSL

Istotne cechy protokołu SSL są następujące -

  • SSL zapewnia bezpieczeństwo połączenia sieciowego dzięki -

    • Confidentiality - Informacje są wymieniane w postaci zaszyfrowanej.

    • Authentication- Podmioty komunikacyjne identyfikują się za pomocą certyfikatów cyfrowych. Uwierzytelnianie na serwerze internetowym jest obowiązkowe, natomiast uwierzytelnianie klienta jest opcjonalne.

    • Reliability - Utrzymuje kontrolę integralności wiadomości.

  • SSL jest dostępny dla wszystkich aplikacji TCP.

  • Obsługiwane przez prawie wszystkie przeglądarki internetowe.

  • Zapewnia łatwość prowadzenia interesów z nowymi podmiotami online.

  • Opracowany głównie dla handlu elektronicznego w sieci Web.

Architektura SSL

SSL jest specyficzny dla TCP i nie działa z UDP. SSL zapewnia aplikacjom interfejs programowania aplikacji (API). Biblioteki / klasy C i Java SSL są łatwo dostępne.

Protokół SSL jest przeznaczony do współpracy między aplikacją a warstwą transportową, jak pokazano na poniższym obrazku -

Sam SSL nie jest protokołem jednowarstwowym, jak pokazano na obrazku; w rzeczywistości składa się z dwóch podwarstw.

  • Dolna warstwa podrzędna składa się z jednego składnika protokołu SSL zwanego protokołem SSL Record. Ten komponent zapewnia usługi w zakresie integralności i poufności.

  • Górna warstwa podrzędna składa się z trzech komponentów protokołu związanych z SSL i protokołu aplikacji. Komponent aplikacji zapewnia usługę przesyłania informacji między interakcjami klient / serwer. Technicznie może również działać na warstwie SSL. Trzy składniki protokołu związane z SSL to -

    • SSL Handshake Protocol
    • Zmień protokół specyfikacji szyfrowania
    • Protokół alertów.
  • Te trzy protokoły zarządzają wszystkimi wymianami komunikatów SSL i zostaną omówione w dalszej części tej sekcji.

Funkcje składników protokołu SSL

Cztery podkomponenty protokołu SSL obsługują różne zadania związane z bezpieczną komunikacją między komputerem klienckim a serwerem.

  • Protokół nagrywania

    • Warstwa rekordu formatuje komunikaty protokołu wyższej warstwy.

    • Fragmentuje dane na łatwe w zarządzaniu bloki (maksymalna długość 16 KB). Opcjonalnie kompresuje dane.

    • Szyfruje dane.

    • Zawiera nagłówek dla każdej wiadomości i skrót (kod uwierzytelniania wiadomości (MAC)) na końcu.

    • Przekazuje sformatowane bloki do warstwy TCP w celu transmisji.

  • SSL Handshake Protocol

    • Jest to najbardziej złożona część SSL. Jest wywoływana przed przesłaniem jakichkolwiek danych aplikacji. Tworzy sesje SSL między klientem a serwerem.

    • Ustanowienie sesji obejmuje uwierzytelnienie serwera, negocjację klucza i algorytmu, ustanowienie kluczy i uwierzytelnienie klienta (opcjonalnie).

    • Sesja jest identyfikowana przez unikalny zestaw kryptograficznych parametrów bezpieczeństwa.

    • Wiele bezpiecznych połączeń TCP między klientem a serwerem może współużytkować tę samą sesję.

    • Działania protokołu Handshake w czterech fazach. Zostały one omówione w następnej sekcji.

  • Protokół ChangeCipherSpec

    • Najprostsza część protokołu SSL. Składa się z pojedynczej wiadomości wymienianej między dwoma komunikującymi się jednostkami, klientem i serwerem.

    • Gdy każda jednostka wysyła komunikat ChangeCipherSpec, zmienia swoją stronę połączenia w stan bezpieczny zgodnie z ustaleniami.

    • Stan oczekujących parametrów szyfrowania jest kopiowany do stanu bieżącego.

    • Wymiana tej wiadomości oznacza, że ​​wszystkie przyszłe wymiany danych są szyfrowane, a integralność jest chroniona.

  • Protokół alertów SSL

    • Ten protokół jest używany do zgłaszania błędów - takich jak nieoczekiwany komunikat, zły rekord MAC, nieudana negocjacja parametrów bezpieczeństwa itp.

    • Służy również do innych celów - takich jak powiadamianie o zamknięciu połączenia TCP, powiadamianie o otrzymaniu złego lub nieznanego certyfikatu itp.

Utworzenie sesji SSL

Jak omówiono powyżej, istnieją cztery fazy ustanawiania sesji SSL. Są one obsługiwane głównie przez protokół SSL Handshake.

Phase 1 - Ustanowienie możliwości bezpieczeństwa.

  • Ta faza obejmuje wymianę dwóch wiadomości - Client_hello i Server_hello .

  • Client_hello zawiera listę algorytmów kryptograficznych obsługiwanych przez klienta w malejącej kolejności według preferencji.

  • Server_hello zawiera wybrany Cipher Specification (CipherSpec) i nowy SESSION_ID .

  • CipherSpec zawiera pola takie jak -

    • Algorytm szyfrowania (DES, 3DES, RC2 i RC4)

    • Algorytm MAC (oparty na MD5, SHA-1)

    • Algorytm klucza publicznego (RSA)

    • Obie wiadomości mają „nonce”, aby zapobiec atakowi typu Replay.

Phase 2 - Uwierzytelnianie serwera i wymiana kluczy.

  • Serwer wysyła certyfikat. Oprogramowanie klienckie jest dostarczane z kluczami publicznymi różnych „zaufanych” organizacji (CA) w celu sprawdzenia certyfikatu.

  • Serwer wysyła wybrany zestaw szyfrów.

  • Serwer może zażądać certyfikatu klienta. Zwykle się tego nie robi.

  • Serwer wskazuje koniec Server_hello .

Phase 3 - Uwierzytelnianie klienta i wymiana kluczy.

  • Klient wysyła certyfikat tylko na żądanie serwera.

  • Wysyła również Pre-Master Secret (PMS) zaszyfrowany kluczem publicznym serwera.

  • Klient wysyła również wiadomość Certificate_verify, jeśli zostanie przez niego wysłany certyfikat, aby udowodnić, że posiada klucz prywatny powiązany z tym certyfikatem. Zasadniczo klient podpisuje skrót poprzednich wiadomości.

Phase 4 - koniec.

  • Klient i serwer wysyłają do siebie komunikaty Change_cipher_spec w celu skopiowania oczekującego stanu szyfrowania do stanu bieżącego.

  • Od teraz wszystkie dane są szyfrowane i chronione integralnością.

  • Komunikat „Zakończono” z każdego końca potwierdza, że ​​procesy wymiany kluczy i uwierzytelniania zakończyły się pomyślnie.

Wszystkie cztery fazy, omówione powyżej, zachodzą podczas ustanawiania sesji TCP. Nawiązywanie sesji SSL rozpoczyna się po TCP SYN / SYNACK i kończy przed TCP Fin.

Wznawianie rozłączonej sesji

  • Możliwe jest wznowienie rozłączonej sesji (poprzez komunikat Alert ), jeśli klient wyśle hello_request do serwera z zaszyfrowaną informacją session_id .

  • Następnie serwer określa, czy session_id jest prawidłowy. Jeśli zostanie zweryfikowana, wymienia ChangeCipherSpec i zakończone komunikaty z klientem i wznawia bezpieczną komunikację.

  • Pozwala to uniknąć ponownego obliczania parametrów szyfrowania sesji i oszczędza obliczenia na serwerze i po stronie klienta.

Klucze sesji SSL

Widzieliśmy, że podczas fazy 3 ustanawiania sesji SSL klient przesyła do serwera pre-master sekret zaszyfrowany za pomocą klucza publicznego serwera. Główny sekret i różne klucze sesji są generowane w następujący sposób -

  • Główny sekret jest generowany (za pomocą generatora liczb pseudolosowych) za pomocą -

    • Sekret przedpremierowy.

    • Dwie wartości nonce (RA i RB) wymienione w komunikatach client_hello i server_hello.

  • Sześć tajnych wartości jest następnie wyprowadzanych z tego głównego sekretu:

    • Tajny klucz używany z MAC (dla danych wysyłanych przez serwer)

    • Tajny klucz używany z MAC (dla danych wysyłanych przez klienta)

    • Tajny klucz i IV używane do szyfrowania (według serwera)

    • Tajny klucz i IV używane do szyfrowania (przez klienta)

Protokół TLS

W celu zapewnienia otwartego internetowego standardu SSL, IETF wypuścił protokół Transport Layer Security (TLS) w styczniu 1999. TLS jest zdefiniowany jako proponowany Internet Standard w RFC 5246.

Zasadnicze elementy

  • Protokół TLS ma te same cele co SSL.

  • Umożliwia aplikacjom klient / serwer komunikację w bezpieczny sposób poprzez uwierzytelnianie, zapobieganie podsłuchiwaniu i przeciwstawianie się modyfikacjom wiadomości.

  • Protokół TLS znajduje się nad niezawodną, ​​zorientowaną połączeniowo warstwą transportową TCP w stosie warstw sieciowych.

  • Architektura protokołu TLS jest podobna do protokołu SSLv3. Ma dwa protokoły podrzędne: protokół TLS Record i protokół TLS Handshake.

  • Chociaż protokoły SSLv3 i TLS mają podobną architekturę, wprowadzono kilka zmian w architekturze i działaniu, szczególnie w przypadku protokołu uzgadniania.

Porównanie protokołów TLS i SSL

Istnieje osiem głównych różnic między protokołami TLS i SSLv3. Są to następujące -

  • Protocol Version - Nagłówek segmentu protokołu TLS zawiera numer wersji 3.1 w celu rozróżnienia między numerem 3 przenoszonym przez nagłówek segmentu protokołu SSL.

  • Message Authentication- TLS wykorzystuje kod uwierzytelniania wiadomości z kluczem skrótu (H-MAC). Zaletą jest to, że H-MAC działa z dowolną funkcją skrótu, nie tylko MD5 lub SHA, jak wyraźnie określono w protokole SSL.

  • Session Key Generation - Istnieją dwie różnice między protokołami TLS i SSL do generowania materiału klucza.

    • Metoda obliczania tajemnic wstępnych i głównych jest podobna. Jednak w protokole TLS do obliczania klucza głównego używa się standardu HMAC i wyjścia funkcji pseudolosowej (PRF) zamiast adresu MAC ad-hoc.

    • Algorytm obliczania kluczy sesji i wartości inicjacji (IV) jest inny w protokole TLS niż SSL.

  • Komunikat protokołu alertów -

    • Protokół TLS obsługuje wszystkie wiadomości używane przez protokół Alert SSL, z wyjątkiem komunikatu o braku certyfikatu , który jest zbędny. Klient wysyła pusty certyfikat, jeśli uwierzytelnienie klienta nie jest wymagane.

    • Wiele dodatkowych komunikatów alarmowych jest zawartych w protokole TLS dla innych warunków błędów, takich jak record_overflow, decode_error itp.

  • Supported Cipher Suites- SSL obsługuje zestawy szyfrów RSA, Diffie-Hellman i Fortezza. Protokół TLS obsługuje wszystkie kombinezony oprócz Fortezza.

  • Client Certificate Types- TLS definiuje typy certyfikatów, które mają być wymagane w wiadomości certificate_request . SSLv3 obsługuje wszystkie te elementy. Ponadto SSL obsługuje niektóre inne typy certyfikatów, takie jak Fortezza.

  • CertyfikatZweryfikuj i zakończone wiadomości -

    • W SSL dla wiadomości certificate_verify używana jest złożona procedura wiadomości. W przypadku protokołu TLS zweryfikowane informacje są zawarte w samych komunikatach uzgadniania, co pozwala uniknąć tej złożonej procedury.

    • Gotowa wiadomość jest obliczana na różne sposoby w protokołach TLS i SSLv3.

  • Padding of Data- W protokole SSL dopełnienie dodane do danych użytkownika przed szyfrowaniem jest minimalną ilością wymaganą, aby całkowity rozmiar danych był równy wielokrotności długości bloku szyfru. W protokole TLS dopełnienie może być dowolną wielkością, która daje w wyniku rozmiar danych będący wielokrotnością długości bloku szyfru, maksymalnie do 255 bajtów.

Powyższe różnice między protokołami TLS i SSLv3 podsumowano w poniższej tabeli.

Bezpieczne przeglądanie - HTTPS

W tej sekcji omówimy wykorzystanie protokołu SSL / TLS do bezpiecznego przeglądania sieci.

Zdefiniowany przez HTTPS

Do przeglądania stron internetowych używany jest protokół Hyper Text Transfer Protocol (HTTP). Funkcja HTTPS jest podobna do HTTP. Jedyną różnicą jest to, że HTTPS zapewnia „bezpieczne” przeglądanie sieci. HTTPS to skrót od HTTP over SSL. Ten protokół służy do zapewniania zaszyfrowanego i uwierzytelnionego połączenia między przeglądarką internetową klienta a serwerem witryny internetowej.

Bezpieczne przeglądanie za pośrednictwem protokołu HTTPS zapewnia szyfrowanie następujących treści -

  • URL żądanej strony internetowej.
  • Zawartość strony internetowej dostarczana przez serwer do klienta użytkownika.
  • Treść formularzy wypełnianych przez użytkownika.
  • Pliki cookie utworzone w obu kierunkach.

Działanie HTTPS

Protokół aplikacji HTTPS zazwyczaj wykorzystuje jeden z dwóch popularnych protokołów zabezpieczeń warstwy transportowej - SSL lub TLS. Proces bezpiecznego przeglądania opisano w poniższych punktach.

  • Żądasz połączenia HTTPS ze stroną internetową, wpisując https: //, a po nim adres URL w pasku adresu przeglądarki.

  • Przeglądarka internetowa inicjuje połączenie z serwerem WWW. Użycie https wywołuje użycie protokołu SSL.

  • Aplikacja, w tym przypadku przeglądarka, używa portu systemowego 443 zamiast portu 80 (używanego w przypadku http).

  • Protokół SSL przechodzi przez protokół uzgadniania w celu ustanowienia bezpiecznej sesji, jak omówiono we wcześniejszych sekcjach.

  • Witryna początkowo wysyła swój cyfrowy certyfikat SSL do przeglądarki. Po weryfikacji certyfikatu uzgadnianie SSL postępuje w celu wymiany wspólnych sekretów dla sesji.

  • Gdy serwer korzysta z zaufanego certyfikatu cyfrowego SSL, użytkownicy widzą ikonę kłódki na pasku adresu przeglądarki. Po zainstalowaniu certyfikatu Extended Validation w witrynie internetowej pasek adresu zmienia kolor na zielony.

  • Po ustanowieniu sesja ta składa się z wielu bezpiecznych połączeń między serwerem WWW a przeglądarką.

Korzystanie z HTTPS

  • Korzystanie z HTTPS zapewnia poufność, uwierzytelnianie serwera i integralność wiadomości dla użytkownika. Umożliwia bezpieczne prowadzenie handlu elektronicznego w Internecie.

  • Zapobiega podsłuchiwaniu danych i kradzieży tożsamości, które są powszechnymi atakami na HTTP.

Współczesne przeglądarki internetowe i serwery internetowe są wyposażone w obsługę HTTPS. Korzystanie z HTTPS przez HTTP wymaga jednak większej mocy obliczeniowej po stronie klienta i serwera, aby przeprowadzić szyfrowanie i uzgadnianie SSL.

Secure Shell Protocol (SSH)

Istotne cechy SSH są następujące -

  • SSH to protokół sieciowy działający na wierzchu warstwy TCP / IP. Ma on zastąpić TELNET, który zapewniał niezabezpieczone środki zdalnego logowania.

  • SSH zapewnia bezpieczną komunikację klient / serwer i może być używany do zadań, takich jak przesyłanie plików i poczta e-mail.

  • SSH2 to rozpowszechniony protokół, który zapewnia lepsze bezpieczeństwo komunikacji sieciowej w porównaniu z wcześniejszą wersją SSH1.

Zdefiniowany przez SSH

SSH jest zorganizowany jako trzy protokoły podrzędne.

  • Transport Layer Protocol- Ta część protokołu SSH zapewnia poufność danych, uwierzytelnianie serwera (hosta) i integralność danych. Opcjonalnie może również zapewniać kompresję danych.

    • Server Authentication- Klucze hosta są asymetryczne, podobnie jak klucze publiczne / prywatne. Serwer używa klucza publicznego do udowodnienia swojej tożsamości klientowi. Klient sprawdza, czy serwer, z którym nawiązał kontakt, jest „znanym” hostem z bazy danych, którą utrzymuje. Po uwierzytelnieniu serwera generowane są klucze sesji.

    • Session Key Establishment- Po uwierzytelnieniu serwer i klient zgadzają się na użycie szyfru. Klucze sesji są generowane zarówno przez klienta, jak i przez serwer. Klucze sesji są generowane przed uwierzytelnieniem użytkownika, dzięki czemu nazwy użytkowników i hasła mogą być przesyłane w postaci zaszyfrowanej. Te klucze są zwykle wymieniane w regularnych odstępach czasu (powiedzmy co godzinę) podczas sesji i są niszczone natychmiast po użyciu.

    • Data Integrity- SSH wykorzystuje algorytmy Message Authentication Code (MAC) do sprawdzania integralności danych. Jest to ulepszenie w stosunku do 32-bitowego CRC używanego przez SSH1.

  • User Authentication Protocol- Ta część SSH uwierzytelnia użytkownika na serwerze. Serwer sprawdza, czy dostęp jest udzielany tylko określonym użytkownikom. Obecnie używanych jest wiele metod uwierzytelniania, takich jak wpisywane hasła, Kerberos, uwierzytelnianie za pomocą klucza publicznego itp.

  • Connection Protocol - Zapewnia to wiele kanałów logicznych w ramach jednego podstawowego połączenia SSH.

Usługi SSH

SSH zapewnia trzy główne usługi, które umożliwiają dostarczenie wielu bezpiecznych rozwiązań. Usługi te są krótko opisane w następujący sposób -

  • Secure Command-Shell (Remote Logon)- Pozwala użytkownikowi edytować pliki, przeglądać zawartość katalogów i uzyskiwać dostęp do aplikacji na podłączonym urządzeniu. Administratorzy systemów mogą zdalnie uruchamiać / przeglądać / zatrzymywać usługi i procesy, tworzyć konta użytkowników, zmieniać uprawnienia do plików / katalogów i tak dalej. Wszystkie zadania możliwe do wykonania w wierszu poleceń komputera można teraz bezpiecznie wykonywać z komputera zdalnego przy użyciu bezpiecznego zdalnego logowania.

  • Secure File Transfer- Protokół transferu plików SSH (SFTP) został zaprojektowany jako rozszerzenie protokołu SSH-2 w celu bezpiecznego przesyłania plików. Zasadniczo jest to oddzielny protokół nałożony na protokół Secure Shell do obsługi przesyłania plików. SFTP szyfruje zarówno nazwę użytkownika / hasło, jak i przesyłane dane pliku. Używa tego samego portu co serwer Secure Shell, czyli portu systemowego nr 22.

  • Port Forwarding (Tunneling)- Umożliwia zabezpieczenie danych z niezabezpieczonych aplikacji opartych na protokole TCP / IP. Po skonfigurowaniu przekierowania portów Secure Shell przekierowuje ruch z programu (zwykle klienta) i wysyła go przez zaszyfrowany tunel do programu po drugiej stronie (zwykle jest to serwer). Wiele aplikacji może przesyłać dane przez pojedynczy, multipleksowany bezpieczny kanał, eliminując potrzebę otwierania wielu portów w zaporze lub routerze.

Korzyści i ograniczenia

Korzyści i ograniczenia stosowania bezpieczeństwa komunikacji w warstwie transportowej są następujące:

  • Korzyści

    • Transport Layer Security jest przezroczysty dla aplikacji.

    • Serwer jest uwierzytelniony.

    • Nagłówki warstwy aplikacji są ukryte.

    • Jest bardziej drobnoziarnisty niż mechanizmy bezpieczeństwa w warstwie 3 (IPsec), ponieważ działa na poziomie połączenia transportowego.

  • Ograniczenia

    • Dotyczy tylko aplikacji opartych na protokole TCP (nie dotyczy UDP).

    • Nagłówki TCP / IP są czytelne.

    • Nadaje się do bezpośredniej komunikacji między klientem a serwerem. Nie obsługuje bezpiecznych aplikacji korzystających z łańcucha serwerów (np. E-mail)

    • SSL nie zapewnia niezaprzeczalności, ponieważ uwierzytelnianie klienta jest opcjonalne.

    • W razie potrzeby uwierzytelnianie klienta należy zaimplementować powyżej SSL.

Podsumowanie

W ciągu ostatniej dekady w Internecie pojawiło się wiele aplikacji internetowych. Wiele portali e-Governance i e-Commerce pojawiło się online. Aplikacje te wymagają, aby sesja między serwerem a klientem była bezpieczna, zapewniając poufność, uwierzytelnianie i integralność sesji.

Jednym ze sposobów ograniczenia potencjalnego ataku podczas sesji użytkownika jest użycie bezpiecznego protokołu komunikacyjnego. W tym rozdziale omówiono dwa z takich protokołów komunikacyjnych, Secure Sockets Layer (SSL) i Transport Layer Security (TLS). Oba te protokoły działają w warstwie transportowej.

Inny protokół warstwy transportowej, Secure Shell (SSH), zaprojektowany w celu zastąpienia TELNET, zapewnia bezpieczne środki zdalnego logowania. Jest w stanie świadczyć różne usługi, takie jak Secure Command Shell i SFTP.

Zastosowanie zabezpieczeń warstwy transportowej ma wiele zalet. Jednak protokół bezpieczeństwa zaprojektowany w tej warstwie może być używany tylko z TCP. Nie zapewniają bezpieczeństwa komunikacji realizowanej przy użyciu protokołu UDP.