Keine Webformulare ohne (TLS-)SSL – Abmahngefahr?

Wir sind von Händlern darauf aufmerksam gemacht worden, dass derzeit von Datenschutzbehörden Händler wegen unverschlüsselt übertragener Webformulare mahnend angeschrieben werden. [Edit: Ob es tatsächlich auch echte Abmahnungen gegeben hat, ist unklar. Es ist aber denkbar, dass auch die Pflichten aus dem IT-Sicherheitsgesetz zukünftig für Abmahnungen benutzt werden könnte.]

Hintergrund

Oft gibt es ja auf einer Website und auch in Onlineshops diverse Formulare, über die Kunden unterschiedlichste Informationen übermitteln können. Angefangen mit den ganz allgemeinen Kontaktformularen über Infoanfragen zu bestimmten Produkten oder der Lieferbarkeit einzelner Artikel bis zu Preisalarm-Abos etc.

Dabei sind heutzutage die vom Shopsystem bereitgestellten Formulare meist analog zum Checkout über SSL angebunden.

Dies gilt jedoch nicht immer für sonstige Webformulare, wie allgemeine Kontaktformulare oder Formulare in angebundenen Blogs. Oft laufen solche Formulare praktisch „nebenher“ und werden nicht über eine Verschlüsselungstechnik wie beispielsweise SSL versendet.

Nach solchen Formulare sucht nun das Bayerische Landesamt für Datenschutzaufsicht systematisch und fordert die Shopbetreiber mahnend mit Fristsetzung zur (sicheren) Verschlüsselung auf.

Rechtliche Grundlage

Denn das LDA Bayern ist der Auffassung, dass unverschlüsselt übertragene Kontaktformulare dem Datenschutzgesetz widersprechen. Und zwar deshalb, weil die Anbieter solcher Formulare – damit also die Händler – verpflichtet sind, die persönlichen Daten der Nutzer nach dem „aktuellen Stand der Technik“ zu schützen. Konkret führt das LDA Bayern auf unsere Nachfrage aus:

Tatsächlich ist die Pflicht zur Absicherung der persönlichen Nutzerdaten prinzipiell ein alter Hut. Die Frage ist nur, welche technischen Maßnahmen tatsächlich dafür gefordert werden. Und hier hat es in letzter Zeit Bewegung gegeben, wie Rechtsanwältin Sabine Heukrodt-Bauer erklärt:

Welche Formulare wie gesichert werden müssen

Dass das HTTPS-Protokoll ein seit langem verbreitetes Verschlüsselungsverfahren beim Transport von Daten im Internet ist, wird sicherlich niemand bestreiten. Insofern ist es auch nicht so verwunderlich, dass dieses als „Stand der Technik“ heute eingefordert wird, wenn persönliche Daten übertragen werden.

Da im deutschen Recht sehr viele Daten als personenbezogen gelten, dürften praktisch alle Webformulare betroffen sein, beispielsweise auch die Kommentarformulare in Blogs. Denn hier werden (zur Spamvermeidung) in der Regel persönliche Daten wir Name und Mailadresse abgefragt, und beides gilt als personenbezogenes Datum. Dabei dürfte unerheblich sein, ob diese Angaben veröffentlicht werden oder nicht. Denn wann immer sie im Formular abgefragt werden, werden sie auch übertragen und müssen dabei geschützt werden. Damit würden auch alle Blogseiten, die ein Kommentarformular enthalten, unter die Verschlüsselungspflicht fallen – und genau dies bestätigte uns das LDA Bayern telefonisch auf Nachfrage auch.

Weiterhin müssen alle Formulare, die Logindaten transportieren, besonders geschützt werden. Hierzu schreibt das LDA Bayern in seinem Tätigkeitsbericht 2014:

HTTPS, TLS1.2, Perfect Forward Secrecy

Für einen wirksamen Schutz der Daten bei der Übertragung sollte in den meisten Fällen die Verschlüsselung über HTTPS ausreichen. Das LDA Bayern verweist jedoch darauf, dass SSL3 seit dem „Poodle“-Angriff „nicht mehr als sicher einzustufen“ sei. Als geforderten „Stand der Technik“ sieht es daher das Protokoll TLS1.2 an. Dabei muss sichergestellt werden, dass die Verschlüsselung nicht umgangen werden kann, zum Beispiel wenn sich die betroffenen Formularseiten alternativ statt über HTTPS auch über HTTP aufrufen lassen.  Solche direkten Aufrufe der betroffenen Seiten über HTTP müssen also technisch abgefangen und automatisch auf HTTPS umgeleitet werden.

Darüber hinaus weist das LDA Bayern auf die Gefahr hin, dass Angreifer Daten „auf Vorrat“ mitschneiden, um sie später mit einem geknackten oder gestohlenen Schlüssel lesbar zu machen. Tatsächlich hatten vor einiger Zeit Angreifer über die „Heartbleed-Lücke“ massenhaft private Verschlüsselungsschlüssel abgegriffen. Mit ihnen konnten die  Verbrecher nachträglich massenhaft Daten entschlüsseln, die sie zuvor über längere Zeit eingesammelt und auf Vorrat gespeichert hatten.

Diese Gefahr einer zukünftigen Entschlüsselung kann durch die Verwendung von Verschlüsselungsalgorithmen mit Perfect Forward Secrecy ausgeschlossen werden. Hierbei wird für jede einzelne Verbindung ein neuer Verschlüsselungs-Key erstellt. Wird später ein Schlüssel entwendet, so taugt dieser stets nur zum Knacken der aktuellen Datenverbindung.

Schlüssellängen

Für eine bis in die Zukunft weisende Datensicherheit sind zudem entsprechend große Schlüssellängen notwendig. Die Überlegung dabei: Schlüssel mit Längen, die sich heute nur mit einem zu großen (Zeit-)Aufwand knacken lassen, könnten mit fortschreitender Technikentwicklung in Zukunft schneller entschlüsselt werden. Daher sind kurze Schlüssellängen nur für sehr kurzfristig gültige Daten erlaubt, beispielsweise Session-Daten oder typischerweise TAN-Nummern von Banken, die nur wenige Minuten lag gültig sind. Nach diesem Muster sind für sehr lange Zeiträume gültige Daten – beispielsweise Gesundheitsdaten o.ä. – extrem lange, auch zukünftig nicht knackbare Schlüssellängen nötig. So empfiehlt das LDA Bayern folgende Schlüsselängen:

Heute sind vielfach jedoch auch Schlüssel mit 1024 Bit Länge im Einsatz. So hat das LDA Bayern in einer Untersuchung von Maillservern 2014 festgestellt, dass die Nutzung von 1024 Bit-Schlüssellängen noch dominiert – und zwar selbst dann, wenn der eigentliche Zertifikatsschlüssel länger ist:

Hierzu schreibt das BSI:

Das LDA Bayern geht hier sogar noch weiter. Es möchte die Ablösung der 1024er-Länge aktiv fördern und kündigt im Tätigkeitsbericht an, zu diesem Zwecke auch aufsichtlich aktiv zu werden:

Und was ist mit Mail?

Aus obengenannter Prüfung von Mailserver geht schon hervor, dass Onlinehändler (und sonstige Unternehmen) auch beim Mailverkehr mit ihren Kunden gefordert sind, deren Daten sicher schützen. Konkret verlangt wird dabei ein Versenden der Mails (so diese schützenswerte Daten enthalten, was allerdings i.d.R. der Fall ist) über Mailserver, die „so konfiguriert werden, dass diese eine opportunistische Transportverschlüsselung mittels SSL/TLS […] insbesondere auch STARTTLS zur Verschlüsselung unterstützen (LDA Bayern).

Zwar stellt das STARTTLS-Verfahren nur ein Angebot an den empfangenden Mailserver, die Mail verschlüsselt zu übertragen. Unterstützt der Empfangs-Mailserver diese Verschlüsselung nicht, so werden die Mails tatsächlich unverschlüsselt übertragen. Weil die Empfangsmailserver jedoch außerhalb des Einflussbereiches des Händlers liegen, hat dieser mit dem „Angebot“ der Verschlüsselung allein jedoch bereits seine Pflicht erfüllt.

Übrigens: Eine Verschlüsselung der Mailinhalte, beispielsweise per PGP oder S/MIME kann diese Übertragungsverschlüsselung ausdrücklich NICHT ersetzen. Denn werden PGP- oder S/MIME-verschlüsselte Nachrichten über einen unverschlüsselten Kanal versendet, so lassen sich die sogenannten „Meta-Informationen“ (Absender, Empfänger, Zeitpunkt oder Betreff) mitlesen. Dagegen hilft eben nur ein verschlüsselter Versand via STARTTLS. Allerdings: Sind in der Mail besonders stark zu schützende Daten enthalten, kann es notwendig sein, zusätzlich zum verschlüsselten Versand noch eine Inhaltsverschlüsselung vorzunehmen, dies ist z.B. bei Gesundheitsdaten denkbar, aber sicherlich nicht bei normalen Personen-/Einkaufsdaten.

Snowden-Enthüllung als Anlass

Warum wird der Transportverschlüsselung mittlerweile so ein hoher Stellenwert zugeschrieben? Schuld sind die Enthüllungen von Edward Snowden. Denn in der auch vom LDA Bayern genannten Entschließung (PDF-Download hier) zur vermehrten Kontrolle dieses Themas verweist die Datenschützer-Konferenz auf die Snowden-Enthüllungen über das massenhafte Abhören der Internetkommunikation.

Nach dem Motto, „wenn aller Datenverkehr mitgeschnitten wird, so muss eben auch aller Datenverkehr verschlüsselt werden, sobald er schützenswerte Daten beinhaltet“, fordert die Konferenz die entsprechenden Institutionen der Länder auf, zur Durchsetzung des geltenden Rechts aktiv zu werden.

Von daher ist zu erwarten, dass es in der Zukunft eher öfter als seltener zu Überprüfungen und entsprechend auch zu Abmahnungen kommen wird.

Auf einen Blick: Checkliste

• Alle Web-Formulare identifizieren, in denen personenbezogene Daten abgefragt werden: Kontaktformulare, aber z. B. auch Blogartikelseiten mit Kommentarfunktion oder mit Share-Funktionen, wenn über sie Login- oder Session-Daten weitergeleitet werden. Ebenso alle anderen Seiten mit Logins etc.)
• Alle diese Seiten über SSL/https einbinden.
• Direkte Aufrufe solcher Seiten über http verhindern, indem diese Aufrufe automatisch auf https umgeschrieben werden
• SSL-Zertifikat überprüfen: Hat es eine Schlüssellänge größer 1024-Bit (empfohlen wird 2048-Bit)? Wenn ja, prüfen: Nutzt die Webserverkonfiguration diese größere Länge auch? Wenn nein, entsprechend umkonfigurieren.
• Beträgt die Schlüssellänge des SSL-Zertifikates nicht mindestens 2048-Bit einen Wechsel auf diese empfohlene Länge für die nächste Zukunft planen und durchführen. Auch dann darauf achten, dass die Webserverkonfiguration die größere Länge nutzt.
• Mailserver überprüfen: Ist als Übertragungsart STARTTLS eingestellt? Wenn nein, umkonfigurieren. Auch hier die Schlüssellänge prüfen und ggf. größeren Schlüssel besorgen und einbinden.
• Darüber hinaus Webserver/Mailserver auf Vorhandensein bekannter Schwachstellen wie der Heartbleed-Lücke überprüfen und ggf. fixen.
• Wichtig: Das hilft alles nur, wenn die Kundenkommunikation dann auch wirklich ausschließlich über den Mailserver mit STARTTLS versendet wird. Wer hin und wieder auch von anderen Rechnern aus versendet (Stichwort Homeoffice) sollte diese daraufhin überprüfen, ob sie ebenfalls via STARTTLS angebunden sind oder evtl. noch andere Mailserver nutzen.

Herzlich aus Hürth
Nicola Straub