Poziom: ocena 3.0 - podstawy infrastruktury PKI, protokołu TLS i uwierzytelniania

Zestaw 10 praktycznych zadań laboratoryjnych do wykonania w trakcie zajęć (90–100 minut).
Kierunek: Informatyka, semestr 7, przedmiot: Kryptologia.
Podstawa materiałowa: wykład część 5 (bezpieczna wymiana informacji: PKI, TLS i uwierzytelnianie).

1. 01.Generowanie prywatnego urzędu certyfikacji (Root CA) i inspekcja certyfikatu samopodpisanego X.509 w OpenSSL
2. 02.Tworzenie wniosku CSR i wystawianie certyfikatu serwera z rozszerzeniami SAN oraz Key Usage
3. 03.Konwersje formatów certyfikatów i kluczy: PEM, binarny DER oraz kontener PKCS#12 chroniony hasłem
4. 04.Weryfikacja łańcucha zaufania certyfikatów i badanie publicznych logów Certificate Transparency w crt.sh
5. 05.Generowanie listy unieważnień CRL i weryfikacja statusu odwołania certyfikatu w OpenSSL
6. 06.Praktyczna diagnostyka i inspekcja sesji TLS za pomocą openssl s_client i ciphersuite'ów
7. 07.Badanie błędów konfiguracji TLS i certyfikatów z wykorzystaniem platformy testowej BadSSL.com
8. 08.Bezpieczne haszowanie haseł: sól, obciążenie obliczeniowe i porównanie SHA-256 z PBKDF2 w konsoli Linux
9. 09.Anatomia i dekodowanie tokenów JSON Web Token (JWT) w serwisie CyberChef i jwt.io
10. 10.Weryfikacja rekordów uwierzytelniania domeny pocztowej SPF, DKIM i DMARC w narzędziach sieciowych

Cel

Celem zadania jest praktyczne zapoznanie się z architekturą prywatnego urzędu certyfikacji (Root CA) oraz strukturą samopodpisanego certyfikatu X.509. Student generuje parę kluczy RSA, konfiguruje plik openssl.cnf, wystawia główny certyfikat urzędu z rozszerzeniem Basic Constraints oraz analizuje jego pola za pomocą narzędzi OpenSSL i CyberChef.

Scenariusz – opis

Infrastruktura klucza publicznego opiera się na hierarchii zaufania, której fundamentem jest nadrzędny urząd certyfikacji Root CA. W systemach produkcyjnych certyfikat urzędu głównego znajduje się w zaufanym magazynie systemu operacyjnego lub przeglądarki internetowej. Podstawową cechą certyfikatu Root CA jest jego samopodpisanie, co oznacza, że tożsamość wystawcy Issuer jest tożsama z podmiotem Subject. Klucz prywatny Root CA musi być otoczony najwyższą ochroną fizyczną i proceduralną, gdyż jego przejęcie unieważnia zaufanie do całej gałęzi certyfikatów. W tym ćwiczeniu wcielasz się w rolę administratora bezpieczeństwa tworzącego wewnętrzne środowisko certyfikacji dla sieci uczelnianej. Konfiguracja urzędu certyfikacji wymaga zdefiniowania specyficznych rozszerzeń standardu X.509 v3, w tym kluczowej flagi Basic Constraints o wartości CA:TRUE.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz w przeglądarce terminal JSLinux Alpine (bellard.org/jslinux/vm.html?cpu=x86_64&url=alpine-x86_64.cfg&mem=256).
2. Utwórz katalog roboczy i przejdź do niego: mkdir -p ~/ca_lab && cd ~/ca_lab.
3. Wygeneruj zabezpieczony hasłem klucz prywatny Root CA: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -aes256 -out rootCA.key.
4. Sprawdź uprawnienia wygenerowanego klucza i ustaw restrykcyjne prawa: chmod 400 rootCA.key.
5. Utwórz plik konfiguracyjny root_ca.cnf za pomocą polecenia cat z sekcjami [req], [req_distinguished_name] oraz [v3_ca].
6. W sekcji [v3_ca] zdefiniuj wpisy: basicConstraints = critical, CA:TRUE oraz keyUsage = critical, keyCertSign, cRLSign.
7. Zdefiniuj identyfikator klucza: subjectKeyIdentifier = hash oraz authorityKeyIdentifier = keyid:always,issuer.
8. Wygeneruj samopodpisany certyfikat Root CA: openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.crt -config root_ca.cnf -subj '/C=PL/O=Uczelnia IT/CN=Uczelniany Root CA'.
9. Wyświetl pełną strukturę certyfikatu w konsoli: openssl x509 -in rootCA.crt -text -noout.
10. Wykonaj zrzut ekranu terminala z parametrami certyfikatu oraz widoku zdekodowanego certyfikatu w CyberChef.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie specyfiki certyfikatu samopodpisanego Root CA oraz tożsamości pól Issuer i Subject.
• Praktyczna znajomość roli rozszerzenia krytycznego Basic Constraints CA:TRUE w budowaniu hierarchii PKI.
• Umiejętność generowania kluczy RSA 4096-bit i zabezpieczania ich hasłem w środowisku OpenSSL.
• Weryfikacja integralności i tożsamości certyfikatu za pomocą skrótów kryptograficznych (odcisków palców SHA-256).

Cel

Celem zadania jest opanowanie procedury wnioskowania i wystawiania certyfikatów serwerowych X.509 v3. Student generuje wniosek CSR dla serwera WWW, definiuje współczesne rozszerzenia nazw alternatywnych SAN oraz podpisuje wniosek wcześniej przygotowanym urzędem Root CA, weryfikując poprawność nadanych uprawnień.

Scenariusz – opis

Procedura wdrażania certyfikatu na serwerze WWW rozpoczyna się od wygenerowania pary kluczy oraz wniosku o podpisanie CSR. Klucz prywatny serwera powstaje lokalnie i w żadnym wypadku nie może zostać przekazany do urzędu certyfikacji. Wniosek CSR zawiera tożsamość serwera, jego klucz publiczny oraz podpis cyfrowy poświadczający posiadanie klucza prywatnego. We współczesnym internecie pole Common Name CN jest uznawane za przestarzałe i ignorowane przez nowoczesne przeglądarki internetowe. Standardem autoryzacji domen i adresów IP stało się rozszerzenie Subject Alternative Name SAN zdefiniowane w specyfikacji RFC 5280. Prawidłowy certyfikat TLS dla serwera musi ponadto posiadać rozszerzenie Extended Key Usage z flagą serverAuth.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W terminalu JSLinux utwórz podkatalog dla serwera WWW: mkdir -p ~/ca_lab/serwer && cd ~/ca_lab/serwer.
2. Wygeneruj klucz prywatny serwera RSA 2048-bit: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out server.key.
3. Zabezpiecz uprawnienia do klucza serwera: chmod 400 server.key.
4. Utwórz plik konfiguracyjny server_req.cnf z sekcją [req] oraz [v3_req].
5. W sekcji [v3_req] dodaj wpisy: basicConstraints = CA:FALSE, keyUsage = digitalSignature, keyEncipherment oraz extendedKeyUsage = serverAuth.
6. W sekcji [v3_req] dodaj odwołanie do nazw alternatywnych: subjectAltName = @alt_names.
7. Zdefiniuj sekcję [alt_names] z wpisami: DNS.1 = portal.local, DNS.2 = *.portal.local, IP.1 = 127.0.0.1.
8. Wygeneruj wniosek CSR: openssl req -new -key server.key -out server.csr -config server_req.cnf -subj '/C=PL/O=Laboratorium/CN=portal.local'.
9. Sprawdź zawartość wygenerowanego wniosku CSR: openssl req -in server.csr -text -noout.
10. Wykonaj zrzut ekranu konsoli dokumentujący poprawne wykonanie weryfikacji łańcucha oraz obecność sekcji SAN.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie procedury tworzenia wniosków CSR bez ujawniania klucza prywatnego serwera.
• Znajomość konieczności definiowania rozszerzenia Subject Alternative Name (SAN) we współczesnych certyfikatach TLS.
• Praktyczna umiejętność ograniczania uprawnień certyfikatu końcowego flagami Basic Constraints CA:FALSE oraz EKU serverAuth.
• Opanowanie komendy openssl verify do potwierdzania ważności certyfikatu względem zaufanego Root CA.

Cel

Celem ćwiczenia jest praktyczne opanowanie konwersji pomiędzy standardowymi formatami reprezentacji danych kryptograficznych w systemach IT. Student przekształca certyfikaty i klucze pomiędzy tekstowym formatem PEM a binarnym DER, buduje zabezpieczony hasłem magazyn tożsamości PKCS#12 oraz bada strukturę binarną nagłówków ASN.1.

Scenariusz – opis

W infrastrukturze IT administratorzy spotykają się z różnorodnymi formatami plików kryptograficznych w zależności od platformy. Środowiska uniksowe i serwery Apache lub Nginx preferują czytelny format PEM z nagłówkami BASE64. Z kolei maszyny wirtualne Java, urządzenia sieciowe oraz systemy wbudowane często wymagają surowego formatu binarnego DER. Format DER reprezentuje bezpośrednią serializację obiektów w notacji ASN.1 bez kodowania alfanumerycznego. Wymiana pary klucz prywatny oraz certyfikat pomiędzy serwerami wymaga bezpiecznego mechanizmu opakowującego. Standard PKCS#12 definiuje format archiwum zdolnego pomieścić klucze prywatne, certyfikaty tożsamości oraz łańcuchy pośrednie.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Utwórz katalog do testów konwersji: mkdir -p ~/ca_lab/formaty && cd ~/ca_lab/formaty.
2. Skopiuj pliki z poprzedniego zadania: cp ~/ca_lab/serwer/server.crt . &&cp ~/ca_lab/serwer/server.key .
3. Wyświetl nagłówki i treść pliku PEM: head -n 5 server.crt && tail -n 5 server.crt.
4. Skonwertuj certyfikat PEM do postaci binarnej DER: openssl x509 -in server.crt -outform DER -out server.der.
5. Porównaj rozmiary plików: ls -lh server.crt server.der (odnotuj redukcję rozmiaru o około 25-30%).
6. Zbadaj pierwsze 16 bajtów pliku binarnego DER: hexdump -C -n 16 server.der.
7. Zidentyfikuj bajty znacznika sekwencji ASN.1 (bajt 0x30, po którym następuje długość 0x82).
8. Dokonaj konwersji powrotnej DER do PEM: openssl x509 -in server.der -inform DER -out server_odtworzony.pem.
9. Porównaj odtworzony plik PEM z pierwotnym certyfikatem: diff -s server.crt server_odtworzony.pem.
10. Wykonaj zrzuty ekranu podsumowujące wykonane polecenia i sporządź tabelę porównawczą formatów PEM, DER i PKCS#12.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie różnic konstrukcyjnych pomiędzy formatami PEM (Base64) i DER (binarna notacja ASN.1).
• Umiejętność bezstratnej konwersji certyfikatów i kluczy pomiędzy środowiskami uniksowymi a aplikacjami Java/Windows.
• Opanowanie tworzenia i bezpiecznego rozpakowywania kontenerów PKCS#12 (.p12/.pfx) chronionych hasłem.
• Znajomość mechanizmów zabezpieczania tożsamości cyfrowej podczas transportu pomiędzy serwerami produkcyjnymi.

Cel

Celem zadania jest zbadanie mechanizmu weryfikacji łańcucha zaufania certyfikatów X.509 oraz analiza publicznych rejestrów Certificate Transparency. Student weryfikuje łańcuchy certyfikatów w konsoli OpenSSL, symuluje błąd braku certyfikatu pośredniego oraz przeszukuje publiczną bazę crt.sh w celu audytu certyfikatów wystawionych dla wybranej domeny.

Scenariusz – opis

Bezpieczeństwo połączeń TLS opiera się na łańcuchu zaufania łączącym certyfikat końcowy z zaufanym urzędem nadrzędnym. W praktyce urzędy główne Root CA rzadko wystawiają bezpośrednio certyfikaty dla serwerów WWW. Ze względów bezpieczeństwa stosuje się urzędy pośrednie Intermediate CA, co ogranicza ryzyko kompromitacji klucza głównego. Klient TLS weryfikuje każdy certyfikat po kolei, sprawdzając podpisy cyfrowe i ważność od serwera aż do magazynu zaufania. Jeśli serwer WWW nie dostarczy klientowi certyfikatu pośredniego, przeglądarka zgłasza błąd nieznanego wystawcy. Aby przeciwdziałać wystawianiu nieautoryzowanych certyfikatów przez skompromitowane urzędy CA, wprowadzono Certificate Transparency.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W terminalu JSLinux utwórz katalog dla testu hierarchii: mkdir -p ~/ca_lab/lancuch && cd ~/ca_lab/lancuch.
2. Wygeneruj klucz urzędu pośredniego: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out inter.key.
3. Utwórz wniosek CSR dla pośrednika z atrybutem CN='Uczelniany Intermediate CA': openssl req -new -key inter.key -out inter.csr -subj '/C=PL/O=Uczelnia IT/CN=Uczelniany Intermediate CA'.
4. Utwórz plik konfiguracyjny inter.cnf z wpisem: basicConstraints = critical, CA:TRUE, pathlen:0 oraz keyUsage = critical, keyCertSign, cRLSign.
5. Podpisz certyfikat pośrednika kluczem Root CA: openssl x509 -req -in inter.csr -CA ~/ca_lab/rootCA.crt -CAkey ~/ca_lab/rootCA.key -CAcreateserial -out inter.crt -days 1825 -sha256 -extfile inter.cnf.
6. Wygeneruj klucz i CSR dla nowej usługi: openssl req -new -newkey rsa:2048 -nodes -keyout app.key -out app.csr -subj '/C=PL/O=Uczelnia IT/CN=aplikacja.local'.
7. Podpisz certyfikat aplikacji kluczem pośrednika: openssl x509 -req -in app.csr -CA inter.crt -CAkey inter.key -CAcreateserial -out app.crt -days 365 -sha256.
8. Przetestuj naiwną weryfikację certyfikatu aplikacji względem Root CA: openssl verify -CAfile ~/ca_lab/rootCA.crt app.crt (odnotuj zgłoszony błąd braku wystawcy).
9. Wykonaj poprawną weryfikację z dostarczeniem certyfikatu pośrednika: openssl verify -CAfile ~/ca_lab/rootCA.crt -untrusted inter.crt app.crt (odnotuj wynik app.crt: OK).
10. Zapisz zrzuty ekranu z konsoli oraz raportu crt.sh, sporządzając opis działania Certificate Transparency w raporcie.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie trójstopniowej architektury zaufania PKI (Root CA -> Intermediate CA -> End-Entity).
• Praktyczna znajomość przyczyny błędu unable to get local issuer certificate i roli parametru untrusted/fullchain.
• Zrozumienie znaczenia mechanizmu Certificate Transparency w wykrywaniu fałszywych certyfikatów.
• Umiejętność przeszukiwania i interpretowania publicznych logów CT w portalu crt.sh.

Cel

Celem zadania jest praktyczne przećwiczenie procedury unieważniania certyfikatów X.509 za pomocą list unieważnień CRL. Student konfiguruje bazę danych urzędu CA, symuluje incydent kompromitacji klucza prywatnego serwera, unieważnia certyfikat, generuje podpisaną listę CRL oraz przeprowadza weryfikację stanu odwołania w OpenSSL.

Scenariusz – opis

Nawet poprawny kryptograficznie certyfikat traci zaufanie w sytuacji kompromitacji powiązanego klucza prywatnego. Innymi przyczynami wycofania certyfikatu mogą być zmiana danych firmy, zmiana adresu domeny lub zakończenie świadczenia usługi. Najstarszym standardem informowania klientów o wycofaniu certyfikatu jest lista unieważnień Certificate Revocation List CRL. Lista CRL jest podpisywanym cyfrowo dokumentem publikowanym okresowo przez urząd certyfikacji pod adresem wskazanym w rozszerzeniu CRL Distribution Points. Każdy wpis na liście CRL zawiera numer seryjny odwołanego certyfikatu, datę unieważnienia oraz powód wycofania. Kluczowym elementem nagłówka CRL są pola thisUpdate oraz nextUpdate definiujące okno czasowe ważności samej listy.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W terminalu JSLinux utwórz katalog dla bazy unieważnień: mkdir -p ~/ca_lab/crl_demo && cd ~/ca_lab/crl_demo.
2. Utwórz pusty plik bazy danych certyfikatów: touch index.txt.
3. Zainicjalizuj numer seryjny certyfikatu: echo '01' > serial.
4. Zainicjalizuj numer kolejny listy unieważnień: echo '1000' > crlnumber.
5. Utwórz plik konfiguracyjny ca_crl.cnf definiujący sekcję [ca] oraz ścieżki do index.txt, serial, crlnumber i klucza rootCA.
6. Wygeneruj certyfikat testowy do unieważnienia: openssl req -new -newkey rsa:2048 -nodes -keyout test_revoke.key -out test_revoke.csr -subj '/CN=serwer-zagrozony.local'.
7. Podpisz certyfikat za pomocą narzędzia urzędu: openssl ca -config ca_crl.cnf -in test_revoke.csr -out test_revoke.crt -batch.
8. Wygeneruj wstępną pustą listę unieważnień CRL: openssl ca -config ca_crl.cnf -gencrl -out pusta.crl.
9. Zweryfikuj certyfikat przed unieważnieniem: openssl verify -CAfile ~/ca_lab/rootCA.crt -CRLfile pusta.crl -crl_check test_revoke.crt (odnotuj wynik: OK).
10. Odnotuj i zarejestruj zgłoszony błąd weryfikatora: error 23 at 0 depth lookup: certificate revoked.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie mechanizmu działania list unieważnień CRL i ich struktury wewnętrznej.
• Praktyczna znajomość przyczyn wycofywania certyfikatów oraz ich formalnego oznaczania (np. keyCompromise).
• Umiejętność generowania, inspekcji i wykorzystywania list CRL w narzędziu OpenSSL.
• Świadomość ograniczeń świeżości danych w modelu CRL wynikających z okna czasowego pomiędzy thisUpdate a nextUpdate.

Cel

Celem zadania jest opanowanie zaawansowanej diagnostyki sesji TLS z wykorzystaniem narzędzia konsolowego openssl s_client. Student nawiązuje szyfrowane połączenia z publicznymi serwerami internetowymi, bada przebieg negocjacji protokołu, identyfikuje użyte zestawy szyfrów, krzywe eliptyczne oraz testuje wpływ nagłówków SNI i negocjacji ALPN.

Scenariusz – opis

Protokół TLS zabezpiecza warstwę transportową, gwarantując poufność, integralność oraz autentyczność komunikacji sieciowej. Podstawowym narzędziem inżyniera bezpieczeństwa do analizowania konfiguracji TLS serwera jest polecenie openssl s_client. Pozwala ono nawiązać bezpośrednie połączenie z portem usługi i prześledzić wszystkie komunikaty fazy uzgadniania TLS Handshake. W nowoczesnym internecie na jednym adresie IP często hostowane są setki niezależnych serwisów internetowych. Z tego względu kluczowe znaczenie ma rozszerzenie Server Name Indication SNI przesyłane w pierwszym pakiecie ClientHello. Brak wskazania poprawnego nagłówka SNI skutkuje odesłaniem przez serwer domyślnego certyfikatu i błędem weryfikacji tożsamości.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W konsoli JSLinux nawiąż połączenie z serwerem Cloudflare z obsługą SNI: openssl s_client -connect cloudflare.com:443 -servername cloudflare.com.
2. Zatrzymaj sesję wysyłając polecenie Q lub naciskając Ctrl+C.
3. Przeanalizuj pierwsze linie wyjścia i odczytaj liczbę certyfikatów przesłanych w łańcuchu (Certificate chain).
4. Odszukaj linię Peer signing digest i odczytaj funkcję skrótu użytą do podpisu serwera (np. SHA256 lub SHA384).
5. Odszukaj linię Server Temp Key i sprawdź użytą grupę efemerycznej wymiany kluczy (np. X25519, 253 bits).
6. W sekcji New, TLSv1.3 odczytaj pozycję Cipher i zanotuj nazwę szyfru AEAD.
7. Przetestuj połączenie bez nagłówka SNI: openssl s_client -connect cloudflare.com:443.
8. Porównaj pole subject certyfikatu uzyskanego bez SNI z certyfikatem uzyskanym z SNI.
9. Wymuś nawiązanie połączenia z protokołem TLS 1.2: openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -tls1_2.
10. Zapisz zrzuty ekranu podsumowujące parametry wynegocjowanej sesji TLS 1.3 oraz TLS 1.2.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Praktyczna umiejętność diagnostyki połączeń TLS za pomocą narzędzia openssl s_client.
• Zrozumienie krytycznej roli rozszerzenia SNI (Server Name Indication) w środowiskach wirtualnego hostingu.
• Znajomość różnic architektonicznych w nazewnictwie i działaniu ciphersuites pomiędzy TLS 1.2 a TLS 1.3.
• Zrozumienie mechanizmu ALPN w negocjowaniu protokołów wyższej warstwy (HTTP/2 vs HTTP/1.1).

Cel

Celem zadania jest empiryczne zbadanie i sklasyfikowanie najczęstszych błędów konfiguracji certyfikatów X.509 oraz protokołu TLS. Student wykorzystuje publiczną platformę badawczą BadSSL.com do analizy zachowania przeglądarki internetowej oraz narzędzi konsolowych w obliczu certyfikatów wygasłych, samopodpisanych, o niezgodnej nazwie hosta oraz pozbawionych certyfikatów pośrednich.

Scenariusz – opis

W codziennej pracy inżynier IT często spotyka się z ostrzeżeniami bezpieczeństwa generowanymi przez przeglądarki i aplikacje. Komunikaty te wynikają z rygorystycznych reguł weryfikacji tożsamości zdefiniowanych w standardach internetowych. Do celów edukacyjnych i audytowych powstała publiczna platforma BadSSL.com utrzymywana przez inżynierów bezpieczeństwa. Platforma ta udostępnia subdomeny skonfigurowane celowo w sposób błędny pod kątem różnych parametrów kryptograficznych. Wśród typowych anomalii znajduje się certyfikat wygasły expired, w którym bieżąca data wykracza poza pole notAfter. Innym powszechnym błędem jest wrong.host, gdzie żądana domena nie występuje ani w CN, ani w rozszerzeniu SAN.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz w przeglądarce stronę główną https://badssl.com.
2. Kliknij kafelek 'expired' i wykonaj zrzut ekranu komunikatu blokady w przeglądarce.
3. W terminalu JSLinux wykonaj diagnostykę wygasłego certyfikatu: openssl s_client -connect expired.badssl.com:443 -servername expired.badssl.com.
4. Zlokalizuj w wyjściu linię: verify error:num=10:certificate has expired.
5. Kliknij w przeglądarce kafelek 'wrong.host' i zbadaj komunikat o niezgodności domeny.
6. W konsoli JSLinux przetestuj weryfikację nazwy hosta: openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com -verify_hostname wrong.host.badssl.com.
7. Odnotuj błąd: verify return:1 oraz failure: Hostname mismatch.
8. Wyświetl nazwy alternatywne SAN z tego certyfikatu: openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com 2>/dev/null | openssl x509 -noout -ext subjectAltName.
9. Przetestuj certyfikat samopodpisany: openssl s_client -connect self-signed.badssl.com:443 -servername self-signed.badssl.com.
10. Opracuj tabelę zestawiającą 4 badane scenariusze awarii z ich kodami numerycznymi OpenSSL i opisem przyczyny.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Praktyczna znajomość najczęstszych błędów certyfikacji TLS i ich symptomów w przeglądarkach oraz konsoli.
• Zdolność precyzyjnego diagnozowania przyczyn odrzucenia certyfikatu na podstawie kodów błędów OpenSSL (num=10, 18, 20).
• Zrozumienie ryzyka związanego z ignorowaniem błędów TLS (np. przełącznik -k w narzędziu curl).
• Umiejętność odróżniania błędów kryptograficznych od błędów konfiguracji nazw domenowych i łańcuchów certyfikatów.

Cel

Celem zadania jest praktyczne zrozumienie zasad bezpiecznego przechowywania haseł w bazach danych. Student bada podatność prostych skrótów kryptograficznych na ataki tęczowe, implementuje mechanizm solenia haseł oraz testuje standard derywacji klucza PBKDF2 o regulowanym koszcie obliczeniowym, analizując czas potrzebny na sprawdzenie przestrzeni haseł.

Scenariusz – opis

Przechowywanie haseł użytkowników w postaci otwartego tekstu jest rażącym naruszeniem zasad bezpieczeństwa i przepisów prawa. Wielu programistów popełnia jednak błąd, stosując do ochrony haseł szybkie funkcje skrótu, takie jak MD5 lub pojedyncze SHA-256. Szybkie funkcje skrótu zostały zaprojektowane do sprawdzania integralności danych i wykonują się w ułamkach mikrosekund. Brak soli kryptograficznej umożliwia natychmiastowe odzyskanie hasła za pomocą publicznych baz odwróconych i tablic tęczowych. Sól kryptograficzna to unikalny, losowy ciąg bajtów dołączany do hasła przed wyliczeniem skrótu. Solenie uniemożliwia stosowanie wcześniej przeliczonych tablic, wymuszając atak słownikowy indywidualnie dla każdego użytkownika.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W konsoli JSLinux wylicz surowy skrót SHA-256 popularnego hasła: echo -n 'haslo123' | sha256sum.
2. Zanotuj uzyskany skrót: ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f.
3. Wklej uzyskany skrót do wyszukiwarki lub serwisu CyberChef i przekonaj się, jak łatwo go zidentyfikować.
4. Wygeneruj bezpieczną losową sól: SALT=$(openssl rand -hex 16) && echo $SALT.
5. Oblicz posolony skrót SHA-256: echo -n "${SALT}haslo123" | sha256sum.
6. Wyjaśnij w sprawozdaniu rolę soli w zapobieganiu atakom przy użyciu gotowych tablic tęczowych.
7. Wykonaj derywację PBKDF2 z 1000 iteracji: openssl kdf -kdfopt digest:SHA256 -kdfopt pass:haslo123 -kdfopt salt:$SALT -kdfopt iter:1000 -keylen 32 PBKDF2.
8. Zmierz czas wykonania 100 000 iteracji PBKDF2: time openssl kdf -kdfopt digest:SHA256 -kdfopt pass:haslo123 -kdfopt salt:$SALT -kdfopt iter:100000 -keylen 32 PBKDF2.
9. Zmierz czas wykonania 500 000 iteracji PBKDF2: time openssl kdf -kdfopt digest:SHA256 -kdfopt pass:haslo123 -kdfopt salt:$SALT -kdfopt iter:500000 -keylen 32 PBKDF2.
10. Zapisz zrzuty ekranu poleceń konsolowych oraz tabelę pomiarów czasu trwania derywacji.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie fundamentalnej roli soli kryptograficznej w unieszkodliwianiu tablic tęczowych.
• Świadomość niebezpieczeństwa stosowania szybkich funkcji skrótu (MD5, SHA-256) do przechowywania haseł.
• Praktyczna znajomość działania spowalniających funkcji KDF (PBKDF2, crypt-SHA512) i roli parametru kosztu.
• Zdolność odczytywania i interpretowania formatu zapisu haseł w systemach linuksowych (/etc/shadow).

Cel

Celem zadania jest praktyczne zapoznanie się z anatomią i mechanizmem weryfikacji tokenów JSON Web Token (JWT). Student dekoduje poszczególne segmenty tokena, analizuje nagłówek i roszczenia w payloadzie, bada format kodowania Base64URL oraz weryfikuje matematyczną poprawność podpisu cyfrowego HMAC-SHA256 w serwisach jwt.io i CyberChef.

Scenariusz – opis

We współczesnych architekturach mikroserwisowych i aplikacjach chmurowych dominuje model bezstanowej autoryzacji. Podstawowym standardem wymiany poświadczeń i uprawnień stał się format JSON Web Token zdefiniowany w RFC 7519. Token JWT składa się z trzech części rozdzielonych kropkami: nagłówka Header, ładunku Payload oraz podpisu Signature. Wszystkie części tokena są zakodowane w bezpiecznym dla adresów internetowych formacie Base64URL. Wielu początkujących programistów myli kodowanie Base64URL z szyfrowaniem, sądząc błędnie, że treść tokena jest poufna. W rzeczywistości ładunek JWT jest całkowicie jawny i może zostać odczytany przez każdego posiadacza tokena.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz w przeglądarce portal diagnostyczny https://jwt.io.
2. Zbadaj strukturę trójczłonowego tokena w panelu 'Encoded': nagłówek, ładunek i podpis.
3. W panelu 'Payload' dodaj własne dane: {"sub": "12345", "name": "Jan Kowalski", "role": "user", "exp": 1735689600}.
4. W panelu 'Verify Signature' wprowadź sekret HMAC: 'klucz_tajny_laboratorium_2024'.
5. Skopiuj wygenerowany token z lewego panelu do schowka.
6. Otwórz w nowej karcie serwis CyberChef (gchq.github.io/CyberChef).
7. Wklej token do panelu wejściowego CyberChef.
8. Użyj operacji 'Split' ze separatorem '.' lub zaznacz i skopiuj środkową część (Payload).
9. W CyberChef zastosuj operację 'From Base64' z zaznaczoną opcją 'URL safe' i odczytaj czysty JSON z ładunkiem.
10. Wykonaj zrzuty ekranu z poprawnie zweryfikowanego tokena oraz odrzuconego po próbie manipulacji uprawnieniami.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie bezstanowego modelu autoryzacji opartego na tokenach JWT (RFC 7519).
• Świadomość braku poufności danych w standardowym ładunku JWT kodowanym w Base64URL.
• Praktyczna umiejętność matematycznej weryfikacji podpisu HMAC-SHA256 (HS256).
• Zrozumienie, w jaki sposób kryptograficzny podpis uniemożliwia nieautoryzowaną eskalację uprawnień w aplikacjach webowych.

Cel

Celem zadania jest praktyczne zapoznanie się z triadą technologii chroniących pocztę elektroniczną przed spoofingiem i phishingiem: SPF, DKIM oraz DMARC. Student odpytuje serwery DNS o specjalistyczne rekordy TXT za pomocą narzędzi konsolowych dig/nslookup, analizuje reguły autoryzacji serwerów, odnajduje asymetryczne klucze publiczne DKIM oraz interpretuje polityki ochrony domeny DMARC.

Scenariusz – opis

Protokół SMTP opracowany w latach osiemdziesiątych nie posiadał wbudowanych mechanizmów uwierzytelniania nadawcy wiadomości. W efekcie każdy użytkownik internetu mógł wysłać wiadomość ze sfałszowanym adresem nadawcy w nagłówku From. Aby przeciwdziałać podszywaniu się pod instytucje i domeny, wprowadzono trzy komplementarne mechanizmy ochronne oparte na systemie DNS. Mechanizm SPF publikuje listę adresów IP serwerów uprawnionych do nadawania poczty w imieniu danej domeny. Standard DKIM wprowadza kryptograficzny podpis asymetryczny RSA lub Ed25519 umieszczany w nagłówku wiadomości pocztowej. Klucz publiczny służący do weryfikacji podpisu DKIM jest publikowany przez właściciela domeny w specjalnym rekordzie DNS.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W terminalu JSLinux wykonaj zapytanie o rekord SPF domeny google.com: nslookup -type=TXT google.com (lub dig TXT google.com).
2. Zlokalizuj odpowiedź zawierającą ciąg: 'v=spf1 include:_netblocks.google.com ... ~all'.
3. Zinterpretuj mechanizm include oraz kwalifikator ~all (SoftFail).
4. Wykonaj zapytanie o rekord SPF dla domeny uczelnianej lub krajowego portalu (np. wp.pl): nslookup -type=TXT wp.pl.
5. Zidentyfikuj kwalifikator końcowy -all (HardFail) i wyjaśnij różnicę w traktowaniu nieautoryzowanych serwerów.
6. Zbadaj rekord DKIM firmy Google dla selektora 20230601: nslookup -type=TXT 20230601._domainkey.google.com.
7. Zanotuj zawartość pola p= zawierającego klucz publiczny RSA.
8. Przeanalizuj format klucza publicznego DKIM i upewnij się, że nie zawiera on nagłówków PEM, lecz czysty Base64.
9. Wyślij zapytanie o rekord polityki DMARC domeny google.com: nslookup -type=TXT _dmarc.google.com.
10. Zapisz zrzuty ekranu poleceń konsolowych i sformułuj wnioski dotyczące bezpieczeństwa ekosystemu pocztowego.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie podatności pierwotnego protokołu SMTP na ataki podszywania się pod nadawcę (email spoofing).
• Praktyczna znajomość mechanizmu autoryzacji adresów IP serwerów w rekordach SPF.
• Zrozumienie kryptograficznej natury podpisów DKIM i roli publikacji klucza publicznego w rekordach TXT DNS.
• Świadomość decydującej roli polityki DMARC (szczególnie reguły p=reject) w egzekwowaniu odrzucania wiadomości phishingowych.