On Fri, May 16, 2008 at 12:59:28PM +0200, Marc Haber wrote: > On Fri, May 16, 2008 at 12:37:08PM +0200, Raphael Becker wrote: > > Hmm, wenn dsa-Private keys auf UUGRN-Servern liegen, dann nehme ich per > > default an, dass der Eigentümer diesen auch dort erstellt hat. > > Bei DSA-Keys liegt das Problem etwas anders: Hier reicht die Benutzung > eines DSA-Keys mit einem gegen das schwache Debian-OpenSSL gelinkten > Clients für die Kompromittierung des Keys, unabhängig davon ob der Key > selbst stark oder schwach ist. > > Ich würde deswegen dringend empfehlen, alle Zeilen, die mit ssh-dss > beginnen, aus authorized_keys Files rauszuwerfen, da Du nicht > kontrollieren kannst, ob Deine User vielleicht ein Debian oder Ubuntu > als Client benutzen. Ist nicht einzig entscheidend, mit welcher Version der Key generiert wurde ("ssh-kegen -t dsa")? Welches OS der Client hat, dürfte ziemlich egal sein, auch ob es ungepatchtes Debian ist oder gepatchtes. Entscheidend ist, aus welchem Material der Key besteht, denn dieser ist vorhersagbar bzw. auf sehr wenige verschiedene Keys reduzierbar. Dieses sehe ich als eine konkrete Gefahr an und ich glaube (hoffe), dass ich mit dowkd.pl erkennen kann, wenn ein Schlüssel dieser sehr geringen Menge von vorhersagbaren Schlüsseln entspricht. Auch wenn es nicht repräsentativ ist: Ja, ich gestehe, in der letzten zeit auch mal was mit Debian gemacht zu haben, ich hatte sogar SSH-Keys damit generiert UND VERWENDET. Da ich eine sehr übreschaubare Anzahl an Debian-Installationen habe, konnte ich hier sehr gezielt prüfen. Alle Keys wurden als "weak" erkannt. Ja, aus der Vergangenheit hatte ich @home auch User, die von Debian kommend einen SSH-Login bei mir hatten. Die fraglichen keys wurden 2005 (oder früher) erzeugt. Auch nicht viele, aber alle wurden als "nicht weak" erkannt. Keys aus egal welchen Zeiträumen, die mit anderen Systemen generiert wurden, wurden alle als "nicht weak" erkannt. Ich gehe also mal davon aus, dass ich mittels dowkd.pl "weak keys" anhand der public-keys erkennen kann. Das habe ich bisher getan. Wo liegt die konkrete(!) Gefahr bei ALLEN DSA-Keys oder die Wahrscheinlichkeit, dass ein beliebiger DSA-Schlüssel von einem Debian stammt und NICHT als "weak" erkannt wurde? > Leider kann man DSA im ssh-Daemon nicht komplett abschalten, sonst > hätte ich das längst gemacht. > > > Ich wüsste aus dem Stand auch nicht, wie ich die diversen id_dsa-Dateien > > prüfen sollte, > > Ob DSA-Keys auch bei Verwendung gegen einen gegen das schwache > Debian-OpenSSL gelinkten Server kompromittiert werden, weiß ich nicht. > Primäre Priorität sollte aber der Schutz der UUGRN-Systeme gegen > unerwünschte Benutzer sein, also eine Behandlung der > authorized_keys-Fils gegen schwache RSA-Schlüssel und grundsätzlich > gegen DSA-Schlüssel.. Wie wahrscheinlich siehst Du es an, dass ein Debian-DSA-Key von dowkd.pl als "unbedenklich" eingestuft wird und dieser dennoch der vorhersagbaren Schlüsselmenge entspricht (sprich: dass das tool falsch liegt)? Ich halte es für übertrieben, DSA grundsätzlich zu verbieten, denn ich gehe zu mindest weiterhin davon aus, dass DSA-Keys, die von einem !debian erstellt wurden, gewohnt sicher sind. Gruß Raphael -- Raphael Becker <rabe@uugrn.org> http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -- http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/
Dieses Archiv wurde generiert von hypermail 2.2.0 : 16.05.2008 CEST