Email Sicherheit?!? - Seite 3

Seite 3 von 3 - Forum: Internet & Provider auf overclockers.at

URL: https://www.overclockers.at/internet-provider/email_sicherheit_211743/page_3 - zur Vollversion wechseln!


deftenski schrieb am 09.11.2009 um 14:16

wenn du Leuten vertraust, die irgendwelche, teilweise fremden Menschen den Key unterschreiben, solltest du dir unter umstaenden ueberlegen, selbigen doch nicht zu vertrauen ..


Smut schrieb am 09.11.2009 um 16:27

Zitat von COLOSSUS
Auch eine Zertfizierungsstelle (CA) ist nicht unangreifbar: Zertifikate und ganze CAs lassen sich, kommen nur genug unguenstige Faktoren zusammen, mit heutigem Stand der Technik faelschen. Schau mal, wie viele CAs ihre Root-Zertifikate immer noch mit MD5 signieren. Eine recht beeindruckende Rouge CA gab es vor nicht allzu langer Zeit auf einer Sicherheitskonferenz zu bewundern. Es koennte auch sein, dass der private Schluessel der CA unwissentlich in die falschen Haende geraet. Damit koennte man ebenfalls beliebige Identitaeten beglaubigen, und es gaebe nicht einmal Anhaltspunkte dafuer, dass irgendetwas nicht mit rechten Dingen zugeht - es sei denn, der tatsaechliche Eigentuemer des CA-Schluessel bemerkt irgendwie, dass eines der durch ihn augenscheinlich beglaubigten Zertifikate nie von ihm unterschrieben wurde.
gut, das waren tragische schwachstellen im system, dennoch gibt es momentan keine bessere methode den public key dem signator zuzuordnen. das selbe bei ssl zertifikaten zum schutz vor fishing. wenn ich bei einem von der CA ausgestellten schlüsselpaar meinen private key "verliere", gibt es wenigstens revocation lists, die jeden automatisch erreichen.
btw: welche root zertifikate sind heute noch mit md5 signiert?


EG schrieb am 09.11.2009 um 17:33

Das frag ich mich allderdings auch...diese "Rogue CA" (ja Rogue schreibt man so ;)) war nämlich iirc ein rein theoretischer Ansatz, der wie du schon gesagt hast auf MD5-Kollisionen basierte. Falls wir von der reden, die heuer mal auf einer Security Konferenz publiziert wurde...leider vergessen wo genau...Link vorhanden?
Wird jedenfalls so schon länger nicht mehr von den nahmhaften Anbietern eingesetzt.

Jedenfalls nix was real Probleme gemacht hätte.

Was deine herangehensweise angeht um "falsche Identitäten" im Web-of-Trust zu vermeiden, muss ich mich doch _sehr_ wundern. Gerade von dir hätt ich doch erwartet, dass du solche "Pfusch"-Konzepte ohne vernünftige Regelungen und Standards nicht beführwortest.
Oder hats vielmehr damit zu tun weil einfach "Open" drauf steht?

Sicherheit die von der persönlichen Erfahrung und Einschätzung des Benutzers abhängt und _nicht_ technisch/mathematisch eindeutig nachweisbar ist, kann man wohl wenig ernst nehmen. Das Problem ist der Faktor Mensch, dem man nicht vertrauen kann.
Dann noch zu sagen: "ja aber da kann man sich ja persönlich treffen!" zeigt doch gerade wie schwach das System ist. Wenn ich mich persönlich treffen muss, kann ich ihm die Nachricht auch direkt in die Hand drücken.


Smut schrieb am 09.11.2009 um 18:29

hier die links zum thema:

1. die md5-kollision:
http://www.heise.de/security/artike...MD5-270106.html

2. hier das SSL zertifikat auf welches ich vorhin angespielt habe:
http://www.heise.de/security/meldun...ate-798273.html

schlussendlich vertraue ich diesem system mehr als einem web of trust. auch wenn das jetzt wieder etwas weg führt vom thema: bei elektronischer rechnungslegung sind z.b. zur signatur ohnehin nur qualifizierte zertifikate erlaubt. der für mich einzig relevante nachteil sind die kosten.


COLOSSUS schrieb am 23.03.2011 um 11:30

https://blog.torproject.org/blog/de...owser-collusion - Und man sieht wieder einmal: CAs sind eine schlechte Idee. Zumindest, wenn nicht irgendwie limitiert ist, fuer welche Subjects sie buergen koennen (was in X.509 nicht vorgesehen ist).


COLOSSUS schrieb am 23.03.2011 um 15:16

http://www.heise.de/newsticker/meld...es-1212986.html - heise hat das Thema aufgegriffen und kommt zu einem aehnlichen Schluss wie ich ;)




overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025