HTTPS-konfigurationsrevision

Indsæt svar-headerne fra et websted — og, hvis man har dem, dets certifikat, et uddrag af sidekilden og værtsnavnet — og denne side rapporterer, hvordan HTTPS-delen er konfigureret: om HSTS er sat, og i hvor lang tid; om en content security policy opgraderer usikre forespørgsler; om cookies er markeret Secure og SameSite; om en serverbanner afslører en version; og hvad proxy-headers siger om den forespørgsel, programmet faktisk så. Certifikatet revideres i samme rapport, almindelige http://-underressourcer tælles ud af sidekilden, og kommandoerne, der kan se håndtrykket, listes, så de kan køres af én selv. Alt kører i browseren, og siden laver ingen egne forespørgsler.
1. Response-headers
Hele response-headerblokken, inklusive statuslinjen. Nemmeste kilde: curl -sI https://example.com/ i en terminal, eller fanen Headers i Network-fanen i browserens udviklerværktøjer, kopieret fra toppen af filen. Ekstra headers læses og ignoreres; kun de HTTPS-relevante rapporteres.
2. Certifikat eller kæde (valgfrit)
Når dette er udfyldt, indeholder den samme rapport også den fulde certifikatrevision, så konfiguration og certifikat læses samlet. PEM, en ren base64- eller hexadecimal-krop og en PKCS#7-.p7b virker alle; certifikattjekkeren går i dybden med certifikatet alene.
3. Uddrag af sidekilde (valgfrit)
Indsæt sidekilden (eller blot tags med URL'er), og hver almindelig http://-adresse opføres, fordi en underressource indlæst over HTTP bryder hængelåsen og kan omskrives under transport, selv når siden selv kom over HTTPS. Adresser til webstedets egen vært fremhæves særskilt, da det er dem, en relativ URL ville rette.
4. Værtsnavn (valgfrit)
Med et værtsnavn her kontrollerer revisionen de alternative emnenavne, sådan som en browser gør, inklusive jokerreglerne, og matcher de almindelige http://-adresser mod det.
intet revideret endnu
Eksemplet er bevidst ufuldkomment, så hver del af rapporten har noget at vise: en header-blok med HSTS og en content security policy (men ingen preload og én cookie uden SameSite), en kæde med to certifikater og et sidestykke, der indlæser et script over almindelig http:// og peger et billede mod webstedets egen vært på samme måde. Forvent et F på eksemplet, og læs fundene nedenunder for at se, hvad hvert enkelt betyder.
Hvad der kontrolleres. Fra header-blokken: HSTS, dens max-age, includeSubDomains og preload; en content security policy, der opgraderer usikre forespørgsler; flagene Secure, HttpOnly og SameSite på hver Set-Cookie; en serverbanner, der nævner et produkt og en version; og de videresendte headers, der viser, om programmet så forespørgslen som HTTPS. Fra certifikatblokken: den fulde certifikatrevision, ned til om hvert led i kæden virkelig har signeret det næste. Fra sidekilden: de almindelige http://-underressourcer. De tre opgøres hver for sig og sammenfattes derefter, fordi en brudt hængelås typisk skyldes en af de tre og ikke de to andre. For den fulde OWASP-liste over sikkerhedssvar-headers — X-Content-Type-Options, indramningsbeskyttelse, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP og den bedømte score — indsæt den samme header-blok på siden Tjek af sikkerhedsheaders; de to sider deler arbejdet op efter TLS-laget og header-laget.

Hvad den ikke kan se. Denne side åbner aldrig en TLS-forbindelse. Browsere eksponerer ikke håndtrykket over for en side, så protokolversionen, chifferpakken, nøgleudvekslingsgruppen, OCSP-stapling, sessionsgenoptagelse, 0-RTT, certifikatkæden en kørende server faktisk sender, og om en HTTP-til-HTTPS-omdirigering sker på origin eller i en proxy, ligger alt sammen uden for det, enhver webside kan rapportere. Den kan heller ikke nå en tredjepartsside for at hente headers for brugeren, og den kan ikke sige, om et certifikat er betroet, fordi det afhænger af en rodbutik, en side ikke kan læse. Kommandoerne længere nede på siden ser disse ting, og de er beregnet til at blive kørt af brugeren selv på sin egen maskine.

Hvor man får header-blokken. I en terminal udskriver curl -sI https://example.com/ præcis det, denne side vil have. I en browser åbnes udviklerværktøjerne, gå til fanen Network, genindlæs siden, vælg dokumentanmodningen, og kopiér hele området Response Headers, eller brug Kopiér → Kopiér response headers. Til omdirigeringstjekket køres også curl -sI http://example.com/, og begge blokke indsættes; siden rapporterer dem efter hinanden.
Revisionsrapport
Intet revideret endnu. Indsæt en header-blok ovenfor, og tryk på Revidér denne konfiguration for den fulde rapport; et certifikat, et uddrag af sidekilden og et værtsnavn er valgfri, og hver tilføjer sin egen sektion.
Tilgængelighedsprøve — den eneste del af denne side, der bruger netværket
En side kan ikke åbne en TLS-forbindelse, men den kan prøve en almindelig forespørgsel. Tillader webstedet læsning på tværs af domæner, viser den URL, svaret ender ved, om http:// blev omdirigeret til https://, og det er alt, dette kan bevise. Fejler forespørgslen, kan siden ikke fortælle, om værten er nede, om ens egen forbindelse er nede, eller om webstedet blot ikke tillader læsning på tværs af domæner — det sidste er det almindelige tilfælde, fordi de fleste websteder ikke sender Access-Control-Allow-Origin. En http://-URL besvares før enhver omdirigering, så det er det ene her, en browser vil forsøge på en almindelig forbindelse. Intet forlader browseren, før knappen trykkes.
Kommandoer, der kan se håndtrykket
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
Disse er beregnet til at blive kørt af brugeren selv på en maskine, man kontrollerer, mod en vært, man har lov til at teste. Outputtet fra -showcerts kan indsættes direkte i certifikattjekkeren, og header-outputtet tilbage på denne side.
Certifikatet er et offentligt dokument. Ethvert offentligt betroet certifikat offentliggøres i Certificate Transparency-logs, så ethvert værtsnavn i et certifikat — inklusive et internt eller fejlstavet navn, som en offentlig certifikatudsteder har signeret — kan findes ved at søge i disse logs. Et certifikat bærer også de tilbagekaldelsesadresser, udstederen valgte, og de nævner nogle gange en intern vært. Derfor siger certifikatet, et CDN serverer, intet om origin-serveren: navnene i det hører til CDN'et. Hvis revisionen finder et værtsnavn, man ikke forventede, skal det behandles som offentligt, og det, det beskytter, skal udskiftes.

Privatliv: header-blokken, certifikatet og sidekilden læses lokalt og uploades aldrig, og der sendes ingen forespørgsel af nogen art, medmindre knappen i tilgængelighedsprøven trykkes. For at oprette et eget certifikat bruges generatoren for selvsignerede certifikater; for at kontrollere, at en privat nøgle hører til et certifikat, bruges certifikat- og nøglematcheren.