Historia SSL-a.
SSL powstał w 1994 za sprawą Netscape. Jednocześnie, Microsoft wymyślił PCT (ang. Private Communicating Technology) jako konkurencje dla SSL-a. Wymusiło to na Netscape zrealizowanie SSL w wersji 3 (SSL v3) w 1995 roku.
W 1996 roku za sprawą IETF (ang. Internet Engineering Task Force) powstała grupa robocza TLS (ang. Transport Layer Security), która ma za zadanie rozwijać oraz publikować standard SSL. W styczniu 1999 roku grupa ta opublikowała protokół TLS, który bazuje na SSL v3. Ważny jest fakt, że Microsoft oraz Netscape wspierają TLS. Microsoft oraz Netscape zaimplementowały TLS w swoich przeglądarkach.
Ogólny opis sesji SSL.
Hello (i negocjacja parametrów kryptograficznych)
Klient: Hello, serwer. Porozmawiajmy. Proszę, przyślij mi swój klucz publiczny.
Serwer: Przesyła klientowi swój certyfikat.
Klient: Szyfruje losowy numer za pomocą klucza publicznego serwera i przesyła do serwera.
Uzgadnianie klucza:
Klient i Serwer: Użycie losowego numeru do niezależnego generowania dzielonych tajnych kluczy (ang. secret keys).
Klient uwierzytelnia serwer:
Serwer: Serwer udowadnia klientowi, że wygenerował identyczny tajny klucz jak klient.
Poufność i integralność:
Klient i Serwer: Używają tajnych kluczy do wymiany wiadomości.
Pierwszą rzeczą jaką muszą zrobić uczestnicy biorący udział w sesji SSL/TLS jest negocjacja parametrów kryptograficznych, ponieważ przy pierwszym połączeniu ich nie znają. Warto zauważyć również to, że to klient uwierzytelnia serwer, a nie odwrotnie.
Szczegółowy opis sesji SSL.
Ponieważ SSL/TLS może używać różnych wariacji systemów kryptograficznych, dla uproszczenia w przykładzie użyję tylko jednej z nich.
Hello i negocjacja parametrów:
KLIENT:
Wymiana certyfikatów
Po udzieleniu odpowiedzi klientowi na Hello, serwer wysyła swój certyfikat. Certyfikat serwera podpisany jest przez zaufany ośrodek jakim może być urząd ds. certyfikatów (CA). Klient weryfikuje certyfikat serwera za pomocą klucza publicznego udostępnionego przez CA.
Po tym jak serwer wysyła swój certyfikat, protokół SSL/TLS zezwala na to by zażądał od klienta jego certyfikatu. Nie jest jednak wymagane to by serwer żądał certyfikatu klienta i nawet jeśli serwer go zażąda klient nie musi go wysyłać. Później wytłumaczę dlaczego.
Uzgadnianie klucza (Wymiana)
Klient generuje 48 bajtową losową wartość (pre-master secret). Szyfrowana ona jest za pomocą klucza publicznego (RSA) serwera. Następnie serwer odszyfrowuje tą wartość używając swojego dobrze dobranego klucza prywatnego RSA.
Do tej pory we wszystkich przykładach wymiany tajnego klucza pokazywano, że obie strony dzielą tylko jeden tajny klucz. W prawdziwych systemach preferowane jest używanie większej ilości tajnych kluczy by utrudnić kryptoanalizę.
Metoda HMAC (Hashed Message Authentication Code) używana jest do tworzenia niepowtarzalnego kodu uwierzytelniającego wiadomości, obliczanego z użyciem generatora skrótów i klucza prywatnego. Metoda HMAC powiększa moc istniejących generatorów skrótów do poziomu gwarantującego ich odporność na ataki nawet wówczas, gdy generator w oryginalnej postaci może zostać złamany (więcej informacji na temat tej metody zawiera specyfikacja RFC 2104). Więcej: ftp://sunsite.icm.edu.pl/pub/doc/rfc/rfc2104.txt.
Uwierzytelnienie
Jesteśmy w miejscu w którym możesz spodziewać się, że to serwer będzie sprawdzał autentyczność klienta, ale w naszym przykładzie tak nie jest.
Są ku temu dwa ważne powody:
Po pierwsze, serwer i tak będzie sprawdzał kartę kredytową klienta, a sprawdzanie autentyczności klienta może zabrać trochę czasu (usprawnienie dla niecierpliwych klientów).
Po drugie, większość klientów e-commerce nie posiada jeszcze swoich certyfikatów, a przyjmowanie nieznanych i tak wiązałoby się z dużym ryzykiem.
Klient przesyła do serwera wiadomość zaszyfrowaną za pomocą wspólnych tajnych kluczy. Wiadomość ta, nazywana końcowym uzgodnieniem (ang. finished handshake) jest jako pierwsza szyfrowana tajnym kluczem.
Serwer odpowiada również podobnym komunikatem. Klient jest teraz zapewniony, że musi komunikować się z serwerem ponieważ klient przesłał wiadomość: pre-master secret zaszyfrowaną za pomocą za pomocą klucza publicznego RSA serwera. Serwer odszyfrowuje tą wiadomość by obliczyć sześć wspólnych tajnych kluczy.
Poufność i integralność
Anonimowy Diffie-Hellman (ang. Anonymous Diffie-Hellman).
Jedna z odmian szyfru, zwana anonimowym Diffie-Hellmanem, pozwala serwerowi oraz klientowi na równoczesne generowanie sześciu dzielonych tajnych kluczy bez uwierzytelniania drugiej strony. Ale wtedy ani serwer ani klient nie jest pewny z kim ma doczynienia po drugiej stronie połączenia. Nasuwa się pytanie, po co zatem ktoś chce zastosować takie podejście ?
Jak już powiedziałem, strona serwera jest często zadowolona, kiedy otrzyma numer karty kredytowej i jest także chętna do podjęcia ryzyka jeżeli ktoś jeszcze używa karty kredytowej klienta bez jego uwierzytelnienia.
Co możemy powiedzieć o stronie klienta ? Klient może podjąć decyzję by zaufać, że serwer z którym się łączy jest tym którego on ma na myśli. Być może nie jest to wielkie ryzyko. Ludzie często dają numer karty kredytowej nieznajomym przez telefon, w restauracji itd. Więc czemu nie skorzystać także i z tej drogi ? Cóż, większość z nas tak robi.
Ale jeśli chcemy wysłać przez Internet bardziej wartościowe dane np. hasło, informacje na temat zdrowia, sposób z użyciem szyfru anonimowego Diffie-Hellmana jest zły.
Stały i ulotny Diffie-Hellman (ang. Fixed and Ephemeral Diffie-Hellman).
Oba rodzaje szyfru Diffie-Hellmana zawierają uwierzytelnienie. W stałym (statycznym) Diffie-Hellmanie serwer oraz klient wymieniają publiczne wartości zaszyfrowane Diffie-Hellmanem używając zaufanych certyfikatów. W odmianie ulotnej szyfru, serwer oraz klient wymieniają publiczne wartości Diffie-Hellmana podpisane za pomocą kluczy RSA lub DSA.
Porównanie protokołów TLS, SSL v3 i SSL v2.
W standardzie TLS jest napisane, że "wersja 1.0 protokołu TLS i SSL v3 są bardzo podobne i użycie obu jest równie łatwe". Kilka różnic dotyczy drobnych zmian w obliczeniach HMAC, wsparcia co do uzgodnienień wyboru szyfrów użytych w transmisji (ang. cipher suite) oraz obliczeniach losowej wartości. Możesz traktować TLS jako protokół "SSL v3.1".
Różnice pomiędzy SSL v3 a SSL v2 są już wyraźne. Ten kto ma dostęp do SSL v3 nie powinien używać SSL v2. Użytkownicy powinni wyłączyć wsparcie dla SSL v2 w ich przeglądarkach internetowych.
Problemy z protokołem SSL v2
Sposób negocjacji cipher suite w protokole SSL v2 umożliwia atakującemu zmuszenie serwera oraz klienta do użycia dużo słabszego szyfrowania niż są w stanie osiągnąć. Atak ten zwany jest odwróconym uzgadnianiem szyfrów (ang. cipher suite rollback). Dla przykładu, nawet jeżeli serwer oraz klient mogą użyć potrójnego DES-a (np. 168 - bitowe szyfrowanie), atakujący może zmusić obie strony do użycia 40 - bitowego szyfrowania.
Możliwe problemy protokołów TLS oraz SSL
Żadna z wersji protokołów TLS lub SSL nie chroni przeciw analizie ruchu w sieci. (ang. traffic analysis). Kryptoanalityk analizując ruch może zaobserwować liczbę wiadomości wysyłanych oraz adresy obu połączeń. Choć analityk nie wie co zawiera każda wiadomość, to jest możliwe że znajomość samej ilości przesyłanych danych pomiędzy dwoma adresami jest pożyteczną informacją. Dla przykładu, wymiana dużej ilości informacji pomiędzy dwoma oddziałami firmy znajdującymi się w różnych miastach może ułatwić przeciwnikowi analizę sposobu transmisji danego użytkownika.
Generowanie dzielonych tajnych kluczy
Rozdział ten opisuje co się dzieje po tym jak klient prześle do serwera poprzednik tajnego klucza. Serwer i klient używają poprzednika tajnego klucza, losowe wartości wymieniają w wiadomościach Hello oraz używają pseudo-losowych funkcji (PRF) do niezależnej i równoczesnej generacji głównego tajnego klucza.
Pseudo-losowe funkcje są bardzo podobne w działaniu do uruchamianych wielokrotnie funkcji tworzących skrót wiadomości. Dzięki temu tajny klucz jest na tyle przypadkowy, że uniemożliwia to atakującemu zrobieniu jego repliki. Po zakończeniu dwóch kolejek PRF, serwer i klient generują niezależnie sześć równoważnych tajnych kluczy.
W dokumentacji standardu TLS podano by pseudo-losowe funkcje używały dwóch różnych funkcji skrótów wiadomości. W przypadku gdy jedna z metod zostanie złamana, druga przypuszczalnie jest bezpieczna. Zapewnia to nas, że atakujący nie może wygenerować takich samych tajnych kluczy jak serwer i klient.
Po wygenerowaniu sześciu dzielonych tajnych kluczy, poprzednik tajnego klucza nie jest dłużej potrzebny i powinien być z powodów bezpieczeństwa skasowany.
Klient potwierdza swoja autentyczność
Jesłi serwer chce uwierzytelnić klienta, żąda on jego certyfikatu po tym jak sam go prześle. Poniżej przedstawiam poprawioną akcję komunikacji po tym jak klient prześle do serwera poprzednik tajnego klucza i swój certyfikat zawierający publiczny klucz RSA.
Klient potwierdza swoją autentyczność przedstawiając, że jego prywatny klucz RSA odpowiada kluczowi publicznemu zawartemu w certyfikacie serwera. Klient tworzy skrót kombinacji tajnego klucza i kilku poprzednich wiadomości. Następnie podpisuje skrót za pomocą swojego prywatnego klucza i przesyła go do serwera. Wiadomość przesyłana do serwera nosi nazwę wiadomości weryfikującej certyfikat (ang. certyficate verify message).
Serwer weryfikuje tą wiadomość za pomocą kopii publicznego klucza klienta.
Ważne jest to, że jeżeli nawet atakujący zdoła odszyfrować wiadomość z publicznym kluczem klienta, nie może on zdobyć tajnego klucza serwera oraz klienta ponieważ klient tworzy skrót z tajnego klucza przed podpisaniem go. Musisz wiedzieć, że w przypadku takich funkcji skrótu wiadomości jak MD5 lub SHA-1 nie możliwe jest odzyskanie oryginalnej wiadomości.
Źródło:
http://www.it-faq.pl/EditModule.aspx?tabid=1& mid=1170&def=Cs_ITSCS_CMS_Articles_View&ArticleID=1168
Autor: Łukasz Wójcicki
