Check your Website - kleine Anwendung zum Test von Redirects http - https, Zertifikaten und Hinweisen zur Konfiguration - mit Ranking-System
Redirect Check of your website
check-your-website.server-daten.deCheck your redirects http - https, your preferred version (www vs. non-www) and your /.well-known/acme-challenge/ - settings. A ranking system shows, if your domain is A (no errors preload), has errors (https - http) or loops
Wer eine Website betreibt, der kennt das Problem. Immer mal wieder ändern sich Dinge. Techniken, die zeitweilig top waren, gelten plötzlich als unsicher und sollten deaktiviert werden. Aber wie soll man bei all den verschiedenen Dingen auf dem Laufenden bleiben?
Im Internet gibt es einige Testseiten für solche Zwecke. Diese ermöglichen es, eine Website einzugeben und diese testen zu lassen. Die Tests kann man immer mal wieder wiederholen. So daß man bsp. bei SslLabs plötzlich sieht, daß bestimmte Techniken nicht mehr verwendet werden sollten.
Aus einigen Beobachtungen heraus entstand vor einigen Wochen die Idee, ein kleines Tool zu bauen, mit dem man eine Grundfunktion von Websites testen kann. Inzwischen werden immer mehr Websites auf https, auf einen verschlüsselten Zugang umgestellt. Aber was macht man dann mit dem http - Zugang?
Weiterleitungen einrichten, von http zu https. So die gängige Antwort. Aber was heißt das im Detail? Was sollte man nicht machen? Wie kann man bei einer Website schnell sehen, welche Konfiguration vorliegt? Ohne daß man 4 Urls manuell testen muß?
Das Ergebnis ist nun in einer ersten Version fertig und verwendbar.
.
Redirect Check
https://check-your-website.server-daten.de/
.
Man kann den Namen einer Website (ohne http/https und ohne www) eingeben. Und die Website testen lassen.
Wenn man als Name bsp. "server-daten.de" eingibt, dann wird der Reihe nach
- http://server-daten.de/
- http://www.server-daten.de/
- https://server-daten.de/
- https://www.server-daten.de/
abgerufen. Ferner zwei Anfragen an das Standardverzeichnis /.well-known/acme-challenge/ mit einem nicht existenten Dateinamen gestellt. Das ist interessant, wenn man ein Zertifikat von Letsencrypt nutzen möchte. Solche Anfragen sollten mit einem 404 beantwortet werden.
Ermittelt wird, welchen Statuscode der Aufruf zurückgibt, ob es grundsätzliche Fehler gibt und ob es eine Weiterleitung auf eine andere Seite gibt. Falls ja, wird dieser solange gefolgt, bis keine weitere Weiterleitung, sondern ein Http-Status 200 oder etwas anderes gefunden wird.
Die Ergebnisse werden vierfach aufbereitet:
- Es gibt einen globalen Rang: A+, A, B, C usw. bis V, W und Z.
- Zu jeder einzelnen Abfrage gibt es eine Kurzklassifikation mit Buchstaben und Farben.
- Drunter gibt es eine Liste mit Erläuterungen zu einzelnen Zeilen und Erläuterungen zu Kombinationen aus Zeilen.
- Ferner kann man sich die Http-Header zu jeder Zeile einblenden lassen.
Die Prinzipien für einen Grad B sind eigentlich relativ einfach:
1. Von http sollte immer direkt zu https weitergeleitet werden. Und zwar zur gleichen Domain. Also http://server-daten.de/ -> https://server-daten.de/, nicht auf die www-Version.
2. Wenn damit beide http-Zugriffe in https-Zugriffe umgewandelt sind, sollte eine Version (non-www oder www) als präferierte Version ausgewählt und von der nicht präferierten Version auf die präferierte Version weitergeleitet werden. Also bsp. von https://server-daten.de/ auf https://www.server-daten.de/.
3. Damit hat man bei 4 Seitenaufrufen 3 Weiterleitungen und ein einziges https - Ziel mit dem Http-Status 200.
4. Klar ist, daß das Zertifikat gültig sein sollte. Üblicherweise nutzt man ein Zertifikat mit beiden Namen (non-www und www-Version).
Den Grad A gibt es, wenn alle https-Aufrufe einen zusätzlichen Strict-Transport-Security - Header haben und alle per https gesendeten Cookies als "secure" markiert sind, also nur über https gesendet werden dürfen. A+ gibt es, wenn die Domain zusätzlich eine der etwa 60.000 Preload-Domains ist.
Die Regel 1 wurde nicht selbst erfunden, sondern stammt vom HSTS-Preload-Formular https://hstspreload.org/ , dort ist das die Regel 2 (Regel 1, das gültige Zertifikat, versteht sich von selbst).
> Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.
Nur, wenn man zusätzlich alle Subdomains per https absichert, einen HSTS-Header von einem Jahr und einer preload-Direktive sendet, kann man den Antrag stellen, daß die Website in die Preload-Liste aufgenommen wird. Falls alle Bedingungen erfüllt sind, übernimmt Google die Domain in die Preload-Liste. Das ist eine hartcodierte Liste im Chrome-Browser:
https://cs.chromium.org/codesearch/f/chromium/src/net/http/transport_security_state_static.json
Vorsicht: Das sind 6 MB. Die Domains, die dort drauf sind, werden von Chrome ausschließlich per https kontaktiert. Das gilt auch dann, wenn dieser Browser noch nie auf der Website drauf war, den HSTS-Header also nicht kennen kann. server-daten.de ist da schon ziemlich lange drauf, etwa Platz 12.000.
--
Beim ersten Zusammenbauen dachte ich eigentlich, daß es "fast nur" Grad-A - Seiten geben müßte. Dann wurden erste Domains getestet - und es fand sich das genaue Gegenteil: Grad A (zu dem Zeitpunkt noch ohne die Überprüfung von HSTS und Cookies) wurde fast nicht gefunden. Selbst Websites wie google.de, die auf der Preload-Liste sind, halten diese einfache Regel (1) nicht ein. Andere machen ein Redirect von https zu http (Grad F), um dann wieder bei https zu landen. Dritte Seiten haben überhaupt keine Weiterleitung, so daß Nutzer auf http + Status 200 bleiben. Das wird zum Grad H.
Oder es gibt richtige Loops (Grad L), so daß eine Site unter der non-www - Version problemlos nutzbar ist. Die https + www - Version hat aber eine Weiterleitung - auf sich selbst, da hängt der Nutzer aussichtslos fest.
Ferner gibt es diverse Websites, bei denen bsp. www.example.com per http und https erreichbar ist. example.com ist aber per https nicht erreichbar, sondern es gibt ein Timeout (Grad T) oder ein ConnectFailure (Grad V).
Die Wirkung: Ursprünglich hatte ich gedacht, mit einer Handvoll von Graden auszukommen (A - D plus Zertifikatsfehler, https-Protokollfehler und Timeout). Inzwischen sind 19 Grade (von 26 Buchstaben) belegt. Denn es hatte sich einfach gezeigt, daß die Fehler "in freier Wildbahn" vorkommen. Ein ConnectFailure weist bsp. auf eine aktive blockierende Komponente (Firewall) hin, wohingegen ein Timeout deshalb auftreten kann, weil der Port 443 nicht lauscht, also keine lauschende Komponente definiert wurde. Folglich wurden ursprüngliche Zusammenfassungen (alles, was für den Nutzer wie ein Timeout aussieht, wird als Timeout ausgegeben) in verschiedene Fehlertypen getrennt.
--
Zwei Listen sind integriert: Zum einen die Google-Preload-Liste mit derzeit etwa 60.000 Domains. Da ist der obige Chrome-Quellcode die Quelle. Ferner wurde die Public-Suffix-List (unter https://publicsuffix.org/ verfügbar) integriert. Diese Liste legt fest, welche öffentlichen Domainendungen es gibt.
Das kann nicht nur eine Top Level Domain wie .de, .eu oder .com sein. Sondern es gibt bsp. diverse Länderdomains, die ein oder zwei Labels nutzen:
ac
com.ac
edu.ac
gov.ac
net.ac
mil.ac
org.ac
Man kann also eine Domain server-daten.ac registrieren. Ebenso wäre aber server-daten.com.ac denkbar. In beiden Fällen ist das eine Domain (und nicht eine Subdomain). Man benötigt also die Public Suffix List (PSL), um entscheiden zu können, ob es sich bei dem ins Formular eingetragenen Namen um eine Domain oder um eine Subdomain handelt.
Die Liste ermöglicht es, private Domainendungen, für die es keine öffentlich sichtbare IP-Adresse geben kann, sofort zu ermitteln.
--
Es könnte noch die Mozilla-Preload-Liste hinzukommen. Mozilla nutzt zwar die Chrome-Liste, überprüft da wohl aber Einträge und hat deshalb eine kürzere Liste. Für die Microsoft-Liste ist mir keine Quelle bekannt.
Ferner fehlen bei Zertifikaten noch diverse Informationen. Etwa eine genauere Darstellung der Zertifikatsfehler, der SAN-Namen sowie ergänzender Features (OCSP-Stapling, CT - Certificate Transparency).
Mal sehen, ob und wann ich solche Dinge noch ergänze.
--
Wer seine Ssl-Konfiguration testen will: Da ist die Testseite von SslLabs ( https://www.ssllabs.com/ssltest/ ) die beste Variante.