HTTPS-konfigurasjonsrevisjon

Lim inn svarheaderne til et nettsted — og, hvis tilgjengelig, sertifikatet, et utdrag av sidekilden og vertsnavnet — så rapporterer denne siden hvordan HTTPS-delen er konfigurert: om HSTS er satt og hvor lenge, om en innholdssikkerhetspolicy oppgraderer usikre forespørsler, om informasjonskapsler er merket Secure og SameSite, om en serverbanner avslører en versjon, og hva proxy-headerne sier om forespørselen applikasjonen faktisk så. Sertifikatet revideres i samme rapport, vanlige http://-underressurser telles ut av sidekilden, og kommandoene som kan se håndtrykket, listes for å kjøres lokalt. Alt kjøres i nettleseren, og siden gjør ingen egne forespørsler.
1. Svarheadere
Hele svarheaderblokken, inkludert statuslinjen. Enkleste kilde: curl -sI https://example.com/ i en terminal, eller Headers-panelet i Nettverk-fanen i nettleserens utviklerverktøy, kopiert fra toppen av filen. Ekstra headere leses og ignoreres; bare de som er relevante for HTTPS, rapporteres.
2. Sertifikat eller kjede (valgfritt)
Når dette er fylt ut, inneholder den samme rapporten også den fulle sertifikatrevisjonen, slik at konfigurasjon og sertifikat leses sammen. PEM, en ren base64- eller heksadesimal kropp og en PKCS#7 .p7b fungerer alle; sertifikatsjekken går dypere inn i sertifikatet alene.
3. Utdrag av sidekilde (valgfritt)
Lim inn sidekilden (eller bare taggene med nettadresser), så listes hver vanlige http://-adresse, for en underressurs lastet over HTTP bryter hengelåsen og kan skrives om underveis, selv når selve siden kom over HTTPS. Adresser til nettstedets egen vert merkes separat, siden det er dem en relativ nettadresse ville rettet.
4. Vertsnavn (valgfritt)
Med et vertsnavn her sjekker revisjonen de alternative emnenavnene slik en nettleser gjør, inkludert jokerreglene, og matcher de vanlige http://-adressene mot dem.
ingen revidert ennå
Eksempelet er bevisst ufullkomment, slik at hver del av rapporten har noe i seg: en headerblokk med HSTS og en innholdssikkerhetspolicy (men uten preload og med én informasjonskapsel uten SameSite), en kjede med to sertifikater, og et sideutdrag som laster et skript over vanlig http:// og peker et bilde mot nettstedets egen vert på samme måte. Forvent en F på eksempelet, og les funnene under for å se hva hvert av dem betyr.
Hva sjekkes. Fra headerblokken: HSTS, max-age, includeSubDomains og preload; en innholdssikkerhetspolicy som oppgraderer usikre forespørsler; flaggene Secure, HttpOnly og SameSite på hver Set-Cookie; en serverbanner som navngir et produkt og en versjon; og de videresendte headerne som viser om applikasjonen så forespørselen som HTTPS. Fra sertifikatblokken: den fullstendige sertifikatrevisjonen, helt ned til om hver lenke i kjeden faktisk signerte den neste. Fra sidekilden: underressursene med vanlig http://. De tre rapporteres hver for seg og oppsummeres deretter sammen, fordi en brutt hengelås vanligvis skyldes én av de tre og ikke de to andre. For hele OWASP-listen over sikkerhetsresponsheadere — X-Content-Type-Options, rammebeskyttelse, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP og den graderte poengsummen — lim samme headerblokk inn på siden Sjekk av sikkerhetsheadere; de to sidene deler arbeidet langs TLS-laget og header-laget.

Hva den ikke ser. Denne siden åpner aldri en TLS-forbindelse. Nettlesere eksponerer ikke håndtrykket for en side, så protokollversjonen, chifferpakken, nøkkelutvekslingsgruppen, OCSP-stapling, sesjonsgjenopptakelse, 0-RTT, sertifikatkjeden en kjørende server faktisk sender, og om en HTTP-til-HTTPS-viderekobling skjer på opprinnelsesserveren eller i en proxy, er alt utenfor det en nettside kan rapportere. Den kan heller ikke nå en tredjepartsside for å hente headerne, og den kan ikke si om et sertifikat er klarert, fordi det avhenger av et rotlager en side ikke kan lese. Kommandoene lenger ned på siden ser disse tingene, og de er ment å kjøres på egen maskin.

Hvor headerblokken hentes. I en terminal skriver curl -sI https://example.com/ nøyaktig det denne siden ønsker. I en nettleser åpnes utviklerverktøyene, Nettverk-fanen velges, siden lastes inn på nytt, dokumentforespørselen velges, og hele området Response Headers kopieres, eller Kopier → Kopier responsheadere brukes. For viderekoblingssjekken kjøres også curl -sI http://example.com/, og begge blokkene limes inn; siden rapporterer dem etter hverandre.
Revisjonsrapport
Ingenting revidert ennå. Lim inn en headerblokk over og trykk Revider denne konfigurasjonen for den fulle rapporten; et sertifikat, et sideutdrag og et vertsnavn er valgfrie, og hver av dem legger til sin egen seksjon.
Tilgjengelighetsprobe — den eneste delen av denne siden som bruker nettverket
En side kan ikke åpne en TLS-forbindelse, men den kan prøve en vanlig forespørsel. Hvis nettstedet tillater lesing på tvers av opphav, viser adressen responsen ender på om http:// ble viderekoblet til https://, og det er alt dette kan bevise. Hvis forespørselen mislykkes, kan ikke denne siden si om vertsnavnet er nede, om den egne forbindelsen er nede, eller om nettstedet rett og slett ikke tillater lesing på tvers av opphav — det siste er det vanlige tilfellet, fordi de fleste nettsteder ikke sender Access-Control-Allow-Origin. En http://-adresse besvares før noen viderekobling, så dette er det eneste her som en nettleser vil forsøke over en vanlig forbindelse. Ingenting forlater nettleseren før knappen trykkes.
Kommandoer som faktisk ser 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 ment å kjøres lokalt, på en maskin man kontrollerer, mot en vert man har lov til å teste. -showcerts-utdataene kan limes rett inn i sertifikatsjekken, og header-utdataene tilbake på denne siden.
Sertifikatet er et offentlig dokument. Hvert offentlig klarert sertifikat publiseres i Certificate Transparency-logger, så et hvilket som helst vertsnavn i ett — også et internt eller feilskrevet navn som en offentlig sertifiseringsinstans signerte — kan finnes ved å søke i disse loggene. Et sertifikat bærer også de tilbakekallingsadressene utstederen valgte, og de navngir noen ganger en intern vert. Derfor sier sertifikatet et CDN serverer, ingenting om opprinnelsesserveren: navnene i det tilhører CDN-en. Hvis revisjonen finner et vertsnavn man ikke ventet, behandles det som offentlig, og det som beskyttes, erstattes.

Personvern: headerblokken, sertifikatet og sidekilden leses lokalt og lastes aldri opp, og ingen forespørsel av noe slag sendes med mindre knappen i tilgjengelighetsproben trykkes. For å lage et eget sertifikat, bruk generatoren for selvsignerte sertifikater; for å sjekke at en privat nøkkel tilhører et sertifikat, bruk sertifikat- og nøkkelmatcheren.