Audyt TLS 1.3, mTLS i PKI: techniczny przewodnik

Audyt TLS 1.3, mTLS i PKI nie kończy się na sprawdzeniu, czy przeglądarka pokazuje kłódkę. Trzeba zweryfikować wersje protokołu, negocjację parametrów, walidację tożsamości usługi, ścieżkę certyfikacji, użycie klucza, zachowanie przy błędzie, obsługę 0-RTT, rotację oraz granice zaufania po obu stronach połączenia. Poprawny handshake może nadal chronić połączenie do niewłaściwego hosta, akceptować niepożądanego klienta albo zależeć od klucza, którego organizacja nie potrafi szybko odwołać.

Poniższa metodyka jest przeznaczona dla aplikacji internetowych, API, komunikacji service-to-service i prywatnego PKI. Łączy wymagania RFC z testami wdrożeniowymi, dzięki czemu wynik audytu opisuje realny scenariusz ryzyka, a nie tylko listę szyfrów.

TLS, mTLS i PKI rozwiązują różne problemy

TLS zapewnia poufność i integralność kanału oraz zwykle uwierzytelnia serwer certyfikatem. mTLS dodaje certyfikat klienta, dzięki czemu obie strony przedstawiają tożsamość kryptograficzną. PKI jest systemem, który wydaje, dystrybuuje, odnawia i unieważnia certyfikaty oraz definiuje zaufane urzędy, profile i polityki.

Te warstwy nie są zamienne. TLS nie naprawi nadmiernych uprawnień aplikacji. Certyfikat klienta potwierdza kontrolę nad kluczem, ale nie określa automatycznie, do jakich rekordów może uzyskać dostęp. Prywatny root CA nie daje bezpieczeństwa, jeśli klucz urzędu jest kopiowany między serwerami. Audyt musi więc ocenić protokół, tożsamość i autoryzację jako osobne mechanizmy.

Warstwa	Dowód, którego szukamy	Przykład awarii
TLS	kanał używa dozwolonej wersji i parametrów	fallback do przestarzałego protokołu
Identyfikacja serwera	nazwa usługi pasuje do certyfikatu	klient nie sprawdza SAN lub ignoruje błąd
mTLS	klient ma zaufany, właściwy certyfikat i klucz	każdy certyfikat z firmowego CA uzyskuje dostęp
PKI	łańcuch, profile, rotacja i odwołanie działają	wygasły intermediate zatrzymuje wszystkie usługi
Autoryzacja	tożsamość certyfikatu ma minimalne prawa	wspólny certyfikat daje dostęp wielu workloadom

Baseline protokołu: TLS 1.2 i TLS 1.3

RFC 9325 zaleca wspieranie i preferowanie TLS 1.3 oraz wyłączenie przestarzałych wersji. Dla systemów wymagających interoperacyjności TLS 1.2 może nadal być częścią baseline’u, ale musi używać współczesnych konfiguracji. TLS 1.0 i 1.1 nie powinny pozostawać aktywne jako „awaryjna kompatybilność”. NIST SP 800-52 Rev. 2 daje dodatkowy punkt odniesienia dla wdrożeń administracji amerykańskiej i organizacji korzystających z podobnego profilu.

TLS 1.3 upraszcza zestaw cipher suites i usuwa wiele historycznych konstrukcji, lecz nie sprawia, że każda konfiguracja jest dobra. Audytuj obsługiwane wersje na każdym publicznym i wewnętrznym listenerze, zachowanie terminatorów load balancera, połączenie od proxy do backendu oraz bibliotekę klienta. Frontend może używać TLS 1.3, gdy odcinek proxy–aplikacja pozostaje nieszyfrowany albo nie weryfikuje certyfikatu.

Nie oceniaj bezpieczeństwa wyłącznie na podstawie jednego skanera. Weryfikuj próbami pozytywnymi i negatywnymi, konfiguracją infrastruktury oraz obserwacją rzeczywistego handshake. CDN, WAF, ingress i service mesh mogą prezentować różne profile zależnie od SNI, ALPN, adresu IP lub regionu.

Negocjacja kryptograficzna i grupy kluczy

W TLS 1.3 cipher suite określa AEAD i funkcję skrótu, a grupy wymiany klucza są negocjowane osobno. RFC 9325 wskazuje X25519 i secp256r1 jako szeroko stosowane opcje. W audycie ustal, które grupy są oferowane, czy istnieje forward secrecy oraz czy polityka organizacji nie wymusza konfiguracji niekompatybilnej z klientami krytycznymi.

Sprawdź również:

czy serwer preferuje współczesny profil i nie akceptuje historycznych algorytmów w TLS 1.2;
czy certyfikat i algorytm podpisu są obsługiwane przez wymaganych klientów;
czy urządzenie pośrednie nie obniża profilu na drugim odcinku;
czy klucze prywatne nie są współdzielone szerzej, niż wymaga architektura;
czy parametry są zarządzane jako kod lub baseline, a wyjątki mają właściciela i termin usunięcia.

Wynik „A” ze skanera publicznego jest użyteczny, ale nie obejmuje aplikacji mobilnej z wyłączoną walidacją, prywatnego API ani klienta, który ufa każdemu certyfikatowi. Dlatego audyt TLS powinien być częścią pentestu aplikacji webowej i testów API, a nie osobnym kolorowym raportem.

Walidacja nazwy: SAN, nie Common Name

RFC 9525 opisuje współczesną weryfikację tożsamości usług. Klient porównuje oczekiwaną tożsamość z odpowiednim identyfikatorem w rozszerzeniu Subject Alternative Name. Pole Common Name nie jest już prawidłowym źródłem identyfikacji hosta. Audyt powinien wykazać, co klient uważa za oczekiwaną nazwę i jak zachowuje się przy braku dopasowania.

Testy negatywne obejmują certyfikat:

dla innej nazwy DNS;
z wildcardem o szerszym lub innym poziomie niż host;
prawidłowy kryptograficznie, ale wydany przez niezaufane CA;
wygasły lub jeszcze nieważny;
z brakującym intermediate;
zawierający właściwy tekst tylko w CN, bez odpowiedniego SAN.

Każdy przypadek powinien kończyć się przerwaniem połączenia. Logowanie ostrzeżenia i kontynuowanie jest podatnością. Szczególnie często problem występuje w klientach API, webhookach, agentach aktualizacji i integracjach, gdzie deweloper tymczasowo wyłącza weryfikację, aby uruchomić środowisko testowe.

Adres IP, nazwa DNS i URI są różnymi typami identyfikatorów. Certyfikat z dNSName nie powinien automatycznie potwierdzać połączenia wykonanego do surowego adresu IP. W service mesh lub SPIFFE mogą występować identyfikatory URI; wówczas polityka musi sprawdzać właściwy typ SAN, a nie dowolny wpis.

Budowanie i walidacja ścieżki certyfikacji

RFC 5280 definiuje profil certyfikatów X.509 i algorytm walidacji ścieżki. Klient powinien zbudować łańcuch do skonfigurowanego trust anchor, sprawdzić podpisy, okres ważności, ograniczenia CA, name constraints, policy constraints oraz przeznaczenie klucza. Nie wystarczy znaleźć certyfikat z podobną nazwą wystawcy.

W prywatnym PKI najczęstsze problemy to:

root CA używany online do codziennego podpisywania;
ten sam intermediate dla serwerów, klientów, urządzeń i kodu;
brak Basic Constraints lub nieprawidłowe użycie CA;
nadmiernie szerokie Key Usage i Extended Key Usage;
brak name constraints w relacji z zewnętrznym lub przejętym sub-CA;
dystrybucja rootów przez niekontrolowane obrazy i skrypty;
brak inwentaryzacji certyfikatów i właścicieli usług.

Klucz root CA powinien być silnie chroniony i używany rzadko, a intermediate rozdzielone według ryzyka i przeznaczenia. Kompromitacja jednego profilu mTLS nie powinna umożliwiać wystawienia certyfikatu dla publicznej strony firmy.

Key Usage i Extended Key Usage

Rozszerzenia Key Usage oraz Extended Key Usage ograniczają zastosowanie certyfikatu. Certyfikat serwera powinien odpowiadać uwierzytelnianiu serwera, a certyfikat klienta — uwierzytelnianiu klienta. Jeśli walidator ignoruje EKU albo profil wydaje certyfikat o wielu przeznaczeniach, granice między tożsamościami się zacierają.

Podczas audytu utwórz macierz: profil certyfikatu, dozwolone SAN, issuer, EKU, czas życia, metoda odnowienia, magazyn klucza i zakres zaufania. Następnie przeprowadź test cross-purpose: czy certyfikat przeznaczony dla innego systemu lub roli zostanie przyjęty? Sam fakt podpisania przez firmowe CA nie powinien wystarczać.

mTLS: uwierzytelnienie nie jest autoryzacją

mTLS jest bardzo dobrym mechanizmem identyfikacji workloadów i klientów B2B, lecz łatwo zbudować z niego jedną ogromną strefę zaufania. Serwer musi zweryfikować łańcuch, okres ważności, przeznaczenie certyfikatu i oczekiwaną tożsamość. Dopiero potem aplikacja mapuje ją na uprawnienia.

Unikaj wspólnego certyfikatu dla całego klastra, zespołu lub floty. Kradzież jednego klucza utrudnia wtedy ustalenie źródła i wymaga wymiany na wszystkich hostach. Preferuj tożsamość per workload lub instancja, krótkie czasy życia i automatyczne odnowienie. Prywatny klucz powinien powstawać i pozostawać w chronionym magazynie, a nie podróżować w obrazie kontenera.

W OAuth 2.0 RFC 8705 opisuje mTLS do uwierzytelnienia klienta i certyfikatem związane tokeny dostępu. To drugi mechanizm niż „mTLS na load balancerze”. Jeśli proxy kończy TLS, backend musi otrzymać wiarygodną, integralnie chronioną informację o zweryfikowanej tożsamości. Nie wolno ufać nagłówkowi klienta o nazwie podobnej do X-Client-Cert, jeśli edge nie usuwa wartości wejściowej i nie dodaje własnej.

0-RTT i ryzyko replay

TLS 1.3 umożliwia early data (0-RTT) przy wznowieniu sesji. Zmniejsza opóźnienie, ale dane 0-RTT nie mają pełnych gwarancji ochrony przed replay. RFC 8446 wymaga, aby aplikacja brała to ryzyko pod uwagę. Operacje zmieniające stan — płatność, utworzenie konta, reset hasła, wysłanie wiadomości lub wdrożenie — nie powinny być bezrefleksyjnie wykonywane jako early data.

Audyt ustala, czy 0-RTT jest aktywne na CDN, proxy i serwerze, które metody i endpointy mogą je otrzymać oraz jaka jest strategia anty-replay. Najprostsza bezpieczna decyzja dla większości aplikacji biznesowych to wyłączenie early data, jeśli nie istnieje udokumentowana potrzeba wydajnościowa i mechanizm idempotencji.

Resumption, session tickets i rotacja kluczy

Wznowienie sesji poprawia wydajność, ale klucze chroniące session tickets stają się wrażliwym zasobem. RFC 9325 zaleca ich bezpieczne generowanie, przechowywanie i regularną rotację. W klastrze trzeba znaleźć równowagę między współdzieleniem klucza a ograniczeniem blast radius.

Zweryfikuj, czy rotacja nie unieważnia masowo połączeń w sposób powodujący awarię, ale też czy jeden skompromitowany klucz nie pozostaje aktywny bezterminowo. Klucze ticketów nie powinny znajdować się w logach, repozytorium ani niezaszyfrowanej konfiguracji obrazu.

Unieważnianie: CRL, OCSP i ograniczenia praktyczne

Certyfikat może wymagać unieważnienia przed datą wygaśnięcia z powodu utraty klucza, błędnego wydania lub zmiany właściciela. CRL i OCSP są mechanizmami PKI, lecz ich realne zachowanie zależy od klienta. RFC 9325 omawia ograniczenia sprawdzania statusu i OCSP stapling. Audyt musi sprawdzić nie tylko obecność URL, ale rzeczywiste zachowanie przy statusie revoked, timeoutie i niedostępności respondera.

W prywatnym mTLS krótkie czasy życia często ograniczają ryzyko lepiej niż mechanizm, którego klienci nie egzekwują, ale nie eliminują potrzeby reakcji. Organizacja musi potrafić zablokować tożsamość, usunąć trust, cofnąć uprawnienia i wymienić klucz. Fail-open może zachować dostępność, ale akceptować skompromitowany certyfikat; fail-closed poprawia bezpieczeństwo, lecz awaria respondera może zatrzymać usługę. Decyzję trzeba udokumentować na podstawie modelu ryzyka.

Zarządzanie cyklem życia certyfikatu

Bez automatyzacji certyfikaty zwykle wygasają w najgorszym możliwym momencie. ACME, opisane w RFC 8555, standaryzuje automatyczne uzyskiwanie i odnawianie certyfikatów. W prywatnym PKI analogiczny mechanizm powinien uwierzytelniać workload, ograniczać profil i zapisywać zdarzenia wydania.

Mierz i alarmuj na:

certyfikaty zbliżające się do wygaśnięcia;
nieudane odnowienia oraz wzrost liczby retry;
certyfikat wydany poza zatwierdzonym profilem;
zmianę issuera, SAN, EKU lub algorytmu;
nagły wzrost wydawania dla jednej tożsamości;
użycie certyfikatu po wycofaniu workloadu;
prywatny klucz wykryty w repozytorium, obrazie lub kopii zapasowej.

Inwentaryzacja powinna łączyć serial, fingerprint, issuer, subject/SAN, właściciela, usługę, środowisko, magazyn klucza i ścieżkę odnowienia. Sam arkusz bez danych z runtime szybko przestaje być wiarygodny.

Metodyka technicznego audytu TLS i PKI

1. Zdefiniuj powierzchnię

Zbierz domeny, adresy, porty, SNI, endpointy prywatne, ingressy, load balancery, service mesh, webhooki, brokerów i klientów mobilnych. Uwzględnij połączenia wychodzące — SSRF lub przejęte DNS może skierować klienta do serwera z innym certyfikatem, co pokazuje znaczenie poprawnej walidacji.

2. Zbadaj handshake

Zweryfikuj wersje, ALPN, cipher suites, grupy, podpisy, łańcuch, kolejność certyfikatów, stapling i resumption. Powtórz dla każdego SNI i odcinka architektury. Nie wykonuj agresywnych testów na produkcji bez limitu i uzgodnienia.

3. Wykonaj testy negatywne klienta

W kontrolowanym środowisku podstaw certyfikat dla złej nazwy, niezaufany issuer, brak intermediate, niewłaściwy EKU oraz certyfikat wygasły. Klient ma przerwać połączenie bez opcji cichego obejścia.

4. Przetestuj mTLS i autoryzację

Użyj certyfikatu prawidłowego, odwołanego, innego profilu i innej tożsamości. Sprawdź mapowanie na konto aplikacyjne, izolację tenantów oraz logowanie decyzji. Zweryfikuj, czy edge nie ufa nagłówkom dostarczonym przez klienta.

5. Oceń PKI i operacje

Przejrzyj ochronę CA, profile, role administratorów, approval, klucze HSM/KMS, kopie, disaster recovery, rotację intermediate i procedurę kompromitacji. Przećwicz odnowienie oraz wycofanie w środowisku testowym.

6. Powiąż z ryzykiem aplikacji

Nie opisuj wyłącznie „serwer akceptuje TLS 1.0”. Wykaż, czy dostępny jest chroniony endpoint, jakie dane przechodzą kanałem, czy atak wymaga pozycji MITM i czy klient faktycznie negocjuje słaby wariant. Priorytetyzuj razem z zarządzaniem podatnościami oraz modelowaniem zagrożeń.

Checklista dowodów do raportu

lista endpointów i warstw terminacji;
przechwycone parametry handshake bez prywatnych kluczy i danych użytkownika;
pełny łańcuch oraz wyniki walidacji SAN, EKU i ograniczeń CA;
wynik testów błędnego certyfikatu i zachowanie aplikacji;
macierz tożsamości mTLS do uprawnień;
dowód działania odnowienia, rotacji i odwołania;
właściciel każdego wyjątku oraz termin naprawy;
test regresyjny możliwy do uruchomienia w CI lub monitoringu.

Najczęstsze pytania

Czy TLS 1.3 wystarczy, aby uznać usługę za bezpieczną?

Nie. Nadal trzeba zweryfikować certyfikat, nazwę usługi, bibliotekę klienta, terminację na każdym odcinku, klucze i autoryzację aplikacji.

Czy mTLS zastępuje OAuth lub kontrolę dostępu?

Nie. mTLS może uwierzytelnić klienta lub związać token z certyfikatem, ale aplikacja nadal musi podjąć decyzję autoryzacyjną dla zasobu i operacji.

Czy wildcard certificate jest zawsze błędem?

Nie zawsze, lecz zwiększa zakres skutków kradzieży klucza i utrudnia segmentację. Oceń liczbę usług, magazyn klucza, automatyzację oraz możliwość użycia certyfikatów per usługa.

Czy skaner zewnętrzny zbada prywatne PKI?

Nie w pełni. Nie zobaczy klientów, połączeń backendowych, mapowania mTLS, ochrony CA ani procedury rotacji. Te elementy wymagają dostępu architektonicznego i kontrolowanych testów.

Audyt kryptografii powinien kończyć się testem regresyjnym

Raport jest wartościowy wtedy, gdy poprawkę da się stale egzekwować. Breachroad łączy analizę TLS i PKI z przygotowaniem organizacji do pentestu, testami aplikacji oraz przeglądem chmury. Wynikiem jest uporządkowana lista ryzyk i kontrole, które można przenieść do IaC, CI oraz monitoringu certyfikatów.