[linux-l] CAcert - alternativen?

[Steffen Dettmer]

* Steffen Schulz wrote on Thu, Aug 24, 2006 at 20:59 +0200:
> 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.

Ja, wird aber meist ohne DNSSEC gefahren (also müsste man analog auch
HTTP oder S fahren :)) - oder?

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

Cache-Poisoning funktioniert heute noch? Gut, dann muss man rauskriegen,
welchen Server cacert.org nimmt ;)

> Ist, ohne das mal gemacht zu haben, glaube ich noch einfacher als
> den Server zu knacken, der fuer die Domain zustaendig ist.

Weiss nicht, wieviele heute DNS überhaupt noch selbst machen.
 
> 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.

Für'n Dialup-User müsstest Du z.b. t-onlines DNS Server angreifen, was
hoffentlich schwierig 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..

Ja, genau. Daher guckt man, ob ein RIPE record nicht gesichert ist, ein
reseller-frontend missbraucht werden kann oder sowas.

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

(Na doch, tut es, wenn ich "Deutsche Bank AG" erwarte und "Snakeoil"
lese, kann ich abbrechen, was die meisten natürlich nicht merken
würden).

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

OK, es ist genauso sicher, wie ein HTTP MITM, was ja auch nicht so ganz
einfach ist. Braucht man also wieder kein cert.

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

Ja, und gerade der policy-freie cacert.org Bude natürlich nicht (die
keine Identitäten drin haben, weil man die nicht prüfen kann, nasowas
lol)

> Fremde self-signed certs benutzt der Browser glaub ich nicht, um
> weitere self-signed certs zu authentifizieren(?).

self-signed certs zu authentifizieren? Ist das nicht ein Widerspruch?

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

genau, selbst am Telefon vorgelesen meiner Meinung nach recht sicher,
weil schwer anzugreifen.

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

enorme Serverlast? mmm... Kommt doch bloss ein 304? Naja, damals, als
ich mit damit beschäftigt hatte, machten die Browser das einfach nicht.

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

Das sind die mit den Kreditkarten (Europay, Mastercard und VISA, sind
aber nur noch zwei Firmen, ich glaub, Mastercard hat Europay gekauft)
:-) Also überhaupt fast alle Karten, weltweit gesehen. In Deutschland
auch, weil ec EMV-konform werden wird.

> Generell sollte aber gelten, dass man mit SmartCards nen ziemlich
> hohen Sicherheitsstand hinbekommt. 

Technisch, aber nicht unbedingt praktisch. International geht symetrisch
nicht, weil man niemandem traut. asmyetrisch braucht RSA chip, kostet
angeblich 5 EUR pro Karte und ist damit oft zu teuer...

> Weil eben nicht kopierbar.

static data authentication /ist/ kopierbar (also: von den gewinnbaren
Informationen kann man einen Simulator bauen). Macht halt nur mit
dynamic (und RSA chip) Sinn...

> Mindestens die PIN kann man allgemein auch selbst setzen.

Ja gut, aber die dient ja der Inhaberprüfung, nicht der Kryptographie,
aber egal.

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

Vielleicht ist es auch langsam, lässt sich nicht gut in Hardware giessen
oder sowas, keine Ahnung.

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

Ja gut, /das/ war mir noch klar ;)

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

als sicher wofür? Ohne das "wofür" macht's ja nu keinen Sinn.
Normalerweise hat man einen Schutzlevel, z.B. 100.000 $ pro Key. Klar,
wenn man 1.000.000.000.000.000 $ Schutzlevel haben möchte, braucht man
vielleicht 1280 Bit ;)

Zahlungssystemhardware muss 50.000 $ abkönnen, glaub ich. Ist gar nicht
soooo viel, aber schon aufwändig genug, das hinzukriegen.

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

Wie gesagt, ich glaube, es geht dabei nur um CA Schlüssel, nicht um zu
zertifizierende.

> Auf der Serverseite hat man natuerlich ein Problem. Wer viele Anfragen
> erwartet, muss dann halt die Crypto in Hardware machen. 

Nein, man macht Crypto nicht so sehr in Hardware, damit's schneller
geht, sondern weil man dann einen sicheren (tamper-responsive)
Schlüsselspeicher nehmen kann. Die Leistung von einem AMD x2 musste mit
einer cryptobox erstmal schaffen, CPUs sind bestimmt immer viel viel
billiger :)

> Client-Seite ist heute egal, jeder Desktop schluckt gut ueber 2048
> ohne spuerbare Verzoegerungen. 

Sicher das? mmm... Ich bilde mir ein, bei 500 MHz Maschinen bei SSH RSA
einen Unterschied wahrgenommen zu haben (1024 vs 2048). Naja, ist auch
nicht mehr wirklich "heute" lol

> Performance ist aber nicht Gegenstand der Ueberlegungen, es geht dort
> nur darum, was offiziell sicher ist.

offiziell sicher ist ein one-time-pad unter bestimmten Bedingungen ;)

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

Schade, aber vielen lieben Dank!

oki,

Steffen

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