1 2 Zurück Weiter 43 Antworten Neueste Antwort am 02.01.2018 12:43 von akoppel

    beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?

    michael.renz Aufsteiger

      wie eben in den diversen Gruppen Online gepostet wird, scheint die von der BRAK/ATOS gestern nach dem Zertifikatchaos „rausgehauene“ Notlösung das Zeug zur digitalen Katatrophe zu haben.

       

      Auf golem wird berichtet, dass mit dem schnell freigegeben Ersatzzertifikat s.g. Man-In-the-Middle Angriffe ermöglicht werden.

       

      Ich hoffe bloß, dass uns diese Katastrophe erspart bleibt. Unbedingt den nachfolgenden Artikel lesen und die evtl. installierten Zertifikate löschen!!!!!!!

       

      https://www.golem.de/news/bea-bundesrechtsanwaltskammer-verteilt-https-hintertuere-1712-131845.html

       

      Nachtrag vom 26.12. (11:50)

       

      weil es in meinem Thread nicht so explizit zum Ausdruck kommt will ich kurz schildern, warum ich auf meinen Produktivsystemen den SecurityClient der BRAK deinstalliert habe.

      1. am 22.12. war das für die Funktion des SecurityClient ausgestellte Zertifikat gesperrt worden -> damit war beA nicht mehr erreichbar und (so die IT-ler in den Foren) konnte im Grunde nichts Sicherheitsrelevantes mehr passieren.
      2. am späten Vormittag des 22.12. wurde von der BRAK (oder deren Dienstleister) ein (erstes) self-signed-Ersatzzertifikat mit Installationsanleitung bereit gestellt. Bei der Installation sollte dieses Zertifikat in "Vertrauenswürdige Stammzertifikate" Speicher des Browsers installiert werden. Dies führte zu der zutreffenden Meldung in den Browsern, dass diese Vorgehensweise den Sicherheitsrichtlinien widerspricht.
      3. kurze Zeit nach der in Ziff. 2 beschrieben Maßnahme (gegen 15:00 Uhr) war der Download des Ersatz-Zertifkats nicht mehr möglich, es wurde vom SecurityClient beim Start "selbst installiert" (ohne Sicherheitswarnungen). Damit dies funktioniert hat dieses (2. Ersatz-)Zertifikat (verkürzt dargestellt) alle Zertifikats-Sicherheitsmaßnahmen auf dem lokalen PC "ausgeschaltet".
      4. Am frühen Abend des 22.12. war dann beA vom Netz und damit der Aktualisierungsprozess des SecurityClient der die Zertifikate "sicherheitswidrig" verteilt/installiert hat "ausgeschaltet". Dies hält nach dem Konzept des "Selbstupdates" bis zur Wiedererreichbarkeit der beA-Seiten an.

       

      Auch wenn das ziemlich untechnisch und von einem "Nur-Anwalt" geschrieben ist, hoffe ich doch, dass es den wesentlich Gang korrekt beschreibt.

       

      Da zum Konzept des SecurityClients vom 26.11.2017 (Ver. 3.1.3.0) gehört, dass er sich bei Erreichbarkeit der beA-Seiten selbst aktualisiert und dies am 22.12. gem. oben Ziffer 3. zu einer "missbräuchlichen Nutzung" eines Zertifikats verwendet wurde, habe ich mich entschlossen, den SecurityClient der BRAK auf allen Produktivsystemen zu deinstallieren - dieses von der BRAK (ihren Partnern) unter Ziffer 3 ausgelöste Sicherheitsleck ist einfach viel zu groß (von mir jedenfalls nicht sinnvoll anders eingrenzbar) als das damit verbundene Risiko einzugehen.

       

      Die BRAK schweigt zum Thema und wegen des "Selbstaktualisierungsprozess" des SecurityClients der BRAK ist absolut nicht abschätzbar, wer von der unter Ziffer 3 beschriebenen Problematik betroffen ist. Während die o.a. Ziff 2. aktiv veranlasst werden musste, sind die "stillen Updates" in o.a. Ziffer 3 des halb VIEL gefährlicher (meine ich wenigstens). Um das für die Zukunft auszuschließen bleibt nur die Deinstallation:

      1) des SecurityClients der BRAK

      2) des ggf. im Zertifikatsspeicher "Vertrauenswürdige Stammzertifikate" aufzufindenden Zertifikats "bealocalhostde.cer" über

      • IE-Browser starten
      • Extras; Internetoptionen aufrufen
      • dort Registerkarte "Inhalte"
      • dort "Zertifikate"
      • dort Reiter "Vertrauenswürdige Stammzertifikate"

      aufrufen und das o.a. Zertifikat suchen und löschen UND NUR DAS UND SONST KEIN ANDERES!!!

      Geändert am 26.12.17 um 12:23 Uhr
        Alle Antworten
        • 2. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
          michael.renz Aufsteiger

          Bei heise ist der Artikel von gestern!!! und das Update vor der Veröffentlichung von GOLEM.

           

          ich habe sicherheitshalber den WEB-Scurity-Client von beA und auf allen Geräten das installierte Zertifikat gelöscht. Ein Risiko - wie bei GOLEM beschrieben - würde ich jedenfalls nicht eingehen wollen.

           

          Für mich ist jedenfalls bis 31.12.2017 beA auf dem Produktivsystem raus!!!! Mal sehen wie BSI und BRAK reagieren. Kann nur hoffen, dass nicht viele Kollegen die Notlösung eingesetzt haben.

          Geändert am 23.12.17 um 16:14 Uhr 1 von 1 Personen fanden dies hilfreich
          • 3. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
            kroerig Einsteiger

            Hallo Herr Renz,

             

            kann man das seinen Kunden gefahrlos raten?

             

            Ich gehe bis nicht davon aus, dass es bis 31.12., 23:59 Uhr eine Lösung geben wird.

             

            Soweit ich das bisher aus dem, was an die Öffentlichkeit gedrungen ist beurteilen kann, haben die mit dem aktuellen Konzept keine Chance das in der Kürze der Zeit zu reparieren.

             

            Damit wäre es nicht möglich ab dem 01.01. Nachrichten aus dem beA abzurufen, selbst wenn man das Postfach vorschriftsmäßig rechtzeitig aktiviert hat. Was nun?

             

            Wie groß ist das Risko, dass jemand den lokalen PC erfolgreich angreift? Und welche Daten kann er dann abfangen? Da es keine (öffentliche) Verfahrensdokumentation des beA-Clients gibt, kann ich das nicht beurteilen.

             

            Was kann ein Anwalt jetzt machen?

            • 4. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
              michael.renz Aufsteiger

              Hallo Herr Rörig,

               

              meine EDV-Kenntnisse reichen nicht aus, um zu beurteilen, ob bis 31.12.2017 24:00 Uhr das (bzw. die zwischenzeitlich bekannten VIELEN) Probleme beseitigt sind. Ich schätze jedoch, dass das nicht der Fall sein kann - so wie ich diesen Artikel verstehe, ist das grundlegende Konzept schon vermurkst.

               

              Falls beA am 27.12. - wider Erwarten - wieder ans Netz geht, werde ich den unsicheren Securityclient nebst der nötigen Kartenleser etc auf ein einziges Stand-Alone-Gerät installieren auf dem nichts anderes als die Abwicklung der beA-Post geschieht.

               

              Das ist zwar maximal unkomfortabel, aber technisch und zur Vermeidung unabsehbarer Haftungsrisiken nach dem 1.1.18 wohl kaum anders lösbar. Ob allerdings beA überhaupt bis 1.1. am Netz ist, ist mehr als unsicher. Was ich in diesem Fall mache, kann ich nicht sagen!

               

              Zulassung zurückgeben - dann jedenfalls kann mir keiner mehr was ins beA zustellen   - wäre eine sehr radikale Lösung.

              Geändert am 25.12.17 um 10:05 Uhr
              • 5. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                akoppel Beginner

                Die Sache ist ganz einfach, es ist ein quasi unlösbares Dilemma. Selbst erzeugte Zertifikate werden per se vom Browser als nicht sicher eingestuft (daher auch die dicken Warnungen) und ein qualifiziertes - soll heißen offiziell signiertes und anerkanntes - Zertifikat muss für jeden Rechner individuell erstellt, von einem Trust Center (gegen Gebühren) bestätigt und dann auch noch auf dem PC eingespielt werden.

                Umgehen kann man das nur dadurch, indem man den eigenen PC zum Trust Center macht, und dann damit seine eigenen Zertifikate als vertrauenswürdig erklärt.  Damit wiederum reißt man ein gigantisches Sicherheitsloch in die Sicherheitsarchitektur des eigenen PCs, denn damit sind dann nämlich alle anderen wichtigen Zertifikate (z.B. fürs Online banking) schlagartig nicht mehr sicher. Man hat also die Sicherheitswarnungen aus Vorschlag eins dadurch abgeschaltet, indem man sämtliche Schutzmechanismen ausgeschaltet hat.

                Die BRAK machte zur Lösung den ersten Vorschlag oben, das ist ihnen wegen der fetten Sicherheitswarnungen um die Ohren geflogen, darauf hin schlugen sie Variante zwei vor, und das hats dann noch schlimmer gemacht, die Fachleute grossen kübelweise Kommentare bezüglich des Irrsinn aus.

                Tatsächlich gibt es eben keine Lösung für dieses Dilemma, es ist failure by Design. Die BRAK muss das gesamte Kommunikationsdesign umbauen - bis zum 1.1.2018. Viel Spaß dabei. Ach übrigens, dass muss dann natürlich noch alles getestet und ein gespielt werden, auf über 100.000 PCs

                • 6. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                  zippo Aufsteiger

                  Moin,

                   

                  so wie ich das verstehe, gibt es nur eine saubere Lösung: Jeder Anwalt kauft sich ein eigenes Zertifikat für seinen Client.

                   

                  Das wird bis Montag nicht ganz einfach.

                  • 7. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                    kroerig Einsteiger

                    OK, die ersten 5 können das machen. Dann sind die öffentlichen CAs aufgebraucht.

                    • 8. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                      mkinzler Fachmann

                      Oder die BRAK besorgt sich eine entsprechendes intermediate Zertifikat und signiert die Zertifikate der einzelnen Anwälte.

                      • 9. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                        akoppel Beginner

                        Das ist vollkommen korrekt, das wäre die saubere Lösung. Da gibt's jedoch zwei Probleme:
                        1) Kosten: min. 40,- € pro Zertifikat für jeden Rechner pro Jahr (sind bei 100.000 Rechnern min 4 Mio, hinzu kommen noch die Installationsaufwendungen, sagen wir noch mal 20,- € pro Rechner, sind wir bei 6 Mio Zusatzkosten, da wird sich die Anwaltschaft freuen, zumal das auch sehr sehr viel höher liegen könnte (teureres Zertifikat, durchaus bis zu 600,- € pro Zertifikat pro Jahr pro PC, oder sehr viel mehr Rechner)
                        2) Alle Zertifikate müssten auf den gleichen Domainnamen ausgestellt werden bealocalhost, und ich denke, dass das gar nicht zulässig ist

                        • 10. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                          zippo Aufsteiger

                          Stimmt. An Punkt 2 hatte ich nicht gedacht. Also entweder spricht der Client sich selbst mit seinem korrekten Namen an, zu dem es dann ein Zertifikat gibt, oder er verwendet HTTP.

                           

                          In beiden Fällen kommt eine Neuinstallation auf uns zu.

                           

                          Gut, dass wir nur einen PC dafür gebaut haben.... Das ist ja noch schlechter, als ich eh schon dachte.

                           

                          Gruß aus Hamburg

                          • 11. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                            rganter Einsteiger

                            Sehr geehrter Herr Koppel,

                            Sie scheinen ja vom Fach zu sein. Was spricht dagegen die interne Verbindung via HTTP zu machen? Es geht ja um die Kommunikation zwischen beA-Client und Browser (oder hab ich das falsch verstanden?). Sicherheitsproblem?

                            Der EGVP Client macht das meines Wissens ja auch so.

                             

                            Nachtrag: Fehler bereinigt

                            Geändert am 27.12.17 um 13:15 Uhr
                            • 12. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                              kroerig Einsteiger

                              Sehr geehrter Herr Koppel,

                              Sie scheinen ja vom Fach zu sein. Was spricht dagegen die interne Verbindung via HTTP zu machen? Es geht ja um die Kommunikation zwischen beA-Client und Kartenleser (oder hab ich das falsch verstanden?). Sicherheitsproblem?

                              Der EGVP Client macht das meines Wissens ja auch so.

                              Der Anspruch der BRAK, dass sämliche Kommunikation verschlüsselt erfolgen soll. Das ist auch sinnvoll.

                              Es geht um die Kommunikation zwischen Browser und dem beA-Security-Client. Letzterer übernimmt die Kommunikation mit dem Security-Token (Smartcard o.ä.).

                               

                              Der EGVP Client war eine komplette Java-Anwendung, genauso der Nachfolger. Hier ist die Kommunikation einfacher.

                              • 13. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                akoppel Beginner

                                Hallo Herr Ganter,
                                interne Kommunikation ohne Absicherung, also http statt https ist höchst ambivalent zu sehen. Einerseits ist das ja tatsächlich nur rechnerintern, andererseits, was heißt schon rechnerintern? Ich könnte mir vorstellen, das man da eine Sicherheit "vortäuschen" wollte (alles so schön grün in der Browseradresszeile). Andererseits hätte man die Möglichkeit, den beA-Client-Server auf einem dediziertem Rechner (also im Intranet) zu betreiben. Da ergibt die Verschlüsselung dann durchaus Sinn. Das ist derzeit jedoch weder vorgesehen noch technisch implementiert.
                                Mit anderen Worten, so in dieser Form ergibt das keinen Sinn.

                                • 14. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                  zippo Aufsteiger

                                  (alles so schön grün in der Browseradresszeile). .

                                  Das dürfte der Grund sein. Firefox sagt bei HTTP-Verbindungen jetzt schon "Verbindung nicht sicher". Andere Browser werden das demnächst auch machen.

                                   

                                  Und wie erklärt man der Zielgruppe dann, dass damit nicht die Verbindung zum beA-Server gemeint ist? Aussichtslos.

                                  • 15. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                    kroerig Einsteiger

                                    Es geht hier nicht um vortäuschen. Über diese Verbindung Browser -  Security-Client läuft die Authentifizierung ab. Zudem beim Versenden von Nachrichten mit qeS auch die entsprechenden Signaturdaten. Da ist eine gesicherte Verbindung schon wünschenswert.

                                     

                                    Zudem spielen die heutigen Browser nicht mehr mit, wenn eine gesicherte Seite unsichere Seiteninhalte nachladen/ anzeigen soll. Versuchen Sie mal auf einer HTTPS- Seite ein iFrame mit HTTP-Inhalten einzubinden. Der Firefox wird es nicht anzeigen.

                                    Geändert am 27.12.17 um 13:53 Uhr
                                    • 16. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                      rahayko Einsteiger

                                      Wenn ich hier lese, dass es um die Kommunikation zwischen Browser und beA geht, drängt sich mir die Frage auf, ob das Problem bei der Nutzung mit Daten das selbe ist.

                                      Hätte das Datev-Progam auch die Probleme mit dem Zertifikat?

                                      • 17. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                        kroerig Einsteiger

                                        Wenn ich hier lese, dass es um die Kommunikation zwischen Browser und beA geht, drängt sich mir die Frage auf, ob das Problem bei der Nutzung mit Daten das selbe ist.

                                        Hätte das Datev-Progam auch die Probleme mit dem Zertifikat?

                                        Es geht nicht um die Kommunitation zwischen Browser und der beA-Anwendung. Die ist sauber abgesichert. Sondern um Browser und lokaler beA-Security-Client. Hier klafft die Lücke.

                                         

                                         

                                        Ob die Implementierung der DATEV davon auch betroffen ist/wäre, kann nur DATEV beantworten. Die Dokumentation der Schnittstellei ist (wie leider bei vielen derartiger Projekte) nicht öffentlich erhältlich. [Sonst hätte der CCC die Schwachstellen schon früher gemeldet]

                                         

                                        Wenn ich Michael Renz richtig verstanden habe, dann muss auch bei der Nutzung der DATEV-Schnittstelle der Security-Client der BRAK installiert sein

                                        • 18. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                          akoppel Beginner

                                          Man kann aber ganz generell sagen, dass Java-Anwendungen auf Clients (also PCs) keine wirklich gute Idee sind. Das BSI rät schon seit Jahren davon ab, Java auf PCs zu installieren. JAVA ist immer wieder aufs neue führend bei der Anzahl der Sicherheitslücken. Mit sowas baut man einfach kein Hochsicherheitssystem. Das ist nicht nur failure by design, sondern failure overall. Zudem dann auch noch Oracle JDK statt Open JDK. Das ganze Design ist damit mehr als 10 Jahre hinter der Zeit.

                                          • 19. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                            kroerig Einsteiger

                                            Ich bin auch kein Freund von Java. Aber wenn Anwendungen plattformübergreifend sein sollen, ist Java die einfachste Lösung. Es gibt eine gemeinsame Codebasis und im besten Fall keine Sonderbehandlungen für die jeweiligen Plattformen.

                                             

                                            Ich bin ja schon froh, dass der Client nicht als Java-Webstart implementiert wurde (Applets führt ja außer dem IE zum Glück kein aktueller Browser mehr aus). So muss zumindest kein JRE auf den PCs installiert werden. Der Client bringt sein JRE mit. (Leider, wie fast schon üblich, in einer deutlich zu alten Version. Aber bei ÖA bin ich nichts anderes gewohnt).

                                             

                                            Wobei..., würde mich nicht wundern, wenn die Lösung, die jetzt kommen könnte, Java-Webstart wird. Nur dann muss man leider Java installieren. Und dann kommt das nächste Problem, nämlich wenn unterschiedliche Webstart-Programme auf unterschiedliche JREs angewiesen sind, und dann die beA-Lösung nur mir einer alten Version läuft.

                                            • 20. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                              akoppel Beginner

                                              Server-Based-Java ist ja durchaus ok (auch wenn ich absolut kein Freund davon bin), aber auf PCs gehört per se kein Java (höchstens Java-Script, aber das ist eben kein Java). Das ganze beA-Zeugs ist Java (wenn auch gekapselt). Wenn man sowas richtig machen will, dann programmiert man das noch immer in C und vor allem, man macht das alles öffentlich (GitHub), so dass es auf andere Platformen portiert werden kann. Java ist bequem und einfach und unpflegbar, weil jedesmal, wenn es eine neue Java-Release gibt, man mit der Fehlersuche von vorne anfängt. Wenn man Code in C schreibt, dann kann man den auch 30 Jahre später noch verwenden. In der Ingenieurswelt und bei Wissenschaftlern wird aus diesem Grund übrigens auch noch immer die Programmiersprache Fortran verwendet, schlicht weil nämlich ziemlich intelligente Leute schon vor 50 Jahren Algorithmen entwickelt haben, die auch heute noch hervorragend und unglaublich performant laufen. Man muss einfach sehen, dass Java eine Blackbox ist, d.h. der Computer arbeitet den Code nicht direkt ab, sondern der Computer betreibt "einen simulierten Computer" der Java spricht. Damit kommt Java performancetechnisch niemals auch nur ansatzweise an echte Compilersprachen ran und das ist auch der Grund, warum es quasi kein Java auf Kleinstgeräten (Tablets, Smartphones etc.) gibt. Alleine der Betrieb Ihres beA-Java-Clients dürfte übrigens die Performance Ihres PCs spürbar verschlechtern (wenn er nicht von der neuesten Generation ist). Das Wiederum erzeugt Zusatzkosten (Strom oder neue Hardware). Lange Rede kurzer Sinn: PC-Based-Java: no go

                                              • 21. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                agmü Fortgeschrittener

                                                Wieso brauchen Sie kein Java?  Für das Aufladen der (qualifizierten) Signatur, das Ändern der PIN und das zurücksetzen der Zähler bei wiederholter Falscheingabe brauchen Sie doch das wirklich hervorragende Tool, basierend auf Java, der Bundesnotarkammer.

                                                • 22. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                  akoppel Beginner

                                                  Nur weil einer einen grundsätzlichen Konzeptionsfehler macht, muss man den doch nicht wiederholen. Kryptografie-Funktionen, Ansprechen von Kartenlesegeräten u.v.m. ist alles Code, der in C geschrieben wurde, nichts (und zwar garnichts) davon wurde wirklich in Java programmiert. Tatsächlich sind die grundliegenden Funktionen für derartige Basics quasi immer in C programmiert, und dann werden im Nachgang Java-Funktionen geschrieben, die wiederum diese C-Funktionen aufrufen, damit "Schönwetterprogrammierer" sich nicht mit C rumschlagen müssen.
                                                  Das ist vergleichbar mit einem Sportwagen:
                                                  Der echte Rennfahrer setzt sich in ein echtes Rennauto, da muss er alles selber im Blick haben, braucht viel Geschick und Erfahrung, um das Fahrzeug zu beherrschen.
                                                  Der Hobby-Pilot setzt sich in seinen Porsche-Panamera (in dem unter dem Blechkleid in den Tiefen versteckt auch ein Rennauto steckt) und die ganze Komforttechnik und Elektronik nimmt dem Fahrer die Arbeit ab. Bezahlen tut der Fahrer das mit geringerer Performance (im Vergleich zum echten Rennauto, weil z.B. die beheizbaren Massagesessel sehr viel schwerer sind) und sehr viel größerer Fehlerträchtigkeit (weil so viel Zeugs auf die Auto-Basis des Rennwagens draufgepackt wurde).
                                                  Ich entwickle seit Anfang der 80iger Jahre Software, beherrsche (mehr oder weniger) 12 (sic) Programmiersprachen (einige davon richtig perfekt), habe Software für die Chemie-Industrie, Automobilindustrie, Verkehrsleitsysteme, die European-Space-Agency und die Justiz geschrieben (um nur einige wenige zu nennen). Es gibt einige zehntausend Systeme weltweit, die auf von mir in C geschriebenen Bibliotheken basieren und seit über 20 Jahren im Dauereinsatz sind. In absolut keinem Fachbereich, in dem "Mission-Critical-Applications" benötigt werden, setzt man Java ein.
                                                  Also nochmal zusammengefaßt: Java ist eine abstrahierende Programmiersprache, die in der Regel Programmbibliotheken, die in anderen Programmiersprachen erstellt wurden, in einer kommoden Umgebung einem Programmierer zur Verfügung stellt, der sich nicht mit den zugrunde liegenden Programmiersprachen beschäftigen mag.

                                                  • 23. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                    agmü Fortgeschrittener

                                                    Leider scheint mein ironisch gemeinter Hinweis nicht verstanden worden zu sein.

                                                     

                                                    Ich bin bei Ihnen Herr Koppel:  Java hat auf Arbeitsplatzrechnern nichts zu suchen.  Die Kammer nötigt die Anwender jedoch dazu, Java zu installieren, weil ihre Dienstleister (ATOS und BNotK) nichts anderes können.

                                                     

                                                    Bei Durchsicht meiner archivierten E-Mail-Nachrichten habe ich festgestellt, dass ich bereits in einer Mail aus dem September 2015 gegenüber der Kammer meine Bedenken hinsichtlich der Tauglichkeit des Konzeptes kund getan habe.

                                                    • 24. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                      akoppel Beginner

                                                      Um Ihre Frage zu beantworten:
                                                      Das von Ihnen beschriebene hervorragende Tool mag auf Java basieren, aber der Java-Code selbst wiederum greift auf C-Bibliotheken zurück, die dann "die echte Arbeit" machen.
                                                      Wir reden hier vom Management personenbezogener Daten, von Kryptographie und anderen kritischen Dingen. Als ernstzunehmender Profi will ich da keine Blackbox namens Java zwischen haben, sondern nutze die zugrunde liegenden Ausgangswerkzeuge, und die sind nun mal C.
                                                      Anders ausgedrückt: Sie nutzen keine Java-Bibliotheken, sondern sie nutzen C-Bibliotheken. Java ist nur all das Zeugs, was oben drauf gesetzt wird, um die Programmierung "bequem" zu machen. die Bequemlichkeit erkauft man sich mit Sicherheits- und Performancemängeln. Wenn man's professionell macht, dann programmiert man alles in C (oder einem Derivat davon) oder von mir aus teilweise auch noch in Fortran.

                                                       

                                                      Nachtrag: Weder Apple noch Microsoft nutzen Java für ihre Applikationsentwicklung (sondern C-Derivate), SAP setzt auf der echten kritischen Ebene ebenfalls auf C (den Rest z.B. ADABAS haben die selbst gebaut, und der setzt auch wieder auf C auf).

                                                       

                                                      Und dann ist die Notarkammer stolz darauf Java einzusetzen? Das zeugt doch nur davon, dass man sich mit den Grundlagen kryptografischer Systeme einfach mal überhaupt nicht beschäftigt hat und statt dessen Schönwetterprogrammierern traut, die episch umfangreichen Java-Code für ein immenses Geld "zusamenklöppeln" (und ganz unten steckt doch wieder C).

                                                       

                                                      Wenn Sie mit einem U-Boot in 10.000 Meter Tiefe abtauchen, lassen Sie sich das Boot dann von jemandem bauen, der seine Komponenten im Baumarkt kauft (weil jeder den Namen kennt und man (einfach wegen des Namens) der Ansicht ist, da könne man auch selber was machen) oder setzen Sie auf eine Firma, die alles selber baut (aus hochwertigem Stahl mit normierten und geprüften Schweißverfahren), obwohl Sie vielleicht noch nie gehört haben, was Schutzgasschweißen ist? Profis setzen Profiwerkzeuge ein, und die Bekanntheit eines Namens (Java) in der Öffentlichkeit sagt vielleicht etwas über das Marketing, jedoch niemals etwas über die Qualität aus.

                                                       

                                                      Softwareentwicklung hat sich in den letzten Jahrzehnten deutlich fortentwickelt, die echten Profis setzen im "Mission-Critical" oder hochsensiblem Bereich jedoch noch immer auf die bewährten Tools (und da verbietet sich nun mal Java).

                                                      • 25. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                        akoppel Beginner

                                                        Entschuldigen Sie bitte vielmals, die Ironie ist mir wirklich nicht aufgefallen (Asche auf mein Haupt), das mag daran liegen, dass ich wegen der ganzen stressigen beA-thematik derzeit ziemlich angefressen bin :-)

                                                        • 27. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                          akoppel Beginner

                                                          Was sollen wir Softwareentwickler dazu sagen?

                                                          • 28. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                            zippo Aufsteiger

                                                            Na prima. Der Server entschlüsselt und verschlüsselt neu. Wie bei DE-Mail. Eigentlich ist das ja ziemlich unerfreulich, aber wenigstens können die nun die gestrandeten Mails ausdrucken und aufs Fax legen :-)

                                                            • 29. Re: beA - jetzt kommtˋs ganz Dicke, Man-in-the-middle Angriff?
                                                              kroerig Einsteiger

                                                              Na prima. Der Server entschlüsselt und verschlüsselt neu. Wie bei DE-Mail. Eigentlich ist das ja ziemlich unerfreulich, aber wenigstens können die nun die gestrandeten Mails ausdrucken und aufs Fax legen :-)

                                                              ATOS könnte das vielleicht, wenn das System eine solche Hintertür hat. Sollte es nicht und wenn doch, wäre das der nächste Skandal.

                                                              1 2 Zurück Weiter