HTTPS-Konfigurationsaudit

Fügen Sie die Antwort-Header einer Website ein — und, falls vorhanden, ihr Zertifikat, einen Ausschnitt des Seitenquelltexts und den Hostnamen — und diese Seite meldet, wie die HTTPS-Seite konfiguriert ist: ob HSTS gesetzt ist und wie lange, ob eine Content Security Policy unsichere Anfragen hochstuft, ob Cookies mit Secure und SameSite markiert sind, ob ein Server-Banner eine Version verrät und was die Proxy-Header über die Anfrage aussagen, die die Anwendung tatsächlich sah. Das Zertifikat wird im selben Bericht geprüft, einfache http://-Teilressourcen werden aus dem Seitenquelltext gezählt, und die Befehle, die den Handshake sehen können, werden zum Selbst-Ausführen aufgelistet. Alles läuft in Ihrem Browser, und die Seite stellt selbst keine Anfrage.
1. Antwort-Header
Der gesamte Antwort-Header-Block, einschließlich der Statuszeile. Die einfachste Quelle: curl -sI https://example.com/ in einem Terminal oder der Header-Bereich des Netzwerk-Reiters in den Browser-Entwicklertools, oben in der Datei kopiert. Zusätzliche Header werden gelesen und ignoriert; gemeldet werden nur die HTTPS-relevanten.
2. Zertifikat oder Kette (optional)
Wenn dies ausgefüllt ist, enthält derselbe Bericht auch das vollständige Zertifikatsaudit, sodass Konfiguration und Zertifikat gemeinsam gelesen werden. PEM, ein nackter Base64- oder Hexadezimal-Körper und eine PKCS#7-Datei .p7b funktionieren alle. Der Zertifikatprüfer geht das Zertifikat allein ausführlicher durch.
3. Seitenquelltext-Ausschnitt (optional)
Fügen Sie den Seitenquelltext (oder nur die Tags mit URLs) ein, und jede einfache http://-Adresse wird aufgelistet. Ein über HTTP geladenes Teil bricht das Schloss-Symbol und kann auf dem Übertragungsweg umgeschrieben werden, selbst wenn die Seite selbst über HTTPS kam. Adressen auf den eigenen Host der Website werden gesondert hervorgehoben, da relative URLs genau diese beheben würden.
4. Hostname (optional)
Mit einem Hostnamen hier prüft das Audit die Subject Alternative Names so, wie es ein Browser tut, einschließlich der Wildcard-Regeln, und gleicht die einfachen http://-Adressen damit ab.
noch nichts geprüft
Das Beispiel ist bewusst unvollkommen, damit jeder Teil des Berichts etwas enthält: ein Header-Block mit HSTS und einer Content Security Policy (aber ohne Preload und mit einem Cookie ohne SameSite), eine Zertifikatskette aus zwei Zertifikaten und ein Seitenausschnitt, der ein Skript über einfaches http:// lädt und ein Bild auf den eigenen Host der Website verweisen lässt. Erwarten Sie für das Beispiel ein F und lesen Sie die Befunde darunter, um zu sehen, was jeder bedeutet.
Was geprüft wird. Aus dem Header-Block: HSTS, dessen max-age, includeSubDomains und preload; eine Content Security Policy, die unsichere Anfragen hochstuft; die Flags Secure, HttpOnly und SameSite auf jedem Set-Cookie; ein Server-Banner, der ein Produkt und eine Version nennt; und die weitergeleiteten Header, die verraten, ob die Anwendung die Anfrage als HTTPS erkannt hat. Aus dem Zertifikatsblock: das vollständige Zertifikatsaudit bis hin zur Frage, ob jedes Glied der Kette tatsächlich das nächste signiert hat. Aus dem Seitenquelltext: die einfachen http://-Teilressourcen. Die drei werden getrennt gemeldet und dann gemeinsam zusammengefasst, weil ein gebrochenes Schloss-Symbol meist auf eines dieser drei zurückgeht und nicht auf die beiden anderen. Für die vollständige OWASP-Liste der Sicherheits-Response-Header — X-Content-Type-Options, Frame-Schutz, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP und die bewertete Punktzahl — fügen Sie denselben Header-Block in die Security-Headers-Prüfung ein. Die beiden Seiten teilen die Arbeit entlang der TLS-Schicht und der Header-Schicht auf.

Was es nicht sehen kann. Diese Seite öffnet nie eine TLS-Verbindung. Browser legen den Handshake einer Seite nicht offen, daher liegen die Protokollversion, die Cipher-Suite, die Schlüsselaustauschgruppe, das OCSP-Stapling, die Sitzungswiederaufnahme, 0-RTT, die Zertifikatskette, die ein laufender Server tatsächlich sendet, und die Frage, ob eine HTTP-zu-HTTPS-Weiterleitung am Ursprung oder an einem Proxy stattfindet, außerhalb dessen, was eine Webseite melden kann. Sie kann auch keine Header von einer fremden Website für Sie einsammeln, und sie kann nicht sagen, ob ein Zertifikat vertrauenswürdig ist, denn das hängt von einem Root-Speicher ab, den eine Seite nicht lesen kann. Die Befehle weiter unten sehen diese Dinge, und sie sollen von Ihnen auf Ihrem eigenen Rechner ausgeführt werden.

Wo Sie den Header-Block bekommen. In einem Terminal gibt curl -sI https://example.com/ genau aus, was diese Seite braucht. Im Browser öffnen Sie die Entwicklertools, gehen in den Netzwerk-Reiter, laden die Seite neu, wählen die Dokumentanfrage und kopieren den gesamten Bereich Antwort-Header oder verwenden Kopieren → Antwort-Header kopieren. Für die Weiterleitungsprüfung führen Sie zusätzlich curl -sI http://example.com/ aus und fügen beide Blöcke ein; die Seite meldet sie nacheinander.
Noch nichts geprüft. Fügen Sie oben einen Header-Block ein und drücken Sie Diese Konfiguration prüfen für den vollständigen Bericht. Ein Zertifikat, ein Seitenquelltext-Ausschnitt und ein Hostname sind optional, und jedes davon fügt einen eigenen Abschnitt hinzu.
Erreichbarkeitstest — der einzige Teil dieser Seite, der das Netzwerk nutzt
Eine Seite kann keine TLS-Verbindung öffnen, aber sie kann eine gewöhnliche Anfrage stellen. Wenn die Website Cross-Origin-Lesezugriffe erlaubt, zeigt die URL, bei der die Antwort landet, ob http:// auf https:// weitergeleitet wurde — mehr kann dies nicht beweisen. Schlägt die Anfrage fehl, kann diese Seite nicht unterscheiden, ob der Host ausgefallen ist, Ihre eigene Verbindung gestört ist oder die Website Cross-Origin-Lesezugriffe schlicht nicht erlaubt. Letzteres ist der häufige Fall, weil die meisten Websites Access-Control-Allow-Origin nicht senden. Eine http://-URL wird vor jeder Weiterleitung beantwortet, daher ist dies das Einzige hier, was ein Browser über eine einfache Verbindung versucht. Nichts verlässt den Browser, bevor Sie den Knopf drücken.
Befehle, die den Handshake tatsächlich sehen
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
Diese Befehle sind dazu gedacht, dass Sie sie auf einem Rechner ausführen, den Sie kontrollieren, gegen einen Host, den Sie testen dürfen. Die Ausgabe von -showcerts können Sie direkt in den Zertifikatprüfer einfügen, und die Header-Ausgabe zurück in diese Seite.
Das Zertifikat ist ein öffentliches Dokument. Jedes öffentlich vertrauenswürdige Zertifikat wird in Certificate-Transparency-Logs veröffentlicht. Daher lässt sich jeder Hostname darin — auch ein interner oder falsch geschriebener Name, den eine öffentliche Zertifizierungsstelle signiert hat — durch Suche in diesen Logs finden. Ein Zertifikat trägt außerdem die Widerrufsadressen, die sein Aussteller gewählt hat, und diese nennen gelegentlich einen internen Host. Deshalb sagt das Zertifikat, das ein CDN ausliefert, nichts über den Ursprungsserver aus: Die Namen darin gehören dem CDN. Wenn das Audit einen Hostnamen findet, den Sie nicht erwartet haben, behandeln Sie ihn als öffentlich und ersetzen Sie, was er schützt.

Datenschutz: Der Header-Block, das Zertifikat und der Seitenquelltext werden lokal gelesen und nie hochgeladen. Eine Anfrage findet nur statt, wenn Sie den Knopf des Erreichbarkeitstests drücken. Um ein eigenes Zertifikat zu erstellen, verwenden Sie den Generator für selbstsignierte Zertifikate; um zu prüfen, ob ein privater Schlüssel zu einem Zertifikat gehört, verwenden Sie den Zertifikat-und-Schlüssel-Abgleich.