[linux-l] CAcert - alternativen?

Steffen Schulz pepe_ml at gmx.net
Do Aug 24 20:59:57 CEST 2006


Hi Steffen,


Kurz: Macht Sinn.
Lang:

On 060824 at 00:10, Steffen Dettmer wrote:
> * Steffen Schulz wrote on Wed, Aug 23, 2006 at 22:06 +0200:

Ich hab die Reihenfolge der Zitate mal nach Themen sortiert..

> Wieso, wenn ich einen DNS Server hacke, der die domain hostet, kann ich
> schön zentral die IP ändern und gut ist.

Ach du willst den zustaendigen Server knacken.

Also ich denke, wenn du den zustaendigen DNS-Server dein eigen nennen
kannst, hat der Admin noch ganz andere Probleme. zB halt, dass wirklich
alle Mails umgeleitet werden. Dieser DNS-Server ist doch auch oft fuer
die Aufloesung zustaendig, da kann man problemlos backdoors
unterschieben. Der DNS-Server duerfte allgemein auch ungefaehr so stark
abgesichert sein, wie der Webserver.

(dyndns.org jetzt mal ausser acht gelassen)

> Einen DNS im LAN anzugreifen klingt für mich schon wieder ziemlich
> nach exoten-Angriff.

Welchen zustaendigen DNS-Server wolltest du denn dann angreifen?
Auch bei gemieteten Servern duerften Web- und DNS-Server aehnlich gut
abgesichert sein. Und auch hier gilt, dass das vermutlich auch der fuer
DNS-Queries nach draussen zustaendige Server ist.

Ich dachte du beziehst dich mit DNS-Manipulation auf Cache-Poisoning.
Ist, ohne das mal gemacht zu haben, glaube ich noch einfacher als
den Server zu knacken, der fuer die Domain zustaendig ist.

Und zu Cache-Poisoning meinte ich halt, dass das gegenueber dem Opfer
zwar leicht sein kann(innerhalb eines LAN oder bei einem Dialup-User),
aber gegenueber CaCert wohl nicht so leicht ist.

Wenn sie clever sind, nutzen sie intern noch einen weiteren DNS-Server,
der nach aussen hin nicht bekannt ist und immer erstmal die root-server
befragt. Die Mails werden jedenfalls nicht vom Webserver verschickt..

> Warum, geht doch nur, wenn genau für diese Domain schon jemand
> ausgerechnet bei cacert.org was angemeldet hat

Ein Grund mehr, da mitzumachen... :->


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

Damit waeren wir wieder bei "url unterschieben", wogegen auch ein
echtes cert nicht schuetzt. Aber richtig, ein Cert fuer eine
phishing-site zu bekommen, ist schon komplizierter, weil der Fischer
seine Daten nicht grad ueberall angeben will. Beliebter ist hier der
Ansatz, Browserbugs auszunutzen. Oder SSL gleich zu ignorieren.

Also zusammenfassend:

Wenn ich fuer meine Domain ein cacert-cert habe, schliesse ich damit
jeglichen MITM ziemlich gut aus. Niemand wird fuer diese Domain einfach
so ein Zert erzeugen koennen, ausser mein Login bei cacert ist schlecht
geschuetzt.

Wenn das root-cert auf dem Client liegt, bekomm ich das gleiche mit
self-signed certs hin. Wenn auch mit etwas mehr Verwaltungsaufwand.

Wenn das root-cert jeweils noch nicht installiert ist...hab ich auch
nicht viel gewonnen. Vielleicht ist es besser, nur einem cacert-root zu
trauen, als vielen verschiedenen self-signed-certs? Eigentlich nicht,
weil wenn man clever ist, traut man nur dem eigenen root-cert. Fremde
self-signed certs benutzt der Browser glaub ich nicht, um weitere
self-signed certs zu authentifizieren(?).

Wenn man das cacert-root-cert eingebunden hat, buesst man damit das
Feature ein, dass fake-sites grundsaetzlich ne Fehlermeldung erzeugen.
Weil die Urheber dieser Sites sich ungern irgendwo authentifizieren.
Mit cacert bekommen sie das jedoch recht anonym hin.

Im Gegenzug bekommt man etwas Komfort in Sachen root-cert-Verwaltung.
Und man kann sein root-cert zusaetzlich von einer ganz anderen Quelle
beziehen als der (im Angriffsfall vermutlich kompromittierten) Eigenen.

Ich glaub, ich werd wohl doch wieder ne eigene CA aufsetzen und den
Rechnerpark, der mit unterworfen ist, mit certs dieser CA ausstatten.

Der Fingerprint der CA kommt dann, wie einige ssh-pub-key-fingerprints,
auf den Zettel in meinem Portemonaie. Fuer unterwegs.


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

Na man macht ein cert und laesst sich das per Webinterface signieren.

Ich spare Aufwand, weil mir das root-cert erspart bleibt. Weil dieses
root-cert muss man auch verbreiten, fingerprint abrufbar haben, CRL
abrufbar haben.

(BTW, hier in der Ruhr-Uni-Bochum wird einem beigebracht, dass niemand
 ernsthaft CRLs benutzt, wegen der enormen Serverlast, die das erzeugen
 wuerde. Sollte man mal gucken, wie oft firefox die CRLs checkt...)

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

EMV Co kenn ich nich. Generell sollte aber gelten, dass man mit
SmartCards nen ziemlich hohen Sicherheitsstand hinbekommt. Weil eben
nicht kopierbar. Mindestens die PIN kann man allgemein auch selbst
setzen.

> > Und wer da RSA nimmt, ist selbst schuld..
> EMV basiert im Prinzip drauf...

Jo, in der Industrie hat man sich mit Elliptischen Kurven noch nicht so
recht angefreundet. Wird vllt auch noch ne ganze Weile dauern, wegen
der Patentgeier...

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

Es geht um das SigG, also um digitale Signaturen als Ersatz fuer die
uebliche Unterschrift. Ich spreche hier allgemein nur noch von der
Sicherheit der Algorithmen.

Der Algorithmenkatalog wird jaehrlich herausgegeben und sagt, was
derzeit offiziell als sicher angenommen wird.

Wenn wir jetzt mal von RSA ausgehen, kann man aus der Tabelle auf Seite
3 lesen, dass man, wenn man mit seiner Cryto vor Gericht auf der
sicheren Seite sein will, momentan 1024 Bit braucht.

Wenn nun einer mithoert und die Kommunikation bis mindestens 2008
geheim bleiben soll, sollten es schon 1280 sein.

In der Praxis wird der Richter bei SSL mit 1024 in 3 Jahren vllt noch
nen Auge zudruecken, nachdem ihm nen Sachverstaendiger erklaert hat,
dass sowas allerhoechstens vom chinesischen Geheimdienst gebrochen
werden kann. Wer weiss..

Auf der Serverseite hat man natuerlich ein Problem. Wer viele Anfragen
erwartet, muss dann halt die Crypto in Hardware machen. Client-Seite
ist heute egal, jeder Desktop schluckt gut ueber 2048 ohne spuerbare
Verzoegerungen. Performance ist aber nicht Gegenstand der
Ueberlegungen, es geht dort nur darum, was offiziell sicher ist.

Offiziell wird dieser Katalog glaub ich von der Bundesnetzagentur
rausgegeben, aber da hab ich spontan nichts gefunden.


mfg
pepe
-- 
Rauchen ist eine arge Unhoeflichkeit, ja eine impertinente Ungeselligkeit.
Wer kann das Zimmer eines Rauchers betreten ohne dabei Uebelkeit zu
empfinden. Wer kann darin verweilen ohne umzukommen. -- Johann Wv. Goethe



Mehr Informationen über die Mailingliste linux-l