HTTPS-configuratieaudit

Plak de responseheaders van een site — en, als u die heeft, het certificaat, een fragment van de paginabron en de hostnaam — en deze pagina rapporteert hoe de HTTPS-kant is ingericht: of HSTS is ingesteld en hoe lang, of een content security policy onveilige verzoeken upgradet, of cookies als Secure en SameSite zijn gemarkeerd, of een serverbanner een versie prijsgeeft, en wat de proxyheaders zeggen over het verzoek dat de applicatie werkelijk zag. Het certificaat wordt in hetzelfde rapport gecontroleerd, gewone http://-subresources worden uit de paginabron geteld, en de opdrachten die de handshake kunnen zien, staan voor u vermeld om zelf uit te voeren. Alles draait in uw browser en de pagina doet zelf geen enkel verzoek.
1. Responseheaders
Het volledige responseheaderblok, inclusief de statusregel. De eenvoudigste bron: curl -sI https://example.com/ in een terminal, of het paneel Headers op het tabblad Netwerk van de ontwikkelaarstools van de browser, gekopieerd vanaf de bovenkant van het bestand. Extra headers worden gelezen en genegeerd; alleen de HTTPS-relevante worden gerapporteerd.
2. Certificaat of keten (optioneel)
Met dit ingevuld draagt hetzelfde rapport ook de volledige certificaatcontrole, zodat configuratie en certificaat samen worden gelezen. PEM, een kaal base64- of hexadecimaal lichaam en een PKCS#7 .p7b werken allemaal; de certificaatcontrole gaat op zichzelf dieper op het certificaat in.
3. Fragment van de paginabron (optioneel)
Plak de paginabron (of alleen de tags met URL's) en elk gewoon http://-adres wordt weergegeven, omdat een subresource die via HTTP wordt geladen het hangslot breekt en onderweg kan worden herschreven, ook wanneer de pagina zelf via HTTPS is binnengekomen. Adressen naar de eigen host van de site worden apart aangegeven, omdat dat de adressen zijn die een relatieve URL zou oplossen.
4. Hostnaam (optioneel)
Met een hostnaam hier controleert de audit de subject alternative names zoals een browser dat doet, inclusief de jokerregels, en vergelijkt de gewone http://-adressen daarmee.
nog niets gecontroleerd
Het voorbeeld is bewust niet perfect, zodat elk onderdeel van het rapport iets bevat: een headerblok met HSTS en een content security policy (maar zonder preload en met één cookie zonder SameSite), een keten van twee certificaten, en een paginafragment dat een script via gewoon http:// laadt en een afbeelding op dezelfde manier naar de eigen host van de site laat verwijzen. Verwacht een F bij het voorbeeld en lees de bevindingen eronder om te zien wat elk betekent.
Wat wordt gecontroleerd. Uit het headerblok: HSTS, de max-age, includeSubDomains en preload; een content security policy die onveilige verzoeken upgradet; de vlaggen Secure, HttpOnly en SameSite op elke Set-Cookie; een serverbanner die een product en een versie noemt; en de doorgestuurde headers die aangeven of de applicatie het verzoek als HTTPS zag. Uit het certificaatblok: de volledige certificaatcontrole, tot en met de vraag of elke schakel in de keten werkelijk de volgende heeft ondertekend. Uit de paginabron: de gewone http://-subresources. De drie worden apart gerapporteerd en daarna samen samengevat, omdat een gebroken hangslot meestal één van die drie is en niet de andere twee. Voor de volledige OWASP-lijst van beveiligingsresponseheaders — X-Content-Type-Options, framebescherming, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP en het cijfer — plakt u hetzelfde headerblok in de controle van beveiligingsheaders; de twee pagina's verdelen het werk over de TLS-laag en de headerlaag.

Wat het niet kan zien. Deze pagina opent nooit een TLS-verbinding. Browsers tonen de handshake niet aan een pagina, dus de protocolversie, de cijfersuite, de sleuteluitwisselingsgroep, OCSP-stapling, sessiehervatting, 0-RTT, de certificaatketen die een live server werkelijk stuurt, en of een HTTP-naar-HTTPS-omleiding bij de oorsprong of bij een proxy gebeurt, vallen buiten wat een webpagina kan rapporteren. Ze kan ook geen externe site benaderen om de headers voor u te verzamelen, en ze kan niet zeggen of een certificaat vertrouwd is, omdat dat afhangt van een root-store die een pagina niet kan lezen. De opdrachten verderop op deze pagina zien die dingen wel, en ze zijn bedoeld om door u op uw eigen machine te worden uitgevoerd.

Waar u het headerblok vandaan haalt. In een terminal drukt curl -sI https://example.com/ precies af wat deze pagina wil. In een browser opent u de ontwikkelaarstools, gaat u naar het tabblad Netwerk, laadt u de pagina opnieuw, selecteert u het documentverzoek en kopieert u het hele gebied Response Headers, of gebruikt u Kopiëren → Responseheaders kopiëren. Voor de omleidingscontrole voert u ook curl -sI http://example.com/ uit en plakt u beide blokken; de pagina rapporteert ze na elkaar.
Auditrapport
Nog niets gecontroleerd. Plak hierboven een headerblok en druk op Deze configuratie controleren voor het volledige rapport; een certificaat, een fragment van de paginabron en een hostnaam zijn optioneel en voegen elk een eigen sectie toe.
Bereikbaarheidstest — het enige deel van deze pagina dat het netwerk gebruikt
Een pagina kan geen TLS-verbinding openen, maar kan wel een gewoon verzoek proberen. Als de site cross-origin-lezen toestaat, laat de URL waarnaar de respons uiteindelijk verwijst zien of http:// naar https:// is omgeleid, en meer kan dit ook niet aantonen. Als het verzoek mislukt, kan deze pagina niet zeggen of de host uitligt, uw eigen verbinding uitligt, of de site simpelweg geen cross-origin-lezen toestaat — dat laatste is het gebruikelijke geval, omdat de meeste sites geen Access-Control-Allow-Origin sturen. Een http://-URL wordt beantwoord vóór elke omleiding, dus dit is het enige hier waarvan een browser over een gewone verbinding een poging doet. Er verlaat niets de browser voordat u op de knop drukt.
Opdrachten die de handshake wel zien
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
Deze moet u zelf uitvoeren, op een machine die u beheert, tegen een host die u mag testen. De uitvoer van -showcerts kan rechtstreeks in de certificaatcontrole worden geplakt, en de headeruitvoer terug in deze pagina.
Het certificaat is een openbaar document. Elk publiek vertrouwd certificaat wordt gepubliceerd in logs van Certificate Transparency, dus elke hostnaam erin — ook een interne of verkeerd getypte naam die een publieke certificeringsinstantie heeft ondertekend — kan worden gevonden door die logs te doorzoeken. Een certificaat draagt ook de intrekkingsadressen die de uitgever heeft gekozen, en die noemen soms een interne host. Daarom zegt het certificaat dat een CDN aanbiedt niets over de oorspronkelijke server: de namen erin horen bij de CDN. Als de audit een hostnaam oplevert die u niet verwachtte, behandel die dan als openbaar en vervang wat hij beschermt.

Privacy: het headerblok, het certificaat en de paginabron worden lokaal gelezen en nooit geüpload, en er wordt geen enkel verzoek gedaan tenzij u op de knop van de bereikbaarheidstest drukt. Wilt u een eigen certificaat maken, gebruik dan de generator voor zelfondertekende certificaten; om te controleren of een privésleutel bij een certificaat hoort, gebruikt u de certificaat- en sleutelkoppelaar.