Guten Abend,
http://www.brak.de/fuer-journalisten/pressemitteilungen-archiv/2017/presseerklaerung-15-2017/ vermeldet:
Allen Rechtsanwältinnen und Rechtsanwälten, die entsprechend der ursprünglichen Empfehlung vom 22.12.2017 das ersatzweise bereitgestellte Sicherheitszertifikat installierten, rät die BRAK dringend zur Deinstallation, um sich aus dem Zertifikat möglicherweise ergebende Sicherheitsrisiken für die individuelle PC-Umgebung auszuschließen. "Es ist bedauerlich, dass das beA, eine für die deutsche Anwaltschaft besonders wichtige technische Errungenschaft, derzeit nicht zur Verfügung steht. Die BRAK räumt der Sicherheit des beA und aller Anwältinnen und Anwälte, die das beA einsetzen, absoluten Vorrang ein. Das betrifft insbesondere auch mögliche Hackerangriffe auf die Client-Security", so Dr. Martin Abend, Vizepräsident der BRAK. Daher habe die BRAK auch vom technologischen Dienstleister vorgeschlagene Zwischenlösungen verworfen. „Im Interesse eines sicheren elektronischen Rechtsverkehrs und zum Schutze der Anwalt- schaft wird das beA wieder zur Verfügung stehen, sobald unser Dienstleister eine Lösung für diese Sicherheitslücke gefunden hat“, so Dr. Abend weiter.
Schön, dass Zwischenlösungen verworfen werden und das beA bis zu seiner Vollendung offline bleibt. Was bedeutet das für unser Problem? Wenn die Zertifikatssperre darauf zurückzuführen ist, dass der private Schlüssel für den Webserver, der lokal auf Port 9998 lauscht, in die Client-Software integriert ist,
Zertifikat samt privatem Schlüssel Teil der Software
Das Problem dabei: Da die Software ja selbst die HTTPS-Verbindungen durchführt, muss der private Schlüssel Teil der Software sein. Damit bietet aber eine solche HTTPS-Verbindung keinerlei Schutz. Ein Man-in-the-Middle-Angreifer hätte durch manipulierte DNS-Antworten Anfragen nach bealocalhost.de auf seinen eigenen Server umleiten und dort eine falsche Version der beA-Software präsentieren können.
Doch diese Vorgehensweise ist nicht nur unsicher, sie verstößt auch gegen die Regeln für Zertifizierungsstellen, die sogenannten Baseline Requirements. Diese sehen vor, dass Zertifizierungsstellen Zertifikate, deren privater Schlüssel kompromittiert ist, innerhalb von 24 Stunden zurückziehen müssen.
Markus Drenger vom Chaos Computer Club Darmstadt hatte dieses Zertifikat und den privaten Schlüssel entdeckt - und das Problem an Telesec gemeldet, die daraufhin das Zertifikat zurückzogen. Heise Online hatte gestern darüber berichtet.
(https://www.golem.de/news/bea-bundesrechtsanwaltskammer-verteilt-https-hintertuere-1712-131845.html)
wird man sich darauf einzustellen haben, dass am Konstrukt des Clients Änderungen vorgenommen werden müssen. Für die zukünftige Version stellt sich somit von Neuem die Frage: Läuft es unter dem eingesetzten Linux-Derivat oder nicht. Welchen Vorschlag würde ein Jurist in dieser Situation machen? Bringen wir den Thread hier durch übereinstimmende Parteierklärungen einstweilen zum Ruhen, bis ATOS bzw. die BRAK mit dem neuen Client am Start sind. Das ist in jedem Falle "zweckmäßig" aus sonstigen wichtigen Gründen i. S. v. § 251 S. 1 ZPO.
😬
Viele Grüße und allen einen guten Rutsch nach 2018, coolwalda.