[linux-l] CAcert - alternativen?

[Steffen Dettmer]

* Steffen Schulz wrote on Wed, Aug 23, 2006 at 22:06 +0200:
> 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...

Na ja, ich schreibe meinen Standpunkt nochmal. Dann sagst Du, ob das
Mist ist oder Sinn macht und am besten beenden wir dann die Disskussion
:)

Also, die klassischen X509 SSL Zertifikate schützen vor MITM-Angriffen.
Sie schützen (ohne zusätzliche manuelle Prüfung) nicht vor phisching
(weil der ja problemlos ein SSL Zertifikat haben kann, ist dann ein
authentischer Angriff, später mehr). MITM-Angriffe brauchen
DNS-spoofing, damit der Browser www.ziel.de vom Angreifer und nicht von
Ziel lädt. Wenn man aber ziel.de "umbiegen" kann, weil man z.B. das DNS
manipuliert hat, kann man auch root at ziel.de "umbiegen", weil Mail ja
über DNS MX Records verteilt wird. Das heisst, root at ziel.de ist keine
zusätzliche Sicherheit, weil das beim DNS Spoof Angriff "automatisch"
mit angegriffen wird. Entweder manipuliert man DNS von ziel.de (mail und
HTTP) und das cert hilft nix, oder man manipuliert nicht (und braucht
kein cert). Ergo nützt so ein Zertifikat sowieso schon mal nichts.

Ein zweiter Schutz wäre die Relation zu einer Institution/Firma oder
Person, die juristisch greifbar ist. Dann kann man nach einem Angriff
mit brauchbaren Aussichten vor Gericht. Ein Einbrecher lässt daher auch
selten mit Absicht seinen Personalausweis liegen :) Das ist eigentlich
auch das, was ein Zertifikat macht: einen Schlüssel zu etwas
"natürlichem", fassbaren assozieren. Also genau dem Server Nr 4 im
Regal, der Herrn Müller gehört oder Herrn Müller selbst oder die Müller
Milch GmbH. In allen Fällen kann der Staatsanwalt ggf. was machen.

Gegen den - evtl. nicht mal deutschen - Admin von ziel.de kann man evtl
aber gar nichts machen, weil man nichtmal weiss, wer es ist. Ob nu mit
oder ohne Zertifikat, weil genau das ja auch nicht im Zertifikat drin
steht.

Die beiden Hauptattacken werden also nicht verhindert. Im Gegenteil,
Menschen könnten meinen, sie würden verhindert und daher weniger
skeptisch sein. Unterm Strich ist der Sicherheitsgewinn negativ. Das
sollte man meiner Meinung nach nicht unterstützen.

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

Warum, geht doch nur, wenn genau für diese Domain schon jemand
ausgerechnet bei cacert.org was angemeldet hat - vielleicht sogar für
den Server. Das ist doch sehr unwahrscheinlich. Wahrscheinlich hat er
entweder gar kein Zertifikat (99.99%) oder ist bei einem grossen
reseller hinter Verisign (ca 0.01%). Nur in den verbleibenden ca. 0.00%
der Fälle hat er ein cacert.org Account...

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

Kann er ja so auch. Falls er nach dem DNS spoofing ein Mailprogramm
bedienen kann, wovon man wohl ausgehen kann ;)

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

Wieso, wenn ich einen DNS Server hacke, der die domain hostet, kann ich
schön zentral die IP ändern und gut ist. Einen DNS im LAN anzugreifen
klingt für mich schon wieder ziemlich nach exoten-Angriff. DNS Server im
LAN haben in der Regel Firmen (mit IT, da geht Angriff hoffentlich nicht
so gut), da kommt man so nicht weiter. Klasische DSL-User haben keinen
DNS-Server, kommt man auch nicht weiter, also bis auf ein paar
Home-Linux-Netze (die global gesehen sicherlich nicht die Bedeutung
haben) fällt mir da nix ein...

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

Die meisten haben doch überhaupt kein Zertifikat. Und selbst wenn, der
Hauptangriff geht ja eh anders, mit ähnlicher domain. Also hole ich
mir Steffen-Schulz-Computer.de, ein cert und behauptet zu Deinen Kunden,
dass sie da bitte ihre Kreditkartennummer eingeben. Nun könnten die
drauf reinfallen, weil ja ein Schloss am Browser ist. Das funktioniert,
weil das Zertifikat die Identität nicht beinhaltet. Würde da drin
stehen, es gehört zu Steffen Dettmer, würde der Benutzer eine Chance
haben, den Betrug zu entdecken. So hat er sie nicht.

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

cbg.homeip.net?

> Noch ein Punkt: CaCert ist auch einfach. Einfacher als nen eigenes
> root-cert mit CRL und so. 

Wie "einfach"? Eingene root-CA ist auch einfach. Paar openssl Kommandos
oder ein Skript und fertig. Ist bei mod_ssl dabei, steht cacert drin.
Oder war's snakeoil? :-)

> Und ich denke, jede Site, die auch ssl anbietet, ist insgesamt ein
> Gewinn. 

Nein, eben genau nicht! Das ist die Gefahr! Man denkt, es wäre sicherer,
ist es aber gar nicht! Damt ist es unterm Strich sogar weniger sicher!

> Die Kosten sind vernachlaessigbar und wenn's komplett falsch
> ist...naja, vllt naechstes mal...

Na toll... Nach dieser Aussage bestelle ich mein online-Kunden-Portal
dann doch lieber nicht bei Steffen-Schulz-Computer.de ;-)

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

jo.


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

Welche Quelle sagt das? In der letzten Telefonkonferenz hatte ich
gefragt und es hiess, 1024 bit für Endstellen seien für 10 Jahre
ausreichend und würden T-Systems zertifiziert (bei CAs ist's ja Wurscht,
die nehmen pauschal 2048). Ich weiss nicht mehr genau, wo ich die
Tabelle gesehen hatte, hab schon Kollegen gefragt, müsste bei EMV oder
VISA PED gewesen sein, aber die Specs findet google leider nicht.

Zu 1280 fand google nichts passendes.

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

Gerade SmartCards sind ja das gegenteilige Beispiel! EMV Co kennt
Klartext PIN! Super! Und static data authentication! Da wären ja 512 Bit
ausreichend, kann man eh kopieren!

In der Praxis kenn ich auch nur 1024 Bit bei Zahlungssystemen.

Wofür empfiehlt das BSI 2048 Bit? Für CAs, weil CPU Leistung eh egal?
Ist dann aber ein anderes Thema! Für z.B. Zahlungsverkehr mit Endgeräten
wohl nicht, oder?

> Und wer da RSA nimmt, ist selbst schuld..

EMV basiert im Prinzip drauf... Und ich wüsste nicht, welche grossen
Karten nicht EMV konform werden wollen... AmEx macht /vielleicht/ was
eigenes, aber dann bestimmt auch RSA weil Standard in US.

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

Leider kenn ich §7 Abs. 1 bis 3 SigG usw. nicht, aber das liest sich
sehr, als ob es um Zertifizierungsschlüssel (CA Schlüssel) geht, wo
Leistung keine Rolle spielt, man zertifiziert jeden ja nur alle zwei
Jahre oder so. Das heisst meiner Meinung nach noch lange nicht, dass die
zu zertifizierenden Schlüssel mindestens so gross sein sollten.

Aber Danke für den Link! Hast Du sowas auch noch für
"Klientenschlüssel"?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.