Audyt konfiguracji HTTPS

Wklej nagłówki odpowiedzi strony — a jeśli są dostępne, jej certyfikat, fragment kodu źródłowego strony i nazwę hosta — a ta strona zgłosi, jak skonfigurowana jest część HTTPS: czy HSTS jest ustawiony i na jak długo, czy polityka bezpieczeństwa treści podnosi niezabezpieczone żądania, czy ciasteczka mają flagi Secure i SameSite, czy baner serwera zdradza wersję oraz co mówią nagłówki proxy o żądaniu, które aplikacja faktycznie widziała. Certyfikat jest audytowany w tym samym raporcie, zwykłe zasoby podrzędne http:// są liczone z kodu źródłowego strony, a polecenia, które widzą uzgadnianie, są wypisane, abyś uruchomił je sam. Wszystko działa w przeglądarce, a strona nie wykonuje własnych żądań.
1. Nagłówki odpowiedzi
Pełny blok nagłówków odpowiedzi, wraz z wierszem statusu. Najłatwiejsze źródło: curl -sI https://example.com/ w terminalu albo panel Nagłówki w karcie Sieć narzędzi deweloperskich przeglądarki, skopiowany z góry. Dodatkowe nagłówki są odczytywane i ignorowane; zgłaszane są tylko te istotne dla HTTPS.
2. Certyfikat lub łańcuch (opcjonalnie)
Gdy to pole jest wypełnione, ten sam raport zawiera też pełny audyt certyfikatu, dzięki czemu konfigurację i certyfikat czyta się razem. Działają PEM, goła treść base64 lub szesnastkowa oraz .p7b PKCS#7; sprawdzacz certyfikatów wchodzi w certyfikat samodzielnie, z większą głębią.
3. Fragment kodu źródłowego strony (opcjonalnie)
Wklej kod źródłowy strony (albo same znaczniki z adresami URL), a każdy zwykły adres http:// zostanie wypisany, bo zasób ładowany przez HTTP psuje kłódkę i może zostać przepisany w tranzycie, nawet gdy sama strona przyszła przez HTTPS. Adresy wskazujące na własny host witryny są wyróżnione osobno, bo to je naprawiłby względny URL.
4. Nazwa hosta (opcjonalnie)
Gdy tutaj zostanie podana nazwa hosta, audyt sprawdza alternatywne nazwy podmiotu tak, jak robi to przeglądarka, łącznie z regułami symboli wieloznacznych, i porównuje z nią zwykłe adresy http://.
nic jeszcze nie audytowano
Przykład celowo jest niedoskonały, żeby każda część raportu miała w czym szukać: blok nagłówków z HSTS i polityką bezpieczeństwa treści (ale bez preload i z jednym ciasteczkiem bez SameSite), łańcuch dwóch certyfikatów oraz fragment strony ładujący skrypt przez zwykłe http:// i wskazujący obrazek na własny host w ten sam sposób. Spodziewaj się oceny F na przykładzie i przeczytaj ustalenia pod spodem, aby zobaczyć, co oznacza każde z nich.
Co jest sprawdzane. Z bloku nagłówków: HSTS, jego max-age, includeSubDomains i preload; polityka bezpieczeństwa treści, która podnosi niezabezpieczone żądania; flagi Secure, HttpOnly i SameSite przy każdym Set-Cookie; baner serwera, który podaje produkt i wersję; oraz przekazywane nagłówki, które mówią, czy aplikacja widziała żądanie jako HTTPS. Z bloku certyfikatu: pełny audyt certyfikatu, aż do tego, czy każde ogniwo łańcucha rzeczywiście podpisało następne. Z kodu źródłowego strony: zasoby podrzędne przez zwykłe http://. Te trzy są raportowane osobno, a potem podsumowane razem, bo zepsuta kłódka zwykle wynika z jednego z nich, a nie z dwóch pozostałych. Pełną listę OWASP nagłówków bezpieczeństwa odpowiedzi — X-Content-Type-Options, ochronę przed osadzaniem w ramce, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP oraz ocenę punktową — uzyskuje się, wklejając ten sam blok nagłówków na stronę Sprawdzanie nagłówków bezpieczeństwa; obie strony dzielą pracę na warstwę TLS i warstwę nagłówków.

Czego nie widzi. Ta strona nigdy nie otwiera połączenia TLS. Przeglądarki nie udostępniają stronie uzgadniania, więc wersja protokołu, zestaw szyfrów, grupa wymiany kluczy, OCSP stapling, wznawianie sesji, 0-RTT, łańcuch certyfikatów, który faktycznie wysyła działający serwer, oraz to, czy przekierowanie HTTP na HTTPS następuje na źródle, czy na proxy, leżą poza tym, co jakakolwiek strona może zgłosić. Nie dotrze też do strony trzeciej, żeby zebrać nagłówki, i nie powie, czy certyfikat jest zaufany, bo to zależy od magazynu roota, którego strona nie może odczytać. Polecenia opisane niżej widzą te rzeczy i są przeznaczone do uruchomienia na własnej maszynie.

Skąd wziąć blok nagłówków. W terminalu curl -sI https://example.com/ wypisuje dokładnie to, czego chce ta strona. W przeglądarce otwórz narzędzia deweloperskie, przejdź do karty Sieć, przeładuj stronę, zaznacz żądanie dokumentu i skopiuj cały obszar Nagłówki odpowiedzi, albo użyj Kopiuj → Kopiuj nagłówki odpowiedzi. Do sprawdzenia przekierowania uruchom też curl -sI http://example.com/ i wklej oba bloki — strona zgłasza je jeden po drugim.
Raport audytu
Nic jeszcze nie audytowano. Wklej blok nagłówków powyżej i naciśnij Audytuj tę konfigurację, aby uzyskać pełny raport; certyfikat, fragment kodu źródłowego strony i nazwa hosta są opcjonalne, a każdy dodaje własną sekcję.
Sonda osiągalności — jedyna część tej strony, która korzysta z sieci
Strona nie może otworzyć połączenia TLS, ale może wykonać zwykłe żądanie. Jeśli witryna dopuszcza odczyty między domenami, adres, pod który ostatecznie trafia odpowiedź, pokazuje, czy http:// został przekierowany na https:// — i to wszystko, co to może udowodnić. Jeśli żądanie się nie powiedzie, strona nie powie, czy host leży, czy połączenie z siecią nie działa, czy witryna po prostu nie dopuszcza odczytów między domenami — ten ostatni przypadek jest częsty, bo większość stron nie wysyła Access-Control-Allow-Origin. Adres http:// jest obsługiwany przed jakimkolwiek przekierowaniem, więc to jedyna rzecz tutaj, którą przeglądarka spróbuje wykonać na zwykłym połączeniu. Nic nie opuszcza przeglądarki, dopóki nie zostanie naciśnięty przycisk.
Polecenia, które widzą uzgadnianie
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
Mają być uruchamiane na maszynie kontrolowanej przez użytkownika, przeciwko hostowi, który wolno testować. Wynik -showcerts można wkleić wprost do sprawdzacza certyfikatów, a wynik nagłówków z powrotem na tę stronę.
Certyfikat jest dokumentem publicznym. Każdy publicznie zaufany certyfikat jest publikowany w dziennikach Certificate Transparency, więc każdą nazwę hosta w nim — także wewnętrzną lub przepisaną z błędem, którą publiczny urząd certyfikacji podpisał — można znaleźć, przeszukując te dzienniki. Certyfikat niesie też adresy unieważnień wybrane przez wystawcę, a te czasem wskazują wewnętrzny host. Dlatego certyfikat, który serwuje CDN, nic nie mówi o serwerze źródłowym: nazwy w nim należą do CDN. Jeśli audyt ujawni nazwę hosta, której się nie oczekuje, traktuj ją jako publiczną i wymień to, co chroni.

Prywatność: blok nagłówków, certyfikat i kod źródłowy strony są odczytywane lokalnie i nigdy nie są wysyłane, a żadne żądanie nie jest wykonywane, dopóki nie zostanie naciśnięty przycisk w sondzie osiągalności. Aby utworzyć własny certyfikat, użyj generatora certyfikatów z podpisem własnym; aby sprawdzić, czy klucz prywatny należy do certyfikatu, użyj dopasowania certyfikatu i klucza.