Antwort #15: Oktober 26, 2012, 01:52:49
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.
« Letzte Änderung: Oktober 26, 2012, 02:10:55 von Florian »
_______
"If music be the food of love, play on!”
William Shakespeare
“We’re all going to be dead soon, and it really doesn’t matter anymore, so there’s zero pressure.”
Joe Mazzulla, Trainer der Boston Celtics über den Druck auf seinem Team.