Alternatywy dla szyfrowania SSL

Transkrypt

1 PRACA DYPLOMOWA INŻYNIERSKA Alternatywy dla szyfrowania SSL Rafał Szymański Wydział Fizyki Technicznej, Informatyki i Matematyki Stosowanej Promotorzy: dr inż. Michał Morawski Dyplomant: Rafał Szymański Nr albumu: Kierunek: Informatyka Specjalność: Sieci Komputerowe i Systemy Teleinformatyczne Łódź, Maj 213

2

3 Spis treści 1 Wstęp 6 2 Cel i zakres pracy 8 3 Podstawy teoretyczne SSL/TLS Specyfikacja protokołu Sprawdzanie i wymuszanie zgodności wersji DTLS Tcpcrypt Specyfikacja protokołu Porównanie SSL/TLS z tcpcrypt Wymiana kluczy Uwierzytelnianie Mechanizm cache owania sesji Ilość przesyłanych danych Testy wydajności Środowisko testowe Sprzęt komputerowy Oprogramowanie Metodologia testowania Wyniki testów 44 2

4 Spis treści 5.1 Czas odpowiedzi Strona z samym tekstem Strona z tekstem i dużym obrazkiem Sklep internetowy Najkrótszy czas realizacji transakcji Strona z samym tekstem Strona z tekstem i dużym obrazkiem Sklep internetowy Najdłuższy czas realizacji transakcji Strona z samym tekstem Strona z tekstem i dużym obrazkiem Sklep internetowy Szybkość realizowania transakcji Strona z samym tekstem Strona z tekstem i dużym obrazkiem Sklep internetowy Przepustowość Strona z samym tekstem Strona z tekstem i dużym obrazkiem Sklep internetowy Współbieżność Strona z samym tekstem Strona z tekstem i dużym obrazkiem Sklep internetowy Porównanie do istniejących wyników Wnioski Dodatki 12 A Czas odpowiedzi - wykresy szczegółowe 121 B Najkrótszy czas realizacji transakcji - wykresy szczegółowe 128 3

5 Spis treści C Najkrótszy czas realizacji transakcji - wykresy szczegółowe 135 D Szybkość realizowania transakcji - wykresy szczegółowe 142 E Przepustowość - wykresy szczegółowe 149 F Współbieżność - wykresy szczegółowe 156 Bibliografia 163 Spis rysunków 164 Załączniki 172 4

6 Wykaz oznaczeń DCCP Datagram Congestion Control Protocol DTLS Datagram Transport Layer Security FTP File Transfer Protocol HMAC keyed-hash Message Authentication Code HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IMAP Internet Message Access Protocol IP Internet Protocol MAC Message Authentication Code SSL Secure Socket Layer TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol WWW World Wide Web 5

7 Rozdział 1 Wstęp Internet globalna sieć komputerowa, bez której spora część jej użytkowników nie wyobraża sobie dnia codziennego. Projekt początkowo tworzony z myślą o wojskowości rozprzestrzenił się wśród ludności cywilnej tak szybko, że szacuje się iż obecnie 34, 3% populacji może zostać określona mianem użytkownika Internetu [1]. Czym jest obecnie Internet? Mnogość funkcji jaką spełnia we współczesnym świecie sprawia, że wyliczanie oferowanych użytkownikowi możliwości mogłoby zająć kilka stron tej pracy, a i tak byłaby to lista niekompletna. Nie wdając się więc w szczegóły można powiedzieć, że Internet jest obecnie motorem napędowym przemian społecznych, których efektem końcowym (jednym spośród wielu) jest społeczeństwo informacyjne. Skoro, tak jak ma to miejsce w społeczeństwie informacyjnym, informacja stała się towarem to użytkownikom urządzeń, które przesyłają, przetwarzają lub przechowują ową informację (komputery, smartfony, itp.) powinno zależeć na zapewnieniu bezpieczeństwa danych. Jak zaś obecnie wygląda sprawa bezpieczeństwa i poufności przesyłanych przez Internet danych w oczach przeciętnego użytkownika sieci? Zapewne spotkał się on ze stronami, których adres rozpoczyna się od zamiast zwykłego Być może nawet słyszał, że to oferuje mu coś związanego z bezpieczeństwem. Ale dlaczego adresy tylko niektórych stron tak się rozpoczynają? I czemu w przeglądarce 6

8 Rozdział 1. Wstęp internetowej pojawia się ikonka kłódki przy adresie strony? Podobne, choć bardziej szczegółowe, pytania zadają sobie również specjaliści związani z sieciami komputerowymi. Czy można w jakiś sposób podnieść poziom bezpieczeństwa przesyłanych/odbieranych przez użytkownika komputera danych? Czy da się ulepszyć obecnie stosowane zabezpieczania? A może poszerzyć zakres ich stosowania? Owocem takich rozważań są różnorodne rozwiązania techniczne, z których tylko część została wdrożona na szerszą skalę. Nie znaczy to jednakże, że te mniej popularne nie są warte uwagi. 7

9 Rozdział 2 Cel i zakres pracy Przeglądając stan obecnych rozwiązań z dziedziny bezpieczeństwa komunikacji z wykorzystaniem sieci komputerowych można dość szybko zauważyć powszechną obecność pewnego protokołu. Jest on stosowany zarówno przy ruchu www, korzystaniu z poczty elektronicznej czy transferze plików z różnej maści serwerów (i w wielu innych sytuacjach). Oferuje on m.in. szyfrowanie, uwierzytelnianie stron komunikacji, integralność oraz poufność przesyłanych danych. Jest to protokół SSL/TLS (Secure Sockets Layer [2] / Transport Layer Security [3]). Przyglądając się przykładowo ruchowi www możemy podzielić zwyczajowe zastosowanie SSL/TLS następująco: zwykłe strony internetowe (bez e-commerce itp.) głównie przy formularzach rejestracji/logowania, serwisy oferujące funkcjonalność e-commerce przy formularzach rejestracji/logowania oraz dla podstron biorących udział w procesie sprzedaży, serwisy instytucji finansowych lub rządowych panel klienta. Oczywiście, przedstawiona powyżej lista jest dużym uproszczeniem gdyż pomija wiele innych typów serwisów. Dodatkowo nikt nie broni twórcom 8

10 Rozdział 2. Cel i zakres pracy dowolnej strony internetowej wykorzystania SSL/TLS w całej rozciągłości podstron a jednak jest to rzadkie zjawisko. Jak widać z listy zastosowań (w przypadku stron internetowych) protokół SSL/TLS stosowany jest wybiórczo, zwykle tam gdzie jest to niezbędne z uwagi na poufne dane. Co w takim razie stoi na przeszkodzie w zabezpieczaniu całego ruchu sieciowego w ten sposób? Przeszkodą jest sam SSL/TLS, którego konstrukcja posiada wiele rozwiązań utrudniających realizację takiego scenariusza. O ile SSL/TLS jest najbardziej rozpowszechnionym protokołem dbającym o bezpieczeństwo i poufność komunikacji o tyle nie jest jedynym. Istnieje obecnie wiele pomysłów a nawet funkcjonujących rozwiązań, które pomogłyby znacznie poszerzyć zakres stosowania szyfrowania i uwierzytelniania w komunikacji z wykorzystaniem sieci komputerowych. Jednym z takich już istniejących rozwiązań jest tcpcrypt [4]. Jego zgoła inne podejście do zapewnienia bezpieczeństwa sprawia, że wydaje się być rozwiązaniem, które mogłoby zostać wprowadzone w całej rozciągłości ruchu www (i nie tylko). Realizacja takiego scenariusza byłaby wielce korzystna zarówno dla użytkowników sieci jak i dla tych którzy tworzą oferowane w niej usługi. Celem tej pracy jest sprawdzenie jak na tle protokołu SSL/TLS rysuje się działanie protokołu tcpcrypt, zarówno pod względem oferowanych możliwości jak i wydajności działania. Praca ta będzie próba odpowiedzi na następujące pytanie: Czy i w jakim zakresie protokół tcpcrypt mógłby zastąpić SSL/TLS?. Odpowiedź na to pytanie zostanie podzielona na dwie części: porównanie specyfikacji obydwu protokołów (w rozdziale 3.3) na podstawie którego będzie można określić mocne i słaby punkty protokołów w stosunku do siebie nawzajem, testy wydajności oparte o scenariusze zastosowania, które pozwolą sprawdzić czy zmiana podejścia do realizacji szyfrowania ruchu wpływa na obciążenie stron komunikacji. 9

11 Rozdział 3 Podstawy teoretyczne 3.1 SSL/TLS Stworzony przez firmę Netscape Communications w 1994 roku zarys protokołu SSL w wersji 1. miał być odpowiedzią na narastające problemy z bezpieczeństwem komunikacji i transakcji przeprowadzanych za pośrednictwem Internetu (i nie tylko). Prace nad tym protokołem rozpoczęły się niedługo po premierze przeglądarki internetowej Mosaic stworzonej przez NCSA (National Center for Supercomputing Applications). Jednakże, SSL w wersji 1. posiadał wiele słabych stron (m.in. podatność na ataki metodą powtórzeniową) oraz ograniczeń (np. brak mechanizmu sprawdzania spójności danych) i z tego powodu w takiej wersji nie został upubliczniony ani nigdzie zastosowany. Większość z tych problemów udało się rozwiązać w drugiej (2.) wersji protokołu SSL [5], która została opublikowana pod koniec 1994 roku i wdrożona w wydanej przez Netscape Communications przeglądarce internetowej Netscape Navigator. Prace nad dalszym rozwojem protokołu SSL przebiegały w trochę inny sposób niż dotychczas. Mianowicie, po stworzeniu zarysu poprawek do wersji 2. zaproszono zewnętrznych ekspertów (zarówno akademickich jak i z firm konkurencyjnych) z dziedziny bezpieczeństwa do współtworzenia ostatecznej wersji 3. [6]. Takie podejście miało nie tylko przyśpieszyć rozwój protokołu 1

12 3.1. SSL/TLS SSL, lecz również rozpropagować go wśród środowisk z których owi eksperci pochodzili jako standard w zabezpieczaniu ruchu internetowego. Efektem tych prac było wydanie w 1995 roku wersji 3. [2], ostatniej rozwijanej pod skrzydłami firmy Netscape. W celu dalszego rozpropagowania i zdynamizowania rozwoju stworzonego przez siebie protokołu, Netscape przekazał w maju 1996 roku pieczę nad SSL organizacji IETF (Internet Engineering Task Force), która pracowała nad wieloma standardami związanymi z Internetem i bezpieczeństwem. Owo stowarzyszenie rozwija do dziś SSL pod zmienioną nazwą TLS (Transport Layer Security) która lepiej oddaje ideę tego protokołu. Wraz ze zmianą nazwy zmianie uległa też numeracja wersji. Wydany w styczniu 1999 roku opis protokołu TLS nosił numer 1. [7], chociaż zdarzało się, że był określany mianem SSL 3.1 ze względu na powszechność poprzedniej nazwy tego protokołu i brak diametralnych zmian w stosunku do wersji 3.. Takie nazewnictwo wynika również z interoperacyjności TLS i SSL, która wymusza na protokole TLS zachowanie ciągłości numerów wersji przesyłanych w rekordach tego protokołu. Z tego powodu TLS 1. wysyła w polu wersji wartość 3.1, TLS 1.1 wysyła 3.2 itd. Do dnia dzisiejszego pojawiły się tylko dwie kolejne wersje protokołu TLS: 1.1 [8] w 26 roku, która koncentruje się na usunięciu problemów kryptograficznych występujących w poprzednich wersjach [6], 1.2 [3] w 28 roku, która skupia się na włączeniu do standardu TLS opisywanych w innych dokumentach RFC (m.in [9], 4366 [1]) rozszerzeń i modyfikacji. Dodatkowo, w 211 roku IETF wydało dokument RFC [11] w którym zarzucona zostaje możliwość realizowania połączeń z jednej strony zabezpieczanych przez TLS 1.2 a z drugiej przez SSL

13 3.1. SSL/TLS Specyfikacja protokołu Umieszczony między protokołami warstwy aplikacji (do której sam należy) a warstwą transportową (modelu TCP/IP) protokół SSL/TLS sam w sobie składa się z kilku innych protokołów. Jego umiejscowienie oraz podział na elementy składowe zaprezentowane są na rysunku 3.1. Bloki połączone klamrą z podpisem Secure Socket Layer reprezentują protokoły składowe, zaś blok z kreskowaną krawędzią pokazuje protokół wiążący SSL/TLS z protokołami warstwy aplikacji. Jako, że omawiany protokół wymaga dostarczenia wszystkich przesyłanych przez siebie wiadomości w całości (wraz z zachowaniem kolejności) to opiera się o użycie TCP (Transmission Control Protocol) w warstwie transportowej (w przypadku stosu TCP/IP), co też widać na rysunku 3.1. Rysunek 3.1: Położenie protokołu SSL/TLS w modelu TCP/IP i jego podział na protokoły. [12] Takie umiejscowienie SSL/TLS sprawia, że jest on w stanie zapewnić bezpieczeństwo dla szerokiego wachlarza protokołów warstwy aplikacji, m.in. HTTP, FTP, IMAP. Ważnym aspektem omawianego w tym rozdziale protokołu są role jakie przypisuje on stronom komunikującym się za jego pośrednictwem. Strona ini- 12

14 3.1. SSL/TLS cjująca połączenie nazywana jest klientem zaś strona z którą klient się łączy serwerem. Taki podział jest bardzo istotny, ponieważ to klient przedstawia zestaw opcji przy ustanawianiu połączenia z wykorzystaniem SSL/TLS zaś serwer jedynie wybiera spośród nich te które zostaną użyte podczas właściwej komunikacji. Do protokołów składowych SSL/TLS należą: Handshake pozwala na uwierzytelnienie stron oraz ustalenie szczegółów sesji SSL/TLS (metoda szyfrowania, sposób kompresji itd.) Change Cipher Spec służy do zatwierdzenia i wprowadzenia do użycia (w ramach danej sesji) wynegocjowanych z pomocą protokołu Handshake opcji (związanych z metodami szyfrowania i potwierdzania spójności wiadomości), Alert wykorzystywany do zgłaszania napotkanych problemów oraz sytuacji, które mogą powodować problemy, Application Data do niego trafiają dane z protokołów z warstw aplikacji zabezpieczanych w ramach danej sesji SSL/TLS. Record Layer służy do enkapsulacji danych (wiadomości) pochodzących z opisanych powyżej protokołów do formatu rekordu SSL/TLS. Umieszczone w nim dane zostają po stronie nadawcy podzielone na odpowiednie fragmenty, spakowane (opcjonalnie) i zaszyfrowane (po negocjacji parametrów). Po stronie odbiorcy w odwrotnej kolejności zachodzą procesy przeciwne. Zanim dojdzie do przesłania zabezpieczonych danych z protokołów z takich jak HTTP czy FTP musi nastąpić etap wymiany wiadomości (z wykorzystaniem opisanych podprotokołów) ustanawiających szczegóły komunikacji między klientem a serwerem. Przebieg wymiany takich komunikatów w wypadku szyfrowania z wykorzystaniem SSL/TLS przedstawia rysunek 3.2. Zgodnie z rysunkiem 3.2 proces negocjacji (bez wznawiania sesji) przebiega następująco: 13

15 3.1. SSL/TLS Rysunek 3.2: Przebieg negocjacji opcji połączenia szyfrowanego z użyciem SSL/TLS. [12] 1. Klient wysyła komunikat ClientHello w którym przedstawia proponowane opcje (wspierane metody szyfrowania i kompresji). 2. Serwer odpowiada wiadomością ServerHello określając, które opcje posłużą dla danej sesji SSL/TLS. Opcje wybierane są na podstawie propozycji klienta i możliwości serwera. 3. Serwer przesyła do klienta swój klucz publiczny w wiadomości Server- KeyExchange. 4. Serwer zakańcza swoją część negocjacji komunikatem ServerHelloDone. 5. Klient przesyła w wiadomości ClientKeyExchange zaszyfrowany (kluczem publicznym serwera) klucz który posłuży do zaszyfrowania danych w ramach sesji SSL/TLS. 14

16 3.1. SSL/TLS 6. Klient wysyła ChangeCipherSpec w celu uaktywnienia ustalonych dotąd opcji i zastosowania ich do wszystkich kolejnych wysyłanych przez niego wiadomości. 7. Klient przesyła Finished dzięki któremu serwer może sprawdzić poprawność użycia wynegocjowanych opcji i tym samym aktywować wynegocjowane ustawienia po swojej stronie. 8. Serwer wysyła ChangeCipherSpec w celu uaktywnienia ustalonych dotąd opcji i zastosowania ich do wszystkich kolejnych wysyłanych przez niego wiadomości. 9. Serwer przesyła Finished dzięki któremu klient może sprawdzić poprawność użycia wynegocjowanych opcji. W przypadku potrzeby uwierzytelnienia serwera (najczęstszy przypadek) rysunek przebiegu negocjacji ulega pewnej modyfikacji, przedstawionej na rysunku 3.3. Widać na nim, że nie ulega zmianie liczba przesyłanych wiadomości a jedynie te, które są oznaczone czarnym kolorem zostają zmienione w następujący sposób: Dotychczasowy komunikat ServerKeyExchange zostaje zastąpiony wiadomością Certificate. Na tym etapie serwer zamiast jak dotychczas przesyłać klientowi swój klucz publiczny wysyła certyfikat swojego klucza publicznego (zgodny ze standardem X.59 [13]). Przesyłana przez klienta wiadomość ClientKeyExchange jest szyfrowana z wykorzystaniem certyfikatu serwera. Tylko serwer posiadający klucz prywatny powiązany z certyfikowanym kluczem publicznym będzie w stanie odszyfrować tę wiadomość a tym samym serwer zostanie uwierzytelniony. Istnieje również możliwość dokonania potwierdzenia tożsamości klienta na podstawie posiadanego przez niego certyfikatu klucza publicznego (w standardzie X.59). 15

17 3.1. SSL/TLS Rysunek 3.3: Przebieg negocjacji opcji połączenia szyfrowanego z uwierzytelnionym serwerem z użyciem SSL/TLS. [12] Dalsze szczegóły funkcjonowania protokołu SSL/TLS zostaną opisane w części pracy poświęconej porównaniu SSL/TLS z protokołem tcpcrypt (patrz rozdział 3.3) Sprawdzanie i wymuszanie zgodności wersji Pomimo opublikowania specyfikacji TLS 1.1 w 26 roku [8], a wersji 1.2 w roku 28 [3] nadal najpopularniejszą stosowaną odmianą pozostaje wersja 1.. W marcu 213 roku statystyki wsparcia wersji SSL/TLS [14] wyglądały tak jak na wykresie 3.4. Jak widać na wykresie 3.4 dosyć spora liczba stron obsługuje nadal SSL 2. pomimo jego wielu znanych słabości i luk. Jako, że kolejne wersje SSL/TLS zachowują wsparcie dla połączeń zabezpieczanych za pomocą starszych wersji 16

18 3.1. SSL/TLS Rysunek 3.4: Wykres obsługiwania przez strony internetowe danych wersji SSL/TLS na podstawie danych z [14]. protokołu musi istnieć mechanizm pozwalający określić jakie wersje SSL/TLS są obsługiwane przez klienta i serwer oraz która z nich zostanie użyta w ramach danego połączenia. W protokole SSL/TLS istnieje mechanizm negocjowania wersji protokołu który zostanie użyty do zabezpieczenia komunikacji. W celu określenia stosowanej wersji protokołu klient podczas rozpoczęcia wymiany wiadomości przesyła komunikat ClientHello, który oprócz wielu istotnych informacji (takich jak wspierane metody szyfrowania i kompresji) zawiera pole związane z wersją SSL/TLS. Sama wiadomość ClientHello posiada obecnie dwie specyfikacje: starszą zgodną z SSL 2. oraz nowszą zaprojektowaną dla SSL 3. i TLS. W celu zachowania utrzymania możliwości ustanawiania bezpiecznych połączeń z zachowaniem wstecznej kompatybilności (z SSL 2.) dany klient powinien przesyłać na rozpoczęcie komunikacji wiadomość ClientHello zgodną ze specyfikacją SSL 2.. Aby jednocześnie nie utracić zdolności nawiązywania zabezpieczonych przez nowsze odmiany protokołu SSL/TLS połączeń klient powinien w wiadomości ClientHello przesyłać dodatkowe informacje (podpowiedzi ignorowane przez SSL 2.), na podstawie których będzie można ustalić 17

19 3.1. SSL/TLS najwyższą wersję wspieranego protokołu. W celu lepszego zrozumienia funkcjonowania takowego mechanizmu można sobie wyobrazić następującą sytuację: na maszynie, która będzie łączyć się z różnymi serwerami mamy zapewnioną obsługę zarówno SSL 2. jak i SSL 3., ze względu na częste (zgodnie z wykresem 3.4) występowanie SSL 2. na serwerach WWW klient powinien móc zabezpieczać komunikację starszą wersją protokołu, w celu zapewnienia wyższego poziomu bezpieczeństwa klient powinien również móc wykorzystać SSL 3. tam gdzie to możliwe, przy pierwszym połączeniu klient natrafia na maszynę z SSL 2., przy kolejnym połączeniu klient łączy się z serwerem z SSL 3.. Pierwsze połączenie, czyli z serwerem wspierającym jedynie SSL 2. przedstawia rysunek 3.5. Widać na nim, że serwer po otrzymaniu wiadomości ClientHello zgodnej ze standardem SSL 2. odpowiada wiadomością Server- Hello w ramach tegoż standardu, całkowicie ignorując podpowiedzi. Po tym etapie dalszy przebieg negocjacji zachodzi zgodnie ze starszą wersją protokołu SSL. Kolejne połączenie, czyli z serwerem wspierającym SSL 3. zobrazowane zostało na rysunku 3.6. Widać na nim, że serwer po otrzymaniu wiadomości ClientHello zgodnej ze standardem SSL 2. z podpowiedziami odpowiada wiadomością ServerHello w standardzie SSL 3.. To oznacza, że serwer kierował się głównie podpowiedziami a nie formatem wiadomości. Po tym etapie dalszy przebieg negocjacji zachodzi zgodnie z nowszą wersją protokołu SSL. W związku z tym, że każda kolejna wersja protokołu SSL/TLS usuwa słabe punkty i błędy wersji poprzednich, zachowanie wstecznej kompatybilności może posłużyć jako podstawa do przeprowadzania pewnego rodzaju ataku obniżającego poziom bezpieczeństwa i poufności komunikacji. Jest to atak 18

20 3.1. SSL/TLS Rysunek 3.5: Przebieg ustanawiania połączenia z obsługą zgodności wstecznej (tutaj z SSL 2.). Zgodność wsteczna zostaje wykorzystana. [12] Rysunek 3.6: Przebieg ustanawiania połączenia z obsługą zgodności wstecznej (tutaj z SSL 2.). Zgodność wsteczna nie zostaje wykorzystana. [12] typu człowiek pośrodku 1, w którym atakujący wymusza na obydwu stronach komunikacji użycie jak najstarszej odmiany protokołu SSL/TLS. Tego typu działanie przedstawia rysunek 3.7. Atakujący wykorzystuje fakt przesyłania wiadomości ClientHello w wersji SSL 2. z podpowiedziami sugerującymi możliwość użycia SSL 3. w celu wynegocjowania wersji protokołu. Na początku atakujący włącza się mię- 1 ang. man-in-the middle 19

21 3.1. SSL/TLS Rysunek 3.7: Atak typu man in the middle skutkujący użyciem starszej wersji SSL. [12] dzy klienta a serwer i prezentuje się jako serwer klientowi. Klient przesyła do atakującego wiadomość ClientHello z podpowiedziami. Atakujący odbiera wiadomość, eliminuje z niej podpowiedzi i przesyła do serwera samemu udając klienta. W ten sposób serwer otrzymuje informacje, że prawdziwy klient (który w rzeczywistości wspiera SSL 2. i 3.) potrafi obsłużyć jedynie starszą i mniej bezpieczną wersję protokołu SSL. Serwer odpowiada klientowi komunikatem ServerHello w wersji SSL 2.. Taki początek komunikacji pozwoli atakującemu wykorzystać występujące w SSL 2. słabości i luki do podsłuchiwania i modyfikacji przesyłanych między klientem a serwerem informacji. W celu utrudnienia przeprowadzania tego typu ataków, klient posiadający wsparcie zarówno dla SSL 2. jak i 3. w przypadku wynegocjowania użytkowania SSL 2. ustawia ostatnie 8 bajtów dopełnienia w wiadomości ClientKeyExchange na specjalną wartość 11. Owa wartość wskazuje na to, że klient może użyć SSL 3., ale w wyniku wymiany komunikatów wspólna wersja została ustalona na 2.. Jeżeli serwer również wspiera SSL 3. to może brać pod uwagę możliwość pojawienie się takiej wartości i gdy 2

22 3.1. SSL/TLS taki przypadek nastąpi założyć wystąpienie ataku typu człowiek pośrodku. Należy zwrócić uwagę na to, że atakujący nie posiada możliwości modyfikacji dopełnienia w ClientKeyExchange ze względu na to, że jest ono zazwyczaj zaszyfrowane kluczem publicznym serwera DTLS Przedstawiony w poprzednim rozdziale protokół SSL/TLS opiera się w swoim działaniu o protokół strumieniowy (TCP) występujący w warstwie transportowej. Taki układ powoduje, że ruch sieciowy wykorzystujący protokoły takie ja np. UDP, DCCP, SCTP nie może zostać zabezpieczony z użyciem SSL/TLS. W celu eliminacji tego braku stworzono protokół DTLS (Datagram Transport Layer Security) [15]. Idea oparcia DTLS o protokoły bezpołączeniowe wprowadza wiele problemów, które z racji użycia protokołu połączeniowego nie występowały w zwykłym protokole SSL/TLS, takich jak brak rzetelności przeprowadzonej transmisji czy zapewnienie retransmisji w razie problemów komunikacyjnych. Gdyby jednak dodać wszystkie brakujące funkcjonalności w ramach protokołu DTLS to narzut wynikający z jego użycia byłby tak duży, że niwelowałby wszelkie zalety stosowania takich protokołów jak UDP czy DCCP. Od początku tworzenia protokołu DTLS starano się dokonywać jak najmniej modyfikacji w sprawdzonym już protokole SSL/TLS. Zmianom uległy głównie następujące podprotokoły: Record Layer wprowadzenie numeru sekwencyjnego do rekordu tego protokołu. Taka modyfikacja umożliwia sprawdzenia rzetelności komunikacji, potencjalną retransmisję czy też uporządkowanie przychodzących pakietów. Handshake nagłówek tego protokołu zmodyfikowano tak, żeby na jego podstawie można było poradzić sobie z utratą, nieprawidłową kolejnością czy fragmentacją wiadomości. Protokół poszerzono o opcję retransmisji oraz dodano do niego wymianę bezstanowych ciasteczek w 21

23 3.2. Tcpcrypt celu ochrony przed atakami typu DoS (Denial of Service). Jako, że celem tej pracy jest porównanie funkcjonowania i wydajności między SSL/TLS a tcpcrypt, szczegóły zmian wprowadzonych w ramach protokołu DTLS nie będą tutaj poruszane. 3.2 Tcpcrypt Opisywany w rozdziale 3.1 protokół SSL/TLS jest obecnie najczęściej stosowanym rozwiązaniem z zakresu zapewnienia bezpieczeństwa ruchu sieciowego (z wykorzystaniem protokołu TCP). Nie czyni to z niego jednakże rozwiązania idealnego ani jedynego w tej dziedzinie. Jednym spośród alternatywnych do SSL/TLS rozwiązań jest protokół tcpcrypt. Został stworzony przez grupę 6 osób (z których większość związana jest z Uniwersytetem Stanforda) i sfinansowany z nagród przyznanych przez National Science Foundation (amerykańska agencja rządowa zajmująca się edukacją i badaniami naukowymi). Prezentuje on odmienne pod wieloma względami (w stosunku do SSL/TLS) podejście w temacie zabezpieczania ruchu sieciowego Specyfikacja protokołu Tcpcrypt w swojej konstrukcji jest w rzeczywistości rozszerzeniem protokołu TCP, stworzonym w celu rozpropagowania użycia szyfrowania w komunikacji punkt-punkt. Zastosowanie modyfikacji TCP w ramach dostępnych opcji zamiast dodawania kolejnego protokołu w modelu TCP/IP sprawia, że użycie tcpcrypt nie wymaga modyfikacji już istniejących aplikacji i rozwiązań. Dostosowując więc diagram 3.1 do specyfikacji protokołu tcpcrypt otrzymujemy rysunek 3.8, na którym struktura protokołów uległa znacznemu uproszczeniu. Należy pamiętać, że przedstawiony na rysunku blok z etykietą HTTP służy tutaj jedynie za przykład zastosowania. W jego miejscu może występować dowolny protokół wykorzystujący protokół TCP do przesyłu danych. 22

24 3.2. Tcpcrypt Rysunek 3.8: Położenie protokołu tcpcrypt w modelu TCP/IP. W celu zapewnienia wstecznej kompatybilności (oraz możliwości rezygnacji z zabezpieczeń) szyfrowanie oferowane w ramach tcpcrypt jest okazyjne. To znaczy, że w przypadku braku wsparcia szyfrowania z użyciem tcpcrypt po stronie klienta lub serwera komunikacja odbywa się bez szyfrowania (z użyciem niezmodyfikowanego protokołu TCP). Okazyjne szyfrowanie jest skutecznym zabezpieczeniem przed pasywnym podsłuchiwaniem, jednakże nie chroni przed jego aktywną odmianą (możliwe jest wymuszenie przejścia do komunikacji nieszyfrowanej, którą można następnie pasywnie podsłuchiwać). W celu utrudnienia przeprowadzenia aktywnego podsłuchu należy zapewnić jakąś formę uwierzytelnienia stron, co też w oparciu o dostępne w tcpcrypt opcje może zostać zrealizowane. Tcpcrypt w swoim działaniu opiera się o pole opcji występujące w nagłówku segmentu TCP. Dodaje do niego dwie nowe opcje CRYPT oraz MAC, z których CRYPT jest niezbędna na etapie negocjacji parametrów szyfrowania zaś MAC niezbędna na etapie przesyłania szyfrowanych danych z warstwy aplikacji. Opcja CRYPT sama w sobie posiada szeroki zbiór zagnieżdżonych opcji, przykładowo: HELLO sygnalizuje chęć użycia tcpcrypt w ramach nawiązywanej komunikacji, DECLINE oznacza odmowę zastosowania tcpcrypt do zabezpieczenia połączenia, 23

25 3.2. Tcpcrypt PKCONF potwierdza możliwość zastosowanie szyfrowania i określa listę kryptograficznych mechanizmów asymetrycznych z których wybrany posłuży do wymiany kluczy, INIT1, INIT2 stosowane do ustalenia parametrów szyfrowania i wymiany kluczy, NEXTK1, NEXTK2 służą do wyeliminowania potrzeby użycia metod kryptograficznych mechanizmów asymetrycznych dla już ustanowionych sesji (także element wznawiania sesji). Stworzenie protokołu zapewniającego szyfrowanie (i kilka innych możliwości) na poziomie TCP, pomimo tego, że pozwala uniknąć kilku problemów (przykładowo z NATem) ma też swoje wady [16]. Odpowiednio skonfigurowane firewalle (a także normalizatory ruchu) mogą odrzucać pakiety z nieznanymi im opcjami lub też czyścić owe opcje tym samym uniemożliwiając szyfrowanie kanału komunikacji. Jednakże, gdyby tcpcrypt spopularyzował się wystarczająco dodanie odpowiednich reguł do tego typu urządzeń nie nastręcza większych problemów. W celu zminimalizowania narzutu jaki wprowadza do komunikacji tcpcrypt, szczegóły dotyczące szyfrowania danego połączenia ustalane są już podczas negocjacji połączenia TCP w opcjach pakietów SYN/ACK. Jedynymi danymi, które nie mieszczą się w samych opcjach są klucze stosowane do szyfrowania. W celu ich przesłania wykorzystuje się część przeznaczoną na dane, gdyż i tak nie ma ona zastosowania dla pakietów SYN/ACK. Przykład ustanawiania połączenia zabezpieczonego przez tcpcrypt przedstawia rysunek 3.9. Oprócz szyfrowania tcpcrypt zapewnia również autentyczność i spójność przesyłanych danych poprzez zastosowanie HMAC (keyed-hash Message Authentication Code) po tym jak zostanie ustanowiony kanał szyfrowany. W tcpcrypt w tym celu zdefiniowana jest opcja MAC, w której umieszczana jest wyliczona wybraną funkcją skrótu wartość. Jako, że wykorzystywana jest tutaj funkcja typu HMAC to jednym z etapów wyliczania wartości koń- 24

26 3.2. Tcpcrypt Rysunek 3.9: Ustanawianie połączenia zabezpieczonego przez tcpcrypt. [16] cowej jest wmieszanie tajnego klucza. Ten dodatkowy krok pozwala zapewnić autentyczność danych. Pola brane jako podstawa do wyliczenia HMAC przedstawia rysunek 3.1. Występujące na nim 64 bitowe numery sekwencyjne i potwierdzenia, choć nie są przesyłane w ramach normalnego nagłówka TCP, są brane pod uwagę podczas wyliczania HMAC. Poszerzenie tych dwóch wielkości do 64 bitów ma na celu zabezpieczenie ich przed przekroczeniem zakresu, co może wystąpić przy np. atakach powtórzeniowych. Rysunek 3.1: Pakiet TCP z zaznaczonymi na szaro polami niezbędnymi do wyliczenia HMAC. Kreskowana obwiednia oznacza pola nie występujące w nagłówku pakietu, ale będące w zbiorze wartości na podstawie których wyliczany jest HMAC. [16] 25