Keine Webformulare ohne (TLS-)SSL – Abmahngefahr?

Nicola Straub

vor 9 Jahren

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:

Werden Formulare oder andere Webelemente in Internetauftritten eingebunden, die es Webseitenbesuchern ermöglichen, personenbezogene Daten einzugeben und über das Internet zu übertragen, betrachten wir die Verwendung einer Transportverschlüsselung (TLS bzw. HTTPS) als erforderlich an, um auf dem Transportweg für den Schutz dieser personenbezogener Daten zu sorgen. Gleichzeitig sollen hierbei Verfahren zum Einsatz kommen, die auch eine nachträgliche Entschlüsselung des abgeschöpften Datenverkehrs erschweren (sog. Perfect Forward Secrecy).

Hintergrund dieser Anforderung ist, dass eine nicht-öffentliche Stelle nach § 9 BDSG die technischen und organisatorischen Maßnahmen treffen muss, die erforderlich sind, um die Ausführungen der Vorschriften des BDSG, insbesondere die in der Anlage zu § 9 BDSG genannten Anforderungen, zu gewährleisten. Im Rahmen der Zugangs-, Zugriffs- und Weitergabekontrolle (Anlage zu § 9 BDSG Satz 2 Nrn. 2 bis 4) sind insbesondere Verschlüsselungsverfahren nach dem Stand der Technik entsprechende Maßnahmen. Wir verweisen hierbei auch auf die veröffentlichte Entschließung „Gewährleistung der Menschenrechte bei der elektronischen Kommunikation“ der 87. Konferenz der Datenschutzbeauftragten des Bundes und der Länder vom 27. März 2014 (kostenfrei online verfügbar).

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:

Im Juli dieses Jahres ist das IT-Sicherheitsgesetz in Kraft getreten. Hiernach haben auch Shopbetreiber Pflichten zur Stärkung der IT-Sicherheit zu erfüllen. Darunter zählt in der Tat auch die Pflicht Maßnahmen nach dem „aktuellen Stand der Technik“ zu ergreifen, wozu insbesondere gängige, anerkannte Verschlüsselungsmaßnahmen zählen. Bezüglich Formularseiten, in denen persönliche Daten eingegeben werden, wie Anmelde oder Bestellformulare, ist dies sogar schon seit einigen Jahren in § 9 BDSG iVm Nr. 4 des Anhangs zu § 9 BDSG gesetzlich geregelt. Hier ändert sich lediglich die Bewertung des „aktuellen Stands der Technik“.

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:

Sofern personenbezogene Daten über das Web (HTTP) übertragen werden, ist eine HTTPS-Verschlüsselung einzusetzen. Dies betrifft z. B. die Eingabe von Zugangsdaten im Rahmen einer Authentifizierung (Login-Name und Passwort), die Übermittlung von Inhaltsdaten als auch Session-Token, die einen mittelbaren Personenzug herstellen können.

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:

So sollte beim symmetrischen AES-Verfahren eine Schlüssellänge von 256-Bit gewählt werden, die nach heutigem Kenntnisstand auch eine langgültige Vertraulichkeitgewährleistet – auch nicht so bekannte Verfahren wie beispielsweise Blowfish eignen sich beientsprechend langer Schlüssellänge. Bei Einsatz des asymmetrischen RSA-Verfahrens ist bei personenbezogenen Daten mit normalem Schutzbedarf eine Schlüssellänge von 2048-Bit als Stand der Technik anzusehen – bei erhöhtem Schutzbedarf und langgültiger Vertraulichkeit wäre eine Schlüssellänge bis zu 15360-Bit aus heutiger Sicht notwendig. Die Problematik liegt momentan aber darin, dass derart lange Schlüssel in der Praxis nicht effizient einsetzbar sind. In Anbetracht dieser momentanen Einschränkung sehen wir bei erhöhtem Schutzbedarf eine RSA-Schlüssellänge von 4096-Bit als zulässig aber auch zwingend notwendig an.

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:

Von maßgeblichen Experten wird vorhergesagt, dass 1024 Bit RSA-Moduli mit einem Aufwand von circa 2 hoch 80 Operationen faktorisierbar sind, und auch der Aufwand der besten generischen Algorithmen für das diskrete Logarithmusproblem in einer Gruppe der Ordnung 160 Bit liegt in dieser Größenordnung. Da der Aufwand von 2 hoch 80 Operationen mit Fortschreiten der Rechentechnik allmählich in den Bereich des technisch Machbaren gerät, sollten die derzeit eingesetzten Algorithmen mit 80 Bit Sicherheitsniveau (z. B. 1024 Bit RSA) bei Neuentwicklungen nicht mehr verwendet werden und auf längere Sicht ganz abgelöst werden. (Quelle)

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:

Zum jetzigen Zeitpunkt sehen wir RSA 1024-Bit als einen kritischen Grenzwert bezüglich der Schlüssellänge – es ist angedacht, nach Prüfung der Verhältnismäßigkeit entsprechend § 9 BDSG im Rahmen von weiteren automatisierten Online-Prüfungen eine Erhöhung der Schlüssellänge auf 2048-Bit (RSA) bei personenbezogenen Daten mit normalen Schutzbedarf und 4096-Bit (RSA) bei personenbezogenen Daten mit erhöhtem Schutzbedarf einschließlich Perfect Forward Secrecy als aktueller Stand der Technik aufsichtlich durchzusetzen.

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