Wprowadzenie
Czy namawianie do akceptowania certyfikatu SSL, który wygasł i nie jest prawidłowy, jest OK?
A może jest to sprzeczne z dobrymi praktykami?
Jakie inne komunikaty błędów możemy napotkać podczas przeglądania Internetu przy pomocy protokołu HTTPS?
O czym one świadczą i jakie są ich powody?
A także kiedy mogą informować one o potencjalnym ataku, a kiedy tylko pokazują ignorancję właściciela witryny?
Ja jestem Kacper Szurek, a to kolejny odcinek podcastu Szurkogadanie, w którym tłumaczę zawiłe kwestie powiązane z bezpieczeństwem komputerowym w prosty i zrozumiały sposób.
Jeżeli materiały tego rodzaju Ci się podobają - zapraszam do dołączenia do grupy od 0 do pentestera na Facebooku.
Wideo to podzielone jest na kilka części.
Ich sygnatury czasowe odnajdziesz w opisie filmu.
Po co szyfrujemy połączenie
Dzisiaj o temacie, który raz na jakiś czas pojawia się w Internecie, gdy któraś z większych firm zapomni o odnowieniu swojego certyfikatu SSL.
W obecnych czasach praktycznie każda większa strona używa certyfikatów, aby obok nazwy domeny w przeglądarce pojawiła się zielona kłódeczka.
Ale po co tak naprawdę szyfrujemy połączenie?
Chodzi o to, aby wszystko, co podamy na stronie nie zostało przechwycone przez kogoś z zewnątrz.
Czyli - jeżeli wpisuję coś w formularzu na stronie to zobaczyć to może jedynie serwer, do którego te informacje kieruję.
Możesz się zastanawiać: ale kto może podsłuchać moje dane?
Odpowiedź na to pytanie nie jest taka prosta, ponieważ po drodze od naszego komputera do serwera witryny, którą odwiedzamy, jest wielu pośredników.
Począwszy od naszego usługodawcy internetowego, który dostarcza nam połączenie ze światem.
On to nie posiada Internetu na własność, ale musi się komunikować z innymi podmiotami aby nasz ruch doszedł tam, gdzie powinien.
Takich podmiotów pośredniczących jest wiele i każdy z nich może podsłuchiwać to co przesyłamy, o ile oczywiście ruch ten nie jest szyfrowany.
Przesłanki dlaczego ludzie nie chcą aby ktoś przeglądał ich ruch są różne.
Począwszy od bezpieczeństwa - wszak nie chcemy aby ktoś poznał nasze hasło do banku.
Niektórzy nie chcą także aby instytucje rządowe śledziły ich ruchy i poczynania w Internecie.
A więc - używamy szyfrowania.
Klucz prywatny
Ale to wszystko nie jest takie proste.
Każda strona musi bowiem posiadać swój unikalny klucz prywatny.
Można tutaj zastosować analogię do klucza w zamku do drzwi naszego mieszkania.
Nie chcemy mieć takiego samego zamka jak nasi sąsiedzi, bowiem jest to nasz dom i tylko my powinniśmy mieć do niego dostęp.
Podobnie tutaj - każdy serwer powinien mieć swój klucz, aby tylko on mógł odszyfrować ruch, który jest do niego kierowany.
Podczas ustawiania serwera generuje się zatem unikalny klucz prywatny.
Czy to prawidłowy klucz?
Ale tutaj natrafiamy na kolejny problem.
Każdy serwer może wygenerować swój własny klucz - tak jak każde z drzwi mają swój własny zamek.
Ale skąd internauta ma wiedzieć, że klucz ten należy do tego serwera, a nie innego, który się pod niego podszywa?
W przypadku mieszkań - sprawa jest prosta.
Znamy swoję ulicę, a także numer bloku i mieszkania - wiemy więc, że nasz klucz powinien pasować.
W przypadku serwerów taką rolę odgrywają domeny - czyli nazwy, które wpisujemy w pasku adresu przeglądarki aby przenieść się do konkretnej witryny.
Taką nazwą domenową jest google.pl czy też szurek.pl.
A więc klucz wygenerowany przez serwer powinien być w jakiś sposób powiązany z domeną, której używa jakaś witryna.
Główne urzędy certyfikacji
No ale przecież każdy może powiedzieć, że ten klucz powiązany jest z tą domeną.
Trzeba to rozwiązać jakoś inaczej, używając jakiejś instytucji, której wszyscy ufamy.
Te firmy nazywamy głównymi urzędami certyfikacji.
Ich dane identyfikacyjne są zapisane w każdym systemie operacyjnym oraz przeglądarce.
Wszyscy umówiliśmy się, że im ufamy i że firmy te przestrzegają wszystkich procedur.
To tak jak z nazwami ulic.
Ktoś kiedyś nadał danej ulicy pewną nazwę i wszyscy zakładamy to jako pewnik - jako fakt.
Zadaniem tych firm jest sprawdzenie, czy dana osoba lub instytucja posiada uprawnienia do zarządzania daną domeną.
Uprawnienia do zarządzania domeną
Jak można to zweryfikować?
Jest przynajmniej kilka różnych metod.
Pierwsza z nich polega na umieszczeniu specjalnego pliku o specjalnej nazwie i wartości w obrębie naszej witryny.
Wartości te są generowane losowo i przyporządkowane do konkretnej domeny.
Jeżeli więc urząd chce sprawdzić, że rzeczywiście posiadamy prawa do danej domeny - weryfikuje ona wartość tego pliku.
Gdy są takie same - oznacza to, że posiadamy kontrolę nad serwerem wskazującym na dana nazwę.
Inną opcją jest użycie poczty internetowej.
Używa się tutaj pewnych specyficznych adresów email w stylu postmaster@example.com.
Ponownie, jeżeli ktoś będzie w stanie odczytać zawartość wiadomości wysłanej pod taki adres - oznacza to, że posiada dostęp do danej domeny.
W taki oto sposób urzędy certyfikacji ustalają czy dana osoba lub firma posiadają dostęp do danej domeny.
Taka weryfikacja nazywa się weryfikacją typu DV - czyli domain validation.
Sprawdza się tutaj bowiem jedynie, czy ktoś posiada prawa do danej domeny.
Certyfikat typu OV
Ale to nie jedyny typ certyfikatów, jakie możemy otrzymać.
Inny to OV - organization validation.
Tutaj oprócz sprawdzenia prawa do domeny sprawdza się również sam podmiot, który o taki certyfikat się stara.
Zatem tutaj do urzędu przesyła się również komplet dokumentów poświadczający iż reprezentujemy daną organizację.
Dzięki temu w certyfikacie oprócz nazwy domeny, może się także znaleźć nazwa firmy oraz jej adres.
Po co tego rodzaju certyfikat?
Załóżmy, że w Internecie pojawia się nowa kampania jakiejś marki modowej.
W tym celu stworzono nową stronę internetową wraz z nową domeną, której nazwa jest szeroko reklamowana.
Serwis promocyjny umożliwia uzyskanie korzystnych rabatów.
Wymaga jednak podania pewnych wrażliwych danych.
Jako iż jesteśmy osobami, dla których prywatność jest istotna - nie podajemy tego rodzaju danych na pierwszych lepszych stronach.
Nie znamy bowiem tej nowej domeny i nie wiemy do kogo ona należy.
Ale możemy sprawdzić dane zawarte w certyfikacie.
Jeżeli jest to certyfikat typu OV wydany przez zaufany urząd certyfikacji, będzie widniała tam nazwa firmy.
Dzięki temu wiemy, że zewnętrzny podmiot, któremu ufamy, zweryfikował dane firmy, która posługuje się daną domeną.
Podsumowując: urząd certyfikacji po potwierdzeniu naszych praw do domeny potwierdza, że klucz prywatny wygenerowany przez nasz serwer jest powiązany z tą domeną.
No ale jak to w działce bezpieczeństwa bywa - nie wszystko jest takie proste.
Ważność certyfikatu
Takie potwierdzenie bowiem jest ważne jedynie przez pewien określony czas.
Tak samo jak dowód osobisty - posiada datę ważności.
Dlaczego? W przypadku dowodu chodzi o to aby raz na jakiś czas zmienić zdjęcie profilowe.
10 lat to sporo czasu i nasza twarz potrafi mocno się w tym czasie zmienić.
To samo w przypadku domeny.
Może się bowiem okazać, że została ona sprzedana innemu podmiotowi bądź też wygasła.
Dlatego też certyfikaty mają określoną datę ważności.
W przeszłości, gdy szyfrowanie nie było takie popularne, było to nawet 3 lata.
W dzisiejszych czasach jednakże, zauważa się tendencję, aby certyfikaty miały zdecydowanie krótszą datę ważności, liczoną bardziej w miesiącach niż latach.
A to powoduje pewnego rodzaju problem dla właścicieli witryn internetowych.
Automatyczne generowanie certyfikatów
Teoretycznie, krótsze daty powodują większą ilość pracy.
Każdy nowo wygenerowany certyfikat bowiem wymaga potwierdzenia go przez urząd certyfikacji a potem zainstalowania na odpowiednim serwerze.
Wydaje się to być czasochłonne i rzeczywiście takie jest.
Ale - na szczęście istnieją narzędzia, które pozwalają cały ten proces zautomatyzować.
Jeżeli są odpowiednio skonfigurowane, automat odpowiednio wcześniej rozpocznie całą procedurę, automatycznie potwierdzi prawo do posługiwania się daną domeną a także podmieni odpowiedni certyfikat.
No ale życie nie jest takie kolorowe.
Nie w każdym bowiem przypadku proces ten da się całkowicie zautomatyzować.
Zwłaszcza, jeżeli mówimy o typie OV gdzie należy również sprawdzić dokumenty podmiotu, który ubiega się o dany certyfikat.
Robot nie jest bowiem w stanie przesłać tych dokumentów automatycznie.
Co więcej - po drugiej stronie - czyli w urzędzie certyfikacji - dane te są zazwyczaj weryfikowane ręcznie.
To sprawia, że niektóre certyfikaty muszą być odnawiane ręcznie.
A to rodzi pewne problemy, zwłaszcza jeżeli takich domen jest kilkanaście.
A posiadanie kilkunastu domeny w obrębie jednej firmy nie jest takie rzadkie jak mogło by się wydawać.
Jeżeli zatem nie istnieją procedury, które pilnują tego procesu - może dojść do sytuacji, w której organizacja zapomni (lub nie zdąży) odnowić certyfikatu na czas.
To połączenie nie jest prywatne
I tutaj pojawia się problem.
Przeglądarki bowiem od razu wychwytują taką sytuację i wyświetlają użytkownikowi odpowiedni komunikat.
Jest on różny ale można zauważyć pewną tendencję.
Na przykładzie Google Chrome, otrzymujemy złowrogo brzmiące okienko z nazwą To połączenie nie jest prywatne opatrzone dodatkowo czerwonym trójkątem ze znakiem wykrzyknika.
Nic więc dziwnego, że zwyczajny użytkownik komputera nie za bardzo wie co w takim przypadku zrobić.
Zwłaszcza, że proponuje się mu jedynie dwie opcje do wyboru.
Pierwsza - oznaczona jako proponowane rozwiązanie to "Wróć do bezpieczeństwa".
Po kliknięciu w ten przycisk, internauta jest przekierowywany do poprzednio oglądanej witryny.
Zaawansowane opcje
Druga opcja to "zaawansowane".
Tam to znajdują się dodatkowe informacje na temat danego błędu oraz dodatkowy przycisk, który umożliwia wejście na daną witrynę, pomimo ostrzeżenia.
I tutaj dochodzimy do sedna całego problemu.
W przypadku dużych firm (zwłaszcza tych, które posiadają sklepy internetowe) błędny certyfikat to nie tylko plama na wizerunku.
To również realna strata ponieważ mało osób będzie w stanie otworzyć stronę z takim błędem.
Stąd też zdarzają się sytuacje, gdzie firmy takie podczas oczekiwania na nowy certyfikat przy użyciu innych kanałów komunikacyjnych oraz mediów społecznościowych, informują swoich użytkowników, o możliwym obejściu tego problemu.
Wtedy poleca się im, aby zignorować ostrzeżenie i kontynuować wyświetlanie strony.
Z jednej strony nie dziwię się, że sytuacje takie mają miejsce.
Teoretycznie, stronę taką w większości przypadków bowiem można spokojnie odwiedzać bez narażania siebie i swoich danych na niebezpieczeństwo.
Tylko, że trzeba rozumieć treść błędu a także dlaczego się on pojawił, a także rozróżniać różne komunikaty od siebie.
A to nie jest takie oczywiste.
badssl.com
Wytłumaczenie tego standardowemu użytkownikowi nie jest proste.
Zwłaszcza, że potrzebny jest tutaj szerszy kontekst, aby zrozumieć całe zagadnienie.
Mamy bowiem do czynienia z bardzo podobnym komunikatem w przynajmniej kilku, odmiennych od siebie sytuacjach.
Bardzo fajnie prezentuje to strona badssl.com, na której możemy zobaczyć przykłady różnych problemów z certyfikatami.
W przypadku gdy oglądasz ten materiał na Youtube - w tle zobaczysz teraz plansze wyświetlane w każdym z przypadków, który omówię.
Dla osób jedynie słuchających tego podcastu, postaram się jak najdokładniej wytłumaczyć różnice.
Certyfikat expired
A więc pierwszy przypadek najczęściej występujący do certyfikat expired - czyli wygaśnięty.
Klikając w przycisk Zaawansowane możemy doczytać, że ten serwer nie mógł udowodnić, że należy do expired.badssl.com.
Jego certyfikat bezpieczeństwa wygasł 1500 dni temu.
Może to być spowodowane błędną konfiguracją lub przechwyceniem połączenia.
Zegar komputera jest obecnie ustawiony i tutaj obecna data.
Dopiero w szczegółach otrzymujemy interesującą nas informację.
Możemy tam bowiem przeczytać, że certyfikat wygasł określony czas temu.
Przeglądarka pokazuje również bieżącą datę.
Dlaczego to robi? Może się bowiem okazać, że z jakiegoś powodu nasz czas systemowy jest błędnie ustawiony.
W takim przypadku ten błąd również może się pokazać.
Wystarczy wtedy zmienić datę i odświeżyć stronę.
Tutaj rozpatrujemy jednak inny przypadek kiedy to certyfikat rzeczywiście wygasł a nasza data jest prawidłowa.
Zazwyczaj, oznacza to zatem, że ktoś zapomniał go odnowić.
W takim przypadku, moglibyśmy się pokusić o zaakceptowanie wyjątku bezpieczeństwa i wejście na daną stronę, jeżeli jest to absolutnie konieczne i każda zwłoka nie jest przez nas akceptowana.
Zwłaszcza, jeżeli certyfikat wygasł jedynie parę dni temu.
Dlaczego? Ponieważ nic nie wskazuje na to, że klucz prywatny wyciekł albo został skradziony.
Jest on dalej bezpieczny i znany jedynie serwerowi z którym chcemy się połączyć.
Czyli przesyłane przez nas dane są dalej bezpieczene.
Co więcej certyfikat ten był w przeszłości prawidłowy czyli posługiwał się nim podmiot, który posiada prawa do tej domeny.
Nie ma możliwości, aby ktoś podsłuchiwał nasze połączenie.
Tutaj kluczowym jest czas kiedy certyfikat wygasł.
W przypadku kilku dni świadczy to zapewne jedynie o nieuwadze administratora.
Ale, jeżeli certyfikat wygasł już znaczny czas temu - zalecał bym ostrożność.
Dlaczego? Ponieważ może się okazać, że certyfikat ten został skradziony, albo w jakiś inny sposób wyciekł i jest teraz używany przez przestępców do przeprowadzania ataków.
Błędna praktyka
Tylko, że namawianie użytkowników do akceptowania wyjątków bezpieczeństwa zazwyczaj przynosi więcej szkody niż pożytku.
W przypadku bezpieczeństwa edukacja jest bardzo ważna.
Niestety, zajmuje ona sporo czasu.
Bezpieczeństwo jest trudne i zwykłemu użytkownikowi kojarzy się z czymś, co mu przeszkadza.
Po co mam przepisywać dodatkowe hasła z mobilnych tokenów gdy wchodzę na stronę banku?
Dlaczego nie wystarczy mi jedynie hasło?
Gdy będziemy zachęcać użytkowników do akceptowania wyjątków, może to się zemścić w przyszłości.
Widząc bowiem podobny komunikat – ktoś może ponownie zaakceptować dany wyjątek.
Tylko, że kolejnym razem może nie być to informacja o wygaśnięciu daty ale o próbie podszycia się pod daną witrynę.
Podsumowując: w przypadku tego rodzaju komunikatów zazwyczaj świadczy to o nieuwadze administratora strony, zwłaszcza jeżeli certyfikat wygasł stosunkowo niedawno.
Ale aby potwierdzić ten fakt, musimy się zapoznać z wiadomością, którą przedstawia nam przeglądarka.
Najlepiej spróbować wrócić na tą stronę za jakiś czas wierząc, że właściciele witryny naprawią problem.
Wrong host
Kolejny rodzaj to wrong host - czyli zła nazwa.
Tym razem widzimy informację, iż serwer nie mógł udowodnić, że należy do wrong.host.badssl.com.
Jego certyfikat pochodzi z badssl.com.
Co to oznacza?
Próbowaliśmy wejść na stronę wrong.host.badssl.com,
Ale serwer zwrócił nam certyfikat należący do innej domeny.
Ten komunikat zazwyczaj pojawia się w sytuacji, gdy serwer jest błędnie skonfigurowany.
Dzisiejsze komputery bowiem potrafią obsługiwać wiele stron jednocześnie.
Czasem zdarza się sytuacja, gdy administrator pomyli pliki i zwraca nie ten certyfikat co powinien.
Załóżmy że wchodzisz na stronę security.szurek.pl.
Ale przeglądarka zwraca Ci certyfikat dla szurek.pl.
Wychodzi więc na to, że właściciel popełnił błąd podczas konfiguracji.
Będąc bowiem właścicielem domeny szurek.pl mogę wygenerować certyfikat dla dowolnej subdomeny, w tym również security.szurek.pl.
Tylko, że ten sam komunikat może się pojawić także w innych sytuacjach.
Załóżmy, że wchodząc na google.pl, otrzymujesz certyfikat szurek.pl.
Może to świadczyć chociażby o tym, że ktoś nieudolnie próbuje podejrzeć Twój ruch, wykorzystując certyfikat prawidłowy dla innej domeny.
Jeżeli zaakceptujesz taki wyjątek, nie będziesz w stanie stwierdzić – czy ktoś po drodze nie analizuje Twoich żądań.
Self-signed
Dalej mamy do czynienia z certyfikatem self-signed, czyli takim, który nie został potwierdzony przez zaufany urząd certyfikacji.
I tutaj zalecał bym wzmożoną ostrożność.
Informacja, która się pojawia to: certyfikat bezpieczeństwa nie jest zaufany w systemie operacyjnym tego komputera.
Czyli żadna zewnętrzna organizacja, której ufamy, nie potwierdziła, że osoba (bądź firma) posługująca się danym certyfikatem ma prawa do danej domeny.
To bardzo niebezpieczna sytuacja.
Może bowiem oznaczać ataki man in the middle, kiedy to ktoś próbuje podsłuchać nasze połączenia.
Wtedy to generuje się taki certyfikat licząc, że niczego nieświadomy użytkownik go zaakceptuje.
A jak wspominałem na początku tego materiału - każdy może wygenerować klucz dla dowolnej domeny.
Aby mieć pewność co do jego pochodzenia, musi on być zaakceptowany przez zewnętrzny podmiot.
W takich sytuacjach odradzał bym korzystanie z danej strony.
Untrusted root
Kolejny rodzaj to untrusted root - czyli wykorzystanie niezaufanego urzędu certyfikacji.
Co znaczy niezaufany?
To znaczy taki, którego dane nie są zapisane w przeglądarce lub w systemie operacyjnym.
Taki urząd może stworzyć każdy.
Wystarczy wygenerować odpowiedni certyfikat i już.
Z punktu widzenia komunikatu, jest on identyczny z tym, który wyświetla się w przypadku certyfikatów self-signed.
Różnica pojawia się jednak, gdy wchodzimy w szczegółowe dane certyfikatu.
W przypadku Google Chrome możemy to zrobić klikając na ikonę kłódki lub czerwonego trójkąta z napisem "ostrzeżenie" w pasku domeny.
Następnie wybieramy zakładkę „certyfikat”.
Tutaj to widzimy więcej szczegółów.
Między innymi informacje dla jakiej domeny jest on wystawiony a także przez kogo oraz w jakich datach był on ważny.
Nas jednak interesuje zakładka "Ścieżka certyfikacji".
Tam to widzimy który urząd podpisał się pod daną domeną.
W przypadku certyfikatu z wykorzystaniem niezaufanego urzędu certyfikacji widzimy dwa wpisy.
Pierwszy - urząd certyfikacji wraz z czerwonym znakiem X.
Świadczy to o tym iż ten certyfikat nie jest przez nas zaufany.
W przypadku poprzedniego rodzaju widnieje tam tylko jeden wpis - ponieważ tam, nie korzystaliśmy z żadnego urzędu certyfikacji.
Tutaj ponownie - zalecał bym niewchodzenie na takową witrynę.
Revoked
Ostatni typ jaki chciałbym dzisiaj przedstawić to "revoked" czyli certyfikat cofnięty - unieważniony.
Każdy właściciel certyfikatu bowiem, może poinformować urząd iż jego klucz prywatny został skradziony i certyfikat powinien być traktowany jako nieprawidłowy.
To analogiczna sytuacja, gdy ktoś ukradnie nam klucze do mieszkania.
Wtedy to zazwyczaj zmieniamy zamki w drzwiach, aby nikt nie włamał się do naszego domu.
Podobnie tutaj - jeżeli ktoś skradł nasz certyfikat to może go używać do podszywania się pod naszą stronę.
Taki certyfikat jest bowiem prawidłowy aż do utraty ważności.
Stąd tendencja, aby certyfikaty miały jak najkrótszy czas ważności.
Dopiero jego unieważnienie chroni naszych użytkowników.
Podsumowanie
I to już wszystko w tym odcinku.
Jak widzisz jeden temat - tak wiele różnych możliwości.
Wytłumaczenie tego wszystkiego zajęło mi kilkanaście minut.
Stąd też proponowanie użytkownikom aby akceptowali wygaśnięte certyfikaty nie jest najlepszym pomysłem.
Standardowy Jan Kowalski bowiem nie zdaje sobie sprawy z ryzyka, jakie niesie takie postępowanie.
Jeżeli nauczymy użytkowników złych praktyk – czyli akceptowania takich ostrzeżeń, może się okazać iż w przyszłości, nauczeni doświadczeniem – zaakceptują podobnie wyglądający komunikat – tym razem otwierając drogę potencjalnym przestępcom.
Jeżeli ten materiał Ci się spodobał rozważ rozesłanie go do swoich znajomych.