AW: PCGH & SSL-Verschlüsselung
Hallo,
Wir nutzen auf den Webservern die u.a. auch für
PCGH: Computer, IT-Technik und PC-Spiele verwendet werden nur genau ein Zertifikat, das auf den Host ssl.computec.de ausgestellt wurde.
Auf diesen Webservern laufen neben
PCGH: Computer, IT-Technik und PC-Spiele auch eine Vielzahl weiterer Hosts, u.a. auch ssl.computec.de. Aufgrund der technischen Spezifikation von SSL können Virtual Hosts auf SSL-Ebene nicht aufgelöst werden (der Hostname ist Teil des HTTP-Headers und somit verschlüsselt); eine Separierung wäre allenfalls für verschiedene IP-Adressen möglich. Da aber die Server für alle Hosts die gleiche IP-Adresse nutzen, wird für alle Hosts bei Aufruf über https das ssl.computec.de-Zertifikat im Kontext des ssl.computec.de-Virtual Hosts ausgeliefert.
Da dieses Zertifikat nur für ssl.computec.de gilt und nicht für
PCGH: Computer, IT-Technik und PC-Spiele meldet der Browser, dass die Identität der Webseite nicht bestätigt werden kann. Da es nur diesen einen SSL-Virtual-Host für diese IP-Adresse gibt, werden über
https://www.pcgameshardware.de auch keine Inhalte von
PCGH: Computer, IT-Technik und PC-Spiele ausgeliefert, sondern die Inhalte von ssl.computec.de.
Dieser SSL-Host wird nur für die Einbindung von Ressourcen wie Magazin-Covers u.ä. auf abo.computec.de, für datenschutz-kritische APIs im Rahmen der Abonnenten-Verwaltung sowie für Facebook-Apps unserer Webseiten genutzt, die SSL zwingend erfordern. Daher bekommt man beim direkten Aufruf von
https://ssl.computec.de/ oder
https://ssl.pcgameshardware.de/ auch nur diese Testseite zu sehen.
Die Implementierung von SSL für das Login ist aufgrund der Nutzung extern entwickelter Software wie VBulletin nicht ohne weiteres möglich. Veränderungen an dieser Software würden ein wesentlich höheres Sicherheitsrisiko mit sich bringen als der Verzicht auf SSL-Verschlüsselung fürs Login, da solche Veränderungen ein schnelles Update im Falle von Sicherheitspatches mitunter verhindern oder wenigstens erschweren. Solche Updates gab es allerdings gerade in der jüngeren Vergangenheit immer wieder - sowohl für VBulletin als auch für einzelne Komponenten wie Tapatalk, VBSeo und andere von uns genutzte Plugins.
Zum anderen böte eine SSL-Verschlüsselung des Logins keinen echten Sicherheitsgewinn, da anschließend die Session des Users über Session-Cookies gehandelt wird, die ebenfalls notwendigerweise unverschlüsselt übertragen werden. Da SSL-Verschlüsselung nur bei Man-in-the-Middle-Angriffen überhaupt relevant ist, könnte ein solcher Angreifer nach dem erfolgreichen Login auch problemlos das Session-Cookie abfangen und nutzen (Session-Hijacking). Das einzige was zunächst geschützt wäre, ist das Klartext-Passwort, das für das Login genutzt wird. Wenn dieses Passwort jedoch nur auf PCGH genutzt wird und sonst nirgendwo (was wir immer wieder dringend empfehlen), dann hat das Passwort keine höhere Bedeutung als das Session-Cookie.
Eine SSL-Verschlüsselung des Login-Vorgangs allein bringt daher keinen Sicherheitsgewinn, verursacht allerdings Kosten für das Zertifikat, das Zertifikatsmanagement, benötigt eine eigene öffentliche IPv4-Adresse und würde erhebliche Anpassungen an eigener und z.T. auch fremder Software erfordern, was in letzterem Fall einen deutlich erhöhten Patch-Aufwand für Sicherheitsupdates und damit einer verlängerte Zeitspanne zwischen Verfügbarkeit (und damit öffentlicher Bekanntheit der Sicherheitslücke) und Deployment von Updates mit sich bringt, was wiederum ein stark erhöhtes Risiko für die Gesamtheit der Daten darstellen würde. Das ist somit nicht vertretbar.
Die SSL-Verschlüsselung der gesamten Webseite andererseits scheitert unter anderem daran, dass dann alle Inhalte auf der Webseite SSL-verschlüsselt sein müssen - somit könnte praktisch keine Werbung eingebunden werden und Fremd-Software, wie eben z.B. VBulletin bzw. einige Plugins, die z.T. absolute URLs (d.h. mit
http://) verwenden, würde damit nicht zuverlässig funktionieren.
Der Heartbleed-Bug zeigt zudem, dass das ganze SSL-Konstrukt an sich höchst fragil und fragwürdig ist. Durch Heartbleed konnten über mehrere Jahre hinweg die privaten Schlüssel von Zertifikaten remote ausgelesen werden. Somit konnte sich ein Man-In-The-Middle-Angreifer Zugriff auf das Zertifikat verschaffen und die Kommunikation zwischen Client und Server problemlos mitlesen. Der Bug ist zwar behoben, aber er zeigt, dass es immer wieder Möglichkeiten gibt, wie Zertifikate vor Ablauf ihrer Gültigkeit kompromittiert werden.
Wird das bemerkt, so kann ein solches Zertifikat zwar revoked und ein neues ausgestellt werden. Das kümmert allerdings die Clients nicht, die akzeptieren auch zurückgezogene Zertifikate weiterhin; die Server der Root-Zertifizierungsstellen würden auch kaum den Ansturm von Requests vertragen, wenn bei jedem Aufruf einer SSL-Ressource die Gültigkeit des Zertifikats dort angefragt werden müsste. Daher ist dieser Test in Chrome defaultmäßig deaktiviert, zumal der Test bei jedem Aufruf auch Zeit kostet und somit das Surfen merklich verlangsamt.
Man kann den Test im Client (z.B. eben Chrome) natürlich manuell aktivieren, doch das bringt ebenfalls rein gar keinen Sicherheitsgewinn: Das Protokoll sieht vor, dass bei einem Timeout bei der Gültigkeitsabfrage das Zertifikat weiterhin als gültig anzusehen ist. Da das wie gesagt nur bei Man-in-the-Middle-Angriffen überhaupt relevant ist, hat dieser Man-in-the-Middle also nichts weiteres zu tun, als die Anfragen an die Root-Zertifizierungsstellen zu droppen, um mit gestohlenen, bereits revokten Zertifikaten auch weiterhin die Kommunikation entschlüsseln zu können.
Daher bleiben wir dabei: SSL ist für unseren Anwendungsfall (Community-Webseiten) nicht wirklich zweckdienlich und bringt viele Probleme mit sich, die wir gar nicht oder nur mit nicht vertretbarem Aufwand lösen könnten. Passwörter sollten grundsätzlich nicht mehrfach verwendet werden - allein damit sinkt der Wert eines Passworts bei Man-in-the-Middle-Angriffen schon beträchtlich. Wenn man zudem über öffentliche WLANs oder anderweitig ungesicherte Verbindungen surft, dann sollte man im Bedarfsfall auf einen vertrauenswürdigen VPN-Anbieter zurückgreifen - ich nutze privat
https://www.privateinternetaccess.com, es gibt sicher auch eine Reihe weitere gleichwertige Anbieter.
Die Sache sieht anders aus, wenn wirklich kritische Daten übertragen werden sollen wie Kreditkartendaten oder Bankverbindungen. Unsere Abo-Seite ist daher komplett SSL-verschlüsselt. Bei Forenposts, Kommentaren u.ä. sehen wir aber auch keine besonders hohe Attraktivität für Lauscher.
Viele Grüße
Markus
Auch dort werden Transaktionen durchgeführt bei denen kritischen Daten, wie Bankverbindungen einsehbar sind. 
