Umstellung einer alten Website auf https - SSL - einige Hinweise

05.08.2017 16:32:58, Jürgen Auer, keine Kommentare

Wenn Sie bei einem der großen Massenhoster heute eine neue Website starten: Dann ist es durchaus denkbar, daß Ihnen der verschlüsselte Zugang per https / SSL kostenlos mit angeboten wird. Buchen Sie SSL gleich mit dazu. Das schadet nichts und kann nur nützlich sein. Sie ersparen sich spätere Anpassungen.

Was aber ist, wenn Sie eine ältere Website haben? Die womöglich seit Jahrzehnten unverschlüsselt läuft? Bei der es "eigentlich" nur Informationen gibt und bei der bsp. ein Kontaktformular bereits auf einen sicheren Kanal ausgelagert worden ist?

Soll man diese auch umstellen? Wenn ja, wo lauern Klippen?

Klar ist: Werden irgendwelche Informationen oder gar Passwörter auf der Seite eingegeben, sollten Sie möglichst schnell umsteigen. Denn Chrome und FireFox zeigen seit etwa Anfang des Jahres hässliche Warnmeldungen an. So etwas ist "nicht so prickelnd".

"Im Prinzip" ist der Umstieg ganz einfach:

(1) Sie müssen dafür sorgen, daß alle Inhalte der Seite, die bislang per http geladen wurden, nun per https geladen werden. Also Bilder, JavaScript-Dateien, iFrame-Einbindungen anderer Sites. Das vermeidet Mixed Content Warnungen, die man immer wieder auf umgestellten Sites sieht. Ich hatte zum Testen zwar kein wirklich geeignetes Tool gefunden. Aber der alte Linkchecker Xenu tat es auch. Diesen über die https-Version laufen lassen und das Ergebnis nach Url sortieren. Dann sieht man, ob es Zugriffe auf die umgestellte Site per http gibt.

(2) Sie sollten dafür sorgen, daß derselbe Inhalt (dieselbe Seite) nicht unter http und https gleichzeitig erreichbar ist. Die http-Version sollte auf die https-Version (Status 301) weiterleiten. Das vermeidet Probleme mit Suchmaschinen, die sonst plötzlich Inhalte unter zwei verschiedenen Adressen (per http und per https) drin haben. Und Sie dementsprechend abwerten. Ferner sollten Sie sich für eine Variante (mit www oder ohne www) entscheiden. Und Zugriffe auf die andere Variante entsprechend weiterleiten.

Dabei ist zu berücksichtigen: Erst von http auf https. Dann bsp. von . domainname . de auf www . domainname . de, wenn Sie die www-Variante bevorzugen.

--

Hintergründe:

Ich bin in der vergangenen Woche mit meiner alten (Inklusiv-) Domain www.sql-und-xml.de von 1&1 auf einen eigenen Server umgezogen. Die lief dort seit 2003. Hintergrund war, daß ich die Website auf SSL umstellen wollte, es mir aber zu unklar war, was ich bei 1&1 selbst konfigurieren kann und was nicht. Das hat einen Umzug der Mailpostfächer mit sich gebracht, dieser eigentliche (technische) Domainumzug war aber problemlos. Kleiner Trick: Vor dem Domainumzug bei 1&1 für jedes Mailkonto zusätzlich eine Weiterleitung auf eine anderswo liegende Mailadresse definieren. Dann bekommt man zwar Mails bis zum Umzug doppelt (über die Weiterleitung und den direkten Kontoabruf). Man stellt aber sicher, daß jede Mail sofort weitergeschickt wird und man nach dem Umzug gar nicht mehr an das alte Konto ran muß.

Früher konnte man an eine IP-Adresse nur ein Zertifikat binden, damit war auf dieser IP-Adresse auch nur eine verschlüsselte Domain möglich. Da Massenhoster auf einer IP-Adresse sehr viele Domains betreiben, war SSL für diese Domains ausgeschlossen. Das hat sich erst mit Server Name Indication (SNI) geändert. Seither kann man unter einer IP-Adresse viele verschlüsselte Domains betreiben.

Ferner war die Erstellung und Erneuerung von Zertifikaten ursprünglich eher Handarbeit. Das geht bei einem Server, wenn man das meinetwegen alle drei Jahre einmal macht und den Server komplett selbst verwaltet. Es war aber undenkbar, das als Massengeschäft zu betreiben. Seit dem Start von Let’s Encrypt Ende 2015 hat sich das gewaltig verändert. Diese bieten (1) kostenlose Zertifikate an und haben (2) ein Protokoll ACME entwickelt, mit dem sich die Anfrage nach einem Zertifikat, die Bestätigung und die Installation automatisieren lassen.

ACME soll Anfang nächsten Jahres in einer Version 2 weltweit standardisiert werden. Die Version 2 soll grade den Bedürfnissen von Massenhostern deutlich entgegenkommen und auch Sternzertifikate (*.example.com) unterstützen. Es ist davon auszugehen, daß Massenhoster Verschlüsselung massiv forcieren.

--

Gründe für den Umstieg:

- Die Seite kann nicht verändert werden. Etwa durch eingeschleuste Werbung. Es ist allerdings weiterhin möglich, daß Addins im lokalen Browser JavaScript injizieren und dadurch Werbung einschleusen. So daß Nutzer denken, daß die Werbung von der Seite käme. Deshalb habe ich gleichzeitig meine Website auf Content Security Policy Header umgestellt. Das hat einige Anpassungsarbeiten in JavaScript-Dateien erfordert. Dies stoppt JavaScript-Injektionen von Addins und Virenscannern, sofern man Inline-JavaScript unterbindet.

- Früher waren Man-in-the-middle-Angriffe nur sehr schwer durchführbar: Im Festnetz muß jemand auf den gesamten Datenverkehr zwischen dem Browser des Nutzers und dem Webserver zugreifen können. Heute sind Man-in-the-middle-Angriffe weitaus leichter. Man kann bsp. am Flughafen per eigenem Laptop einen eigenen WLan-Zugang anbieten. Dann nutzen Leute diesen - und man greift darüber Daten ab. Der "technische Fortschritt" erleichtert ein Angriffsszenario, das früher nur sehr schwierig zu realisieren war.

Keine Gründe für den Umstieg:

- Besseres Ranking: Das Ranking einer Site mag sich marginal verbessern. Einer bis dahin schlecht gerankten Site dürfte das aber nichts helfen, einer guten nutzt es nichts.

- Performance des Clients: Wenn die Verschlüsselung den Client überfordert, dann sieht mir das eher danach aus, daß die Website zu schlecht aufgebaut ist (zu viele Elemente anfordert). Wenn das Sites wie Facebook und Xing seit Jahren schaffen, Clients nicht zu überfordern, dann sollten das auch Webshops schaffen.

Den Kopf geschüttelt habe ich über manche Aussagen (Zitate) in diesem Beitrag von 2014:

HTTPS für jede Website – sinnvoll oder nicht?

https://feller.systems/https-fuer-jede-website-sinnvoll-oder-nicht/

Da hat mich dieses Zitat des "Datenschutz Nord" verblüfft:

> Zum Thema Vollverschlüsselung von Webseiten rät auch der Datenschutz Nord aktuell ab, da es nicht notwendig ist den Inhalt von normalen Webseiten verschlüsselt zu senden. Denn auf einer Webseite liegen keine geheimen Informationen. Anders verhält es sich wenn auf einer Seite persönliche Daten abgefragt werden, Kontaktformulare eingebunden sind oder Logins verwendet werden. Diese Seiten sollten gezielt verschlüsselt sein. Der Rest einer Webseite nicht.

Das Problem dabei ist: Grade so ein Mixbetrieb (dieselbe Domain teils per http, teils per https) macht SSL-Stripping-Angriffe erst möglich. Diese setzen einen Man-in-the-middle-Angriff voraus - und diese sind inzwischen sehr viel einfacher geworden als früher.

SSL-Stripping-Angriffe kann man mit Strict-Transport-Security (HSTS) unterbinden: Da teilt der Webserver dem Browser mit dem ersten Zugriff per https mit, daß in Zukunft alle Zugriffe per https erfolgen sollen. Dann wandelt der Browser von sich her Links, die mit http anfangen, in https-Links um. Das korrekt implementiert bedeutet, daß der Server per http niemals Inhalte, nur 301-Weiterleitungen ausliefert.

Theoretisch ist der Erstzugriff auf eine Website noch gefährdet. Das kann man dadurch vermeiden, daß man sich in die Preload-Liste von Google einträgt und wartet, bis das im Chrome, FireFox und IE übernommen wurde (das kann einige Monate dauern). Dann wird sogar beim allerersten Zugriff auf eine Website nur https aufgerufen, auch wenn der Nutzer http eingegeben hat.

Meine Hauptdienstleistung Server-Daten läuft inzwischen schon seit geraumer Zeit unter https, HSTS und ist in der Preload-Liste drin. Allerdings bedeutet die Nutzung dieser Features auch: Man nagelt sich selbst auf https fest. Sprich: Wenn Sie mit solchen erweiterten Konfigurationen arbeiten, dann ist Ihnen der Rückweg zu http praktisch verbaut. Damit gegebenenfalls auch der Umzug zu einem Hostingunternehmen, das Ihnen kein SSL anbietet.

Links:

https://www.ssllabs.com/ssltest/ - Server-SSL-Konfiguration mit SslLabs testen

https://securityheaders.io/ - zusätzliche Securityheader testen: Strict-Transport-Security, Content Security Policy, Public Key Pins. Die anderen Header sind zwar "nice to have", aber wirklich sicherheitskritisch sind diese drei. Wobei ich auf *.server-daten.de X-Frame-Options nicht gesetzt habe - einige Kunden binden einzelne Seiten per Frame auf ihrer Website ein. Content Security Policy kann umfangreiche Änderungen am gesamten JavaScript-Code einer Site erfordern.

SSL Stripping: Black Hat: Neue Angriffsmethoden auf SSL vorgestellt (2009)

https://www.heise.de/security/meldung/Black-Hat-Neue-Angriffsmethoden-auf-SSL-vorgestellt-198285.html

Ein Video (2012): SSL-Stripping, die ignorierte Gefahr

https://blog.mgm-sp.com/2012/11/02/ssl-stripping-die-ignorierte-gefahr/

https://hstspreload.org/ - HSTS-Preload-Formular. Auch wenn man Preload nicht nutzen möchte, kann man den dortigen Test nutzen, um zu prüfen, ob Weiterleitungen http -> https in der richtigen Reihenfolge durchgeführt werden.

https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json - statische Liste aller Domains mit Preload. Die Domains werden direkt im Quellcode von Chrome verankert. FireFox / Microsoft übernehmen diese Listen nach einiger Zeit.

Es fällt auf, daß bsp. deutsche Banken da überhaupt nicht drin sind. Ferner wächst die Liste mit jeder neuen Chrome-Version. Die server-daten.de ist da drin (schon relativ alt), die sql-und-xml.de noch nicht. Neue Domains kommen dort immer blockweise rein und sind im Block alphabetisch sortiert.

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