Audyt konfiguracji HTTPS / TLS
Skoncentrowany audyt tego, jak Twój endpoint negocjuje TLS i serwuje HTTPS — dla zespołów, którym nie wystarcza plakietka „A+”. Testujemy wersje protokołów, dobór szyfrów i forward secrecy, cały łańcuch certyfikatów i unieważnianie, HSTS/preload, mixed content oraz nagłówki bezpieczeństwa, a następnie przekazujemy uporządkowaną listę poprawek zgodną z bazami Mozilla i NIST.
Co testujemy
Enumeracja wersji protokołów
Sprawdzamy obsługę SSLv2/SSLv3/TLS1.0/1.1/1.2/1.3 i oznaczamy każdą negocjację TLS 1.0/1.1 lub SSL, które są wycofane (RFC 8996) i niedozwolone przez PCI DSS oraz NIST SP 800-52r2.
Zestawy szyfrów i forward secrecy
Enumerujemy oferowane zestawy per protokół, weryfikujemy wymianę kluczy ECDHE/DHE dla forward secrecy oraz oznaczamy RC4, 3DES, starsze tryby CBC, NULL, EXPORT i szyfry anonimowe, a także słabe parametry DH (<2048 bitów).
Łańcuch i ważność certyfikatu
Walidujemy certyfikat końcowy, pośrednie i kolejność łańcucha, długość klucza i algorytm podpisu (oznaczając SHA-1 i RSA <2048), okno ważności, zgodność SAN/hosta oraz przypadki self-signed lub niezaufanego roota.
Unieważnianie: OCSP i stapling
Sprawdzamy dostępność respondera OCSP, OCSP stapling i must-staple oraz dostępność CRL — tak aby unieważniony certyfikat był faktycznie odrzucany, a nie po cichu zaufany.
HSTS i preload
Weryfikujemy obecność Strict-Transport-Security, max-age co najmniej rok, includeSubDomains oraz kwalifikację do preload i potwierdzamy, że nagłówek jest serwowany wyłącznie po HTTPS, zgodnie ze specyfikacją.
Utwardzanie przekierowań i mixed content
Potwierdzamy, że HTTP trwale przekierowuje na HTTPS przed jakąkolwiek wrażliwą odpowiedzią, oraz skanujemy strony pod kątem aktywnego/pasywnego mixed content (skrypty, style, obrazy przez http://) łamiącego granicę zaufania.
Ekspozycja na znane ataki TLS
Testujemy BEAST, POODLE, Heartbleed (CVE-2014-0160), ROBOT, CRIME/BREACH, Sweet32, LOGJAM, FREAK i błędy renegocjacji przy użyciu bezpiecznej detekcji klasy testssl — bez eksploatacji żywych danych.
Nagłówki bezpieczeństwa odpowiedzi
Przeglądamy CSP (w tym upgrade-insecure-requests), X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy i Permissions-Policy pod kątem luk osłabiających warstwę transportową.
Metodologia
- 1
Zakres i rozpoznanie
Potwierdzamy autoryzację oraz hosty/porty w zakresie, a następnie enumerujemy każdy endpoint terminujący TLS — apex, www, subdomeny API, load balancery i krawędzie CDN — bo konfiguracja często się między nimi rozjeżdża.
- 2
Automatyczny skan bazowy
Uruchamiamy narzędzia klasy testssl.sh oraz kontrole w stylu Mozilla Observatory na każdym endpoincie, aby zebrać protokoły, kolejność szyfrów, dane certyfikatów i nagłówki jako powtarzalny dowód.
- 3
Weryfikacja manualna
Ręcznie potwierdzamy ustalenia — negocjując konkretne zestawy, przechodząc łańcuch, sprawdzając stapling — aby wyeliminować fałszywe alarmy skanera, zanim trafią do raportu.
- 4
Mapowanie do baz i ocena
Każde ustalenie oceniamy względem Mozilla Intermediate/Modern i NIST SP 800-52r2, z CVSS tam gdzie dotyczy CVE, tak aby waga odzwierciedlała realny standard, a nie ocenę literową narzędzia.
- 5
Raport i wskazówki naprawcze
Otrzymujesz priorytetyzowany raport z dokładnymi poprawkami — ciągi szyfrów, dyrektywy HSTS, naprawa łańcucha — oraz gotową konfigurację dla nginx/Apache/HAProxy lub Twojego CDN.
- 6
Retest i weryfikacja
Po wdrożeniu poprawek ponownie skanujemy zmienione endpointy i wydajemy zaktualizowaną atestację potwierdzającą spełnienie bazy — w ramach okna retestu.
Standardy i odniesienia
Co otrzymujesz
- Streszczenie zarządcze — Jednostronicowy przegląd ryzyka z aktualną postawą wg Mozilla/NIST i wskazaniem kilku zmian o największym wpływie — dla kierownictwa i audytorów.
- Raport techniczny — Szczegóły per endpoint: protokoły, pełna lista szyfrów, łańcuch certyfikatów, nagłówki, każde ustalenie z wagą, dowodem i krokami odtworzenia.
- Gotowa remediacja — Utwardzone fragmenty konfiguracji dla nginx/Apache/HAProxy/CDN — ciągi szyfrów, tylko TLS 1.2+, OCSP stapling, HSTS i wskazówki zgłoszenia do preload.
- Atestacja po retescie — Podpisany dokument weryfikacji po poprawkach potwierdzający spełnienie uzgodnionej bazy — do użytku w zgodności i przeglądach bezpieczeństwa klientów.
FAQ
Ile trwa audyt TLS i ile kosztuje?+
Pojedynczy host zwykle kończymy w 1–2 dni robocze; zestaw powiązanych endpointów (apex, www, kilka subdomen API) w 3–5. Cena jest stała dla danego zakresu i zależy od liczby endpointów terminujących TLS, więc znasz koszt przed startem, zamiast płacić za godziny.
Czego potrzebujecie od nas na start?+
Wystarczą hosty/adresy IP i porty w zakresie oraz pisemna autoryzacja od właściciela domeny lub infrastruktury. Audyt wykonujemy na publicznym endpoincie TLS, więc nie jest potrzebny kod źródłowy, poświadczenia ani instalacja agentów — choć informacja o CDN i WAF przed usługą pomaga nam przetestować każdą warstwę dokładnie.
Czy to bezpieczne dla środowiska produkcyjnego?+
Tak. Kontrole to sondy konfiguracji i negocjacji oraz bezpieczna, nieniszcząca detekcja podatności (klasy testssl). Nie eksploatujemy ustaleń, nie wykradamy danych i nie generujemy istotnego obciążenia. Testy Heartbleed i podobne używają łagodnej detekcji, która nie czyta pamięci ani nie uszkadza usługi.
Czy retest po naprawie jest w cenie?+
Tak. Jeden retest naprawionych endpointów jest wliczony w zdefiniowanym oknie (zwykle 30 dni) i kończy się zaktualizowaną atestacją. Jeśli potrzebujesz ciągłego pokrycia przy rotacji certyfikatów i dryfie konfiguracji, oferujemy też monitoring cykliczny.
Czy dostanę tylko ocenę z SSL Labs?+
Nie. Oceny literowe ukrywają realne ryzyko — strona może mieć „A”, a wciąż nie mieć HSTS preload, staplingu czy poprawnego łańcucha. Każde ustalenie mapujemy do Mozilla i NIST SP 800-52r2 i priorytetyzujemy według rzeczywistego wpływu, z dokładnymi poprawkami zamiast plakietki.
Czy sprawdzacie też nagłówki bezpieczeństwa HTTP?+
Tak. Bezpieczeństwo transportu jest osłabione, gdy warstwa odpowiedzi jest słaba, dlatego przeglądamy HSTS, CSP (w tym upgrade-insecure-requests), X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy i Permissions-Policy oraz oznaczamy mixed content łamiący granicę zaufania HTTPS.