Webseiten, die bisher nicht zu vertrauenswürdigen Zertifikaten gewechselt haben, bekommen Googles strenge Sicherheitspolitik zu spüren
Wie schon länger angekündigt, verweigert Chrome inzwischen standardmäßig den Zugriff auf Webseiten, die alte, als nicht vertrauenswürdig eingestufte SSL-Zertifikate von Symantec verwenden.
Mit dem Fehler NET::ERR_CERT_SYMANTEC_LEGACY konfrontiert Google Chrome den Nutzer beim Versuch, betroffene Webseiten zu laden.
Solche Datenschutzwarnungen sollten großen Druck auf Webseitenbetreiber ausüben, vor allem mit Hinblick auf Chromes Marktanteil. Auch Firefox und Co. folgen auf dem Fuß. Die Browserbetreiber hatten sich zuvor darauf geeinigt, Symantec-Zertifikaten nicht mehr zu vertrauen.
Wer trotzdem eine betroffene Webseite besuchen möchte, kann über den „Erweitert“-Button die Webseite trotzdem besuchen. Das sollte aber nur eine Übergangslösung sein, besser macht man den Betreiber der Webseite darauf aufmerksam. Dann kann dieser sein Symantec Zertifikat austauschen.
Das stärkste Schloss nutzt nichts, wenn die Tür nicht abgeschlossen wird.
Update, 01.12.2018: Heute habe ich entdeckt, dass ich bereits in der aktuellen Preload-Liste des Chromium-Projekts aufgenommen bin und diese Änderung voraussichtlich in die kommenden Versionen von Chrome, Firefox und Edge propagiert werden wird!
Ich habe am vergangenen Wochenende einige Stunden investiert, diesen Blog etwas „sicherer“ zu machen. Eigentlich werden alle Anfragen per 301-Redirect auf HTTPS umgeleitet. Das ist die gängige Praxis, jedoch noch anfällig für Man-in-the-middle Attacken, welche versuchen auf HTTP-Verbindungen umzuleiten, bzw. vor Zustandekommen einer HTTPS-Verbindung lauschen.
Diese Angriffe vom Typ sslstrip sollen mithilfe von HTTP Strict Transport Security, kurz HSTS, verhindert werden. Das Prinzip ist simpel: Bei der ersten Verbindung per HTTPS teilt der Server dem Browser mit, für eine definierte Zeitspanne (typischerweise Jahr(e)) nur noch verschlüsselte Verbindungen zu dieser Webseite aufzubauen. Folglich werden Verbindungen zu dieser Seite dann gar nicht mehr über HTTP versucht, sondern direkt über HTTPS.
Das Problem? HSTS funktioniert nach dem trust-on-first-use Prinzip, das heißt, ein erstes Mal muss der Browser die Verbindung auf herkömmliche Weise herstellen, denn der HSTS-Header wird erst über HTTPS gesendet. Der Browser kann also vor dem ersten Kontakt gar nicht wissen, dass er eine sichere Verbindung aufbauen soll. Erst nach der Weiterleitung auf HTTPS weiß der Browser vom HSTS-Header.
Die Lösung? Riesige, hard-gecodete Listen von HSTS-unterstützenden Websites (kein Witz!). Das Chromium-Projekt hinter Google Chrome unterhält die größte dieser Listen, die, mit einigen Monaten Verzögerung, in die neusten Versionen von Chrome, Firefox und Co. eingebracht wird. Bei Webseiten in dieser Liste weiß der Browser dann schon vor dem ersten Kontakt, dass er nur über HTTPS eine Verbindung aufbauen soll. Inklusion einer Webseite kann man auf https://hstspreload.org/ beantragen, wie auch ich das getan habe. Dafür muss die Webseite einen HSTS-Header auf allen Subdomains senden, der einige Kriterien bezüglich Parametern und Gültigkeitsdauer erfüllen muss.
Obwohl sie mehrere Megabyte groß ist, ist die Liste verschwindend winzig, verglichen mit allen Webseiten, die standardmäßig HTTPS senden. Ja, HSTS Preloading ist ein gewisses Risiko, sollten sich Konfigurationen ändern oder Zertifikate auslaufen. Mit dem jüngsten Schritt von Chrome, HTTP-Verbindungen grundsätzlich als unsicher zu kennzeichnen, ist die Idee, standardmäßig HTTPS zu versuchen, aber auch nicht sehr abwegig.
Obwohl HSTS seit 2012 existiert, wird es wohl noch viel Druck benötigen, den letzten Webseitenbetreiber zu HTTPS zu bewegen, auch in der Zeit kostenloser SSL-Zertifkate.
P.S.: Dieser Blogeintrag dient mir als Maßstab, um nachzurechnen, wie lange es dauert, bis mein Blog es in die HSTS-Preloadlisten der Browser geschafft hat.
