ausblenden > Mac-Software
Frage bezüglich Zertifikate ...
Florian:
Der erste Link dreht sich um die fehlerhafte Implementation von verschlüsselten Verbindungen in Programmen. Also um Programmierfehler.
Beim zweiten geht es ganz einfach um zu kurze Passwörter.
Das sind beides Schlampereien, die an der Sinnhaftigkeit des Systems nicht rütteln.
Ja, es gibt viele Stellschrauben, an denen man sich vertun kann. Hauptgrund für mich ist aber die fehlende Verbreitung von seriösem Umgang mit Daten. Das Problembewusstsein ist einfach nicht da.
Ich schreibe, soweit es die Zeit erlaubt (also „bald") gerne was Längeres zum Zertifikat-Systems, aber eigentlich ist es ganz einfach.
Person/Seite A will eine Verschlüsselung aufbauen. Im SSL-System weist sie sich dazu aus mit einem Zertifikat, das sowohl Identität als auch öffentlichen Schlüssel beinhaltet.
Diese Identität wird von allgemein anerkannten Privatunternehmen wie Thawte mehr oder weniger gut überprüft, wie gut sieht man am Zertifikat. Das im Falle von Webseiten am weitesten verbreitete „Domain validated“ ist die wenigstens strenge Überprüfung und natürlich die billigste. Konkret bekommt man meistens eine Email, ob man dieses Zertifikat auch angefordert hat.
Und eine Menge anderer Daten steht auch noch drin. Schön also wenn man das Zertifikat angezeigt bekommt, was bei den meisten Programmen nicht der Fall ist, außer Browser und Email-Clients.
Es gibt natürlich auch Zertifikate ohne Identitätsprüfung. So könnte ich mir eins selbst ausstellen und benutzen. Ich stehe aber nicht im OS-X-eigenen Schlüsselbund als vertrauenswürdige Instanz und so kommt eine entsprechende Meldung in Safari oder Mail.
Im Fall einer Webseite zeigt die Seite dem Browser das Zertifikat:
„Hallo, ich bin XY.xy, geprüft VON ZZ (und zwar mit Methode M) und mein öffentlicher Schlüssel ist 6djd6dute….
Dieser Ausweis ist gültig bis X.X:XXXX)"
Daraufhin schaut der Browser in seinen/den Schlüsselbund, ob denn ZZ unter den vertrauenswürdigen Zertifikationsinstanzen gelistet ist. Falls nicht, kommt eine Fehlermeldung. Oder auch, wenn das Zertifikat abgelaufen ist.
Ist das Zertifikat scheinbar i.O., baut der Browser eine verschlüsselte Verbindung auf. Dazu generiert er einen sog. Session-Schlüssel und verbindet diesen mit dem öffentlichen Schlüssel der Seite zu einem gemeinsamen einmaligen Schlüssel/Passwort, mit dem die Verbindung abgesichert wird.
Analog läuft das bei Emails (wo zwei öffentliche Schlüssel zum Passwort verbunden werden) oder anderen Datenverbindungen.
Konkrete Gefahr ist der Man-in-the-middle-Angriff, gängiges Szenario wäre das Hotel-WLAN. Das ist bekannt und darum müsste Client-Software eigentlich schon so programmiert werden, dass sie Zertifikate richtig prüft und einordnet. Dies ist aber, wie Link 1 zeigt, leider oft nicht der Fall.
warlord:
Ich glaube nicht, dass es sich dabei überall um Programmierfehler handelt - bzw. man greift da deutlich zu kurz, wenn man das einfach als Programmierfehler abtut. Es wird sicher auch solche darunter haben. Aber ich bin mir ziemlich sicher, es hat darunter viele Fälle, in welchen die Programmierer durchaus wissen, was sie tun und es mit voller Absicht tun. Nicht, weil sie böse sind oder den Nutzern schaden wollen. Sondern ganz einfach, weil sie Software schreiben wollen, die funktioniert (im Sinne von: ihren Hauptzweck ohne zu murren erfüllt).
In sehr vielen Anwendungsbereichen wird nämlich Software, die selbstsignierte und/oder abgelaufene Zertifikate nicht akzeptiert häufiger nicht funktionieren, als dass sie funktioniert. Und was tut der Nutzer dann? "Scheiss Software! So'n Mist ist ja nicht zu gebrauchen! ..."
Ich würde das viel eher als Zertifikat- bzw. Zertifizierungsproblem bezeichnen. Überall und an allen Ecken und Enden gibt es selbstsignierte und/oder abgelaufene Zertifikate. Und wieso ist das so? Zertifikate sind umständlich zu erhalten, teuer und nur lächerlich kurz gültig. In so einem Umfeld lässt sich gar keine sichere SSL-Software betreiben. Es ist ein Infrastruktur-Problem und nicht ein Programmierproblem.
Digitale Identitätsausweise (also Zertifikate) sind bzw. wären etwas vom Wichtigsten für das gute Funktionieren einer zunehmend digital funktionierenden Volkswirtschaft. Während es im analogen Leben als Staatsaufgabe betrachtet wird, Identitätsnachweise auszustellen, haben sich die europäischen Staaten bisher kaum um digitale IDs gekümmert. Bzw. sie beginnen damit erst zögerlich (z.B. Deutschland mit dem neuen Perso), beschränken sich dabei aber wie im analogen Leben ausschliesslich auf natürliche Personen. Den Rest überlässt man sich selbst bzw. einem Markt, der irgendwie nicht recht funktionieren will. Es gibt kaum europäische Anbieter. Und die Anbieter, die es weltweit gibt, bieten schlecht organisierte und nicht wirklich überzeugende Identifikationen und verkaufen überteuerte Zertifikate mit zu kurzen Laufzeiten. Mit dem Resultat, dass nur gerade dort, wo absolut sicherheitskritisch, anständige Zertifikate eingesetzt werden.
Und während insbesondere die europäischen Staaten sonst jeden erdenklichen Mist, der im freien Markt besser aufgehoben wäre, als Staatsaufgabe betrachten bzw. sich einmischen, geschieht bei diesem ziemlich kritischen Marktversagen einfach nichts. Und so wird bezüglich Zertifikate weiterhin gewurstelt und die Ursache für eine ganze Reihe von Sicherheitsproblemen weiterhin Anwendungsentwicklern in die Schuhe geschoben...
Florian:
Du bringst einen sehr guten Punkt, aber so teuer sind Zertifikate auch nicht. Oder sagen wir mal so: Fehlendes Problembewusstsein und Spar-Interesse ergänzen sich hier wunderbar.
Es ist halt die Frage, was einem das wert ist. Diese Frage betrifft freilich auch die Kunden bzw. Nutzer.
Das so viele mit abgelaufenen oder selbstsignierten Zertifikaten arbeiten, finde ich inakzeptabel. Entweder verschlüsselt man möglichst richtig oder eben nicht. Sonst führt man doch nur den User in die Irre. Zumindest sollte man über die Einschränkungen informieren.
Ich gehe mit Dir einig, dass es eigentlich eine staatliche Aufgabe wäre. Deutschland war m.W. das erste Land mit einem Gesetz zur digitalen Signatur, aber dann ging nichts weiter.
Da das nicht zu kommen scheint, muss man sich eben anders arrangieren. Da gäbe es viele Verbesserungsmöglichkeiten. So wäre wohl besser, wenn man z.B. beim Hosting-Provider zum Server oder DSL-Vertrag gleich eine Identitätsprüfung dazu bestellen könnte.
Zum anderen könnte man auch privat oder halbstaatlich ein Web-of-Trust aufbauen, hier müsste es jedenfalls eine Organisation geben, die als vertrauenswürdig bekannt und allgemein anerkannt ist. Von mir aus der TÜV.
Da man bei jedem Handy-Vertrag heute den Ausweis vorzeigen muss, wäre das für natürliche Personen auch ein Weg zur schnellen Identifizierung.
Kreativität ist gefordert, aber wie gesagt: Den meisten Leuten ist das Problem nicht bewusst oder es ist ihnen schlicht egal.
radneuerfinder:
Mir ist es nicht egal. Aber ich bekomme nix zur Hand das ich handhaben könnte.
Ich finde die Analyse von warlord sehr einleuchtend.
Florian:
Einfache Zertifikate von anerkannten Stellen gibt es sogar umsonst. Es gibt Community-Ansätze, die sich schon längst durchgesetzt hätten, wäre das Interesse der Leute da.
Extended Validation kostet dann halt ein paar hundert Euro im Jahr.
So kompliziert ist das m.E. nicht.
Ich sage mal ganz keck: Wer solche Summen und etwas Einarbeit nicht aufbringen kann, ist vielleicht auch nicht der richtige um sensible Daten zu speichern und durch die Welt zu schicken.
Zumindest aber könnte man den User über die Sachverhalte aufklären.
Mir ist klar: Es gibt Freeware, oder Billigprogramme oder solche die sich nur ganz wenig verkaufen - die alle niemals so viel Geld reinbekommen bzw. dann verschenkt werden. Aber vielleicht sollte man dann mal die ewige Rumfunkerei in den Wolken generell hinterfragen.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln