Protokół SSL (Secure Socket Layer) został w pocz?tkowej wersji opracowany przez firmę Netscape i stał się wkrótce standardem, powszechnie stosowanym w Internecie. Ostatnia, trzecia wersja protokołu (SSLv3) stała się podstaw? do opracowania nieco ulepszonego i firmowanego przez IETF protokołu TLS (Transport Layer Security).<br><br> Przeznaczenie SSL
Podstawowymi zadaniem SSL jest zapewnienie bezpiecznego kanału dla protokołów wyższych warstw. Kanał taki, dzięki zastosowaniu kryptografii, jest zupełnie nieprzezroczysty dla osoby podsłuchuj?cej ł?czno?ć lub próbuj?cej modyfikować jej przebieg. Protokół SSL gwarantuje następuj?ce funkcje:<br><br> -        <B><I>Autentyczno?ć stron</I></B>. Obie strony komunikacji maj? pewno?ć, że s? rzeczywi?cie tymi, za których się podaj?. Ma to znaczenie w przypadku ataków polegaj?cych na podszywaniu się za inny komputer. Za pomoc? protokołu SSL ta możliwo?ć została rozwi?zana i nie tu już moziwo?ci podszywania się za kogo? innego.<br><br> -        <B><I>Poufno?ć transmisji</I></B>. Oznacza to ochronę przesyłanych danych przed podsłuchem przez ich zaszyfrowanie. Szyfruj?c wiadomo?ć kluczem publicznym odbiorcy mamy pewno?ć, że tylko on j? jest w stanie odczytać, ponieważ jest to możliwe tylko drug? para kluczy, w tym wypadku kluczem prywatnym odbiorcy. Dzieje się tak dlatego, że jak sama nazwa wskazuje klucz prywatny ma tylko i wył?cznie odbiorca i nikt inny bez tego klucza nie jest w stanie tej wiadomo?ci odczytać.<br><br> -        <B><I>Integralno?ć danych</I></B>. Oznacza to pewno?ć, że przesłane dane nie zostały zmodyfikowane po drodze, czy to w wyniku awarii czy zło?liwej ingerencji. Szyfruj?c wiadomo?ć własnym kluczem prywatnym i wysyłaj?c go, odbiorca ma pewno?ć, że informacje w międzyczasie nie zostały zmienione. Dzieje się tak dlatego, że wiadomo?ć zakodowan? kluczem prywatnym możemy odczytać tylko i wył?cznie jego kluczem publicznym.<br><br> Jednym z podstawowych założeń SSL była otwarto?ć i rozszerzalno?ć protokołu, czyli brak przywi?zania do jednego, konkretnego algorytmu szyfruj?cego. Zamiast tego protokół umożliwia stronom przedstawienie swoich propozycji obsługiwanych algorytmów i wybranie wspólnego, najbardziej odpowiedniego dla obu stron.<br><br> Przykładowo, klient ł?cz?cy się z serwerem po SSL może oznajmić mu, że może użyć algorytmów szyfruj?cych DES, 3DES oraz RC4. Je?li serwer stwierdzi, że z zaproponowanej listy obsługuje wył?cznie RC4, to ten wła?nie algorytm zostanie użyty do zabezpieczenia transmisji.<br><br> Kryptografia w SSL
Jak wiele innych protokołów tego rodzaju, SSL wykorzystuje dwa podstawowe rodzaje szyfrów, szyfry asymetryczne (z kluczem prywatnym i publicznym) oraz symetryczne (z jednym kluczem szyfruj?co - deszyfruj?cym). Pierwsze z nich s? wykorzystywane do uwierzytelnienia stron oraz bezpiecznej wymiany klucza symetrycznego, który z kolei służy do faktycznego szyfrowania strumienia danych.<br><br> Powody, dla których tak się robi s? dwa: po pierwsze, algorytmy z kluczem publicznym s? znacznie wolniejsze od szyfrów symetrycznych, przez co nie nadaj? się do wydajnego kodowania danych przesyłanych w dużych strumieniach. Z drugiej jednak strony zastosowanie tylko i wył?cznie szyfru symetrycznego wymagałoby wcze?niejszej wymiany klucza za pomoc? jakiego? innego kanału. Poł?czenie dwóch rodzin szyfrów rozwi?zuje oba te problemy w sposób efektywny i elegancki.<br><br> Działanie protokołu
Typowa sesja SSL składa się z następuj?cych kroków:<br><br> -        1. Nawi?zanie przez klienta poł?czenia do serwera (po zwykłym TCP).<br> -        2. Wymiana informacji o obsługiwanych szyfrach, certyfikatów tożsamo?ci i innych danych.<br> -        3. Uzgodnienie wspólnego zbioru obsługiwanych algorytmów szyfrowania.<br> - 4. Potwierdzenie tożsamo?ci serwera przez klienta na podstawie otrzymanych informacji (opcjonalnie także potwierdzenie tożsamo?ci klienta przez serwer).<br> - 5. Je?li serwer wymaga tego, to opcjonalnie potwierdzenie tożsamo?ci klienta przez serwer.<br> -        6. Wymiana kluczy sesyjnych (session keys), wygenerowanych w sposób losowy.<br> -        7. Rozpoczęcie transmisji całkowicie szyfrowanej wygenerowanymi wcze?niej kluczami.<br> <br> W punktach 2, 3 i 4 wykorzystywany jest szyfr asymetryczny, wybrany ze wspólnej listy7. Po zakończeniu ostatniego (5) etapu kanał SSL staje się całkowicie przezroczysty dla tunelowanego wewn?trz protokołu wyższej warstwy.<br><br> Do szyfrowania wła?ciwych danych tunelowanych w SSL jest wykorzystywany szyfr symetryczny, jeden z uzgodnionych podczas pocz?tkowej wymiany. Klucz szyfruj?cy jest generowany losowo dla każdego poł?czenia.<br><br> Infrastruktura klucza publicznego (PKI)
Podstaw? uwierzytelnienia w SSL s? mechanizmy infrastruktury klucza publicznego (PKI), oparte o kryptografię asymetryczn?. W modelu tym każdy węzeł posiada swój klucz prywatny, chroniony przed kradzież?, oraz klucz publiczny, który jest wysyłany do klienta podczas nawi?zywania poł?czenia. Z punktu widzenia klienta ł?cz?cego się z takim systemem nie jest to jednak wystarczaj?ce dla stwierdzenia autentyczno?ci przedstawionego klucza publicznego ( w przypadku ataku typu man-in-the-middle klucz ten mógłby być podstawiony).<br><br> W modelu PKI najważniejsz? rolę spełnia tutaj zaufana trzecia strona (trusted third party), czyli kto? obdarzany zaufaniem przez obie strony poł?czenia. W praktyce może to być instytucja rz?dowa, firma posiadaj?ca odpowiedni? akredytację lub, w ramach jednej instytucji, wydzielona komórka organizacyjna. W terminologii PKI organy te s? okre?lane wspóln? nazw? urzędów certyfikuj?cych CA (Certifying Authority).<br><br> Rol? CA jest w przypadku SSL uprzednie stwierdzenie tożsamo?ci serwera oraz po?wiadczenie jej przez złożenie podpisu cyfrowego na kluczu publicznym zainteresowanego. Dowody przedstawiane przez tego ostatniego urzędowi zależ? oczywi?cie od kontekstu. <br><br> W przypadku wła?ciciela sklepu internetowego, oferuj?cego SSL i chc?cego uzyskać certyfikat jednej z uznanych, ?wiatowych firm certyfikuj?cych (VeriSign, Thawte) będzie to dokument po?wiadczaj?cy istnienie danej firmy (wypis z ewidencji gospodarczej), prawo do domeny sklepu (uzyskany od firmy rejestruj?cej domeny, np. NASK lub Network Solutions) itp. W przypadku CA działaj?cego w obrębie jednej firmy może to być za?wiadczenie z działu kadr lub wręcz ustna deklaracja przełożonego, w zależno?ci od wielko?ci i polityki firmy.<br><br> Hierarchia CA
PKI jest systemem w ogromnym stopniu skalowalnym, gdyż pracuje równie dobrze w ramach jednej firmy, międzynarodowej korporacji oraz ogólno?wiatowej sieci certyfikacji publicznej, stosowanej obecnie w Internecie. Taka złożono?ć nie byłaby możliwa gdyby PKI nie było systemem hierarchicznym, umożliwia ono bowiem delegację czę?ci uprawnień certyfikacyjnych do podmiotów niższego szczebla.<br><br> Mówi?c obrazowo, urz?d certyfikuj?cy szczebla rz?dowego może podpisać klucz publiczny urzędu działaj?cego w ramach okre?lonej instytucji, dzięki czemu może ona tworzyć certyfikaty dla własnych pracowników bez angażowania organu nadrzędnego.<br><br> Równocze?nie, dzięki podpisowi złożonemu przez krajowego CA, certyfikaty wygenerowane przez tę instytucję będ? mogły być weryfikowane tak samo skutecznie, jakby były one wygenerowane przez urz?d wyższego szczebla.<br><br> Weryfikacja tożsamo?ci
Jak przebiega sprawdzenie tożsamo?ci serwera legitymuj?cego się certyfikatem? Przede wszystkim, klient musi w tym celu posiadać klucz publiczny urzędu, który podpisał dany certyfikat albo urzędu wyższego szczebla. Jest to podstawowe założenie PKI i punkt, od którego zależy bezpieczeństwo całego systemu, jako że klucz CA potwierdza tożsamo?ć wszystkich kolejnych ogniw łańcucha certyfikacji.<br><br> Sama weryfikacja odbywa się w ten sposób, że klient po otrzymaniu od serwera jego certyfikatu sprawdza jaki urz?d go podpisał. Następnie szuka w swojej wewnętrznej bazie certyfikatu tego urzędu. Je?li go nie znajdzie, może spróbować poszukać go w bazie zewnętrznej ( do tego celu wykorzystuje się powszechnie katalogi LDAP ).<br><br> Zakres ochrony PKI
Autentyczno?ć podpisu na kluczu publicznym nie jest jedyn? cech? zapewnian? przez SSL. Sprawdzane s? także daty wystawienia oraz utraty ważno?ci certyfikatu (mógł on zostać wystawiony tylko na rok) oraz, opcjonalnie, czy nie był on anulowany przez ogłoszenie na publicznej li?cie unieważnionych certyfikatów (Certificate Revocation List).<br><br> Faktyczne wykorzystanie licznych mechanizmów zapewnianych przez PKI zależy od implementacji oraz potrzeb użytkownika, okre?lonych przez projektanta konkretnego wdrożenia. <br><br> JAVA SSL API
Zasadniczo API JAVA pozwalaj?ce na komunikacje TCP z wykorzystaniem poł?czenia szyfrowanego wiele się nie różni od takiego samego poł?czenia tylko nie szyfrowanego. Podstawow? operacj?, jaka tu należy wykonać przed rozpoczęciem ze strony serwera nasłuchiwanie , czy też ze strony klienta poł?czenia do serwera   jest okre?lenie po obu stronach parametrów zwi?zanych z szyfrowan? komunikacj?. Te parametry, to położenie pliku z baz? certyfikatów oraz pliku z baz? zaufanych kluczy publicznych oraz dodatkowo hasła do oby tych plików.<br><br> Parametry takie ustawiamy poprzez zmienne systemowe JAVA albo programistycznie albo poprzez dodatkowe parametry wywołania. Programistycznie można tego dokonać np. przez poniższy kod:<br><br> <font class=code> System.setProperty("javax.net.ssl.keyStore","/mnt/hd3/keyStore");<br> System.setProperty("javax.net.ssl.keyStorePassword","haslo");<br> System.setProperty("javax.net.ssl.trustStore","/mnt/hd3/trustStore");<br> System.setProperty("javax.net.ssl.trustStorePassword","haslo");<br> </font><br> Te same parametry ustawione w wywołaniu będ? wygl?dać następuj?co:<br><br> <font class=code> java -Djavax.net.ssl.keyStore=/mnt/hd3/keyStore <br>         -Djavax.net.ssl.keyStorePassword=haslo <br>         -Djavax.net.ssl.trustStore=/mnt/hd3/trustStore <br>         -Djavax.net.ssl.trustStorePassword=haslo nazwa_klasy_do_uruchomienia<br> </font><br> Dalej same rozpoczęcie komunikacji po stronie klienta może mieć postać:<br><br> <font class=code> SocketFactory ssf = SSLSocketFactory.getDefault();<br> Socket sockettoserver = ssf.createSocket(listener.host,listener.port);<br> </font><br> Po stronie serwera natomiast rozpoczęcie nasłuchiwania może wygl?dać następuj?co:<br><br> <font class=code> ServerSocketFactory ssf = SSLServerSocketFactory.getDefault();<br> ServerSocket ssoc = ssf.createServerSocket(port);<br> </font><br>