Zabezpieczenie komunikacji internetowej certyfikatem SSL wydaje się dobrym sposobem na uchronienie się przed możliwością odczytania jej przez osoby trzecie. Czy jest tak na pewno? O czym dokładnie mówimy i o czym powinniśmy pamiętać, żeby taka ochrona była skuteczna? Na potrzeby tego artykułu przyjmijmy, że atak SSL to taki, który jest próbą złamania, bądź też obejścia zabezpieczeń opartych na transmisji szyfrowanego strumienia danych. Potrzeba ludzkości dotycząca kryptoanalizy, czyli znalezienia metody przełamania szyfrów lub ich ominięcia ma równie długą historię co samo szyfrowanie.
Co to jest SSL?
SSL (ang. Secure Socket Layer) to protokół opracowany w 1994 r., przez Netscape, służący do bezpiecznej transmisji zaszyfrowanego strumienia danych, działający „nad” protokołem warstwy transportowej (np. TCP), „pod” protokołem warstwy aplikacyjnej (np. HTTP). Jest to właściwie poprzednik protokołu TLS (ang. Transport Layer Security), którym został zastąpiony. Używanie samego SSL nie jest uważane za bezpieczne – jego ostatnia wersja, SSL 3.0, została skompromitowana w 2014 po ujawnieniu podatności na atak POODLE. Nazwa SSL jest jednak nadal powszechnie wykorzystywana, ale pamiętajmy, że standardem jest obecnie TLS.
Czym jest SSL i w jakim celu się go stosuje?
Protokół SSL/TLS ma za zadanie zapewnić integralność i poufność danych w komunikacji sieciowej, oparty jest na architekturze klient – serwer. Najczęściej kojarzony jest z protokołem HTTP (HTTPS), ale jest wykorzystywany także do zabezpieczania wielu innych protokołów, m. in. POP, IMAP, LDAP. Dzięki zastosowaniu protokołu szyfrującego wrażliwe dane przesyłane przez Internet są zrozumiałe tylko przez uprawnionego odbiorcę. Jest to o tyle istotne, że informacje wędrują między wieloma urządzeniami, zanim trafią do adresata.
Czym jest certyfikat SSL i do czego się go używa?
Certyfikat SSL to narzędzie służące do ustanawiania szyfrowanych połączeń, które cyfrowo wiąże klucz kryptograficzny z danymi organizacji. Na certyfikat składa się para kluczy: publiczny oraz prywatny – są to długie ciągi losowo wygenerowanych znaków. Klucz publiczny jest znany i ogólnodostępny, za jego pomocą odbywa się szyfrowanie. Natomiast klucz prywatny służy do odszyfrowywania wiadomości, można to zrobić tylko z jego pomocą, klucz ten nie może być nikomu ujawniony. W celu upewnienia się, że dany klucz publiczny jest prawdziwy dla danej witryny stworzony został system autoryzacji – powstały urzędy certyfikacji (CA – ang. Certificate Authority), które mają za zadanie weryfikować własność klucza publicznego.
Certyfikaty SSL powinny być stosowane wszędzie tam, gdzie następuje wymiana danych osobowych i wszelkich treści, które powinny pozostać poufne (bankowość online, sklepy internetowe, poczta, formularze logowania itp.).
Czym jest HTTPS, w jakim kontekście występuje w przypadku certyfikatów SSL?
HTTPS (ang. Hypertext Transfer Protocol Secure) szyfrowaną wersją protokołu http, działającą domyślnie na porcie 443. Jeżeli certyfikat SSL jest zainstalowany na serwerze webowym, połączenie nawiązywane przez klienta jest szyfrowane, używając wywołania „https://…”, a w przeglądarce pojawia się kłódka oznaczająca, że połączenie jest bezpiecznie.
Ataki na SSL
Podobnie jak w przypadku innych technologii, protokół SSL/TLS ma swoje wady. Zawsze znajdą się ludzie poszukujący słabości w zabezpieczeniach, próbujący je w jakiś sposób złamać lub obejść. Wynikiem tych działań jest ich nieustanny wyścig z twórcami mechanizmów ochronnych, którego efektem są coraz bardziej skomplikowane, wymagające coraz większego nakładu mocy obliczeniowych algorytmy szyfrujące. Można śmiało postawić tezę, ze wyścig ten nigdy się nie zakończy.
Co to są ataki SSL
Sposoby na złamanie zabezpieczeń są, co pokazały ostatnie lata, różnorodne. W lutym 2015 roku IETF (ang. Internet Engineering Task Force), czyli organizacja zajmująca się „porządkiem” w Internecie, opracowała informacyjny dokument RFC (ang. Request for Comments), podsumowując różne znane ataki na protokół SSL/TLS. W miarę pojawiania się nowych zagrożeń, zmienia się zbiór bezpiecznych algorytmów szyfrujących i wersji protokołu szyfrującego – wspomniany wcześniej przykład protokołu SSL w wersji 3.0
Typy ataków na SSL
POODLE (ang.Padding Oracle On Downgraded Legacy Encryption) to atak, który został opublikowany w październiku 2014 roku. Poodle wykorzystuje serwery korzystające jeszcze z SSL 3.0 (najczęściej w celu zgodności ze starszymi systemami). Atakujący musi się znaleźć między ofiarą, a serwerem (atak typu Man in the Middle) i zdegradować połączenie do SSL 3.0. Luka istnieje w trybie Cipher Block Chaining (CBC) – umożliwia użycie szyfru blokowego do szyfrowania wiadomości o właściwie nieograniczonej długości, ale długość danych wejściowych musi być wielokrotnością rozmiaru bloku. Jeżeli tak nie jest, to dodawane są dopełnienie, z ang. padding. Struktura danych wejściowych składa się z czterech połączonych ze sobą pól:
- tekstu jawnego
- klucza uwierzytelniania wiadomości (MAC) obliczonego w oparciu o tekst jawny, obejmującego niektóre dodatkowe informacje, takie jak numer sekwencyjny wiadomości
- tyle bajtów dopełnienia ile jest potrzebnych do wypełnienia bloku.
- pojedynczy bajt określający liczbę dodanych bajtów.
Na potrzeby naszego przykładu przyjmijmy, że klient SSL wysyła wiadomość do serwera używając AES-128 (wielkość bloku to 16 bajtów) do szyfrowania i HMAC-SHA1 (MAC wielkości 20 bajtów) jako uwierzytelnienie:
Przed zaszyfrowaniem, w systemie szesnastkowym wiadomość wyglądałaby tak:
SSL 3.0 nie określa co idzie do bajtów dopełnienia – mogą być jakiekolwiek. Dlatego w tej wersji protokołu niemożliwe jest ustalenie czy dopełnienie zostało naruszone. Jest to szczególnie istotne kiedy padding wypełnia cały blok. Dodamy teraz znak kropki na koniec tekstu, tak, żeby dodany został cały blok wypełnienia:Każda linia to 16 bajtowy blok danych odpowiadający wielkością blokowi AES. Treść wiadomości to bajty od 54 do 70, kolejne 20 bajtów po treści wiadomości to etykieta MAC (od ef do bd). Po MAC zostaje tylko jeden bajt, tak więc nie potrzebujemy tutaj dopełnienia i ostatni bajt bloku określa długość paddingu: 00.
Po zaszyfrowaniu wiadomość będzie wyglądała w ten sposób:
Zatrzymajmy się w tym miejscu i zobaczmy, co się wydarzy jeżeli zaczniemy zmieniać bity w zaszyfrowanym tekście. Zamieńmy ostatni bajt pierwszego bloku z 86 na 85 i odszyfrujmy cały tekst:
Pierwsza linia jest całkowicie uszkodzona, natomiast w drugim bloku widzimy, że ostatnia litera „Q” zamieniła się na „R”. Wynika to ze sposobu działania trybu CBC. W trakcie szyfrowania, każdy kolejny blok jest xorowany z poprzedzającym go zaszyfrowanym blokiem, dlatego zmiana jednego bitu w zaszyfrowanym bloku powoduje zmianę w kolejnym. Wyjątkiem jest pierwszy blok, który jest szyfrowany za pomocą operacji xorowania tekstu jawnego z wektorem inicjującym, określanym w trakcie handshake’u. Wykonajmy teraz kolejną operację. Skopiujmy drugi zaszyfrowany blok w miejsce bloku dopełnienia:
Po dekryptażu otrzymamy:
Ostatni bajt bloku to teraz fb. Jest tak dlatego, że poprzedzający blok kończy się bajtem 2c, a nie jak w oryginalnej wiadomości 86. Stąd tekst jawny bierze się z:
51 XOR 86 XOR 2c = fb.
Dopełnienie zostało wpisane w dowolny sposób, na co pozwala SSL 3.0 – wiadomość nadal będzie akceptowana. Oznacza to, że można zmodyfikować końcowy blok szyfru w dowolny sposób (znaczenie ma tylko ostatni bajt) i jest szansa, ze wiadomość zostanie zaakceptowana, a klucz MAC ciągle będzie ważny. Tak jak w powyższym przykładzie można skopiować drugi blok (ffdb 4540 6069 2f0a ea82 1dae 1d20 cd74) i wstawić w miejsce ostatniego.
Należy powtarzać tę operację do momentu zaakceptowania żądania przez serwer (mimo, że żądanie w tekście jawnym jest takie samo, zaszyfrowany tekst zostanie losowo wybrany przez losowy wektor inicjujący). Średnio 1 na 256 razy, ostatni bajt bloku dopełnienia będzie taki sam jak oryginał – w takim wypadku atakujący będzie mógł wykonać operację XOR, żeby odzyskać ostatni bajt drugiego bloku.W kolejnych krokach, atakujący może przesunąć wiadomość tekstową o jeden bajt (dodając fałszywy bajt na początku i usuwając ostatni, zachowując taką samą długość komunikatu), co w konsekwencji doprowadza do odczytania całej wiadomości.
Kolejne wersje protokołu TLS nie pozwalają na wykonanie podobnej operacji, ze względu na to, że każdy bajt dopełniania musi mieć taką samą wartość jak jego długość, czyli w przypadku dodania całego bloku, dopełnienie wyglądałoby tak:
SSL Stripping (z ang. usuwanie SSLa) to technika degradująca połączenie HTTPS do HTTP. W tym przypadku również jest to atak typu Man in the Middle, a jego powodzenie zależy od przechwycenia ruchu sieciowego ofiary. Załóżmy, że cały ruch przechodzi przez komputer atakującego, który służy jako serwer proxy, ale samo to spowoduje albo błąd certyfikatu albo przechwycony ruch będzie zaszyfrowany i nie będzie możliwości jego wykorzystania. W naszym przykładzie ofiara wpisuje w pasku przeglądarki adres banku: www.example-bank.com
W tle, przeglądarka ofiary, która jest połączona z maszyną atakującego, czeka na odpowiedź serwera. Atakujący przekazuje żądanie ofiary i czeka na odpowiedź serwera banku. Połączenie między atakującym, a bankiem jest bezpieczne. Serwer banku odpowiada stroną logowania: https://www.example-bank.com/LoginPage Atakujący modyfikuje odpowiedź banku z protokołu HTTPS na HTTP, co skutkuje innym adresem w pasku przeglądarki ofiary: http://www.example-bank.com/LoginPage. Od tego momentu żądania ofiary są jawnym tekstem i atakujący może odczytać jej poświadczenia. Przeglądarka nie wyświetla żadnych błędów certyfikatu i użytkownik nie ma pojęcia o tym, że stał się ofiarą.
Atak tego rodzaju jest dość prosty do wykrycia – każdy w miarę świadomy użytkownik powinien zauważyć, że jego połączenie do zaufanej strony nie jest szyfrowane. Niestety, wielu użytkowników nie zwraca nawet uwagi na wyskakujące okienka z ostrzeżeniami, nie zwróci więc tym bardziej uwagi na niewielką różnicę w pasku adresu przeglądarki.
FREAK Attack – w latach 90 XX wieku rząd USA ustanowił regulacje dotyczące eksportowania zaawanasowanych systemów kryptograficznych. Ustanawiały one limit dla siły kluczy RSA do maksimum 512 bitów dla każdej implementacji SSL przeznaczonej na eksport. Od 2000 roku reguły zostały zniesione, a przeglądarki mogły korzystać z bezpieczniejszego SSL.W 2015 roku ujawniono, że stare, eksportowe wersje szyfrowania nadal są używane. Serwery nadal je wspierające są narażone na ataki degradujące połączenie do słabych algorytmów szyfrowania – złamanie kluczy przy dzisiejszej mocy obliczeniowej komputerów zajęłoby jedynie kilka godzin. Mimo tego, że od momentu zniesienia ograniczeń minęło kilkanaście lat, to po odkryciu podatności około 10% z miliona najczęściej odwiedzanych witryn WWW nadal wspierało używanie szyfrów eksportowych.
Wykrywanie ataków SSL
Ze względu na różnorodność ataków związanych z użyciem protokołu szyfrującego, należy mieć na uwadze, że ich wykrywanie powinno się odbywać w obrębie całej infrastruktury dla chronionej usługi. Od ataków DDoS opartych na szyfrowanym ruchu, poprzez ataki na sesje SSL po ataki aplikacyjne – pełna ochrona wymaga wielopoziomowego monitorowania.
Ataki SSL mogą być wykrywane poprzez inspekcję połączeń sieciowych, za pomocą systemu opartego na analizie ruchu sieciowego i detekcji anomalii – takim jak Radware DefensePro. Mimo tego, że przesyłane dane są zaszyfrowane, to nadal wartościowe informacje znajdziemy w nagłówkach IP (adresy IP, porty). W ten sposób możemy wykryć ataki opierające się na renegocjacji sesji SSL, próby degradacji do skompromitowanych wersji protokołu i algorytmów szyfrujących, użycie kradzionych certyfikatów czy też szyfrowane ataki DDoS oparte na analizie ruchu.
W celu zabezpieczenia się przed atakami aplikacyjnymi używa się tych samych metod, które wykorzystują atakujący – chodzi tutaj o zastosowanie architektury znanej z ataków Man in the Middle. W tym wypadku rolę pośrednika pełni system ochrony, który rozkodowuje każdą sesję, przetwarza żądanie w poszukiwaniu zagrożenia w czasie rzeczywistym. W zależności od architektury rozwiązania, sesje SSL są w tym miejscu terminowane, bądź też ruch jest ponownie szyfrowany i wysyłany do adresata.
Zapobieganie atakom SSL
Dzięki zastosowaniu protokołu TLS możemy skutecznie ukryć przesyłane przez Internet dane przed osobami nie będącymi ich adresatami. Ze względu na to, że to informacje poufne, często służące do wykonywania operacji bankowych i płatności, są łakomym kąskiem dla potencjalnego cyberprzestępcy. Z tego powodu istotnym aspektem jest świadomość użytkownika i minimalizacja zagrożenia.
Najprostszym sposobem na zmniejszenie niebezpieczeństwa związanego z atakiem SSL jest „bycie na czasie” w kwestii wykrywanych podatności protokołu szyfrującego i aktualizacja oprogramowania. W tym celu powinno się regularnie korzystać z aplikacji audytujących poziom zabezpieczeń, takich jak np. ssllabs, która analizuje i ocenia konfigurację serwera oraz stosować się do najnowszych rekomendacji dotyczących ustawień polityki SSL na serwerze. Jak pokazały badania przeprowadzone po wykryciu wcześniej opisywanego ataku FREAK, nie dla wszystkich jest to oczywiste.
Warto również korzystać z mechanizmu HSTS, który chroni przed atakami związanymi z degradacją protokołu i przechwytywaniem sesji. Polega on na tym, że pozwala na połączenie do serwera jedynie przy użyciu protokołu HTTPS. Polityka HSTS przekazywana jest przez serwer w nagłówku „Strict-Transport-Security”, w której określony jest m.in. czas, w którym użytkownik może być połączony z serwerem. Skutkiem jej zastosowania jest to, że:
- Wszystkie niezabezpieczone połączenia do aplikacji webowej zamieniane są na szyfrowane.
- Jeżeli nie może zostać zapewnione bezpieczeństwo połączenia (np. przez nieważny certyfikat), to użytkownik nie ma możliwości obejścia polityki bezpieczeństwa i wymuszenia połączenia.
Z punktu widzenia użytkownika usługi, zalecane jest korzystanie z aktualnego oprogramowania, w sieci można bez problemu znaleźć witryny oferujące test zabezpieczeń przeglądarki internetowej. Należy zwracać uwagę na to czy połączenie jest szyfrowane dla usług, które powinny być zabezpieczone (właściwie wszystkie strony wymagające logowania i przetwarzające nasze dane osobowe) oraz nie korzystać z nich używając niezabezpieczonych sieci publicznych.Naturalnie poza zastosowaniem opisanych środków ostrożności warto skorzystać z profesjonalnego systemu ochrony, który kompleksowo monitoruje i oczyszcza szyfrowany ruch i może uchronić potencjalną ofiarę przed poważnymi stratami finansowymi i wizerunkowymi.
Ataki SSL a jakość certyfikatu SSL
Na rynku dostępne są różne klasy certyfikatów SSL, oferujące różne poziomy weryfikacji dostawcy usługi. Certyfikat z powodzeniem zabezpieczający np. forum internetowe, może być niewystarczający dla sklepu internetowego. Technicznie wszystkie rodzaje certyfikatów wykonują to samo zadanie, czyli zapewniają bezpieczeństwo transmisji poprzez jej zaszyfrowanie. Poprzez weryfikację tożsamości, certyfikaty wyższej klasy mają stanowić dodatkowe zabezpieczenie przed podmiotami prowadzącymi nielegalną działalność, chronią przed phishingiem.
Rodzaje certyfikatów SSL
Ze względu na przeznaczenie i metody weryfikacji, certyfikaty możemy podzielić na trzy grupy:
- Certyfikaty klasy DV (Domain Validation)
Są to podstawowe certyfikaty SSL, które mają minimalne wymagania formalne. Weryfikacja domeny polega na:
– porównaniu danych zawartych w pliku CSR (ang. Certificate Signing Request) z danymi w bazie WHOIS przy domenie, dla której ma być wystawiony certyfikat;
– sprawdzenie czy pod domeną działa strona WWW;
– potwierdzenie zamówienia poprzez konto pocztowe „admin” w certyfikowanej domenie.
Tego rodzaju certyfikaty charakteryzują się najniższymi cenami i najszybszą metodą realizacji zamówienia.
- Certyfikaty klasy OV (Organization Validation)
Podczas wystawiania certyfikatu tego typu poza weryfikacją domeny, dodatkowo sprawdzana jest organizacja wnioskująca. Podczas zamówienia wymagane jest dostarczenie dokumentów rejestrowych typu KRS, umowa spółki itp. Wiąże się to z wydłużonym czasem realizacji zamówienia. Certyfikaty OV można rozpoznać wyświetlając szczegóły certyfikaty, w polu Organizacja powinna znajdować się nazwa Firmy – tego elementu nie ma w certyfikatach klasy DV.
- Certyfikaty klasy EV (Extended Validation)
Certyfikat tej klasy oznacza najsilniejszą weryfikację witryny i tożsamości wnioskującego. Zamawiając taki certyfikat należy podać szereg precyzyjnych danych oraz przekazać komplet dokumentów organizacji w języku angielskim. Dodatkowo organizacja wystawiająca certyfikat, weryfikuje telefonicznie przekazane informacje. Certyfikaty klasy EV są najdroższymi i mają najbardziej sformalizowany proces wystawiania. Certyfikaty EV łatwo rozpoznać – w pasku adresu przeglądarki wyświetla zielony pasek z nazwą organizacji.
Poza przedstawionym podziałem, możemy także skategoryzować certyfikaty ze względu na ilość chronionych domen i subdomen. Każdy rodzaj wymienionych powyżej certyfikatów zabezpiecza jedną domenę. Jednak po to, żeby nie musieć kupować certyfikatu dla każdego adresu z osobna, możemy zamówić certyfikat w wersji Wildcard lub Multi Domain:
- Wildcard pozwala chronić także subdomeny, założone w domenie głównej. Nie pozwala na szyfrowanie subdomen trzeciego i kolejnych rzędów.
- Multi Domain pozwala chronić wiele domen internetowych należących do tego samego właściciela.
Podsumowanie
Pomimo szyfrowania komunikacji protokołem SSL/TLS nie możemy mieć 100% pewności, że przekazywana w ten sposób treść zawsze pozostanie skutecznie zabezpieczona. Odczytanie jej przez osoby nieuprawnione może się stać na wiele różnych sposobów, których spektrum starałem się przybliżyć w tym artykule. Warto pamiętać o tych zagrożeniach i prowadzić świadomą politykę SSL, której najważniejszą cechą powinna być aktualność.
W Data Space zajmujemy się kompleksową ochroną ruchu klienta, włączając w to analizę ruchu szyfrowanego i zapobieganie atakom SSL. Posiadamy również właściwą architekturę sieciową i serwerową, która pomaga minimalizować ryzyko związane z bezpieczeństwem naszych klientów.
