Protokół HTTPS. Adam Danecki Informatyka gr. 1.4

Transkrypt

1 Protokół HTTPS Adam Danecki Informatyka gr. 1.4

2 Wstęp, czyli małe co nieco, o HTTP HTTP, czyli Hypertext Transfer Protocol, jest protokołem typu klient serwer poziomu warstwy aplikacji, służącym do przesyłania dokumentów tekstowych, jak i danych binarnych. Dokumenty przesyłane są najczęściej w postaci HTML. Z protokołem powiązanych jest kilka terminów, które stanowią podstawę zrozumienia protokołu. I mamy tak: connection wirtualna warstwa transportowa ustanawiana, pomiędzy dwoma aplikacjami celem komunikacji message podstawowa jednostka komunikacji, request rządanie, zapytanie response odpowiedź client program, który nawiązał połączenie, celem wysłania żądania, server program, który udziela odpowiedzi na żądania Są to podstawowe pojęcia, które stanowią podstawę rozumienia zasad działanie protokołu. Istnieje więcej tych pojęć, jednak te uznałem za najważniejsze. Podsumowując, nawiązywanie połączenia przebiega następująco: Klient przedstawia żądanie pobrania określonego zasobu(polecenie ścieżka protokół; np.: GET /stronka.htm HTTP/1.1 Jeśli serwer posiada dane, o które zapytano, przesyła informacje systemowe(protokół, datę, serwer) jak również sam plik o który pytaliśmy. Jeśli z kolei serwer nie posiada interesujących nas danych, odpowiada komunikatem o błędzie(błąd 404 brak poszukiwanego zasobu)

3 Chrońmy nasze dane kryptografia Algorytmy szyfrowania danych możemy podzielić na dwa rodzaje w zależności od używanego schematu kluczy danych. Pierwszy rodzaj to Kryptografia kluczy prywatnych Ten sposób szyfrowania danych (zwany również kryptografią symetryczną, lub kryptografią z kluczem tajnym) znany jest od dawna. Najprostsze jego rodzaje to szyfry oparte o przestawianie liter według pewnego, z góry ustalonego schematu. Ogólny schemat wszystkich tego typu algorytmów jest następujący: Strony uzgadniają klucz(e) służące do szyfrowania/deszyfrowania danych. W późniejszym czasie strony używają uzgodnionych kluczy do wymiany danych, ewentualnie zmieniając je co jakiś czas. Bardziej zaawansowane szyfry symetryczne używane dzisiaj opierają się o operacje na bitach. Najbardziej znany algorytm to DES używany m.in. do szyfrowania haseł w systemach UNIX owych. Używa on skomplikowanych operacji na bitach danych, których kolejność i rodzaj zależy właśnie od bitów klucza. Inne znane algorytmy symetryczne to 3DES (mocniejsza wariacja DES, RC2 i RC4. Największą zaletą algorytmów symetrycznych jest ich szybkość odpowiednio stosowane, mogą tylko nieznacznie zmniejszać przepustowość kanału transmisyjnego. Kryptografia kluczy publicznych Kryptografia kluczy publicznych, zwana także kryptografią asymetryczną zakłada, że każda transmisja danych używa dwóch kluczy. Jeden z nich, klucz prywatny znany jest tylko jednej stronie, zaś drugi, klucz publiczny, nie musi być tajny jest on powszechnie dostępny i umożliwia przykładowo wysyłanie zaszyfrowanych informacji do właściciela klucza prywatnego. Ogólny schemat działania metod szyfrowania z kluczem publicznym jest następujący: Każda ze stron generuje parę kluczy (publiczny + prywatny); Każda ze stron publikuje swój klucz publiczny w sieci (jest on dostępny dla wszystkich); Jeżeli A chce przesłać wiadomość do B to szyfruje ją kluczem publicznym B. Z własności algorytmu wynika, że tylko używając klucza prywatnego B można ją odtworzyć (to jest typowy schemat wymiany danych). Jeżeli B chce mieć pewność, że wymienia informacje rzeczywiście z A, to może np. poprosić A o zaszyfrowanie pewnego tekstu jego kluczem publicznym. Jeżeli B będzie w stanie odtworzyć tekst używając klucza publicznego A to znaczy, że rozmawia rzeczywiście z właściwym partnerem. Jeżeli B po odebraniu wiadomości od A chce zabezpieczyć się przed sytuacją, w której A zaprzeczy, że wysłał wiadomość, może poprosić A o zaszyfrowanie jej dodatkowo swoim kluczem prywatnym (a następnie kluczem publicznym B). B będzie w stanie ją odszyfrować (najpierw używając swojego klucza prywatnego, a

4 następnie publicznego klucza A) i A nie będzie mógł zaprzeczyć, że wiadomość wysłał wiadomość która dała się odszyfrować kluczem publicznym A musiała być zaszyfrowana jego kluczem prywatnym. Jak widać kryptografia asymetryczna likwiduje wszystkie wady kryptografii symetrycznej. Jest to właściwie rozwiązanie doskonałe, które ma tylko jedną wadę: szybkość. O ile algorytmy symetryczne (zwłaszcza blokowe) dobrze nadają się do stosowania w locie, to złożoność obliczeniowa szyfrowania czy deszyfrowania z użyciem kluczy publicznych raczej wyklucza takie zastosowania. Próbą połączenia najlepszych cech obydwu metod szyfrowania jest. Metoda mieszana Najważniejszym faktem dla tej metody stała się obserwacja, że niedogodność algorytmów symetrycznych nie polega na ich słabości dobierając odpowiednio długi klucz możemy uzyskać zabezpieczenie właściwie dowolnie silne. Problemem jest tylko uzgodnienie tych kluczy. Za to algorytmy symetryczne są o wiele szybsze. Wymyślono więc następujący schemat bezpiecznego przesyłania danych: A generuje klucz K, który używany będzie później przy przesyłaniu danych algorytmem symetrycznym; A wysyła klucz K do B korzystając z jego klucza publicznego; B odczytuje klucz K korzystając ze swojego klucza prywatnego; Strony dalej komunikują się korzystając z szyfrowania symetrycznego z użyciem klucza K Możliwe są różne wariacje tej metody umożliwiające na przykład: Autentyfikację serwera/klienta można to zrealizować na etapie nawiązywania połączenia właściwie sytuacja jest tu taka, jakby używany był tylko algorytm asymetryczny. Okresową wymianę kluczy strony mogą się umówić, że przykładowo co 15 minut niszczą i od nowa generują klucze symetryczne. Może to być ważne przy połączeniach trwających bardzo długo i takich, po których przesyła się niewiele danych. Ktoś posiadający odpowiednio szybki komputer i będący w stanie podsłuchać szyfrowaną transmisję mógłby wtedy jednak dane odszyfrować. Opisywana metoda znalazła zastosowanie w: SSH (Secure Shell) protokół bezpiecznego logowania się do systemu zdalnego. Zaletą SSH w porównaniu z logowaniem się przy pomocy telneta lub rsh (oczywiście poza bezpieczeństwem) jest fakt, że można wyeliminować podawanie hasła do autentyfikacji wystarczający jest klucz prywatny klienta. SSL (Secure Socket Layer) protokół bezpiecznych połączeń WWW.

5 Technologia HTTP+SSL = HTTPS Co nas czeka w Internecie każdy się już zapewne przekonał. Poniższe obrazki bardzo dobrze ilustrują te sytuacje. Brak poufności Utrata integralności przesyłanych danych Podszywanie się pod legalnych użytkowników (Identity spoofing)

6 Firma Netscape Communications, chcąc zwalczyć sytuacje jak przedstawione powyżej opracowała podkładkę pod istniejące protokoły, działającą poniżej warstwy aplikacji (HTTP, FTP, SMTP, Telnet, etc.) a powyżej warstw sieci i transportu (TCP/IP). Jej zadaniem jest stworzenie wirtualnego, odpornego na próby podsłuchiwania kanału transmisji dla informacji przesyłanych przez aplikacje (serwery i klienty WWW, FTP, poczty elektronicznej i inne). Najbardziej rozpowszechnione jest HTTP na SSL (HTTPS). Jak się okazało jest to doskonałe rozwiązanie, ogólnie stosowne przez instytucje rządowe, korporacje, sklepy internetowe, internetowe biura maklerskie i przede wszystkim banki internetowe. Zapewnia użytkownikowi: prywatność połączenie jest szyfrowane autoryzację klient i serwer określają swoją tożsamość(certyfikaty) integralność przesyłanych danych przez sumy kontrolne. Skoro już znamy wiemy co nam oferuje to przyjrzyjmy się w jako sposób to działa. Serwery WWW wykorzystujące protokół SSL mogą prowadzić zarówno szyfrowane jak i jawne sesje komunikacyjne (transmisja SSL obsługiwana jest na porcie 433, a nie na standardowym dla protokołu HTTP numerze portu 80). Zabezpieczone przez SSL strony dokumentu WWW posiadają odmienny format adresu URL Warto zauważyć, że nie tylko przeglądarka musi obsługiwać bezpieczny protokół przede wszystkim musi go obsługiwać serwer. A skoro już mowa o przeglądarkach. Należy wspomnieć, które przeglądarki obsługują ten protokół. Z ogólnie znanych mamy: Netscape Communicator jak również Internet Explorer. Również Linuxowa przeglądarka Lynx (2.7 i 2.8), choć nie posiada na razie takich możliwości jak jej okienkowi bracia. W przeglądarkach Internet Explorer i Netscape Navigator ustanowienie bezpiecznego połączenia z witryną sygnalizowane jest ikoną z symbolem zamkniętej kłódki. Każdorazowe przejście z dokumentu chronionego protokołem SSL do dokumentu niezaszyfrowanego poprzedzane jest wyświetleniem okna z ostrzegawczym komunikatem, co obrazują rysunki.

7 Podstawy działania protokołu są następujące: na początku sesji (tzn. w momencie nawiązania łączności pomiędzy przeglądarką i serwerem) następuje weryfikacja tożsamości, wymiana kluczy publicznych i ustalenie kluczy sesji. Po zakończeniu fazy wstępnej dalsza wymiana informacji jest już szyfrowana. Jedna sesja SSL może przenosić wiele sesji HTTP, podczas gdy w zwykłym HTTP połączenie jest przerywane po zakończeniu pojedynczego transferu danych. Dane są szyfrowane kluczem symetrycznym (ten sam klucz do szyfrowania i odszyfrowania), jednak same klucze w momencie przesyłania, są szyfrowane algorytmem asymetrycznym, tzn. wykorzystującym klucz prywatny i odpowiadający mu klucz publiczny, np. algorytmem RSA lub Diffiego Helmana. Integralność wiadomości zapewniona jest przez funkcje elektronicznych podpisów, zwanych też skrótami. Funkcje skrótu umożliwiają przyporządkowanie dowolnemu tekstowi (dokładnie dowolnemu ciągowi bajtów) podpisu, czyli skrótu (digest), ściśle związanego z danym tekstem. Ze skrótu nie można odzyskać wiadomości (zawiera on po prostu mniej informacji). Próba zmiany wiadomości do której dodano jej skrót powoduje, że skrót przestaje pasować do wiadomości. Własności funkcji skrótu powodują, że znalezienie wiadomości pasującej do skrótu jest bardzo złożone obliczeniowo. Skrót jest więc trudnym do sfałszowania podpisem wiadomości. Ze względu na sposób dokonywania autoryzacji SSL jest protokołem scentralizowanym, inaczej niż np. PGP. Jest on oparty o grupę instytucji certyfikujących (Certyfing Authorities), w skrócie CA, które opatrują swoim podpisem certyfikaty poszczególnych serwerów. CA z założenia są godni zaufania, a uzyskanie podpisu wymaga przedstawienia szeregu dowodów tożsamości. W ten sposób wchodząc na serwer legitymujący się certyfikatem jednego ze znanych CA mamy pewność że serwer rzeczywiście jest tym za który się podaje. Przyjrzyjmy się wiec jakie są rodzaje certyfikatów udostępnia nam protokół SSL. I tak: Certyfikat CA zbiór informacji reprezentujących tożsamość danej instytucji certyfikującej. Obecność podpisu danego CA na certyfikacie serwera oznacza, że CA zaakceptował dowody przedstawione przez firmę występującą o podpis i swoim certyfikatem poświadcza autentyczność serwera.

8 Certyfikat serwera zbiór informacji reprezentujących tożsamość danego serwera. Certyfikat serwera musi być opatrzony podpisem CA. Certyfikat osobisty znacznie mniej rozpowszechnione są certyfikaty klienta firmy promujące używanie tego certyfikatu nazywają go "cyfrowym paszportem". Wraz z podpisem odpowiedniego CA pozwala potwierdzić tożsamość klienta. Firma Netscape proponuje jeszcze jeden: certyfikat atrybutu. Stanowi on rozszerzenie istniejących certyfikatów, jednak sam nie stanowi dowodu tożsamości. Należało by jednak wspomnieć czym owe certyfikaty są naprawdę. Są to zbiory danych jednoznacznie identyfikujące pewną jednostkę, oraz pozwalające stwierdzić czy osoba, która się nim legitymuje jest rzeczywiście tym, za kogo się podaje. Certyfikat taki zawiera: Nazwę certyfikowanego obiektu Identyfikator obiektu Klucz publiczny obiektu Czas ważności Nazwę wystawcy certyfikatu Identyfikator wystawcy Podpis wystawcy Problemem który pojawia się wraz z certyfikatami jest ich unieważnianie. O ile łatwo jest stwierdzić, czy certyfikat nie wygasł zawiera on bowiem odpowiednie pole, to może się okazać, że należy certyfikat unieważnić przed jego terminem wygaśnięcia. Jeśli np. z pracy odchodzi pracownik posiadający dostęp do ważnych danych firmy, to powinna istnieć możliwość odebrania mu tych uprawnień niezależnie od terminu ważności jego certyfikatu. Rozwiązaniem tego problemu są listy unieważnień (certificate revocation lists) przechowywane na wszystkich serwerach wystawiających certyfikaty. Ich działanie polega na tym, że klient przy sprawdzaniu autentyczności dowolnego certyfikatu musi zgłosić się do jego wystawcy i poprosić o sprawdzenie, czy przypadkiem nie został on unieważniony przed czasem. Jednak taki dodatkowy ruch w Internecie nie jest najlepszym rozwiązaniem, gdyż wpływa to negatywnie na funkcjonalność. Przyjrzyjmy się teraz dokładniej algorytmowi nawiązywania połączenia. Dla uproszczenia oznaczmy sobie przez U użytkownika, a przez S serwer. W nawiasach znajdą się komunikaty wysyłane pomiędzy stronami. U => S (ClientHello) Użytkownik wysyła do serwera zgłoszenie zawierające m.in. obsługiwaną wersję protokołu SSL, dozwolone sposoby szyfrowania i kompresji danych oraz identyfikator sesji. Komunikat ten zawiera również liczbę losową używaną potem przy generowaniu kluczy.

9 U <= S (SerwerHello) Serwer odpowiada podobnym komunikatem w którym zwraca użytkownikowi wybrane parametry połączenia: wersję protokołu SSL, rodzaj szyfrowania i kompresji, oraz podobną liczbę losową. U <= S (Certificate) Serwer wysyła swój certyfikat pozwalając użytkownikowi na sprawdzenie swojej tożsamości. Etap ten nie jest regułą, ale zazwyczaj występuje U<=S (ServerKeyExchange) Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i długość tego klucza jest określona przez typ algorytmu przesłany w poprzednim komunikacie. U <= S (ServerHelloDone) Serwer zawiadamia, że użytkownik może przejść do następnej fazy zestawiania połączenia. U => S (ClientKeyExchange) Użytkownik na podstawie ustalonych w poprzednich komunikatach dwóch liczb losowych (swojej i serwera) generuje klucz sesji używany do faktycznej wymiany danych. Następnie wysyła go serwerowi używając jego klucza publicznego. Wygenerowany klucz jest kluczem algorytmu symetrycznego (najczęściej DES). Jest on jednak ustalony w sposób bezpieczny i znany jest tylko komunikującym się stronom. U => S (ChangeCipherSpec) Użytkownik zawiadamia, że serwer może przełączyć się na komunikację szyfrowaną. U => S (Finished)...oraz, że jest gotowy do odbierania danych zakodowanych. U <= S (ChangeCipherSpec) Serwer zawiadamia, że wykonał polecenie od tej pory wysyłał będzie tylko zaszyfrowane informacje. U <= S (Finished)...i od razu wypróbowuje mechanizm ten komunikat jest już wysyłany bezpiecznym kanałem. Protokół SSL przewiduje również kontrolowane zakończenie połączenia. Jest to dosyć ważne, gdyż nie można dopuścić do sytuacji, w której potencjalny intruz jest w stanie przerwać fizyczny kanał komunikacyjny i tym samym zniekształcić treść przesyłanej wiadomości. Do kontrolowania zakończenia połączenia służy komunikat ClosureAlert.

10 Powyższy przykład zawierał tylko sprawdzenie autentyczności serwera. A przecież należał oby sprawdzić też użytkownika. W tym celu korzysta się z trzech dodatkowych komunikatów: U <= S (CertificateRequest) Po przesłaniu swojego certyfikatu serwer zawiadamia, że chciałby otrzymać certyfikat użytkownika U => S (Certificate) Po otrzymaniu komunikatu ServerHelloDone użytkownik odsyła swój certyfikat U => S (CertificateVerify) Użytkownik musi potwierdzić, że faktycznie posiada klucz prywatny odpowiadający wysłanemu certyfikatowi. W tym celu użytkownik szyfruje swoim kluczem prywatnym skrót wszystkich dotychczas ustalonych danych o połączeniu i wysyła go korzystając z tego komunikatu. Nawiązanie połączenia SSL jest procesem dość długotrwałym i wymagającym skomplikowanych obliczeń. W przypadku wielu krótkich połączeń pożądana byłaby możliwość kontynuowania połączenia bez ponownej wymiany kluczy publicznych, ustalania klucza sesji itp. (Podobna sytuacja ma miejsce w przypadku protokołu HTTP stosowane są tam tzw. połączenia trwałe persistent connections. Protokół SSL przewiduje taką możliwość. Jeżeli w komunikacie ClientHello użytkownik poda SessionId równy identyfikatorowi jednej z poprzednich sesji, to serwer przyjmie, że użytkownik chce kontynuować połączenie z użyciem poprzednio używanego klucza.

11 Specyfikacja protokołu SSL W chwili obecnej istnieją dwie specyfikacje SSL: SSL 2.0 z listopada 1994 roku SSL 3.0 z listopada 1996 roku Wersja 3.0 ma poprawione wiele wad wersji 2.0 oraz umożliwia kompresję danych. Wersja SSL 3.0 jest wstecznie zgodna z 2.0. Specyfikacja SSL obejmuje dwa podstawowe protokoły: SSL Handshake Protocol SSL Record Protocol. Protokół SSL Handshake określa metody prowadzenia połączenia serwer użytkownik. (przeglądarka WWW), mające na celu ustalenie parametrów bezpiecznej sesji komunikacyjnej np. algorytmy szyfrowania danych, algorytmy sprawdzania autentyczności i integralności informacji, klucze szyfrowania. Protokół SSL Record określa format przesyłanych pakietów danych w ramach chronionej sesji komunikacyjnej. Wersja 3 specyfikacji SSL przewiduje stosowanie algorytmów szyfrowania DES, Triple DES, IDEA, RC2 i RC4 wraz z jednokierunkową funkcją skrótu MD5 lub SHA oraz algorytmy RSA i DSS do tworzenia podpisów cyfrowych. W procesie negocjacji kluczy szyfrowania, SSL używa algorytmu Diffiego Hellmana.

12 Specyfikacja protokołu negocjacyjnego SSL Protokół negocjacyjny SSL ma 2 główne fazy. Pierwsza jest używana do ustanowienia poufnego połączenia. Druga faza używana jest do uwierzytelnienia klienta. Faza 1 Pierwsza faza jest fazą inicjacji połączenia gdzie obie strony wymieniają wiadomości hello. Klient inicjuje konwersację przez wysłanie wiadomości CLIENT HELLO. Serwer odbiera wiadomość CLIENT HELLO i przetwarzając ją odpowiada wiadomością SERWER HELLO. W tym momencie klient i serwer mają wystarczające informacje, aby dowiedzieć się czy nowy klucz główny jest potrzebny czy nie. Kiedy nowy klucz główny nie jest wymagany, klient i serwer natychmiast przechodzą do fazy 2. Kiedy nowy klucz główny jest potrzebny, wiadomość SERWER HELLO zawiera wystarczające informacje dla klienta aby go wygenerował. Klient generuje nowy klucz główny i odpowiada wiadomością CLIENT WRITE KEY. Każdy węzeł końcowy (serwer lub klient) SSL używa pary szyfrów na połączenie (w sumie 4 szyfry). Jeden szyfr używa do transmisji wychodzącej i jeden do transmisji przychodzącej. Klient lub serwer generują klucz sesji, faktycznie generują 2 klucze, SERWER READ KEY (również znany jako CLIENT WRITE KEY) i SERWER WRITE KEY (również znany jako CLIENT READ KEY). Klucz główny jest używany przez klienta i serwer do generowania zmiennych kluczy sesji. Na koniec, serwer wysyła wiadomość SERWER VERIFY do klienta po określeniu klucza głównego. Ten końcowy krok uwierzytelnia serwer, ponieważ tylko serwer który ma właściwy klucz publiczny może poznać klucz główny. Faza 2 Druga faza jest fazą uwierzytelniania. Serwer był już uwierzytelniony przez klienta w fazie 1, tak więc ta faza jest podstawową używaną do uwierzytelnienia klienta. W typowym scenariuszu serwer wymaga coś od klienta i wysyła żądanie. Klient odpowiada pozytywnie jeżeli ma wymagane informacje lub wysyła wiadomość ERROR, jeżeli nie ma. Kiedy jedna strona jest uwierzytelniona przez drugą stronę, to wysyła wiadomość FINISHED. Dla klienta, wiadomość CLIENT FINISHED zawiera zaszyfrowane CONNECTION ID do weryfikacji przez serwer. Jeżeli weryfikacja jest błędna, to serwer wysyła wiadomość ERROR. Jedna strona wysyłając wiadomość FINISHED, musi kontynuować nasłuchiwanie wiadomości, aż do otrzymania również wiadomości FINISHED.

13 Błędy Obsługa błędów w protokóle połączenia SSL jest bardzo prosta. Kiedy błąd jest wykryty, strona wykrywająca wysyła wiadomość do drugiej strony. Błędy które nie są naprawialne (do odtworzenia) powodują przerwanie bezpiecznego połączenia klienta i serwer. Protokół negocjacyjny SSL definiuje następujące błędy: NO CIPHER ERROR ten błąd zwracany jest przez klienta do serwera, kiedy klient nie może znaleźć szyfru lub rozmiaru klucza, który to jest obsługiwany przez serwer. Ten błąd nie jest naprawialny. NO CERTIFICATE ERROR Kiedy wiadomość REQUEST CERTIFICATE jest wysłana, ten błąd może być zwrócony, jeżeli klient nie ma certyfikatu. Ten błąd jest do odtworzenia. BAD CERTIFICATE ERROR ten błąd jest zwracany kiedy certyfikat jest uważany za zły przez stronę odbierająca. Ten błąd jest do odtworzenia. UNSUPPORTED CERTIFICATE TYPE EROR ten błąd jest zwracany kiedy klient/serwer odbiera rodzaj certyfikatu, który nie jest obsługiwany. Ten błąd jest do odtworzenia. ERROR wiadomość ta jest wysyłana kiedy jest wykryty błąd. Po wysłaniu wiadomości, strona wysyłająca zamyka połączenie, natomiast odbierająca zapisuje błąd i zamyka połączenie. Wiadomość niezaszyfrowana jest wysyłana, jeżeli błąd pojawia się podczas negocjacji klucza sesji. Po uzgodnieniu klucza sesji, błędy wysyłane są szyfrowane jak wszystkie inne wiadomości.

14 Literatura Specyfikacja HTTP/1.1; RFC 2616 Specyfikacja SSL Stephen Thomas "SSL and TLS Essentials", Wiley and Sons 2000 Opis protokołu SSL 2. 0 (Netscape) Propozycja standardu SSL 3.0 (Netscape).