Make your Website better - ursprüngliches kleines Tool Check-your-Website um diverse Tests erweitert - DNS, DNSSEC, EDNS, Content-Check, CT-Logs

17.05.2019 23:53:39, Jürgen Auer, keine Kommentare

Vor ziemlich genau einem halben Jahr hatte ich hier im Blog eine damals "kleine Webanwendung innerhalb von Server-Daten" vorgestellt:

Check your Website - kleine Anwendung zum Test von Redirects http - https, Zertifikaten und Hinweisen zur Konfiguration - mit Ranking-System

https://blog.server-daten.de/de/2018-11-16/Check-your-Website---kleine-Anwendung-zum-Test-von-Redirects-http---https--Zertifikaten-und-Hinweisen-zur-Konfiguration---mit-Ranking-System-451

Eine damals kleine Anwendung, mit der Nutzer die eigene Website auf Redirects testen können.

Man gibt einen Domain- oder Subdomainnamen ein. Dann werden die vier Urls http + domain, http + www.domain, https + domain und https + www.domain getestet, mögliche Redirects ausgewertet und das Ergebnis bewertet.

Als Ergebnis gab es damals die Einzelergebnisse zu jeder Zeile (Url-Checks), Kommentare und einen globalen Rang. Ferner konnte man zu jeder Einzelzeile die Header einblenden.

Inzwischen hat das Tool um diesen Kern herum so dermaßen viele Erweiterungen erhalten, daß ein neuer Blogbeitrag sinnvoll ist.
.

Make your website better - Check the redirects, certificates and connection-settings of your Website

https://check-your-website.server-daten.de/

.
Im November waren noch zwei weitere Ausgaben dazugekommen: Ein Block "Connections" zeigt alle https-Verbindungen mit den Zertifikaten an. Pro Zeile wird einmal eine Verbindung mit den bestmöglichen Werten hergestellt. So daß angezeigt werden kann, ob Tls.1.2 (gut) oder Tls.1.0 (schlecht) genutzt wird, was für ein Schlüsselaustausch, Cipher und Hashalgorithmus genutzt wird.

Plus eine Ausgabe der gefundenen Zertifikate mit möglichen Problemen bei einem ungültigen Zertifikat: Ist es einfach nur nicht mehr gültig? Ist es zurückgezogen / revoked? Handelt es sich um ein selbstsigniertes Zertifikat? Oder ist der Domainname falsch?

Dann tauchte die Idee auf, daß eigentlich CAA- und TXT- Einträge angezeigt werden sollten. Beides sind Einträge im Domain Name System (DNS). Mit dem ersten kann man festlegen, welche Certificate Authorities (CA) dazu berechtigt sind, Zertifikate für diese Domain auszustellen. Daß man eine Domain verwaltet, kann man u.a. mit TXT-Einträgen der Form _acme-challenge.example.com beweisen.

Allerdings gab es innerhalb von .NET keine geeignete Programmierlogik dafür. Das führte prompt zu der Frage: Schreibe ich mir einen eigenen DNS-Client? Nach ein wenig Herumspielen hatte ich den Google-Nameserver 8.8.8.8 abgefragt und meinen eigenen CAA-Eintrag auf dem Bildschirm. Also wurde das ausgebaut.

Eine Konsequenz: Die bisherige Logik hatte nur den Domainnamen http://example.com/ (und die weiteren Varianten dazu) abgefragt. Die Auflösung example.com -> IP-Adresse wurde der Betriebssystemumgebung überlassen. Ein eigener DNS-Client ermöglicht es dagegen, zunächst einen der Root-Server nach den authoritativen Nameservern für die com-Zone zu befragen. Dann einen dieser nach den authoritativen Nameservern für example.com. Schließlich diese direkt nach der Domain, den IP-Adressen und CAA- bzw. TXT-Einträgen zu befragen.

Die Wirkung: Die Ergebnisse sind nicht gecacht (teils bis zu 48 Stunden alt), sondern aktuell. Ein Nutzer kann einen DNS-Eintrag ändern, checkt seine Domain erneut - und hat das Ergebnis auf dem Bildschirm.

Ein zweiter Effekt: Zu einer Domain kann es mehrere IP-Adressen geben. Also werden diese der Reihe nach abgefragt und die Ergebnisse miteinander verglichen. Das beschränkte sich zu diesem Zeitpunkt auf Ipv4-Adressen.

Wenig später die Einsicht: Ein ernstzunehmender DNS-Client müsse DNSSEC berücksichtigen. Also wurden zuerst die DNSSEC-spezifischen DNS-Datensätze implementiert, dann die Überprüfung der Signaturen ergänzt. So daß sichtbar ist: Ist DNSSEC implementiert? Ist das konsistent? Oder gibt es den Fehler (bsp. nach einem Providerwechsel), daß es in der übergeordneten Zone noch einen DS-Record gibt, in der lokalen Zone jedoch keinen passenden DNSKEY, so daß die Zone inkonsistent ist.

Mitte Januar bekam Server-Daten eigene IPv6-Adressen, so daß die Url-Checks auf Ipv6 ausgedehnt wurden.

Ferner wurden die Nameserver und deren IP-Adressen explizit ermittelt und diversen Tests unterzogen: Unterstützt der Nameserver TCP-Abfragen? Wird EDNS grundsätzlich unterstützt? Wie wird auf einzelne spezielle EDNS-Tests reagiert?

Im Januar kam ein zunächst kleiner Content-Check dazu. Die ursprüngliche Idee: Jemand installiert sich erstmalig ein Zertifikat. Dann ist es sinnvoll, wenn er nicht nur die Weiterleitungen checken kann, sondern zusätzlich sieht, wo http-Links auf https umgestellt werden sollten. Wo also mixed Content existiert. Allerdings war das schnell "zu klein" gedacht. Http-Links lassen sich sofort durch die Analyse des Quellcodes ermitteln. Aber auch bei einem https-Link kann das Zertifikat ungültig sein, die verlinkte Seite nicht mehr existieren oder gesperrt sein. Also wurden solche Urls zusätzlich gecheckt.

Nach der Beobachtung einiger Ergebnisse und entsprechender Erweiterungen stellte sich heraus, daß der Content-Check leistungsfähiger ist als die mixed-Content-Anzeige in Browsern. Wenn JavaScript-Code aus einer externen Datei CSS-Definitionen aus einer anderen Datei einlädt, kann es sein, daß diese CSS-Definitionen fehlerhafte Urls der Form "url('http://example.com/image.png')" enthalten. In diesem Fall zeigen aber sowohl FireFox als auch Chrome die JavaScript-Datei als Quelle für den mixed Content an. Da findet sich die fehlerhafte Definition aber nicht, die steckt in der CSS-Datei. Der Check zeigt deshalb zu jeder CSS-Datei die in dieser Datei definierten url(...) - Einbindungen an und markiert jene, die http nutzen. Ferner werden http-Links für canonical / og:image etc. als Fehler angezeigt.

Eine sehr neue Erweiterung des Content-Checks ist der Check auf Subresource Integrity. Bindet eine Website externe Scripte ein, setzt sie sich dem Risiko aus, daß diese externe Subresource geändert / gehackt / manipuliert wird und die eigene Website bsp. plötzlich Kryptomining betreibt. Das kann man verhindern, indem ein Hash des Dateiinhalts als integrity-Attribut im script-Element hinterlegt wird. Ferner setzt die Nutzung dieser Technik voraus, daß die verlinkte Quelle einen Access-Control-Allow-Origin - Header mit * oder dem Domainnamen mitsendet. Das wird geprüft. Wenn es ein integrity - Attribut gibt, wird dessen Wert mit dem berechneten Hashwert der Quelle verglichen. Fehlt das Attribut, werden mögliche Hashwerte angezeigt. Plus der ursprüngliche Link, ergänzt um das Attribut, so daß man den Eintrag mit Copy&Paste austauschen kann.

Schließlich kam ab März eine Abfrage von zunächst einem Certificate Transparency Monitor dazu. Damit können alle Zertifikate ermittelt werden, die zu einer Domain ausgestellt wurden. Da sich die genutzte Quelle im April / Mai als zeitweilig instabil herausstellte, wurde im Mai ein weiterer Monitor eingebunden, der nur aktive Zertifikate listet.

Hinzu kam die Möglichkeit, statt einer Domain eine Ipv4- oder Ipv6-Adresse direkt abzufragen. Und eine Domain bzw. Ip-Adresse mit einem speziellen Port zu testen. Die meisten Online-Tools lassen diese Möglichkeiten nicht zu. So daß Anwendungen, die auf Nicht-Standardports laufen, nicht getestet werden können.

Das ermöglicht es auch, bei einer fehlerhaften Ipv6-Konfiguration den AAAA-Eintrag im DNS zunächst zu entfernen, aber den Zugriff auf den Webserver per Ipv6 und Domainname als Headername direkt zu testen. Erst wenn alles richtig funktioniert, fügt man den AAAA-Eintrag wieder hinzu.

--

Die Nutzungszahlen waren im Dezember 2018 noch relativ niedrig. Deutlich unter 50 Tests pro Tag, davon diverse eigene Tests. Ab Januar ging das schrittweise nach oben. Die eigenen Tests machen inzwischen nur noch einen geringen Prozentsatz aller Tests aus. Werktags sind das inzwischen über 100 pro Tag.

Gänzlich unklar ist, ob in der Zukunft noch "große neue Dinge" dazu kommen werden. Rund um eine Website gibt es nicht mehr allzuviel, Ssllabs will ich definitiv nicht nachbauen. Diverse Kleinigkeiten wie die oben eingebauten Sprunglinks, die älteren Checks oder Erweiterungen bei der Prüfung der TXT-Einträge auf fehlerhafte Einträge gab es auch noch. Allerdings war auch im November noch nicht absehbar, daß ein eigener DNS-Client, Content-Check oder CT-Checks dazu kommen würden.

Ein kleiner Nebeneffekt: Aufgrund der Beschäftigung mit DNSSEC wurden auch server-daten.de und die sql-und-xml.de auf DNSSEC umgestellt. So daß bei beiden Domains DNS-Ergebnisse nun kryptographisch überprüfbar sind.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.