Analiza wersji protokołu TLS i ich znaczenie
Narzędzie analizuje dostarczony tekst pod kątem występowania deklaracji wersji protokołu. W zależności od kontekstu ujętego w analizowanym materiale, wersje te mogą pełnić różne role:
- Negocjowane: Wersja protokołu, która została ostatecznie wybrana do zabezpieczenia sesji.
- Oferowane: Wersje protokołów oferowane przez klienta.
- Zaobserwowane: Wersje protokołów zaobserwowane w analizowanym materiale.
Jeśli w analizowanym tekście nie zostanie wykryta żadna wersja protokołu, narzędzie wyświetli komunikat: „W dostarczonym tekście nie znaleziono żadnej wersji protokołu.”.
Struktura i komponenty zestawów szyfrów TLS
Zestaw szyfrów (cipher suite) to ustrukturyzowany ciąg identyfikujący kombinację algorytmów kryptograficznych używanych do zabezpieczenia połączenia. W tradycyjnym ujęciu (do wersji TLS 1.2 włącznie), nazwa zestawu szyfrów jednoznacznie definiuje cztery kluczowe elementy:
- Algorytm wymiany kluczy: Odpowiada za bezpieczne uzgodnienie klucza symetrycznego (np. ECDHE, RSA).
- Algorytm uwierzytelniania: Służy do weryfikacji tożsamości serwera (np. RSA, ECDSA).
- Szyfr symetryczny: Służy do szyfrowania przesyłanych danych (np. AES, ChaCha20) wraz z trybem pracy (np. GCM, CBC).
- Algorytm skrótu (KDF/MAC): Wykorzystywany do weryfikacji integralności danych oraz w funkcjach wyprowadzania klucza (np. SHA-256).
Narzędzie identyfikuje zestawy szyfrów na podstawie popularnych nazw IANA, aliasów OpenSSL oraz szesnastkowych identyfikatorów (hex IDs). Każdy zidentyfikowany pakiet otrzymuje ocenę określającą jego status bezpieczeństwa:
- Nowoczesne: Bezpieczne, zalecane do powszechnego stosowania zestawy kryptograficzne.
- Recenzja: Pakiety wymagające dodatkowej weryfikacji kontekstu wdrożenia.
- Przestarzałe: Zestawy zawierające słabe lub wycofane algorytmy, które nie powinny być używane.
- Nieznany: Pakiety, których nie ma we wbudowanej bazie danych narzędzia. W takim przypadku wyświetlany jest komunikat: „Tego apartamentu nie ma na wbudowanej mapie wspólnego apartamentu. Sprawdź aktualny rejestr IANA lub dokumentację skanera.”.
W przypadku braku wykrycia jakichkolwiek zestawów szyfrów w wejściu, system prezentuje komunikat: „W dostarczonym tekście nie znaleziono żadnego zestawu szyfrów.”.
Wycofane i przestarzałe algorytmy kryptograficzne
Analiza konfiguracji TLS często ujawnia obecność przestarzałych algorytmów, które zagrażają poufności i integralności danych. Narzędzie automatycznie flaguje niebezpieczne komponenty, przypisując im precyzyjne komunikaty diagnostyczne:
| Algorytm / Typ pakietu | Identyfikowane zagrożenie i status bezpieczeństwa |
|---|---|
| RC4 | „RC4 jest przestarzały i nie należy go negocjować.” |
| DES | „DES nie jest bezpieczny do ogólnego użytku TLS.” |
| 3DES | „3DES ma mały rozmiar bloku i jest przestarzały dla TLS.” |
| Szyfrowanie NULL | „Szyfrowanie NULL nie zapewnia poufności.” |
| Pakiety EXPORT | „Pakiety EXPORT celowo wykorzystują słabą kryptografię i są przestarzałe.” |
| Pakiety anonimowe | „Pakiety anonimowe nie uwierzytelniają partnera i są podatne na przechwycenie.” |
| MD5 | „MD5 nie jest bezpieczny do ogólnego użytku TLS.” |
| SHA-1 | „Ten pakiet wykorzystuje SHA-1, który jest przestarzały do ogólnego użytku TLS.” |
| Szyfry CBC | „Zestawy CBC są starsze. Preferuj pakiet AEAD, taki jak AES-GCM lub ChaCha20-Poly1305.” |
| CCM-8 | „CCM-8 wykorzystuje krótszy znacznik uwierzytelniający i wymaga przeglądu pod kątem protokołu.” |
Specyfika negocjacji w protokole TLS 1.3
Protokół TLS 1.3 wprowadził radykalne zmiany w architekturze bezpieczeństwa poprzez uproszczenie procesu uzgadniania połączenia. W przeciwieństwie do starszych wersji, w TLS 1.3 mechanizmy wymiany kluczy oraz uwierzytelniania zostały całkowicie odseparowane od samego zestawu szyfrów.
W rezultacie nazwy pakietów szyfrów w TLS 1.3 określają wyłącznie algorytm szyfrowania symetrycznego (AEAD) oraz funkcję skrótu dla KDF (np. TLS_AES_256_GCM_SHA384). Narzędzie sygnalizuje tę różnicę strukturalną poprzez komunikat: „TLS 1.3 negocjuje wymianę kluczy i uwierzytelnianie niezależnie od zestawu szyfrów.”. Z tego powodu parametry wymiany kluczy (takie jak grupy ECDHE) oraz algorytmy certyfikatów muszą być analizowane osobno w komunikatach rozszerzeń ClientHello i ServerHello, gdyż nie można ich wywnioskować z samej nazwy pakietu.
Znaczenie utajniania przekazywania (Forward Secrecy)
Utajnianie przekazywania (Forward Secrecy - FS) to właściwość protokołów uzgadniania kluczy, która gwarantuje, że skompromitowanie klucza prywatnego serwera w przyszłości nie pozwoli na odszyfrowanie historycznego ruchu sieciowego zarejestrowanego przez stronę trzecią.
W starszych konfiguracjach TLS powszechnie stosowano statyczną wymianę kluczy opartą na algorytmie RSA. W tym modelu klient szyfruje klucz pre-master za pomocą klucza publicznego serwera. Jeśli klucz prywatny serwera zostanie kiedykolwiek ujawniony, wszystkie sesje zabezpieczone w ten sposób mogą zostać natychmiast odszyfrowane. Narzędzie identyfikuje takie konfiguracje i generuje ostrzeżenie: „Statyczna wymiana kluczy RSA nie zapewnia tajemnicy przekazywania.”. Współczesne wdrożenia wymagają stosowania efemerycznych protokołów wymiany kluczy, takich jak ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
Ograniczenia analizy statycznej a skanowanie na żywo
Narzędzie wykonuje wyłącznie statyczną analizę dostarczonego tekstu. Oznacza to, że przetwarza dane wejściowe bez nawiązywania jakichkolwiek połączeń sieciowych. Należy pamiętać o następujących ograniczeniach takiego podejścia:
- Narzędzie nie łączy się z żadnym hostem ani nie wykonuje aktywnego skanowania portów.
- Nie jest przeprowadzana weryfikacja łańcucha certyfikatów X.509 ani poprawności ich podpisów.
- Narzędzie nie mierzy rzeczywistych rozmiarów kluczy asymetrycznych użytych podczas uzgadniania.
- Nie ma możliwości przetestowania odporności serwera na ataki typu downgrade (wymuszenie starszej wersji protokołu).
- Analiza ogranicza się wyłącznie do parametrów jawnie wskazanych w przekazanym tekście; niewymienione pakiety akceptowane przez serwer pozostają niewykryte.
Wszelkie przetwarzanie danych odbywa się lokalnie w przeglądarce użytkownika. Wklejone informacje nie są wysyłane na serwery zewnętrzne ani zapisywane, co zapewnia prywatność analizowanych danych konfiguracyjnych.
Instrukcja obsługi i rozwiązywanie problemów
Aby dokonać analizy, należy wkleić tekst podsumowania (do 200 000 znaków) w polu wejściowym i uruchomić analizę. Narzędzie obsługuje czytelne formaty tekstowe, lecz nie dekoduje surowych plików binarnych (np. plików.pcap).
Komunikaty o błędach i ich przyczyny
- „Najpierw wklej podsumowanie skanu TLS lub uzgadniania.” – Komunikat pojawia się, gdy użytkownik spróbuje uruchomić analizę przy pustym polu wejściowym.
- „To podsumowanie jest niezwykle duże. Nie przekraczaj 200 000 znaków.” – Występuje w przypadku przekroczenia maksymalnego dopuszczalnego limitu rozmiaru tekstu wejściowego.
- „Nie rozpoznano żadnej wersji TLS ani zestawu szyfrów. Wklej czytelne pola skanera lub uścisku dłoni.” – Pojawia się, gdy tekst wejściowy nie zawiera żadnych znanych nazw IANA, aliasów OpenSSL, identyfikatorów szesnastkowych ani deklaracji wersji protokołu TLS.
Często zadawane pytania (FAQ)
Jakie formaty wyjściowe TLS mogę wkleić?
Wklej tekst z popularnych skanerów TLS, openssl s_client, podsumowań analizy pakietów lub krótką notatkę ClientHello lub ServerHello. Moduł sprawdzający rozpoznaje popularne nazwy IANA, aliasy OpenSSL i kilka popularnych identyfikatorów zestawu szesnastkowego; nie dekoduje surowych bajtów pakietu.
Dlaczego zestaw szyfrów TLS 1.3 nie wyświetla RSA ani ECDHE?
Nazwy zestawów szyfrów TLS 1.3 opisują szyfrowanie rekordów i skrót uzgadniania. Wymiana kluczy i uwierzytelnianie są negocjowane osobno, więc nie można ich wywnioskować na podstawie samej nazwy pakietu.
Czy ten wynik świadczy o tym, że serwer jest bezpieczny?
Nie. Wyjaśnia tylko wklejony tekst. Nie łączy się z hostem, nie sprawdza certyfikatu, nie mierzy rozmiarów kluczy, nie testuje zachowania przy przejściu na niższą wersję ani nie wyświetla każdego pakietu akceptowanego przez serwer.