Jetzt wird es mir langsam klar. Der technischen Pro-Argumentation für OpenSource von ebenda (tekkie und Mtt2) braucht man nichts hinzuzufügen. Man sollte wissen, dass Anwalt Jun auch Mitglied des Ausschusses für IT-Recht bei der deutschen Bundesrechtsanwaltskammer ist (laut wikipedia) und sich auch gegen Schulleiter die "Datenschutzfundamentalisten" wurden positioniert (https://www.sueddeutsche.de/digital/datenschutz-schule-zoom-microsoft-teams-1.5188101). Wie steht es eigentlich mit der immer schlechter bestellten Datensouveränität in Deutschland und exorbitant zunehmenden Ausgaben für Microsoft Lizenzen in Deutschland. Mich würde interessieren ob Microsoft Deutschland Kunde bei der Kanzlei von Jun ist oder nicht.

@Mtt Gute Idee. Danke.

Im Notfall kannst Du den Kommentar als Bild auf Twitter teilen (für Menschen mit Sehbehinderung wäre das allerdings keine praktische Lösung). Daher wirklich nur im Notfall und zusätzlich noch mal mit Link auf die Website.

Hallo Tekkie, ich finde Ihre Argumentation für mich ziemlich lehrreich, vor allem, was den technischen Unterschied zwischen Zoom und Open Source ausmacht. Erst einmal vielen Dank dafür! Wie Sie sehen, experimentiere ich noch etwas mit den Kommentaren, würde das aber freilich gerne irgendwie etwa über Twitter teilen, weil das wirklich lesenswert ist. Ich guck' mal, ob und wie ich das hinkriege. Grüße, Florian Güßgen

Bitte entschuldigen Sie, dass es mit der Freischaltung der Kommentare länger gedauert hat. Ich muss das noch etwas lernen – und mich jetzt mit der inhaltlichen Argumentation beschäftigen. :-)

Test zur Sichtbarkeit eines Kommentars, da meiner nicht dargestellt wird

Ich bin seit Jahren als technischer Berater in der IT-Security tätig und muss leider feststellen, dass das Kernargument von Herrn Jun technisch nicht plausibel ist. Natürlich ist es super und immer zu bevorzugen, wenn Ende-zu-Ende-Verschlüsselung möglich ist. Allerdings vergleicht Herr Jun hier Äpfel mit Birnen. Der große Vorteil von Open Source Lösungen ist doch, dass jeder seinen eigenen Server betreiben kann. Dies steht im Kontrast zu Plattformen mit zentralen Servern und meist geschlossenem Quellcode wie bspw. Zoom. Dieser Unterschied hat eine direkte Auswirkung auf die Sicherheitsbewertung hinsichtlich der Art der Verschlüsselung. Konkret meine ich damit: Wenn eine Schule ihren eigenen BigBlueButton- oder Jitsi-Server betreibt, haben nur die Schulangehörigen Zugriff auf den Server. Die Betreibenden des Servers (also die Schule) sollten ohnehin an den Konferenzen teilnehmen können. Daher ist es ausreichend, wenn hier eine Transportverschlüsselung mittels https verwendet wird und keine Ende-zu-Ende-Verschlüsselung. Anders verhält es sich bei Plattformen mit zentralen Servern wie bspw. Zoom. Hier nutzen viele Beteiligte aus unterschiedlichen Kontexten den Server und es gibt zusätzlich die Serverbetreiber. Um zu verhindern, dass die Serverbetreiber auf die Inhaltsdaten, d.h. die Konferenzen, zugreifen können, möchte man hier eine Ende-zu-Ende-Verschlüsselung vorliegen haben. Mit der Ende-zu-Ende-Verschlüsselung probiert man hier also einem Problem etwas entgegenzusetzen, das im Fall der OpenSource Lösungen gar nicht existiert. Generell wird Ende-zu-Ende-Verschlüsselung auch als zusätzliche Sicherheitsmaßnahme dagegen verwendet, dass ein Angreifer eine Lücke im Server ausnutzt und diesen dadurch kontrollieren kann. Je nach konkreter Architektur der Software, kann der Angreifer dann nicht auf die Inhaltsdaten zugreifen. Das ist hier aber nicht der Fall. Wie Herr Jun selber sagt, handelt es sich bei den Konferenzen meist nicht um Daten, die dauerhaft auf den Servern gespeichert werden. Das bedeutet, dass ein Angreifer unabhängig von der verwendeten Verschlüsselung nur auf die Konferenzen zugreifen kann, die stattfinden während er den Server kontrolliert. Man könnte nun argumentieren, dass Ende-zu-Ende-Verschlüsselung für diese Konferenzen einen Zugriff des Angreifers gänzlich verhindern würden. Das stimmt aber nicht. Die Anwendung, die bei vielen Nutzenden auf den Endgeräten läuft wird, meist als Webseite ausgeliefert. D.h. ein Angreifer, der den Server kontrolliert, kann einfach bestehende Ende-zu-Ende-Verschlüsselungen ausschalten, indem er die Anwendung anpasst. Dabei geschieht dies ohne, dass es den Beteiligten auffällt. Herr Jun greift in dem Gespräch auf, dass OpenSource Software auch Lücken aufweise und damit nicht automatisch sicherer wäre als closed-source Software. Das macht er am Beispiel der Heartbleed-Lücke deutlich. Natürlich gibt es auch in OpenSource-Projekten Lücken. Mache Projekte sind besser gepflegt und andere schlechter. In beinahe jeder Software bzw. jedem System (unabhängig von OpenSource oder nicht) gibt es Lücken, wenn man ausreichend viel Aufwand investiert. Aus eigener Erfahrung kann ich aber sagen, dass das Finden und Aufdecken solcher Lücken durch die Möglichkeit auf den Quellcode zugreifen zu können deutlich vereinfacht wird. Zusätzlich passiert es immer wieder, dass Unternehmen mit geschlossener Software nicht auf gemeldete Lücken reagieren und diese nicht schließen. Bei freier Software ist es Findern und Betreibern leichter möglich selber die Lücke zu beheben, indem sie den Code anpassen und anderen diese Patches zur Verfügung stellen. Herr Jun führt ebenso an, dass zoom kein Vertrauen mehr entgegen zu bringen sei nach all den Fehlern und Lücken, die in der letzten Zeit darin auftraten. Dies spricht umso mehr für Quelloffene Software, da man hier immerhin nachsehen kann und nicht blind dem Hersteller vertrauen muss, dass tatsächlich Ende-zu-Ende-Verschlüsselung eingesetzt wird und auch kein anderer Datenabfluss passiert. Letzteres wird durch das Betreiben eines eigenen Server schlicht unmöglich gemacht, wenn man den Fall eines gezielten Angriffs ausschließt. Die Anpassbarkeit von Software ist ein weiterer Punkt, der durchaus für freie Software im Schulbetrieb spricht. Dadurch, dass die Schulen für die Software nichts zahlen müssen und diese meist nach belieben verändern können, können sie diese theoretisch für ihre eigenen Zwecke anpassen. Diese Anpassungen können sie dann wiederum beliebig anderen zur Verfügung stellen, sodass bspw. auch andere Schulen davon profitieren können. Dadurch werden öffentliche Gelder nicht in einzelne Firmen investeriert sondern kommen der Allgemeinheit zu Gute. Darüberhinaus kann die an der Schule verwendete Software dann direkt in den Unterricht mit eingebunden werden. Z.B. können Informatikkurse praktische Softwareentwicklung an der Software lernen, indem sie für die Schule sinnvolle Features entwickeln oder indem man sich als Kurs ansieht, wie denn die Sicherheit der jeweiligen Software sichergestellt wird und wo es zu Fehlern kommt. Dass es gerade in Deutschland einen massiven digitalen Analphabetismus gibt, will ich gar nicht bestreiten. Daher wird die Anpassbarkeit, wie ich sie hier beschrieben habe, nur in wenigen Fällen so genutzt werden. Aber genau solche Fälle bewirken aus meiner Perspektive, dass der digitale Analphabetismus etwas reduziert wird, der uns erst in die Lage versetzt hat, keine ausreichende Infrastruktur für die Schulen in Pandemiezeiten zu haben. Man kann hierbei sicherlich hinterfragen, ob die Gedanken zur Anpassbarkeit nicht nachrangig zu betrachten sind, wenn man schnellstmöglich überhaupt erstmal einen digitalen Schulbetrieb ermöglichen möchte. Allerdings sind Menschen faul und seltener geneigt laufende Systeme zu verwerfen und durch andere zu ersetzen. Meine Befürchtung ist also, dass auch nach der Pandemie auf Systemen wie Zoom verharrt wird, weil diese eben laufen. Das heißt damit nicht, dass ich finde, dass dieses Argument automatisch eine zeitliche Dringlichkeit überwiegt, aber es sollte mit berücksichtigt und überdacht werden. Hierbei treffen wir ja dann letztlich eine Abwägung zwischen der Qualität des Unterrichts der aktullen Schülergeneration und der Qualität des Unterrichts und der Lerninhalte der darauffolgenden Generationen. Außerdem wird das Thema freie Software im Bildungskontext meiner Erfahrung nach selten berücksichtigt, weshalb ich den Gedanken in diesem Rahmen mal generell einbringen möchte. Herr Jun führt ebenfalls an, dass abseits der IP-Adresse keine weiteren Metadaten bei den geschlossenen Diensten wie Zoom anfallen würden. Das ist falsch. Nutzt man Zoom bspw. über den Browser, werden bspw. Useragent-Strings und damit Typ des Betriebsystems und Browser übermittelt sowie dessen Versionsnummern. Zusätzlich kann der Dienst auch Nutzungsverhalten analysieren, wie beispielsweise: Wann wird der Dienst von bestimmten Nutzenden wie lange mit welchen anderen Nutzenden verwendet? Werden diese Daten zusammengeführt mit Daten aus anderen Quellen, kann man hier durchaus Profile bilden und weitere interessante Aussagen ableiten.

Zu OpenSSL-Heartbleed: Der Fehler ist doch gerade deswegen aufgefallen, weil externe Sicherheitsforscher den Code angesehen haben. Auch wenn der Fehler erst sehr spät (zu spät) gefunden wurde, bestätigt dies doch eigentlich die Stärke von freier Open Source Software. Wäre der Quellcodes nicht zugänglich gewesen, wäre der Fehler ggf. noch heute enthalten. Andererseits gibt es Beispiele für Sicherheitslücken in proprietärer Software, die extrem lange enthalten waren. Über EternalBlue war jede Windows-Version ab XP angreifbar (XP ist 2001 erschienen). Die Lücke wurde erst 2017 geschlossen und führte zum Wannacry-Desaster. Weiterhin ist zu beachten, dass Zoom auch Open Source-Komponenten einsetzt (inkl. OpenSSL). Wir hätten bei Zoom somit die Sicherheitslücken, die wir in den Open Source-Komponeten finden können und zusätzlich noch potentielle Sicherheitslücken, die wir nur mit extrem viel Aufwand in den Closed-Source-Teilen von Zoom finden könnten.

Ich bin seit Jahren als technischer Berater in der IT-Security tätig und muss leider feststellen, dass das Kernargument von Herrn Jun technisch nicht plausibel ist. Natürlich ist es super und immer zu bevorzugen, wenn Ende-zu-Ende-Verschlüsselung möglich ist. Allerdings vergleicht Herr Jun hier Äpfel mit Birnen. Der große Vorteil von Open Source Lösungen ist doch, dass jeder seinen eigenen Server betreiben kann. Dies steht im Kontrast zu Plattformen mit zentralen Servern und meist geschlossenem Quellcode wie bspw. Zoom. Dieser Unterschied hat eine direkte Auswirkung auf die Sicherheitsbewertung hinsichtlich der Art der Verschlüsselung. Konkret meine ich damit: Wenn eine Schule ihren eigenen BigBlueButton- oder Jitsi-Server betreibt, haben nur die Schulangehörigen Zugriff auf den Server. Die Betreibenden des Servers (also die Schule) sollten ohnehin an den Konferenzen teilnehmen können. Daher ist es ausreichend, wenn hier eine Transportverschlüsselung mittels https verwendet wird und keine Ende-zu-Ende-Verschlüsselung. Anders verhält es sich bei Plattformen mit zentralen Servern wie bspw. Zoom. Hier nutzen viele Beteiligte aus unterschiedlichen Kontexten den Server und es gibt zusätzlich die Serverbetreiber. Um zu verhindern, dass die Serverbetreiber auf die Inhaltsdaten, d.h. die Konferenzen, zugreifen können, möchte man hier eine Ende-zu-Ende-Verschlüsselung vorliegen haben. Mit der Ende-zu-Ende-Verschlüsselung probiert man hier also einem Problem etwas entgegenzusetzen, das im Fall der OpenSource Lösungen gar nicht existiert. Generell wird Ende-zu-Ende-Verschlüsselung auch als zusätzliche Sicherheitsmaßnahme dagegen verwendet, dass ein Angreifer eine Lücke im Server ausnutzt und diesen dadurch kontrollieren kann. Je nach konkreter Architektur der Software, kann der Angreifer dann nicht auf die Inhaltsdaten zugreifen. Das ist hier aber nicht der Fall. Wie Herr Jun selber sagt, handelt es sich bei den Konferenzen meist nicht um Daten, die dauerhaft auf den Servern gespeichert werden. Das bedeutet, dass ein Angreifer unabhängig von der verwendeten Verschlüsselung nur auf die Konferenzen zugreifen kann, die stattfinden während er den Server kontrolliert. Man könnte nun argumentieren, dass Ende-zu-Ende-Verschlüsselung für diese Konferenzen einen Zugriff des Angreifers gänzlich verhindern würden. Das stimmt aber nicht. Die Anwendung, die bei vielen Nutzenden auf den Endgeräten läuft wird, meist als Webseite ausgeliefert. D.h. ein Angreifer, der den Server kontrolliert, kann einfach bestehende Ende-zu-Ende-Verschlüsselungen ausschalten, indem er die Anwendung anpasst. Dabei geschieht dies ohne, dass es den Beteiligten auffällt. Herr Jun greift in dem Gespräch auf, dass OpenSource Software auch Lücken aufweise und damit nicht automatisch sicherer wäre als closed-source Software. Das macht er am Beispiel der Heartbleed-Lücke deutlich. Natürlich gibt es auch in OpenSource-Projekten Lücken. Mache Projekte sind besser gepflegt und andere schlechter. In beinahe jeder Software bzw. jedem System (unabhängig von OpenSource oder nicht) gibt es Lücken, wenn man ausreichend viel Aufwand investiert. Aus eigener Erfahrung kann ich aber sagen, dass das Finden und Aufdecken solcher Lücken durch die Möglichkeit auf den Quellcode zugreifen zu können deutlich vereinfacht wird. Zusätzlich passiert es immer wieder, dass Unternehmen mit geschlossener Software nicht auf gemeldete Lücken reagieren und diese nicht schließen. Bei freier Software ist es Findern und Betreibern leichter möglich selber die Lücke zu beheben, indem sie den Code anpassen und anderen diese Patches zur Verfügung stellen. Herr Jun führt ebenso an, dass zoom kein Vertrauen mehr entgegen zu bringen sei nach all den Fehlern und Lücken, die in der letzten Zeit darin auftraten. Dies spricht umso mehr für Quelloffene Software, da man hier immerhin nachsehen kann und nicht blind dem Hersteller vertrauen muss, dass tatsächlich Ende-zu-Ende-Verschlüsselung eingesetzt wird und auch kein anderer Datenabfluss passiert. Letzteres wird durch das Betreiben eines eigenen Server schlicht unmöglich gemacht, wenn man den Fall eines gezielten Angriffs ausschließt. Die Anpassbarkeit von Software ist ein weiterer Punkt, der durchaus für freie Software im Schulbetrieb spricht. Dadurch, dass die Schulen für die Software nichts zahlen müssen und diese meist nach belieben verändern können, können sie diese theoretisch für ihre eigenen Zwecke anpassen. Diese Anpassungen können sie dann wiederum beliebig anderen zur Verfügung stellen, sodass bspw. auch andere Schulen davon profitieren können. Dadurch werden öffentliche Gelder nicht in einzelne Firmen investeriert sondern kommen der Allgemeinheit zu Gute. Darüberhinaus kann die an der Schule verwendete Software dann direkt in den Unterricht mit eingebunden werden. Z.B. können Informatikkurse praktische Softwareentwicklung an der Software lernen, indem sie für die Schule sinnvolle Features entwickeln oder indem man sich als Kurs ansieht, wie denn die Sicherheit der jeweiligen Software sichergestellt wird und wo es zu Fehlern kommt. Dass es gerade in Deutschland einen massiven digitalen Analphabetismus gibt, will ich gar nicht bestreiten. Daher wird die Anpassbarkeit, wie ich sie hier beschrieben habe, nur in wenigen Fällen so genutzt werden. Aber genau solche Fälle bewirken aus meiner Perspektive, dass der digitale Analphabetismus etwas reduziert wird, der uns erst in die Lage versetzt hat, keine ausreichende Infrastruktur für die Schulen in Pandemiezeiten zu haben. Man kann hierbei sicherlich hinterfragen, ob die Gedanken zur Anpassbarkeit nicht nachrangig zu betrachten sind, wenn man schnellstmöglich überhaupt erstmal einen digitalen Schulbetrieb ermöglichen möchte. Allerdings sind Menschen faul und seltener geneigt laufende Systeme zu verwerfen und durch andere zu ersetzen. Meine Befürchtung ist also, dass auch nach der Pandemie auf Systemen wie Zoom verharrt wird, weil diese eben laufen. Das heißt damit nicht, dass ich finde, dass dieses Argument automatisch eine zeitliche Dringlichkeit überwiegt, aber es sollte mit berücksichtigt und überdacht werden. Hierbei treffen wir ja dann letztlich eine Abwägung zwischen der Qualität des Unterrichts der aktullen Schülergeneration und der Qualität des Unterrichts und der Lerninhalte der darauffolgenden Generationen. Außerdem wird das Thema freie Software im Bildungskontext meiner Erfahrung nach selten berücksichtigt, weshalb ich den Gedanken in diesem Rahmen mal generell einbringen möchte. Herr Jun führt ebenfalls an, dass abseits der IP-Adresse keine weiteren Metadaten bei den geschlossenen Diensten wie Zoom anfallen würden. Das ist falsch. Nutzt man Zoom bspw. über den Browser, werden bspw. Useragent-Strings und damit Typ des Betriebsystems und Browser übermittelt sowie dessen Versionsnummern. Zusätzlich kann der Dienst auch Nutzungsverhalten analysieren, wie beispielsweise: Wann wird der Dienst von bestimmten Nutzenden wie lange mit welchen anderen Nutzenden verwendet? Werden diese Daten zusammengeführt mit Daten aus anderen Quellen, kann man hier durchaus Profile bilden und weitere interessante Aussagen ableiten.

Gibt es für Zoom einen Beleg, dass die Ende-Zu-Ende-Verschlüsselung auch wirklich funktioniert und keine Fehler enthält? Ohne Quellcode von Zoom ist das praktisch nicht nachvollziehbar. Ich würde den Standpunkt vertreten, dass Verschlüsselungssoftware immer quelloffen sein muss. Zumindest frühere oberflächliche Analysen von Zoom haben wohl einige Schlampereien gezeigt (nicht bezogen auf E2E-Encryption): https://www.heise.de/security/meldung/Analyse-Windows-Client-der-VIdeokonferenz-Plattform-Zoom-mit-Angriffspotenzial-4704624.html