[linux-l] CAcert - alternativen?

[Steffen Schulz]

On 060823 at 05:10, Steffen Dettmer wrote:
> * Steffen Schulz wrote on Tue, Aug 22, 2006 at 23:38 +0200:
> > 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?

Weil der Server hinter der Domain ein cert hat, welches die Domain im
common-name traegt. Sowas bekommt er nur von cacert.org signiert, wenn
er Mails an root at domain usw lesen kann.

Ich weiss nicht, auf welche Person das cert ausgestellt ist, aber ich
weiss, dass es eine der Personen ist, die die domain managen. Das
schliesst ne ganze Menge MITM-Angreifer aus.

Es ist sicher nicht perfekt, aber wie man im taeglichen Leben immer
wieder sieht:

- perfekt ist sehr teuer und oft auch unbenutzbar
- und irgendwie kommt man dann doch drum rum...


> Und wenn jemand DNS spoofing macht, wird er auch root at domain.de bekommen
> und somit ein "Zertifikat".

Okay, wenn er auch gegenueber cacert das spoofing hinbekommt. Dafuer
muss er einen weiteren Account oeffnen. Ich weiss nicht, ob cacert
meckert, wenn man eine domain sein eigen nennt, die schon ein anderer
login fuer sich in Anspruch nimmt. Wenn ja, engt das den Spielraum
schon enorm ein.

> Und überhaupt nur für DNS spoofing könnte
> ein "Hostname existiert Zertifikat" überhaupt schützen (und meiner
> Meinung nach nichtmal das).

Der Vorteil gegenueber normalen selbst-signierten certs ist doch klar:
Diese kann wirklich jeder trivial fuer eine beliebige Domain aufsetzen
und dann ganz klassisch MITM fahren. Oder DNS spoofen. Oder URLs
unterschieben.

Mit cacert kannst du immernoch URLs unterschieben. Aber die anderen
beiden musst du nicht nur im LAN koennen, sondern auch gegenueber
cacert.org hinbekommen. Das ist in der Praxis schon komplizierter. Und
es faellt auf. Wenn eine legitime Website cacert-certs nutzt, koennte
cacert von vornherein ablehnen, fuer jmd anderen ein cert auf diese
domain auszustellen.

Haette, koennte, waere, ich habs grad mal getestet:

The domain 'cbg.dyndns.org' is already in the system and is listed as
valid. Can't continue.


Noch ein Punkt: CaCert ist auch einfach. Einfacher als nen eigenes
root-cert mit CRL und so. Und ich denke, jede Site, die auch ssl
anbietet, ist insgesamt ein Gewinn. Die Kosten sind vernachlaessigbar
und wenn's komplett falsch ist...naja, vllt naechstes mal...

> > (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

Eben, Schutz gegen o.g. Angriffe = 0...

> 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.

Ganz so gut isis nich, ab 2008 will man schon 1280.

Und BTW: DJB hat den Nagel auf den Kopf getroffen, als er meinte, man
sollte bei Designentscheidungen immer das gerade minimal sichere nehmen.
Das sichert Arbeitsplaetze.

Das BSI macht das auch ganz richtig, es werden durchweg schon jetzt
2048 Bit empfohlen. Es macht einfach keinen Sinn, alle 2 Jahre aufs Neue
zu ueberlegen, was man braucht, damit die Daten auch in 2 Monaten noch
sicher sind. Solche Ueberlegungen machen Sinn, wenn man was fuer z.B.
SmartCards entwirft. Und wer da RSA nimmt, ist selbst schuld..

Entwurf des Algorithmenkatalogs fuer 2007:
http://www.bsi.de/esig/basics/techbas/krypto/algo_entw1_07.pdf


mfg
pepe
-- 
God's in his heaven.
All's right with the world.