[linux-l] CAcert - alternativen?

[Steffen Dettmer]

* Steffen Schulz wrote on Tue, Aug 22, 2006 at 23:38 +0200:
> On 060822 at 10:10, Steffen Dettmer wrote:
> > Es ging mir überhaupt noch nicht mal um laxe Prüfungen, sondern darum,
> > dass ein Zertifikat zertifiziert, dass ein Hostname existiert.
> 
> Also um so ein cert zu bekommen, muss man im Grunde nur Kontrolle ueber
> die Domain haben, also halt Mails an root at domain oder webmaster at domain
> oder an Adressen aus dem whois-Eintrag empfangen koennen.
> 
> Wenn wir jetzt aber mal davon ausgehen, dass wir dem Betreiber
> vertrauen, bedeutet das:
> 
> Das cert zertifizert, dass wir mit dem Server sprechen, der von
> dem/einem "Betreiber" der Domain aufgesetzt wurde.

Woher, weil ein Hostname oder eine IP gleich ist?

> Das war fuer mich immer einer der Hauptpunkte von SSL:
> MITM-Angriffe zu verhindern.

Das setzt vorraus, dass Du den Empfänger eben doch kennst
(authentifizieren kannst), also dieser eine zertifizierte Identität hat,
die von jedem MITM unterscheidbar sein muss.

> Die Felder issued-to usw sind bewusst leer, die Felder werden vor der
> Signierung des certs entfernt, WEIL man halt gar nicht weiss, ob der
> Typ hinter root at domain.de tatsaechlich Karl Klammer ist.

ja, eben!

Und wenn jemand DNS spoofing macht, wird er auch root at domain.de bekommen
und somit ein "Zertifikat". Und überhaupt nur für DNS spoofing könnte
ein "Hostname existiert Zertifikat" überhaupt schützen (und meiner
Meinung nach nichtmal das).

> Wer die Daten da stehen haben will, muss sich melden und von einem
> Notar identifizieren lassen oder sowas.

richtig, nennt man technisch auch Zertifikat ;)

> Eine interessantere Gefahr mit cacert, angenommen das root-cert kommt
> in $BROWSER, waere aber zB www.deutcshe-bank.de, www.citybank.de, ...

unter anderem, richtig. Oder woher man weiss, ob www.guckes.net wirklich
von dieser Autorin ist (Sven könnte ja in ihrem Namen auf dieser Seite
alles "zurücknehmen" was in Buch X steht - keine Ahnung, was die
geschrieben hat - und das über SSL. Man weiss eben nicht, mit wem man
spricht. Vielleicht halt mit dem Man-in-the-middle. Und der eigentlich
bestimmte Empfänger kann das garantiert nicht belauschen, toll...)

> Insbesondere das Stichwort Punycode laesst die Phantasie an der Stelle
> aufleben.
> 
> Aber das ist nur ein Problem, weil unklar(unbewusst) ist, welche
> Sicherheitsziele ein cacert-cert erfuellt. Man bekommt auch mit
> "korrekten" Zertifikaten aehnlich dumme Sachen hin.

Eben, ohne klare Policy geht "Sicherheit" einfach nicht.

> (Erklaer mir mal einer, wieso GMX SSL erst aktiviert, wenn ich meinen
>  Login bereits in ein Formularfeld eingegeben habe...)

Weil erst beim Klicken auf den Submit-Button tatsächlich Daten gesendet
werden. So muss ein Angreifer nach faken der Startseite ein
X509-Zertifikat haben, z.B. auf gmx-phishing.com oder so lol

> > > CACert ändert NICHTS...ich vertraue einem solchen Community-Produkt
> > > sogar mehr, als einige kommerziellen Angeboten.
> > 
> > Ja, und wenn es 2048 anstatt 1024 Bit sind, sogar mehr, schon klar. 1024
> > Bit könnte die NSA ja angreifen. Um Deine Liebesbriefe zu lesen, genau.
> 
> Der zentrale Authentifikations-Server meiner Uni, der die PKI fuer
> mehrere tausend Studenten bereit haelt und Logins Berechtigungen fuer
> diverse weitere Datenbanken hortet, hat einen Webserver mit diversen
> (administrations-)Webfrontends. Die Verbindung zu dem Server wird mit
> einem 512Bit-RSA-Zert gesichert. Man meinte zu mir, dass mehr Bits wohl
> mehr kosten. Die RSA-640-Challenge wurde vor bald einem Jahr nicht unweit
> von der Uni gebrochen.

Ja, aber selbst 768 Bit sind schon viel sicherer und 1024 Bit sind für
die nächsten Jahre (hab die Zahl nicht im Kopf, 2010 oder sowas) für
Zahlungsverkehrssysteme zulässig. Und 2048 ist ja nicht "doppelt so
sicher", sondern unvorstellbar viel sicherer, solange keiner einen
Quantencomputer hat, und wenn, dass ist's eh egal :)

oki,

Steffen