If you're seeing this message, it means we're having trouble loading external resources on our website.

Jeżeli jesteś za filtrem sieci web, prosimy, upewnij się, że domeny *.kastatic.org i *.kasandbox.org są odblokowane.

Główna zawartość

Bezpieczeństwo w internecie

Kurs: Bezpieczeństwo w internecie > Rozdział 1

Lekcja 11: Bezpieczne protokoły internetowe
Nastawienie na rozwój, studia, kariera i nie tylko
Bezpieczeństwo w internecie
Bezpieczeństwo danych w sieci
Bezpieczne protokoły internetowe
© 2023 Khan AcademyWarunki użytkowaniapolitykę prywatnościInformacja o plikach cookie

Cyfrowe certyfikaty

Google Classroom
Protokół TLS (ang. Transport Layer Security) opiera się na [kryptografii klucza publicznengo](/a/public key-encryption). W celu zaszyfrowania danych, nadawca używa klucza publicznego udostępnionego przez odbiorcę. Zanim to nastąpi jednakże, TLS wymaga wykonania dodatkowej akcji, która jest istotna dla jego bezpieczeństwa: nadawca musi zweryfikować tożsamość posiadacza klucza publicznego.
Certyfikat cyfrowy, znany również jako certyfikat klucza publicznego, stanowi dowód posiadania klucza.

Niezbędność certyfikatów

Co by się stało, gdyby protokół TLS nie zawierał etapu weryfikacji certyfikatu?
Atakujący opracowali metody przechwytywania wiadomości przesyłanych pomiędzy komputerami w sieci internetowej, np. za pomocą fałszywych punktów dostępu (ang. rogue access points).
Gdy użytkownik łączy się do takiego punktu dostępu, może stać się on ofiarą ataku zwanego man-in-the-middle (MITM). Mimo, że nazwa zawiera słowo "man" (ang. mężczyzna), atakujący mogą być dowolnej płci i wieku.
W pierwszym kroku, podczas procesu bezpiecznego łączenia z użyciem protokołu TLS, atakujący wysyła swój klucz publiczny zamiast klucza publicznego serwera.
Ilustracja przechwytywania pakietu TLS przez nieuczciwy punkt dostępu. Po lewej stronie pokazany jest serwer, a pop prawej stronie laptop oznaczony jako "Klient". W górnej części widnieje napis "Co klient myśli, że się stało". Tuż pod nim umieszczono odpowiadający schemat zawierający strzałkę z zielonym kluczem szyfrującym, która prowadzi od serwera do „legalnego punkt dostępu”. Kolejna strzałka, również z zielonym kluczem, prowadzi z legalnego punktu dostępu do klienta. Dolna część oznaczona jest jako "Co faktycznie się stało". Zawiera strzałkę z zielonym kluczem prowadzącym od serwera do atakującego z podpisem "rogue access point". Kolejna strzałka, tym razem z czerwonym kluczem, prowadzi od nieuczciwego punktu dostępu do klienta.
Następnie, klient szyfruje dane, jednakże zamiast klucza publicznego serwera używa otrzymanego klucza publicznego atakującego. Atakujący może więc odszyfrować wiadomość, zmodyfikować ją jakkolwiek chce i ponownie zaszyfrować ją kluczem publicznym serwera przed jej wysłaniem.
Ilustracja przechwytywania pakietu TLS przez nieuczciwy punkt dostępu. Po lewej stronie znajduje się laptop z otwartą stronę internetową, na której wypełniono pole hasła, a po prawej stronie serwer . Górna część ilustracji oznaczona jest jako "Co klient myśli, że się stało". Zawiera strzałkę z zielonym kluczem szyfrującym oraz podpisem "ID konta: 25", która sięga od laptopa do punktu dostępu oznaczonego jako "uprawniony punkt dostępu". Kolejna strzałka jest oznaczona w ten sam sposób i biegnie z uprawnionego punktu dostępu do serwera. Dolna część oznaczona jest jako "Co faktycznie się stało". Zawiera strzałkę z czerwonym kluczem i "ID konta: 25", która biegnie od laptopa do atakującego z podpisem "rogue access point". Druga strzałka z zielonym kluczem i "ID konta: 12" prowadzi od nieuczciwego punktu dostępu do serwera.
Aby zapobiec atakom MiTM, klient musi sprawdzić tożsamość klucza publicznego. Certyfikat cyfrowy stanowi dowód tożsamości klucza publicznego. Jeżeli jednak ktokolwiek może stworzyć taki certyfikat, dlaczego klient miałby mu zaufać? W TLS, klienci mogą zaufać certyfikatowi cyfrowemu jedynie w przypadku, gdy został on utworzony przez specialne instytucje: urzędy certyfikacji (ang. certificate authority).

Urzędy certifikacji

Serwer, który chce bezpiecznie komunikować się przy użyciu TLS, rejestruje się w urzędzie certyfikacji. Urząd ten weryfikuje własność danej domeny, podpisuje certyfikat używając jej nazwy i klucza publicznego i przekazuje podpisany certyfikat z powrotem do serwera.
Zmyślony certyfikat, który przypomina certyfikaty przyznawane osobom, które zdobywają nagrody. Na górze jest napisane "Certyfikat autentyczności". Pod nim jest napisane: "To potwierdza, że khanacademy.org jest dumnym właścicielem tego klucza publicznego:" a następnie ma długi szesnastkowy ciąg. Na dole, linia do podpisu jest oznaczona jako "Certificate Authority" i ma podpis "GoDaddy Certificate Authority." Kolejna linia oznaczona jest jako "Ważne daty" i ma numer "13.10.2018 - 18.112020".
Kiedy klient sprawdza certyfikat, widzi, że urząd ds. certyfikacji poświadcza autentyczność klucza publicznego. Ale nadal musi podjąć decyzję: czy ufam temu organowi certyfikacyjnemu?
Systemy zazwyczaj posiadają listę zaufanych certyfikatów. Na przykład iPhone z iOS 10 ufa tej liście urzędów certyfikacji.
Użytkownicy Apple muszą następnie zaufać Appleowi, aby stale monitorował tę listę, aby upewnić się, że każdy urząd certyfikacji prawidłowo weryfikuje domeny.
Możesz sobie wyobrazić łańcuch zaufania od użytkownika do serwera:
Ilustracja łańcucha zaufania do certyfikatów. Zaczyna się od ikony oznaczonej "użytkownik" po lewej stronie. Strzałka oznaczona jako "zaufany" przechodzi od ikony użytkownika do ikony smartfonu oznaczonej jako "klient". Kolejna strzałka oznaczona jako "zaufany" przechodzi z ikony klienta do ikony komputera oznaczonej jako "organ certyfikacyjny". Strzałka końcowa przechodzi z ikony organu certyfikacji do ikony komputera oznaczonego jako "serwer".
W każdym z tych punktów zaufanie może zostać naruszone. Jeśli użytkownik nie ufa klientowi, może nadpisać domyślną listę zaufanych urzędów certyfikacji klienta. Jeśli klient nie ufa już urzędowi certyfikacji, usunie go z listy. Jeśli urząd certyfikacji dostrzeże podejrzane zachowanie z serwera, może unieważnić swój certyfikat.

Pośrednie urzędy certyfikacji

W rzeczywistości istnieje wiele poziomów urzędów certyfikacji: główny (ang. root) urząd certyfikacji i pośrednie (ang. intermediate) urzędy certyfikacji.
Główny urząd certyfikacji (UC) nie przyznaje serwerom żadnych certyfikatów cyfrowych bezpośrednio. Przyznaje certyfikaty jedynie pośrednim UC, które działają w jego imieniu. Pośrednie UC mogą z kolei przyznawać certyfikaty cyfrowe innym pośrednim UC lub bezpośrednio serwerom.
Istnieje zatem dodatkowy łańcuch zaufania, zaczynający się od głównego UC a kończący na serwerze:
Ilustracja łańcucha zaufania urzędów certyfikujących. Zaczyna się od ikonki serwera oznaczonej jako "Główny UC" po lewej stronie. Od tej ikonki prowadzi strzałka oznaczona jako "ufa" do kolejnej ikonki oznaczonej jako "Pośredni UC". Kolejna strzałka oznaczona jako "ufa" prowadzi od tej ikonki do innej ikonki serwera oznaczonej jako "Pośredni UC". Ostatnia strzałka biegnie od tej ikonki do ikonki "Serwera".
Wielowarstwowy system urzędów certyfikujących zwiększa bezpieczeństwo systemu. Jeśli główny UC wykryje, że pośredni UC został zaatakowany, może unieważnić jego certyfikaty ale jednocześnie nadal ufać certyfikatom pochodzącym od innych pośrednich UC.
🔍 Możesz samodzielnie zaobserwować łańcuch zaufania, sprawdzając certyfikat bezpiecznej strony internetowej w przeglądarce. Jeśli klikniesz ikonkę kłódki obok adresu URL, przeglądarka powinna zaoferować sposób na sprawdzenie certyfikatów.
Zrzut ekranu certyfikatów wydanych dla strony Khan Academy. Pokazuje listę certyfikatów z "GlobalSign Root CA" u góry; następnie "GlobalSign CloudSSL CA", kończąc na "khan.map.fastly.net".
Łańcuch zaufania dla KhanAcademy.org zawiera tylko jeden pośredni UC.
🙋🏽🙋🏻‍♀️🙋🏿‍♂️Czy masz jakieś pytania na ten temat? Chętnie na nie odpowiemy — wystarczy, że zadasz pytanie w poniższym obszarze pytań!

Chcesz dołączyć do dyskusji?

Zaloguj się
Na razie brak głosów w dyskusji
Rozumiesz angielski? Kliknij tutaj, aby zobaczyć więcej dyskusji na angielskiej wersji strony Khan Academy.