Das ist auf der einen Seite zu gut verständlich, auf der anderen jedoch völlig lebens- und realitätsfremd. Allein die Tatsache, dass du heute - ganz simpel - deine Daten unterschiedlichen Unternehmen zur Verfügung stellst, um Dienstleistungen in Anspruch zu nehmen (Kontoführung, Musikschulen, ...), Produkte zu kaufen (Kartenzahlung, Kaufkraftanalysen, Bewegungsmuster durch Kameraüberwachung in Supermärkten, ...), oder einfach nur am öffentlichen Leben (...)
Von diesen Themen habe ich nicht gesprochen, sondern Thema dieses Beitrags ist die Anonymität im Internet und wie VPN-Provider damit umgehen. Deine eigene Frage bezog sich schließlich darauf was Anonymität im Internet bedeutet und nicht, ob der Mensch in seinem Leben völlig anonym und unabhängig leben kann. Meine Zitate also auf gänzlich andere Lebensbereiche wie "Musikschulen" oder "Kartenzahlungen" anzuwenden und sie in einem anderen Kontext, von dem nicht die Rede war, als realitätsfremd darzustellen, ist ein bisschen unglücklich. Daher hier noch mal mein originales Zitat auf das eigentliche Thema bezogen:
Ich schalte meinen Computer ein, surfe, schalte meinen Computer aus und niemand außer mir weiß auf welchen Seiten ich mich befand.
Dies war selbstverständlich die Antwort auf Deine Frage nach Anonymität im Internet und tatsächlich _nur_ hierauf.
Ein schönes Argument für Open Source, jedoch wieder absolut realitätsfern, was die letzten Bugs im Linux Kernel wieder eindrucksvoll bewiesen haben. (...)
Ich wäre an der Stelle ein bisschen vorsichtig mit pauschalen Aussagen über statistische Verteilungen von Fehlern und dergleichen. Verwendest Du kein openssh, sondern eine closed source Alternative? Möchtest Du pauschal behaupten, dass opensource mehr Bugs hat als closed source und unsicherer ist? Ich gebe Dir Recht, der Linux Kernel hat Bugs und selbstverständlich auch Sicherheitslücken ohne Ende und auch die Eigenschaft, dass bei Opensource oft kein Code-Review und/oder Security Audit stattfindet, steht außer Zweifel. Vergleichen wir mal zwei Webbrowser miteinander, z.B. den Opensource Browser Firefox mit dem Closed Source Browser Internet Explorer. Bist Du auch hier der Ansicht, dass Firefox mehr Sicherheitslücken als Microsoft's Closed Source Browser hat? Wie sieht es mit MS Windows vs. OpenBSD vom Sicherheitsaspekt aus?
Natürlich muss man hier die unterschiedlichen Lebenszeiten betrachten und das Ganze in einer relativen Fehlerhäufigkeit, z.B. Anzahl und Schweregrad von Fehlen pro Jahr gegenüberstellen.
Eine pauschale Aussage über Sicherheit oder Softwarequalität allein darauf bezogen, ob etwas Opensource oder Closed Source ist, halte ich für schwierig. Meine (lange) Erfahrung sagt mir, und hiermit erhebe ich _keinen_ Anspruch an Allgemeingültigkeit, dass es sowohl in der Opensource Welt gute Produkte gibt (Putty, openssl, OpenBSD, Gimp, ...), als auch in der Closed Source Welt (MS Office, Photoshop, diverse Multimedia Programme, ...)
Ebenso gibt es Bugs und Sicherheitslücken in beiden Welten. Eine pauschale Aussage über die statistische Verteilung der Sicherheitslücken bezogen auf beiden Welten kann und möchte ich nicht treffen. Ich erhalte aus diversen Mailinglisten täglich Meldungen über Bugs aus beiden Welten und eine pauschale Differenzierung a la "entweder Closed Source oder Opensource" gibt es bei mir nicht. Was mir an Opensource gefällt, lade ich mir runter, was mir an Closed Source gefällt, kaufe ich mir.
Gleichzeitig musst du natürlich auch bedenken, dass es durchaus einfacher ist, in OSS Projeken sicherheitskritische Bugs zu finden. Nicht jeder meldet einen Bug. Vor allem nicht in einer Zeit, in der man den Bug viel gewinnbringender verkaufen kann...
Keine Sorge, das habe ich selbstverständlich bedacht und Deine Argumente gegen Opensource sind alle zutreffend und nachvollziehbar. Jedoch finde ich für jedes Deiner Argumente gegen Opensource agrumentum e contrario ebenso mühelos das Pendant gegen Closed Source. Anbei ein Beispiel bez. Deiner Argumente hinsichtlich der Bugs:
Korrekt, es ist einfacher in Opensource Bugs zu finden und ebenfalls ist korrekt, dass nicht jeder Bugs oder gefundene Sicherheitslücken meldet. Leider ist es dafür im Gegenzug einfacherer in Closed Source Bugs und/oder Hintertüren zu verstecken, die man nicht so einfach findet. Ergo steht die Frage im Raum:
Was ist schlimmer? Sicherheitslücken in Opensource leichter finden zu können oder Sicherheitslücken in Closed Source besser verbergen zu können?
Vor ein paar Jahren gab es diese lustige Werbung von Cisco Routern im TV. Hacker versuchen von draußen in die Systeme einzubrechen und die Cisco Admins sind ganz ruhig, da Cisco ja ein Synonym für Sicherheit sein soll. Du hättest vor ein paar Jahren mal das Gesicht des Cisco-Vertrieblers auf der CeBit sehen sollten, als ich ihn fragte, ob Regierungen Zugriff auf deren Router haben.
Apropos Closed Source & Hintertüren:
Wenn ich heute lese, und dies passt auch wieder zum eigentlichen Thema,
dass Cisco Hintertüren in manchen Routern hat, muss ich schmunzeln.
Die Frage bleibt, ob deine Entscheidung fundiert genug ist, um als objektiv und korrekt anerkannt zu werden. Oder anders gesagt: Wenn du keine Ahnung von Sicherheit hast, dann kann ich auf deine Meinung getrost verzichten, denn dann ist sie soviel wert, wie die Aussage eines VPN Providers. Somit gilt wieder die Ausgangsfrage: Wer beweist mir deine (die des VPN Providers, die von Microsoft, die der NSA) Aussage?
Niemand kann oder wird eine 100% Sicherheit und Fehlerfreiheit garantieren. Was ich (als Firma) jedoch vertraglich garantiere ist, dass wir keine Hintertüren in die Kundensoftware einbauen und uns keine Wege in die Software oder Hardware offen halten, von denen der Kunde nichts weiß. Diese Zusage ist vertraglich geregelt und ein Nicht-Einhalten dieser Regel stellt einen schwerwiegenden Vertragsbruch dar, was man sich als Firma nicht erlauben kann/möchte.
Einen Beweis, von dem Du geschrieben hast, gibt es in der Form nicht und wie Du bereits korrekt formuliert hast, spielt in der Security-Szene zwischen Kunde und Provider das Vertrauen eine große Rolle. Dein Argument mit dem Beweis lässt sich aber ebenso wiefolgt umdrehen und damit möchte ich folgendes zum Ausdruck bringen (auch wenn das ein bisschen gemein gegenüber dem Kunden ist):
Ich kann mathematisch beweisen, dass (m)ein bestimmter Algorithmus in Punkto Sicherheit das tut, was er tun soll. Der Kunde kann mit einem solchen mathematischen Beweis jedoch nichts anfangen, da er diesen Background nun mal nicht hat, andernfalls bestünde der Bedarf nicht Sicherheitskonzepte und -implementierungen extern einzukaufen. Ein Beweis ist also überflüssig, denn einen rein kryptologischer Beweis auf mathematischer Basis wird der Kunde nicht verstehen und, wie Du ebenfalls korrekt erwähnt hast, bilden sich potenzielle Angriffsvektoren nicht nur aufgrund kryptoanalytischer Verfahren, sondern auch aus Schwächen in der Implementierung und diversen anderen Randbedingungen aus der Praxis. Was nützt schon ein guter Hashing-Algorithmus, wenn der Betroffene das Passwort im Klartext auf dem Desktop ablegt und seinen Bildschirm bei der Kaffeepause nicht sperrt?
Leider sagt deine subjektive Zufriedenheit - auch aus wissenschaftlicher Sicht - nichts über die Codequalität aus, die bei 1-Mann/Frau-Teams doch nicht wirklich hoch sein kann, da niemand derart viel Wissen aufbauen kann, um jede Funktion eines Entwicklungsteams zu übernehmen. (...)
Ich akzeptiere auch hier natürlich Deine Meinung, aber die Realität beim Kunden läuft anders ab. Für kleine Entwicklungsprojekte benötigt man nur eine Person, d.h. der Kunde fordert nach der erfolgten Aufwandschätzung entsprechend nur einen einzigen Consultant an, der die gewünschte Implementierung betreut, umsetzt und den Kunden berät. Für mittelgroße oder große Projekte benötigt man hingegen ein Team.
Auch hier noch mal mein erneuter Hinweis mit pauschalen Aussagen vorsichtig umzugehen. ;-) Eine pauschale Aussage über die Qualität von Code lässt sich unter gar keinen Umständen aus der Größe des Teams ermitteln. Klar ist natürlich, dass ein gewisser Aufwand in einer Gewissen Zeit auch nur von einer gewissen Mannzahl umgesetzt werden kann. Du kannst dennoch als einzelner, geschulter und erfahrener Programmierer sehr viel mehr Qualität zu Papier bringen als 5 Programmieranfänger. Gerade für kleine Projekte, hätte ein Team einen großen Overhead aufgrund der notwendigen Abstimmung und nicht jedes Shellscript bedarf eines Teams.
Die Notwendigkeit eines Teams bemisst sich aus dem Aufwand der Aufgabenstellung und hat nichts mit der Qualität zu tun und Vorsicht, Open-SSH ist über viele, viele Jahre gewachsen und ein sehr großes Projekt. Nicht jedes Projekt beim Kunden ist vom Aufwand her mit einer Open-SSH Implementierung zu vergleichen, sondern hier gibt es auch viele kleinere Projekte, in denen ausschließlich 1-Mann Teams in Frage kommen und sich eine zweite Person kaum rechtfertigen ließe. Und auch die von mir implementierte Zugriffslösung stellt vom Aufwand nur einen geringen Bruchteil von Open-SSH dar und fügt ein paar weitere Features hinzu, wie bereits zuvor erwähnt. Zum Thema Eigenentwicklung möchte ich noch eine Sache klarstellen: Eine eigene Implementierung, wie z.B. eine eigene Diffie-Hellman implementierung, bedeutet nicht zwangsläufig, dass man die Funktionsweise des standardisierten Diffie-Hellman Algorithmus ändert oder erweitert, sondern es soll bedeuten, dass man den bestehenden und weltweit akzeptierten Diffie-Hellman Algorithmus im Zuge eines Projekts from scratch schreibt.
Wer oder was beweist, dass dein Code wirklich sicherer ist, als der von OpenSSL oder OpenSSH?
Sind Open-SSH oder Open-SSL denn sicher? Vielleicht hat Open-SSH 10 - 20 bisher unentdeckte Sicherheitslücken, die bisher nur übersehen wurden.
Definiere mir den Begriff "Beweis" nach Deiner Vorstellung, d.h. in welcher Form würdest Du einen formalen Beweis der Sicherheit denn überhaupt akzeptieren (wenn es ihn denn gäbe) und wie soll dieser aussehen?
Lass' es mich so darstellen:
Wenn es bei einem Vertriebler von Apple auf einer offiziellen Pressekonferenz unerwartet in der Tasche klingelt und er holt darauf hin sein privates Android-Handy raus, dann könnte das einen Interessenkonflikt darstellen. Was für ein Auditor wäre ich also, wenn ich meinem eigenen Produkt nicht vertrauen würde? ;-) Spaß bei Seite, auch unsere Produkte werden nach dem 4-Augen Prinzip zusätzlich von externen Auditoren geprüft. Wären unsere Produkte nicht sicher, wären wir schon lange weg vom Markt. Dennoch hast Du im Prinzip Recht, einen Beweis gibt es grundsätzlich nicht. Vielleicht übersehen Entwickler, Auditoren und Fuzzer-Algorithmen einen ganz trivialen Fehler. Sollte ich mich hier also längere Zeit nicht mehr melden, wissen wir ja dann, woran es liegt. ;-)
Das Problem ist auch weniger die Mathematik hinter den Verfahren. Das Problem, das heute akuter denn je ist, liegt doch darin, dass es sehr schwer ist, Kryptographie korrekt und nachweislich sicher zu implementieren. Die aktuellen Sicherheitslücken in kryptographischer Software (goto:fail, GnuTLS) zeigen erstens, dass selbst nach jahrelanger Erfahrung noch einfache Fehler auftreten können.
Gut, denn hiermit gibst Du selbst zu, dass es keine Garantie in Punkte Sicherheit geben kann und somit jede Frage nach einem Beweis überflüssig ist, egal wie lange ein Produkt am Markt ist. Daher bringt ein mathematischer Beweis oder die formale Definition eines Verschlüsselungsalgorithmus an der Stelle gar nichts. Das Problem ist oft die Implementierung.
Dementsprechend halte ich persönlich nicht viel davon, wenig bis praktisch garnicht eingesetzte Software irgendwo produktiv einzusetzen, da eine Aussage über die Sicherheit der Implementierung von Kryptographie heutzutage schlichtweg nicht zufriedenstellend möglich ist. Von der rechtliche Seite der Haftbarkeit und Maintenance (Stetige Entwicklung z.B. nach PDCA Zyklen , ...) mal völlig abgesehen.
Davon musst Du persönlich nichts halten und auch dies kann ich ohne Probleme akzeptieren. Lass' Dir dennoch hiermit gesagt sein, dass die Praxis ganz anders aussieht als Deine persönliche Wunschvorstellung. Denn leider deckt Standardsoftware sehr oft beim Kunden bei weitem nicht das ab, was der Kunde benötigt, so dass in Deutschland tausende von Consultants (mich eingeschlossen) davon Leben für den Kunden Spezialsoftware zu schreiben, die auf die individuellen Bedürfnisse dieses Kunden zugeschnitten ist und sonst nirgends im Einsatz ist. Das tun wir das ganze Jahr über. Revisionen, allen voraus die BaFin im Bankensektor, haben oftmals Ansprüche, die sich mit Standardsoftware nicht mal annähernd abbilden lässt.
Zu den rechtlichen Aspekten der Haftbarkeit habe ich mich bereits geäußert. In den Verträgen steht, dass die Software nach bestem Wissen und Gewissen entwickelt wurde, keine Hintertüren enthält und, falls dort ein Standard wie AES eingesetzt wurde, wird dieser namentlich erwähnt. Eine Garantie kann und wird niemand abgeben, egal ob eine Einzelperson oder eine Firma mit 10.000 Angestellten.
Qualität und Sicherheitsgrad der Software haben nichts mit Team- oder Firmengröße zu tun, sondern das Können zählt.
Ich fahre mit der Philosophie "Hole Dir lieber eine Hand voll Spezialisten als einen Haufen voll Halbwissenden" seit vielen Jahren sehr gut.
![[HaBo]](/styles/default/logoklein.png){kind=small}
