Wykład 9 Protokoły SSL i. Scentralizowane systemy uwierzytelniania. 5 listopada 2013 SSL/ Serwery Instytut Informatyki Uniwersytet Jagielloński 9.1
Secure Sockets Layer i Transport Layer Security SSL zaproponowany przez Netscape w 1994 roku wersja 1.0 miała tak wiele błędów, że nigdy nie została udostępniona Netscape współpracował ze społecznością Internetu kryptolodzy natychmiast zauważyli mnóstwo dziur pierwsza udostępniona była wersja v2.0 ok. lutego 1995 poprawił wiele błędów SSL SSL/ Serwery SSL/ ma zapewniać bezpieczeństwo połączeń w sieci SSL/ jest protokołem pomiędzy warstwą TCP a warstwą aplikacji jest "przeźroczysty" i działa w warstwie prezentacji OSI całkowicie opiera się na protokołach połączeniowych zapewniających kompletność transmisji istnieje rozszerzenie Datagram (D) dla UDP 9.2
SSL/ ma zapewniać bezpieczeństwo połączeń między dwoma stronami w sieci gdzie żadna ze stron nie ma kontroli nad całym połączeniem istnieje duże prawdopodobieństwo przejęcia komunikacji SSL/ opiera się na protokołach połączeniowych protokół nawiązuje połączenie, syn, syn-ack, ack wykonuje swój handshake następnie negocjacja bezpiecznego połączenia wszystko przed połączeniem warstwy aplikacyjnej żadna z informacji warstwy aplikacji nie wydostaje się na zewnątrz SSL/ Serwery 9.3
SSL/ narzędzia kryptograficzne szyfrowanie asymetryczne pary kluczy (prywatny, publiczny) tym bezpieczniejszy im liczby pierwsze (RSA) są dłuższe to spowalnia szyfrowanie stosować w skończonej liczbie SSL/ wykorzystują szyfrowanie asymetryczne dla weryfikacji i negocjacji klucza sesyjnego szyfrowanie symetryczne symetryczny klucz sesyjny wspólny dla obydwu stron blokowanie strumienia SSL/ z założenia udostępnia szyfrowanie strumienia danych szyfrowanie symetryczne zwykle jest blokowe to wymaga podziału strumienia na bloki i uzupełniania ich konieczne jest połączenie bloków przez szyfrowanie Message Authentication Codes (MAC) SSL/ Serwery 9.4
SSL/ narzędzia kryptograficzne szyfrowanie asymetryczne szyfrowanie symetryczne blokowanie strumienia SSL/ z założenia udostępnia szyfrowanie strumienia danych szyfrowanie symetryczne zwykle jest blokowe to wymaga podziału strumienia na bloki i uzupełniania ich konieczne jest połączenie bloków przez szyfrowanie Electronic Codebook (): każdy blok szyfrowany oddzielnie niebezpieczne Cipher Block Chaining (): szyfrowanie danego bloku zależne od poprzednich używany wymaga przesyłania wektora inicjalizacyjnego Message Authentication Codes (MAC) zabezpiecza przed modyfikacja strumienia MAC na podstawie danych i numeru seryjnego pakietu strona odbierająca kontroluje poprawność MAC SSL/ Serwery 9.5
electronic codebook każdy blok niezależnie kodowany bloki muszą być dopełniane: zerami, jedynkami, wzorcami, losowo szybkie i wygodne dla dostępu losowego to chyba jedyna zaleta identyczne wiadomości będą kodowane do takich samych bloków szczególna podatność na atak nagłówków i zakończeń często są powtarzalne podatność na ataki słownikowe problemem może być standardowe dopełnianie podatność na ataki polegające na wymianie pojedynczych bloków Mallory może podmienić bloki z numerem konta w komunikacie na swoje własne konto... nie zapewnia integralności SSL/ Serwery 9.6
cipher block chaining łączenie tekstu otwartego z szyfrogramem poprzedniego C i = E K (M i C i 1 ) P i = C i 1 D K (C i ) pierwszy blok łączony z wektorem inicjalizacyjnym IV musi być znany drugiej stronie dobrze losować; nie używać przewidywalnych wartości IV eliminuje wady ale wciąż ujawnia sporo informacji możliwe błędy w przekazywanym szyfrogramie 1 bit błędu całkowici zniszczy blok (propagacja błędu) ale kolejny blok będzie miał tylko 1 bit błędny (self-recovery) nadać strukturę, by Mallory nie mogła dodawać bloków uzupełnić wiadomość nadmiarowością lub uwierzytelnianiem SSL/ Serwery 9.7
Weryfikacja zapewnia uwierzytelnianie (authentication) oparte na certyfikatach komunikaty są podpisywane i przesyłane wraz z certyfikatem strony certyfikat zawiera informację identyfikującą i klucz publiczny podpisane przez instytucję, do której odbiorca ma zaufanie instytucja zapewnia możliwość weryfikacji certyfikatu czasem serwer wykorzystuje certyfikat podpisany przez samego siebie SSL/ jest protokołem typu klient serwer w https, pop3s, imap4s zwykle weryfikowany jest tylko serwer serwer może zażądać weryfikacji klienta możliwa jest anonimowa kluczy w takiej sytuacji weryfikacja nie jest wykonywana możliwość ustawienia fałszywego serwera SSL/ Serwery 9.8
SSL/ protokół zabezpiecza przed modyfikacjami pakietów w wymianie jest kontrola, czy pakiety nie zostały zmodyfikowane wszystkie pakiety są serializowane przez całe połączenie kontrola numerów seryjnych pakietów czy się nie duplikują? czy któregoś nie brakuje? SSL v2.0 używał MD5 jako funkcji haszującej przez długi czas nie było to problemem SSL v3.0 używał jednocześnie MD5 i SHA-1 wynik był xor-owany jeśli jeden zostałby złamany, to w dalszym ciągu rozwiązanie bezpieczne dopóki drugi był bezpieczny wykorzystuje obecnie SHA-256 SSL/ Serwery 9.9
IETF uznało SSL v3.0 i przyjęło go za standard 1.0 w 1999 roku teraz mamy wersję 1.2 wykorzystuje SHA-256 istnieje możliwość użycia poprzednich przy połączeniu z wcześniejszą wersją wykorzystuje funkcję haszującą z kluczem HMAC jako generator liczb losowych do danych xor-owany jest łańcuch bloków 0x5C z kluczem i danymi co jest haszowane do wyniku doklejany jest klucz, xor-owany inny łańcuch i haszowane wielokrotne haszowanie HMAC z ziarnem daje generator liczb losowych o dobrych własnościach SSL/ Serwery 9.10
Komunikaty handshake nawiązanie porozumienia, weryfikacja (serwera, lub obu), kluczy hello request client hello server hello server certificate server key exchange server hello done client certificate client key exchange certificate verify finished change ciper spec informuje, że ustalone parametry stają się ważne od tej chwili wysyłane zaraz po ustaleniu, tuż przed przesyłaniem danych obowiązuje tylko stronę odbierającą musi być wysłane w obydwu kierunkach alert wysyłane w dowolnym momencie gdy połączenie ma być przerwane lub nastąpił błąd application data dane aplikacji SSL/ Serwery 9.11
Dystrybucja kluczy RSA tajny klucz szyfrowany kluczem publicznym adresata Diffie Hellman stały z wykorzystaniem certyfikatów klucza publicznego potwierdzających wartość parametrów Diffie Hellman tymczasowy (efemeryczny) uzgodnienie jednorazowego klucza poprzez przesyłanie publicznych kluczy algorytmu DH zaszyfrowanych kluczami prywatnymi RSA; zapewne metoda najbezpieczniejsza Diffie Hellman anonimowy standardowy algorytm DH bez uwierzytelniania podatny na atak MITM SSL/ Serwery Fortezza wykorzystanie metody kryptograficznej dla algorytmu szyfrującego Fortezza utworzonego dla szyfrowania za pomocą kart w systemie Clipper (klucz 80-bitowy) 9.12
Wymiana : klucza poprzez RSA klient client hello client key exchange change cipher spec finished serwer server hello certificate server hello done change cipher spec finished application data application data klucz na podstawie liczb losowych w komunikatach hello obliczanie klucza wykorzystuje także wstępną tajemnicę tajemnica wysyłana przez klienta zaszyfrowana kluczem publicznym udostępnionym w certyfikacie serwera finished zawiera skrót wszystkich dotąd wysłanych SSL/ Serwery 9.13
Wymiana : client hello połączenie przychodzące na port 443 zakłada użycie serwer oczekuje komunikatu client hello w definicji protokołu istnieje możliwość przesyłania pustych danych dla zmylenia ewentualnych podsłuchiwaczy klient wysyła client hello z zawartym numerem najwyższej wersji, którą obsługuje to sposób na znalezienie najlepszego możliwego połączenia client hello zawiera także identyfikator sesji client hello ma też 32-bajtową liczbę losową (32 bity czasu i 28 bajtów wygenerowanych lokalnie przez generator liczb losowych oparty na HMAC) kryptografia asymetryczna jest kosztowna, więc jeśli klient komunikuje się z tym samym IP czy serwerem, którego już zna i ma uwierzytelnienia, to wysyła ten sam identyfikator sesji, co ostatnim razem to połączenie mogło być bardzo niedawno nie ma żadnej gwarancji, że serwer zaakceptuje ten ID SSL/ Serwery w client hello jest lista obsługiwanych protokołów kryptograficznych i algorytmów kompresji jest łatwo modyfikowalny i można przestać obsługiwać błędne algorytmy a przyjąć nowe ewentualna kompresja (rzadko) oczywiście najpierw 9.14
Wymiana : server hello/certificate/done istnieje możliwość wstecznej kompatybilności jednak nie dalej niż SSL v3.0 na pewno nie wolno użyć np. MD5 serwer wybiera najwyższy poziom kompatybilności, którą znają obie strony generuje własną 32-bajtową liczbę losową wyszukuje czy zna już zaproponowany identyfikator sesji ID serwer zwraca w server hello wybrany poziom, liczbę losową oraz pusty ID zgoda na wznowienie sesji a serwer nie robi cache-owania po swojej stronie nowy ID nie zna podanego ID i proponuje nowy podany ID rozpoznaje klienta i sesję i jest zgoda na jej wznowienie skrócony handshake SSL/ Serwery następnie wysyła certyfikat (w server hello lub certificate) certyfikat zawiera całą hierarchię podpisów 9.15
Wymiana : client key/change cipher spec/finished jeśli wraca do klienta inny ID klient sprawdza otrzymany w certificate certyfikat generacja kluczy klient generuje klucz wysyła go zaszyfrowany kluczem publicznym serwera znajdującym się w certyfikacie wysyłany jest w zasadzie tzw. pre_master_secret z niego obliczany jest master_key z niego klucze służące do wykorzystania w wybranych protokołach kryptograficznych: szyfrowaniu, obliczaniu MAC, wartości uwierzytelniania SHA obie strony wysyłają change cipher spec i finished kontrolują hasze w finished i rozpoczyna się danych SSL/ Serwery 9.16
Komunikaty : efemeryczny handshake klient serwer client hello server hello server key exhange certificate server hello done client key exchange change cipher spec finished change cipher spec finished application data application data SSL/ Serwery wykorzystuje wymianę kluczy Diffie Hellmana 9.17
Wymiana : client cipher jeśli wraca ten sam ID, to nie ma więcej negocjacji klient wysyła change cipher spec oznaczający koniec negocjacji obie strony generują nowy klucz sesyjny serwer potwierdza i wysyła swój change cipher spec wtedy wymieniają finished finished hasze wszystkich poprzednich i dopiero po ich potwierdzeniu rozpoczyna się na poziomie aplikacji SSL/ Serwery 9.18
Wymiana : skrócony handshake klient serwer client hello server hello change cipher spec finished change cipher spec finished application data application data SSL/ Serwery 9.19
Wymiana numery sekwencyjne każdy z klientów ma swoją pulę 64-bitowych numerów sekwencyjnych po nadejściu polecenia change cipher spec należy wyzerować numer sekwencyjny poufność i integralność dane aplikacji są dzielone na pakiety każdy pakiet jest opcjonalnie kompresowany w nie jest określony standardowy algorytm i domyślnie kompresja nie jest robiona dane są uwierzytelniane dołączanym kodem MAC taki pakiet jest szyfrowany zaszyfrowany dostaje nagłowek SSL i jest wysyłany SSL/ Serwery 9.20
jest najczęściej używanym kryptograficznym protokołem w Internecie jest łatwo rozszerzalny jest bardzo oszczędny w liczbie pakietów SSL/ Serwery jest opisany w RFC 5246 (104 strony!) 9.21
Wady? adresy IP są przekazywane otwartym tekstem nie ma wbudowanych ułatwień dla transakcji bankowych na przykład numer karty kredytowej będzie cache-owany na serwerze w otwartym tekście, i jeśli będzie włamanie... jest podatny na atak man in the middle jeśli klient nie używa dobrze potwierdzonych certyfikatów SSL/ Serwery 9.22
HTTPS, SSH HTTPS to HTTP over SSL komunikacja na porcie 443 przede wszystkim dla uwiarygadniania serwera SSH czyli Secure SHell zaproponowany przez Tatu Yl onen w 1995 pierwsza wersja w wersji open, późniejsze coraz bardziej ograniczone OpenSSH utworzone w 1998 kompresja strumienia, uwierzytelnianie kluczem publicznym, forwardowanie portów, forwardowanie X11, transmisja plików w warstwie transportowej: uwierzytelnianie serwera w oparciu o klucz publiczny klucza metodą algorytmu Diffie Hellmana ten klucz staje się kluczem nadrzędnym klucze do szyfrowania generowane na podstawie klucza nadrzędnego K wartości H pochodzącej z etapu negocjowania K (hasz szeregu parametrów wymiany i samego K) identyfikatora sesji (to może być H) szyfrowanie: Blowfish, Twofish, AES, Serpent, CAST, RC4 uwierzytelnianie: klucz publiczny, hasło, przez hosta pozwala na forwardowanie portów SSL/ Serwery 9.23
Systemy A uthentication A uthorization A ccounting NAS Network Access Systems klient poprzez który użytkownik łączy się z serwerem uwierzytelniania Remote Authentication Dial-In User Service Livingstone Enterprises Terminal Access Controller Access Control System SSL/ Serwery Cisco, później + jako rozwinięcie Sun Laboratories 9.24
podstawowe zasady podstawowe elementy rozproszony model bezpieczeństwa klient/serwer transakcje uwierzytelniania elastyczne mechanizmy uwierzytelniania atrybuty połączeń o zmiennej długości dla umożliwienia różnych parametrów modyfikowalny parametr połączenie 1 użytkownik łączy się z NAS podając swój identyfikator i hasło 2 NAS żąda uwierzytelnienia w serwerze połączenia między klientem (NAS) a serwerem są uwierzytelniane i szyfrowane 3 serwer uwierzytelnia użytkownika odsyła parametry połączenia, uwierzytelnienie i informacje o protokole 4 NAS ustanawia połączenie i zapisuje informacje o połączeniu SSL/ Serwery 9.25
szereg zalet użytkownicy obsługiwani przez jeden serwer mniej problemów z obsługą klientów minimalizacja konfiguracji tylko jeden serwer mniej problemów z administracją łatwiejszy audyt pojedynczego systemu możliwość wzmacniania poprzez użycie dodatkowych metod uwierzytelniania rozszerzalna architektura systemu serwery wykorzystywane przez szereg wbudowanych SSL/ Serwery zwykle nie będą sobie radziły z bardzo dużą liczbą użytkowników z różnymi danymi uwierzytelniającymi pozwalają na scentralizowanie zapewniając wystarczający poziom bezpieczeństwa 9.26
Możliwe VPN SSL/ Serwery Możliwa architektura wirtualnej sieci prywatnej (R router, SG security gateway) 9.27
najbardziej popularny prawdopodobnie dzięki udostępnieniu kodu autorzy uwzględnili modyfikacje klientów dostępność dla bardzo wielu system wykorzystuje 2 podstawowe pliki konfiguracyjne konfiguracje klientów: adresy klientów i wspólne tajemnice dla szyfrowania konfiguracje użytkowników identyfikatory i informacje uwierzytelniające klientów parametry połączeń i uwierzytelniania parametry przekazywane w prostym pakiecie UDP SSL/ Serwery brak narzutów transmisyjnych retransmisje stają się problemem przy błędach transmisji szczególnie kłopotliwe przy urządzeniach mobilnych 9.28
: A i A access-request żądanie uwierzytelnienia (authentication) wraz z identyfikatorem i hasłem pakiety są zabezpieczone szyfrowaniem strumieniowym z wykorzystaniem MD5 jako generatorem serwer odszyfrowuje ten pakiet od NAS to uwierzytelnia klienta NAS walidacja parametrów żądania poprzez porównanie z plikiem konfiguracji klientów access-accept potwierdzenie uwierzytelnienia access-reject odrzucenie uwierzytelnienia access-challange żądanie dodatkowego uwierzytelnienia (np. hasło jednorazowe) SSL/ Serwery zwracając potwierdzenie uwierzytelniania serwer podaje także parametry połączenia parametry łącza danych dla PPP parametry warstwy sieci inne parametry związane z konkretnym połączeniem 9.29
:... i A accounting-request i accounting-client osobne funkcje nie zawsze implementowane rozpoczyna serwer NAS jeśli tak skonfigurowany powoduje zapisanie wszystkich informacji o połączeniu SSL/ Serwery 9.30
jako proxy jako pojedyncze proxy do serwerów uwierzytelniania osobnych wydziałów (departamentów) dzielących wspólne połączenie na zewnątrz jako szereg regionalnych proxy do centralnego systemu uwierzytelniania SSL/ Serwery 9.31
wczesny, oparty na UDP, rozwinięty przez Cisco do + (nie kompatybilny wstecz!) pojedynczy plik konfiguracyjny opcje serwera, definicje użytkowników, parametry uwierzytelniania i autoryzacji dzielona wspólna tajemnica, nazwy plików logowania dodatkowe parametry w postaci par atrybut=wartość umożliwia definicje grup klientów definicje zawartości grupy wewnątrz innej grupy wywoływanie programów podanych przez klienta to pozwala na rozszerzenie mechanizmów uwierzytelniania o dodatkowe mechanizmy SSL/ Serwery 9.32
uwierzytelnianie start klient rozpoczyna uwierzytelnianie podając typ uwierzytelnienia który ma być przeprowadzony, także identyfikator i hasło klienta, typ protokołu uwierzytelnienia (PPP, CHAP) reply odpowiedź serwera i możliwe dodatkowe pytania continue ewentualne kolejne parametry klienta autoryzacja szereg request oraz response z parami atrybut-wartość dla ustalenia prawa do ustalonych adresów, komend, usług, protokołów ustalenia priorytetu klienta filtrów pakietów wchodzących i wychodzących przypisania konkretnych adresów sieciowych SSL/ Serwery accounting start, stop, more, watchdog dla ewidencjonowania watchdog waliduje połączenia TCP w trakcie długich okresów gdy żadne dane nie są przesyłane 9.33
podstawowym ograniczeniem + jest rzadkość jego użycia... jest niewiele implementacji jeszcze mniej implementacji klientów NAS właściwie ograniczony do Cisco + nie może działać jako proxy, bo nie ma mechanizmu przekazywania zapytań SSL/ Serwery 9.34
zbudowany z dwóch podstawowych elementów Base Protocol definiuje formaty pakietów, zasady przesyłania, kontrolę błędów, kontrolę bezpieczeństwa używane przez wszystkie rozszerzenia Extensions moduły przeznaczone dla obsługi innych metod uwierzytelniania, autoryzacji i ewidencjonowania (accounting) specjalne moduły dla specyficznych NAS, silnego bezpieczeństwa, etc. zbudowany przez rozwinięcie protokołu dla obejścia ograniczeń pozwala na łatwe przejście z -a do udostępnia mechanizm roamingu uwierzytelnianie pomiędzy dziedzinami pełne wsparcie protokołu EAP możliwe definicje par atrybut-wartość dla określonych producentów rozwinięta ochrona przed atakami odgrywania umożliwia wsteczną kompatybilność z SSL/ Serwery 9.35
uwierzytelnianie jest zależne od modułu, ale schemat jest stały klient (NAS) wysyła żądanie uwierzytelnienia wraz z identyfikatorem sesji rozwiązuje problem podwójnych identyfikatorów przy gęstych połączeniach adresem klienta i nazwą hosta identyfikatorem użytkownika, hasłem serwer sprawdza użytkownika i zwraca pakiet opisujący rezultat jeśli serwer NIE jest serwerem domowym dla użytkownika zadziała jako proxy przekaże żądanie uwierzytelnienia dalej SSL/ Serwery 9.36
obsługuje szereg architektur proxy poza schematami w modelu hierarchicznym przekazuje żądanie wprost do serwera domowego użytkownika połączenia proxy są obsługiwane niezależnie od połączeń mogą być obsłużone wydajniej mogą być obsłużone ze zwiększonym bezpieczeństwem autoryzacja może być połączona z uwierzytelnianiem lub być przeprowadzona osobno ewidencjonowanie jest ulepszone względem i śledzenie zdarzeń, raportowanie okresowe, śledzenie transferów w czasie rzeczywistym, etc. SSL/ Serwery silnym elementem jest bezpieczeństwo dzięki modułom moduł Strong Proxy szyfruje istotne dane wykorzystując S/MIME i wstawia je do zwykłych par atrybut-wartość 9.37