Ochrona systemów informacyjnych. SSL (Secure Socket Layer) - protokół bezpiecznych połączeń sieciowych

Transkrypt

1 Ochrona systemów informacyjnych SSL (Secure Socket Layer) - protokół bezpiecznych połączeń sieciowych

2 Miejsce SSL SSL działa pomiędzy TCPIP a innymi protokołami. Używa TCP/IP w imieniu innych protokołów pozwalając na autentykację serwerklient i ustanowienie szyfrowanego połączenia HTTP LDAP IMAP SSL TCP/IP

3 Podstawy Protokół SSL jest praktycznym wykorzystaniem algorytmów kryptografii symetrycznej i asymetrycznej dla potrzeb bezpiecznej komunikacji w sieci Internet. W swej podstawowej wersji zabezpiecza on protokół HTTP, jednak z użyciem dodatkowych narzędzi można z jego pomocą obudować również usługi FTP, news i poczty elektronicznej. Ważnym problemem, który pojawił się przy implementacji bezpiecznych połączeń sieci WWW była sprawa autentyfikacji kluczy publicznych. To, że nie muszą one być tajne nie oznacza wcale, że mogą być zupełnie nie zabezpieczone przed atakami - powinna istnieć jakaś metoda zabezpieczania integralności kluczy publicznych. W większości rozwiązań z tym problemem poradzono sobie wprowadzając pewne "zaufane" instytucje przechowujące klucze publiczne. Przykładowo w systemie PGP istnieje w sieci centralna baza kluczy publicznych, w której dostępne są klucze wielu znanych osób. Również integralną częścią protokołu SSL jest mechanizm obsługi certyfikatów

4 Certyfikaty Certyfikat jest to zbiór danych jednoznacznie identyfikujących pewną jednostkę (na przykład osobę, lub komputer) oraz pozwalający stwierdzić, czy osoba, która się nim legitymuje jest rzeczywiście tym, za kogo się podaje. Jest on potwierdzony przez zaufaną organizację, zwaną w protokole SSL certificate authority (CA). Certyfikat zawiera: Nazwę certyfikowanego obiektu Identyfikator obiektu Klucz publiczny obiektu Czas ważności Nazwę wystawcy certyfikatu Identyfikator wystawcy Podpis wystawcy (To pole zawiera jednoznaczny skrót całego certyfikatu zaszyfrowany przy pomocy klucza prywatnego wystawcy.)

5 Certyfikaty Szczególnym przypadkiem jest certyfikat poświadczający tożsamość CA - identyfikator wystawcy jest w nim równy identyfikatorowi obiektu, a skrót certyfikatu jest szyfrowany kluczem publicznym obiektu! Jest to logiczna konsekwencja przyjętego założenia, że CA jest instytucją zaufaną i jej tożsamości nie trzeba sprawdzać (a właściwie nie można, bo kto ją miałby potwierdzić?). W ogólnym przypadku mamy tak zwany łańcuch certyfikatów. Nie musimy (a nawet nie powinniśmy) bowiem dla każdego obiektu w danym systemie wystawiać certyfikatu potwierdzonego przez CA, gdyż spowodowałoby to przeciążenie tych instytucji i niepotrzebny rozrost bazy danych. Możemy na własne potrzeby ustanowić lokalny urząd certyfikacyjny który będzie poświadczał lokalne certyfikaty, a sam będzie legitymował się certyfikatem poświadczonym przez CA.

6 Certyfikaty W takim przypadku przy autentyfikacji certyfikatu możliwe są dwie sytuacje: Jeżeli możemy sobie na to pozwolić, to ustalamy, że wewnątrz naszej sieci ufamy wszystkim certyfikatom potwierdzonym przez lokalny CA - wtedy w zasadzie możemy zrezygnować z usług zewnętrznej instytucji certyfikującej. Jeżeli jednak chcemy sprawdzić, czy instytucja potwierdzająca certyfikat, który właśnie otrzymaliśmy jest faktycznie tym, za kogo się podaje, zawsze możemy w analogiczny sposób zweryfikować jej certyfikat. W ten sposób w końcu dojdziemy do kogoś komu ufamy (w najgorszym razie będzie to któryś z międzynarodowych CA - ale komuś ufać musimy :).

7 Unieważnianie certyfikatów Problemem który pojawia się wraz z certyfikatami jest ich unieważnianie. O ile bowiem łatwo jest stwierdzić, czy certyfikat nie jest już za stary - zawiera on odpowiednie pole, to może się okazać, że należy certyfikat unieważnić przed jego terminem wygaśnięcia. Przykładowo, jeśli 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ązanie (choć nie idealne) tego problemu to listy unieważnień (certificate revocation lists) przechowywane we wszytkich 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. Nie jest to niestety rozwiązanie idealne, gdyż generuje dodatkowy ruch w sieci i jest dość "sztuczne". Niestety jak do tej pory nie wymyślono nic lepszego i często wręcz nie stosuje się żadnych metod unieważniania certyfikatów.

8 SSL przebieg SSL jest protokołem typu klient-serwer pozwalającym na nawiązanie bezpiecznego połączenia z użyciem certyfikatów. Jest on zorientowany głównie na autentyfikację serwera (np. sklepu internetowego do którego klient wysyła numer karty kredytowej i chce mieć pewność co do odbiorcy), ale przewiduje również możliwość autoryzacji klienta. Schemat działania protokołu wygląda następująco (jako K oznaczamy klienta, a jako S - serwer):

9 SSL K -> S ClientHello Klient 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. K <- S ServerHello Serwer odpowiada podobnym komunikatem w którym zwraca klientowi wybrane parametry połączenia: wersję protokołu SSL, rodzaj szyfrowania i kompresji, oraz podobną liczbę losową. K <- S Certificate Serwer wysyła swój certyfikat pozwalając klientowi na sprawdzenie swojej tożsamości (ten etap jest opcjonalny, ale w większości przypadków występuje)

10 SSL K <- S ServerKeyExchange Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i długośc tego klucza jest określony przez typ algorytmu przesłany w poprzednim komunikacie. K <- S ServerHelloDone Serwer zawiadamia, że klient może przejść do następnej fazy zestawiania połączenia. K -> S ClientKeyExchange Klient 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. Uwaga: wygenerowany klucz jest kluczem algorytmu symetrycznego (typowo DES)! Jest on jednak ustalony w sposób bezpieczny i znany jest tylko komunikującym się stronom.

11 SSL K -> S ChangeCipherSpec Klient zawiadamia, że serwer może przełączyć się na komunikację szyfrowaną. K -> S Finished... oraz że jest gotowy do odbierania danych zakodowanych. K <- S ChangeCipherSpec Serwer zawiadamia, że wykonał polecenie - od tej pory wysyłał będzie tylko zaszyfrowane informacje. K <- S Finished... i od razu wypróbowuje mechanizm - ten komunikat jest już wysyłany bezpiecznym kanałem!

12 Protokół SSL przewiduje również kontrolowane zakończenie połączenia. Jest 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.

13 Autentyfikacja klienta Jak widać na schemacie z poprzedniego punktu, w protokole SSL domyślna sytuacja zakłada tylko autentyfikację serwera. Istnieją jednak metody pozwalające na autentyfikację klienta. W tym celu korzysta się z trzech dodatkowych komunikatów: K <- S CertificateRequest Po przesłaniu swojego certyfikatu serwer zawiadamia, że chciałby otrzymać certyfikat klienta K -> S Certificate Po otrzymaniu komunikatu ServerHelloDone klient odsyła swój certyfikat K -> S CertificateVerify Klient musi potwierdzić, że faktycznie posiada klucz prywatny odpowiadający wysłanemu certyfikatowi. W tym celu klient szyfruje swoim kluczem prywatnym skrót wszystkich dotychczas ustalonych danych o połączeniu i wysyła go korzystając z tego komunikatu.

14 Odtwarzanie poprzedniej sesji 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 klient poda SessionId równy identyfikatorowi jednej z poprzednich sesji, to serwer przyjmie, że klient chce kontynuować połączenie z użyciem poprzednio używanego klucza.

15 Szyfry używane w SSL

16 Wersje SSL SSL 1 wersja miała poważną dziurę w bezpieczeństwie. Procedury uzgadniania szyfru nie były zabezpieczone, więc atakujący mógł wymusić używanie najsłabszego szyfru obsługiwanego przez komunikujących się, ze złamaniem którego mógł sobie poradzić znacznie łatwiej niż z szyfrem, który strony wybrałyby normalnie. SSL 2 wersja zmienia procedurę negocjacyjną. SSL 3 popularna wersja, obecnie wypierana przez TLS 1.0. TLS 1.0 (Transport Layer Security) rozwinięcie SSL 3 opisane w RFC TLS 1.1 opisana w RFC 4346, zalecana przez IETF jako standard i coraz częściej używana. Wyjaśnia ona pewne niejednoznaczności i dodaje nowe zalecenia wynikające z praktyki użycia opisano to w RFC 4366, RFC 4680 i RFC TLS opisana w RFC 5246 i oparta o wcześniejszą wersję, czyli TLS 1.1.

17 Certyfikaty raz jeszcze Certyfikat klienta klucz publiczny występuje w certyfikacie (jest jego częścią), klucz prywatny zapisywany jest w systemie plików klienta (w danych przeglądarki) i nie podlega przesyłaniu poprzez sieć. Dodatkowo ochronę klucza można wzmocnić stosując szyfrowanie z hasłem. Dzięki takim certyfikatom możliwe jest zapamiętanie loginu w wielu serwisach internetowych chronionych hasłem.

18 Zalety stosowania certyfikatów Hasła nie są przesyłane siecią certyfikaty wysyłają jedynie dane publiczne Jedno konto dla wielu serwisów Dobra ochrona kryptograficzna Zmniejszenie kosztów administracyjnych w intranecie

19 Wydawanie certyfikatów Certyfikaty powinien wydawać dedykowany serwer Proces powinien być możliwie prosty wypełnienie formularza i podanie hasła Tak zorganizowane, że klucz chroniący certyfikat klienta nigdy nie będzie przesyłany siecią

20 Certyfikaty na przykładzie Netscape Klient wypełnia formularz certyfikacji, podając swoje imię, nazwisko, itd. Formularz zawiera też specjalną instrukcję HTML <keygen> która powoduje wygenerowanie pary kluczy klienta "wewnątrz" przeglądarki. Z procesem generowania kluczy wiąże się oczywiście wybranie jego długości oraz wprowadzenie hasła zabezpieczającego klucz prywatny. Po wypełnieniu dane formularza wraz z kluczem publicznym przesyłane są do serwera. Serwer sprawdza dane nadesłane przez klienta, wystawia certyfikat, przesyła go do serwera certyfikatów oraz przesyła klientowi URL certyfikatu pocztą elektroniczną. Użytkownik podłącza się do wskazanego URL sprowadzając swój certyfikat. Dokument z certyfikatem posiada odpowiedni typ MIME, tak, że zostaje przez przeglądarkę automatycznie dopisany do lokalnej (dla przeglądarki) bazy danych certyfikatów.

21 Certyfikaty dla serwera Można założyć, że serwer WWW zarządzany jest przez firmę, która może sobie pozwolić na rejestrację z autorytetem sieciowym oraz zatrudnienie administratora znającego podstawy kryptografii, który będzie zarządzał bezpiecznym serwerem. Certificate Signing Request (CSR) jest żądaniem wystawienia certyfikatu, generowanym przez serwer, dla konkretnej domeny. Zawiera podstawowe informacje takie jak nazwę wnioskującego, adres strony oraz autoryzowany adres . Zawiera również klucz publiczny (który stanowi część jawną certyfikatu). CSR jest następnie przesyłany do wystawcy certyfikatu i na jego podstawie jest generowany certyfikat. Aby uzyskać CSR, możesz zwrócić się z prośbą o jego wygenerowanie do administratora swojego serwera, podając dokładną nazwę domeny dla jakiej ma być wygenerowany certyfikat oraz swoje dane. Możesz również skorzystać z narzędzia generator CSR, które utworzy dla Ciebie zarówno klucz prywatny jak i CSR. Otrzymany CSR możesz sprawdzić na kolejnej stronie, czy jest poprawny. Certyfikaty SSL są wydawane przez różnych wystawców. Wystawcy mogą pochwalić się różnym okresem działania na rynku oraz różną gamą certyfikatów SSL, które jednak zapewniają ten sam, wysoki poziom szyfrowania. Oferta jest również kierowana do różnych segmentów rynkowych. Przykładowo, marka Verisign jest najlepiej rozpoznawana na świecie, zaś certyfikaty Verisign oferują najwięcej możliwości, są jednak najdroższe.

22 proces uwierzytelnienia danych przed wydaniem certyfikatu Szczegółowe informacje odnośnie weryfikacji są wysyłane bezpośrednio przez wystawcę na adres podany przy zamówieniu usługi. Należy postępować zgodnie ze wskazówkami. W większości przypadków wystarczy potwierdzenie dokonane przez Internet. W przypadku pełnego uwierzytelniania może zaistnieć konieczność przesłania dodatkowych dokumentów. Komunikacja odbywa się bezpośrednio pomiędzy zamawiającym certyfikat a wystawcą. Aby otrzymać certyfikat, należy mieć dostęp do skrzynki znajdującej się w domenie, dla której jest wydawany certyfikat o nazwie jednej z następujących: webmaster, admin, administrator, hostmaster, postmaster. Przykładowo, adresem weryfikacyjnym dla domeny secure.xyz.pl może być admin@xyz.pl, zaś dla domeny może być admin@domeny.tv. Przed wysłaniem zamówienia na certyfikat innego typu niż Instant prosimy również o upewnienie się, iż dane abonenta domeny wpisane w bazie WHOIS są zgodne z danymi w CSR oraz we wniosku o wydanie certyfikatu. W przypadku niezgodności danych może nastąpić odmowa wydania certyfikatu.

23 uwierzytelnienie podstawowe a pełne Poziom uwierzytelnienia dotyczy procedury wystawiania certyfikatu. W wariancie podstawowym nie jest weryfikowana tożsamość osoby aplikującej, jedynie prawa własności do domeny, dla której certyfikat ma zostać wydany. W każdym przypadku na adres administratora w domenie wysyłany przez wystawcę certyfikatu z prośbą o potwierdzenie danych i zaakceptowanie warunków wystawienia certyfikatu. W wariancie pełnym uwierzytelnienia weryfikowana jest również tożsamość oraz fizyczny adres aplikanta/firmy na podstawie dodatkowych dokumentów (muszą być one przetłumaczone na język angielski). W takim przypadku do certyfikatu oprócz nazwy domeny wpisywane są również dodatkowe zweryfikowane dane. Wówczas certyfikat nie tylko zapewnia szyfrowane połączenie ale również daje dodatkową gwarancję wiarygodności Twojej firmy dla klienta.

24 Dokumenty potrzebne do wydania certyfikatu Dla certyfikatów z podstawowym uwierzytelnieniem nie są potrzebne żadne dokumenty. Cała weryfikacja odbywa się elektronicznie i trwa mniej niż 24 godziny. Jeśli jednak wybierzesz certyfikat z pełnym uwierzytelnieniem, upewnij się że dane wnioskodawcy są identyczne z danymi wpisanymi w bazie WHOIS dla domeny. Dodatkowo będziesz potrzebować kopii przysięgłego tłumaczenia na język angielski dokumentu rejestrowego firmy (wpis do ewidencji działalności gospodarczej lub KRS). Jeśli nie posiadasz takiego dokumentu, wybierz certyfikat z podstawowym uwierzytelnieniem.

25 Logo uwierzytelniające W przypadku gdy dla certyfikatu dostępne jest logo uwierzytelniające, można je umieścić na stronie WWW będącej przedmiotem szyfrowania. Wówczas po kliknięciu użytkownik uzyska informacje będące uprzednio zweryfikowane (nazwa domeny i opcjonalnie nazwa oraz adres aplikanta/firmy w przypadku droższych certyfikatów). Da to jeszcze większą pewność Twoim klientom, że powierzają swoje dane wiarygodnemu partnerowi.

26 Certyfikat EV Wydanie certyfikatu EV jest możliwe tylko po pomyślnym przeprowadzeniu procedury weryfikacji tożsamości aplikanta. Przygotowanie i przedstawienie dokumentów wystawcy leży w obowiązku zamawiającego certyfikat, zaś cała procedura weryfikacji może trwać kilka dni, bądź dłużej, jeśli zajdzie konieczność uzupełniania dokumentów. W przypadku certyfikatu SSL GeoTrust EV prosimy o dokładnie zapoznanie się z wymaganiami GeoTrust EV, gdzie dokładnie opisana jest procedura weryfikacji oraz lista dokumentów, jakie mogą być potrzebne. W szczególności należy wypełnić oraz dostarczyć dokument Acknowledgement of Agreement. Wszystkie przesyłane dokumenty prosimy oznaczyć numerem zlecenia, otrzymanym po zainicjowaniu realizacji zamówienia. W przypadku certyfikatu SSL Comodo EV prosimy o dokładnie zapoznanie się wytycznymi w zakresie weryfikacji Comodo EV. Dodatkowo, oprócz dokumentów aplikanta, należy wypełnić oraz podpisać następujące dokumenty: EV SSL Certification Form oraz EV SSL Certificate Subscriber Agreement. Wzory obydwu dokumentów znajdują się na stronie pobierania dokumentów Comodo. Wszystkie przesyłane dokumenty prosimy oznaczyć numerem zlecenia, otrzymanym po zainicjowaniu realizacji zamówienia.

27 Co oznacza, że certyfikat jest wydawany dla jednej nazwy domenowej? Oznacza to, że certyfikat będzie zabezpieczał poprawnie wszystkie adresy internetowe umieszczone w domenie, dla której został wydany. Czyli certyfikat wydany dla będzie działał również np. dla adresu Nie będzie jednak działał dla innych subdomen, czyli np. dla www2.mserwis.pl. Prosimy zwrócić uwagę, iż oraz mserwis.pl to dwie różne nazwy domenowe. Certyfikat wydany dla jednej z nich nie będzie działał poprawnie dla drugiej. Wyjątek od powyższej zasady stanowią wyłącznie certyfikaty GeoTrust oraz RapidSSL. Taki certyfikat wydany dla domeny będzie działał również dla mserwis.pl (ale już nie na odwrót). Reguła ta obowiązuje tylko, gdy www stanowi domenę trzeciego poziomu, czyli ale już nie

28 Certyfikat typu EV Certyfikat typu EV (Extended Validation) to najnowszy produkt w rodzinie certyfikatów GeoTrust. Dodatkowa jego funkcjonalność jest wspierana przez przeglądarki Internet Explorer 7.0+ oraz Mozilla Firefox 2+. Polega ona na tym, iż adres strony szyfrowanej certyfikatem EV jest podświetlony w pasku adresowym przeglądarki, jak również wyświetlana jest tam nazwa firmy, której nazwa jest zapisana w certyfikacie (abonent domeny). Te certyfikaty są powszechnie używane przez instytucje zaufania publicznego, szczególnie banki, gdzie priorytetem jest zapewnienie największego bezpieczeństwa i poufności dokonywanych transakcji

29 Czy można anulować certyfikat lub zmienić jego typ? W okresie od momentu rozpoczęcia procedury wydania certyfikatu do jego wydania oraz do 30 dni po wydaniu certyfikatu istnieje możliwość jego anulowania lub zamiany. Przykładowo, można certyfikat EV na inny rodzaj bądź wystawić certyfikat dla innej domeny, niż pierwotnie zamawiana. Z tytułu każdej zmiany tego typu pobierana jest opłata manipulacyjna w wysokości 100 zł netto plus ewentualna różnica w cenie certyfikatów. Nie dotyczy to przypadku ponownego wystawienia certyfikatu tego samego typu dla tej samej domeny - to w okresie ważności całego certyfikatu jest bezpłatne.