Die Möglichkeiten, von Sicherheitslücken im eigenen Website-Auftritt betroffen zu sein, sind vielfältig. Potentielle Angriffsziele reichen von der Netzwerk-Infrastruktur über Betriebssystem und Systemsoftware (wie Webserver und Datenbank) bis zur Webanwendung in Back- und Frontend.
Für Datenschutzverantwortliche sind jedoch die Mittel, eine Website im Rahmen eines Audits auf Sicherheitslücken zu untersuchen, begrenzt- sofern man nicht im Zweitberuf Experte für Cyber-Sicherheit ist und weiß, wie man einen Penetration-Test durchführt.
Einen wichtigen Aspekt der Website-Sicherheit beschreiben wir in diesem Beitrag, und zwar die sogenannte Transportverschlüsselung, die besonders im Zusammenhang mit Web-Formularen relevant ist. Diese ist überraschend häufig nur lückenhaft umgesetzt, obwohl derartige Schwachstellen leicht zu identifizieren sind. Hier erfahren Sie, wie man die Transportverschlüsselung überprüfen kann.
Was ist Transportverschlüsselung?
Wenn man Transportverschlüsselung meint, sagt man umgangssprachlich immer noch sehr häufig „SSL“, das Akronym für Secure Socket Layer. Gemeint ist damit, dass der Datenverkehr zwischen Browser und Webserver so verschlüsselt wird, dass kein Dritter den Datenverkehr abhören kann.
Diese Bedenken sind berechtigt – das Internet ist durch seine dezentrale Architektur so ausgelegt, dass Datenpakete oft eine Vielzahl von Servern passieren, bevor sie Ihr Ziel erreichen. Dies machen sich Geheimdienste zunutze, die die Betreiber der großen Internetknoten verpflichten, ihnen Vollzugriff zu gewähren.
Das erste Protokoll zur Verschlüsselung von Daten im Web war das besagte SSL, es wurde 1994 von Netscape entwickelt. Auf diese Version 1.0 folgten SSL 2.0 und SSL 3.0, anschließend wurde das Akronym TLS (Transport Layer Security) für verbesserte Verfahren verwendet, mit den Versionen TLS 1.0 bis TLS 1.3. Es sollten mittlerweile nur noch die Verfahren TLS 1.2 und 1.3 eingesetzt werden, weil alle anderen als veraltet und nicht mehr sicher genug gelten.
Die Funktionsweise hat sich seit 1994 allerdings nicht grundsätzlich verändert. Sie sieht sehr stark vereinfacht wie folgt aus:
- Der Webserver stellt dem Browser ein digitales Zertifikat zur Verfügung. Dieses wurde von einer unabhängigen Stelle ausgestellt und beweist die Identität des Servers – damit wird verhindert, dass ein Angreifer sich sozusagen vor den Webserver stellt, sich für ihn ausgibt, und die Kommunikation abfängt.
- Das Zertifikat enthält zusätzlich einen sogenannten Öffentlichen Schlüssel für ein asymmetrisches Verschlüsselungsverfahren. Das bedeutet: der Browser kann mit dem öffentlich bekannten Schlüssel eine Nachricht verschlüsseln, die aber nur der Webserver entschlüsseln kann.
- Browser und Server verständigen sich außerdem darüber, welche Verfahren im Detail für die Verschlüsselung verwendet werden.
Schwachstellen rund um Transportverschlüsselung
Für eine sichere Transportverschlüsselung muss ein Websitebetreiber nicht nur ein vertrauenswürdiges TLS-Zertifikat bereitstellen, zusätzlich muss der Webserver korrekt konfiguriert werden – im Business-Kontext typischerweise die Aufgabe eines Providers oder IT-Dienstleisters. Die folgenden Fehler sollten vermieden werden, auch weil sie leicht durch Dritte erkennbar sind:
Unverschlüsselter Server
Fast schon zu banal für diese Auflistung, dennoch im privaten Umfeld oder bei Vereinen immer noch anzutreffen. Da Zertifikate mittlerweile kostenfrei erhältlich sind (etwa bei Let’s Encrypt), und die meisten Web-Provider sie über eine Admin-Oberfläche auf Knopfdruck verfügbar machen, sollte es eigentlich auch für diese Zielgruppe Usus sein, sie einzusetzen.
Ungültiges Zertifikat
Mit technischen Basiskenntnissen ist es leicht möglich, ein Webserver-Zertifikat selber zu erstellen. Da dieses aber nicht von einer unabhängigen Stelle ausgestellt wurde, reicht es nicht aus, um die eigene Identität nachzuweisen. Browser zeigen in diesem Fall eine so deutliche Warnung an, dass die Website unbenutzbar wirkt.
Ein Zertifikat ist auch ungültig, wenn es auf einem falschen Webserver als vorgesehen installiert wird. Die Warnmeldung im Browser sieht dann vergleichbar aus.
Fehlende Zertifikatskette
Damit der Nachweis der Identität gelingt, sollten auf dem Server neben dem eigenen Webserver-Zertifikat noch weitere Zertifikate installiert sein, und zwar die sogenannten „Intermediate Certificates“. Diese identifizieren das Unternehmen, bei dem man das Zertifikat gekauft hat. Moderne Browser können diese Zertifikate nachladen, ältere zeigen einen Fehler an, wenn sie nicht vorhanden sind.
Abgelaufenes Zertifikat
Da Zertifikate immer mit einem Ablaufdatum ausgestellt werden (sie sind typischerweise 1 bis 3 Jahre gültig), werden sie zu einem bestimmten Zeitpunkt ungültig und müssen erneuert werden. Auch in diesem Fall zeigen Web-Browser eine sehr extreme Warnmeldung an.
Veraltete Protokolle
Die eingesetzten Details der Verschlüsselung werden wie oben beschrieben zwischen Browser und Server ausgehandelt. Ein Angreifer könnte dem Server ein sehr altes und leicht zu überwindendes Verfahren vorschlagen. Aus diesem Grund sollten Server so konfiguriert sein, dass sie nur moderne, sichere Verfahren unterstützen.
Anfälligkeit für Angriffe
Die bekannten Angriffsmöglichkeiten gegen TLS hängen meist mit veralteten Protokollen zusammen (so ist bspw. POODLE eine Schwachstelle von SSL 3.0). Eine Ausnahme ist u.A. die Heartbleed-Schwachstelle, die seit 2014 ein großes Presseecho hat. Sie basiert auf einem Fehler in der Softwarebibliothek OpenSSL,
Keine erzwungene Verschlüsselung
Die beste Verschlüsselung nützt nichts, wenn sie nicht eingesetzt wird. Deshalb sollten Websites alle Aufrufe, die per http:// erfolgen, zu https:// umleiten, um so eine Verschlüsselung zu erzwingen.
Die Server-Verschlüsselung überprüfen
Die oben genannten Schwachstellen sind teilweise sehr leicht zu prüfen, weil bei einigen davon jeder Browser eine deutlich sichtbare Warnmeldung anzeigt. Das gilt aber nicht für alle – das Akzeptieren alter Protokolle ist bspw. nicht ohne weiteres erkennbar. Es gibt zum Glück ein sehr mächtiges und gleichzeitig kostenfreies Online-Tool, das alle oben genannten Schwachstellen testet – die Website SSLLabs des Unternehmens Qualys.
Geben Sie einfach im Eingabefeld den Servernamen ein, den Sie prüfen wollen, und warten Sie einige Minuten. Das Ergebnis ist dann eine sehr detaillierte Überprüfung einer Vielzahl von Kriterien. Die fachliche Interpretation der Meldungen kann schwierig sein, der für Sie relevanteste Teil ist deshalb die Zusammenfassung am Kopf des Reports – hier am Beispiel von https://decareto.com:
Es ist empfehlenswert, alle Ergebnisse mit einem Rating schlechter als A mit einem entsprechenden Warnhinweis an den Website-Betreiber weiterzugeben. Der technische Ansprechpartner wird die Hinweise zu deuten wissen, zumindest wurden mögliche Risiken damit adressiert.
Wenn Sie im Report nach unten scrollen, sehen Sie auch die Ergebnisse zu den oben erwähnten potentiellen Problemen bei der Verschlüsselung, etwa den akzeptierten Protokollen:
Alle Protokolle unterhalb (also älter) als TLS 1.2 sollten mit „No“ gekennzeichnet sein, mindestens eins der Protokolle TLS 1.2 oder TLS 1.3 sollte mit „Yes“ gekennzeichnet sein.
