Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › SHA-1: Eigene Empfehlungen nicht…

Bullshit. BULLSHIT.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Bullshit. BULLSHIT.

    Autor: /mecki78 05.02.14 - 15:48

    Das SHA-1 nicht mehr sicher ist, ist Bullshit, denn faktisch betrachtet ist auch MD5 noch sicher und das ist ja sogar noch schwächer als SHA-1. Es kommt immer darauf an, was man genau macht bzw. wofür man den Hash verwenden will.

    Alle SHA-1 Sicherheitsprobleme sind "theoretischer Natur", noch nie hat irgendwer jemals einen auch nur halbwegs brauchbaren Angriff in der Praxis präsentieren können.

    Es werden gerne mal theoretische Angriffe beschrieben, die ca. 200 Jahre dauern und 10 Mrd Euro kosten würden und schon heißt es "total unsicher". Ach ja? Weil ich in 200 Jahren für 10 Mrd Euro eine SHA-1 Signatur knacken könnte (nur rein theoretisch!) ist also SHA-1 unsicher? Dem gegenüber stehen ca. 10 Mrd SHA-1 Signaturen die TÄGLICH erzeugt werden. Wie gesagt EINE davon könnte ich in den nächsten 200 Jahren für 10 Mrd Euro knacken, eine einzige, was bedeutet ich habe weder die Zeit noch das Geld die anderen 9,9 Mrd von heute zu knacken, und morgen kommen bereits weitere 10 Mrd dazu, übermorgen auch, usw., usw., usw. Bis ich also eine geknackt habe (theoretisch), hat die Menschheit mehr Signaturen erzeugt, als ich jemals knacken könnte, weil solange existiert das Universum wahrscheinlich nicht mehr.

    Und in der Theorie sind Praxis und Theorie das gleiche, in der Praxis aber nicht. Zwischen "Ich denk mir mal einen Angriff auf dem Papier aus" und "Ich zeige diesen Angriff auch in der Praxis" liegen manchmal Welten. Welten die dann auch schnell mal weit länger dauern als 200 Jahre oder weit teurere sind als 10 Mrd Euro.

    MD5 ist ja auch sooooooooooo unsicher. Da ist es doch glatt möglich mit viel Aufwand zwei Datensätze zu erzeugen, die beide die gleiche MD5 Signatur haben. Wow. Das ist so ... unspektakulär. Zwei zufällige Datensätze, völlig nutzlos ist der Praxis, erzeugen also die gleiche MD5 Signatur ::gähn:: Und welchen genialen Angriff will ich damit bitte in der Praxis durchführen? Ja, ich höre?

    Denn noch nie ist es jemanden gelungen eine MD5 Signatur "umzudrehen", d.h. noch nie hat es jemand geschafft zu einer beliebigen MD5 Signatur einen passenden Datensatz zu erzeugen (egal welchen), der eben genau diese Signatur liefern würde. Und nur genau dieses wäre wirklich relevant und nur genau dieses würde dazu führen, dass man MD5 "geknackt" nennen dürfte.

    Wobei es hier auch so ist, dass selbst dieses nur dann interessant ist, wenn man bestimmte Datensätze erzeugen kann, denn eine sinnvolle Daten mit einer MD5 durch Datenmüll mit der gleichen MD5 tauschen zu können, bringt bitte genau was? Eben, ich muss sinnvolle Daten durch sinnvolle Daten tauschen können, damit das ganze was bringt. z.B. den Text einer E-Mail durch einen anderen Text ersetzen oder den Programmcode einer Datei durch anderen Programmcode. Nur dann können wir von echten, gefährlichen und in der Praxis anwendbaren Angriffsszenarien sprechen.

    Und solange noch kein Mensch, keine Behörde, kein Super- und kein Quantencomputer auch nur ein einziges mal demonstrieren konnte, dass er wirklich eine MD5 Signatur "brechen" kann, z.B. indem er ein SSL Zertifikat durch ein anderes tauscht, dessen Inhalt anders, aber dessen Signatur gleich ist, solange ist nicht einmal MD5 wirklich gebrochen. Und wenn wir MD5 nicht brechen können, dann sind wir noch ewig weit davon entfernt SHA-1 zu brechen.

    Das ist alles Panikmache hoch 10 und lenkt nur von den echten Problemen ab. So nutzen immer noch diverse Server heute RC4 Verschlüsselung bzw. sie nutzen kein PFS, und das obwohl RC4 wirklich "geknackt wurde", und zwar nicht auf dem Papier, sondern im Computer, und obwohl jedem Kryptographen klar ist, dass eine Verschlüsselung ohne PFS zwar auch sicher sein kann, aber eben nicht auf Dauer. Das sind echte Probleme, echte Probleme, die unsere Sicherheit bereits heute, jetzt genau in diesem Moment, beeinträchtigen. Stattdessen macht man sich Gedanken über die Sicherheit von SHA-1, nur weil es gegen irgend welche Angriffe theoretisch verwundbar ist, was noch nie zu irgend einem auch nur im Ansatz brauchbaren Praxisangriff genutzt werden konnte.

    /Mecki

  2. Re: Bullshit. BULLSHIT.

    Autor: Lala Satalin Deviluke 05.02.14 - 15:55

    Who cares, ich würde eher SHA512 für Passwörter, in dem noch weitere statische Informationen hinein gemischt werden + einem Algorithmus, der 1 Mio Zyklen durchläuft, nutzen.

    Grüße vom Planeten Deviluke!

  3. Re: Bullshit. BULLSHIT.

    Autor: hannob (golem.de) 05.02.14 - 16:00

    Sorry, aber Deine Darstellung ist an verschiedenen Stellen falsch.

    Also: Die Angriffe gegen SHA-1 sind nicht so theoretisch wie Du es darstellst. Die Kosten für einen Angriff sind eher im Zehntausender-Bereich und die Zeit im Bereich von Monaten. Dass das noch niemand öffentlich durchgeführt hat liegt einzig und allein daran dass es bisher noch kein Forscherteam gab, welches sich darum gekümmert hat. Es ist nur eine Frage der Zeit. Und wer will und das Budget hat kann solche Angriffe schon heute durchführen.

    Die Angriffe gegen MD5 sind weit praktischer als Du es darstellst. Es ist nicht nur möglich, Kollissionen von Nonsens-Informationen zu erzeugen, sondern auch solche von sehr praktisch nutzbaren Daten wie beispielsweise Zertifikate. Und das wurde - siehe Flame - schon sehr praktisch ausgenutzt und hat zu ganz realen Sicherheitsproblemen geführt. Das steht im übrigen auch im Artikel, den Du vermutlich nicht bis zu Ende gelesen hast.

    Was auch im Artikel steht: Es gibt einen Unterschied zwischen Kollissionsangriffen und Preimage-Angriffen. Die Details sind ein wenig komplizierter, aber für digitale Signaturen sind Kollissionsangriffe sehr wohl relevant. Es ist damit zwar nicht möglich, zu einer bestehenden Signatur ein für diese Signatur gültiges Urbild zu erzeugen, aber man kann zwei unterschiedliche Dokumente mit selbem Hash erzeugen, eins davon signieren lassen und die Signatur gilt für das andere auch. Bei X509-Zertifikaten schützt vor einem solchen Angriff noch die Seriennummer. Für Details empfehle ich den im Artikel verlinkten Vortrag vom 20C3, der geht da ausführlich drauf ein.

    Bzgl. RC4 sind Deine Infos auch falsch: Diese Probleme sind ebenfalls im Moment zum Großteil nur theoretisch. Einen praktischen Angriff auf RC4 in TLS konnte beispielsweise bisher noch niemand zeigen (wobei es in anderen Protokollen praktisch relevantere Probleme gibt). Es gibt Vermutungen, dass die NSA da mehr kann als der Rest der Welt, aber das selbe gilt auch für SHA-1. Ich will die Nutzung von RC4 auf keinen Fall verteidigen, das muss genauso weg wie SHA-1, aber es spielt in einer ähnlichen Liga.

  4. Re: Bullshit. BULLSHIT.

    Autor: DASPRiD 05.02.14 - 16:29

    Lala Satalin Deviluke schrieb:
    --------------------------------------------------------------------------------
    > Who cares, ich würde eher SHA512 für Passwörter, in dem noch weitere
    > statische Informationen hinein gemischt werden + einem Algorithmus, der 1
    > Mio Zyklen durchläuft, nutzen.

    Ähm, Bcrypt/Scrypt?

  5. Re: Bullshit. BULLSHIT.

    Autor: daniel.ranft 05.02.14 - 16:48

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > MD5 ist ja auch sooooooooooo unsicher. Da ist es doch glatt möglich mit
    > viel Aufwand zwei Datensätze zu erzeugen, die beide die gleiche MD5
    > Signatur haben. Wow. Das ist so ... unspektakulär. Zwei zufällige
    > Datensätze, völlig nutzlos ist der Praxis, erzeugen also die gleiche MD5
    > Signatur ::gähn:: Und welchen genialen Angriff will ich damit bitte in der
    > Praxis durchführen? Ja, ich höre?

    Du hast vermutlich auch noch nie was von Rainbowtables gehört, oder? Klar, die gelten nur für Passwörter ohne Salt, aber es gibt leider viel zu viele Webseiten, welche die Passwörter nicht salzen.

  6. Re: Bullshit. BULLSHIT.

    Autor: chris m. unwillig 05.02.14 - 16:51

    """
    aber man kann zwei unterschiedliche Dokumente mit selbem Hash erzeugen, eins davon signieren lassen und die Signatur gilt für das andere auch. Bei X509-Zertifikaten schützt vor einem solchen Angriff noch die Seriennummer.
    """

    das würde hinter diesen einen paragraph (kollision, preimage) im artikel noch gut passen

    ich wusste nämlich grad mal echt gar nichts von kollisionsangriff und abwehr *schäm
    würde man die abwehr dann auch als "salting" bezeichnen?

  7. Re: Bullshit. BULLSHIT.

    Autor: tobzn 05.02.14 - 16:58

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Bullshit... Schwachsinn erzählen... Sich selbst lächerlich machen.
    > Weiteres Bla Bla Bla ohne Hintergrundwissen.

    Find es immer wieder genial wie sich manche Leute so richtig zum Idioten machen, weil sie nicht in der Lage sind A) das Thema zu greifen oder B) Google zu nutzen.

    http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/



    1 mal bearbeitet, zuletzt am 05.02.14 16:58 durch tobzn.

  8. Re: Bullshit. BULLSHIT.

    Autor: hannob (golem.de) 05.02.14 - 17:00

    Nur um das mal klarzustellen: Wir reden hier von digitalen Signaturen. Mit dem Hashen von Passwörtern und Rainbow Tables hat das ziemlich genau nichts zu tun.

    Beim Hashen von Passwörtern gelten völlig andere Anforderungen an die Hashfunktion. Da sind Kollissionen auch irrelevant, man könnte auch sichere Passwort-Hashing-Schemata mit SHA1 oder sogar mit MD5 bauen. Aber: Es hat hier einfach nichts mit dem Thema des Artikels zu tun.

  9. Re: Bullshit. BULLSHIT.

    Autor: chris m. unwillig 05.02.14 - 17:06

    tobzn schrieb:
    --------------------------------------------------------------------------------
    > /mecki78 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Bullshit... Schwachsinn erzählen... Sich selbst lächerlich machen.
    > > Weiteres Bla Bla Bla ohne Hintergrundwissen.
    >
    > Find es immer wieder genial wie sich manche Leute so richtig zum Idioten
    > machen, weil sie nicht in der Lage sind A) das Thema zu greifen oder B)
    > Google zu nutzen.
    >
    > hackaday.com

    wobei man mecki diesen teil hier zugute halten könnte?

    """
    From testing, they knew that RapidSSL would always sign six seconds after the order was acknowledged. Knowing these two facts they were able to generate a certificate in advance and then purchase the exact certificate they wanted. They’d purchase certificates to advance the serial number and then buy on the exact time they calculated.
    """

    würd mich mal interessieren, ob das auch die/eine schwäche bei "flame" war...

  10. Re: Bullshit. BULLSHIT.

    Autor: chris m. unwillig 05.02.14 - 17:08

    hannob (golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Nur um das mal klarzustellen: Wir reden hier von digitalen Signaturen. Mit
    > dem Hashen von Passwörtern und Rainbow Tables hat das ziemlich genau nichts
    > zu tun.
    >
    > Beim Hashen von Passwörtern gelten völlig andere Anforderungen an die
    > Hashfunktion. Da sind Kollissionen auch irrelevant, man könnte auch sichere
    > Passwort-Hashing-Schemata mit SHA1 oder sogar mit MD5 bauen. Aber: Es hat
    > hier einfach nichts mit dem Thema des Artikels zu tun.

    die kollisionen sind wegen des salts irrelevant oder generell?
    ihr verwirrt mich noch total :)

  11. Re: Bullshit. BULLSHIT.

    Autor: justanotherhusky 05.02.14 - 18:24

    /mecki78 schrieb:
    --------------------------------------------------------------------------------

    >
    > Es werden gerne mal theoretische Angriffe beschrieben, die ca. 200 Jahre
    > dauern und 10 Mrd Euro kosten würden und schon heißt es "total unsicher".
    > Ach ja? Weil ich in 200 Jahren für 10 Mrd Euro eine SHA-1 Signatur knacken
    > könnte (nur rein theoretisch!) ist also SHA-1 unsicher? Dem gegenüber
    > stehen ca. 10 Mrd SHA-1 Signaturen die TÄGLICH erzeugt werden. Wie gesagt
    > EINE davon könnte ich in den nächsten 200 Jahren für 10 Mrd Euro knacken,
    > eine einzige, was bedeutet ich habe weder die Zeit noch das Geld die
    > anderen 9,9 Mrd von heute zu knacken, und morgen kommen bereits weitere 10
    > Mrd dazu, übermorgen auch, usw., usw., usw. Bis ich also eine geknackt
    > habe (theoretisch), hat die Menschheit mehr Signaturen erzeugt, als ich
    > jemals knacken könnte, weil solange existiert das Universum wahrscheinlich
    > nicht mehr.
    >
    >

    Dem muss ich in zwei Punkten widersprechen.

    1. Auch wenn es aus heutiger Sicht vonmiraus erst in 200 Jahren mit 10MRD eine Signatur knacken könnte, heißt das nicht dass das in 5 Jahren auch noch gilt. In 5 jahren dauerts nämlich nicht automatisch 195 Jahre, vielleicht dauerts nur noch 10 Jahre, weil jemand eine bahnbrechende Entdeckung im bereich der Hardware gemacht hat.

    2. Du redest davon, dass mehr Signaturen erzeugt werden, als aus heutiger Sicht jemals geknackt werden könnten (dazu siehe erster Punkt). Es geht aber garnicht darum, ALLE Signaturen zu knacken.. es kann schon eine genügen ;-)

    Analog: Mann mit Waffe erschießt wahllos 3 Menschen in einer Millionenstadt. Die Wahrscheinlichkeit, dass er mich tötet steht 3/X-Millionen. Dennoch würde ich den Mann als gefährlich einstufen, auch wenn er es nicht schaffen wird, die ganze Stadt auszurotten.

  12. Re: Bullshit. BULLSHIT.

    Autor: /mecki78 05.02.14 - 18:25

    daniel.ranft schrieb:
    --------------------------------------------------------------------------------
    > Du hast vermutlich auch noch nie was von Rainbowtables gehört, oder?

    Und was haben Regenbogentabellen mit MD5, SHA-1 oder irgend sonst irgend einem Hash konkret zu tun? Dir ist schon bewusst, dass Regenbogentabellen mit jeder und jeglicher Hash-Funktion funktionieren, oder? Also auch wenn wir morgen alle SUPER-SHA-POWER-HOCH-1000 nutzen, hilft das gegen Regenbogentabellen absolut Null.

    Gegen Regenbogentabellen helfen nur längere Passwörter, ein Salt zu verwenden und mehrfache Iterationen (und dabei ist egal welches Hashes, auch mehrfach MD5 hilft ungemein).

    > Klar, die gelten nur für Passwörter ohne Salt,

    Bei Passwörtern ohne Salt benutzt man keine Regenbogentabellen, sondern greift in der Regel auf Datenbanken zurück (es gibt Datenbank mit zig Mio Hashes zu zig Mio bekannten Passwörtern; ich wette du hast schon Passwörter verwendet, die in diesen Datenbanken vorkommen) oder man nimmt gleich Brute Force was bei kurzen Passwörtern kein Problem darstellt und bei langen auch nicht, wenn man z.B. mit Markow Ketten arbeitet und die Passwörter nicht absolut zufällige Zeichenfolgen sind.

    Aber das hat alles nichts damit zu tun, dass SHA-1 angeblich unsicher ist.

    /Mecki

  13. Re: Bullshit. BULLSHIT.

    Autor: /mecki78 05.02.14 - 18:49

    tobzn schrieb:
    --------------------------------------------------------------------------------
    > Find es immer wieder genial wie sich manche Leute so richtig zum Idioten
    > machen, weil sie nicht in der Lage sind A) das Thema zu greifen oder B)
    > Google zu nutzen.

    Oder C) über Hacks posten, die sie selber gar nicht wirklich verstanden haben, weil sie sie auch im Detail nicht gelesen haben, denn ihnen waren die 50 Seiten detaillierter Text einfach zu viel zum lesen waren (tl;dr)

    Denn es ist zwar schön, dass es Leuten mit viel Aufwand gelungen ist ein Cert zu erzeugen, dass den gleichen Hash wie ein anderes Cert aufweist, aber das ist auch einfach, wenn man nur irgend ein Cert erzeugen will. D.h. wenn es mir total egal ist für welche Domain, mit welchen Attributen oder welchen Werten in den ganzen anderen Feldern.

    Nur in der Realität muss ich eben ein Cert für eine bestimmte Domain, mit bestimmten Attributen und bestimmten Werten erzeugen. Oder einfach und für jedermann verständlich formuliert: Ich hab nichts davon, wenn ich es schaffe die Bankverbindung in einer signierten Mail durch Ausschnitte aus Goethes Faust zu ersetzen, außer dass ich beim Empfänger Verwirrung stiften kann. Um schaden zu erzeugen, muss ich die Bankverbindung durch eine andere Bankverbindung ersetzen und wenn ich davon profitieren will, dann durch die meinige. Und genau hier scheitert der im Hack gewählte Ansatz.

    Im von dir genannten Hack wurde also ein Cert erzeugt, von dem der Browser fälschlicher Weise sagt "Es ist valide" obwohl es das nicht ist. Okay, "böse, böse". Nur passt das Cert auch gar nicht auf die Domain des vorherigen Certs, denn ein anderes Cert für die gleiche Domain zu erzeugen, dass haben sie nämlich nicht geschafft, und daher würde der Browser es sowieso ablehnen und sich weigern Daten damit zu verschlüsseln.

    Wie gesagt, es hängt davon ab, wofür man den Hash verwendet. Zwei Dateien mit gleichen MD5 Hash zu erzeugen kann z.B. ein Verwaltungssystem brechen, dass MD5 Hashes als Unique Keys verwendet und wo die Entwickler davon ausgegangen sind, dass es nie zu einer Kollisionen kommen wird und falls doch, stürzt das ganze System ab. Toll. D.h. man kann jetzt eine DoS gegen so ein System laufen lassen und das System immer wieder zum Absturz bringen. Nicht in allen Bereichen ist MD5 als sicher, aber das heißt nicht, dass es generell unsicher ist.

    Und bei SHA-1 sind wir noch weit von der MD5 Unsicherheit entfernt.

    /Mecki

  14. Re: Bullshit. BULLSHIT.

    Autor: /mecki78 05.02.14 - 18:59

    justanotherhusky schrieb:
    --------------------------------------------------------------------------------
    > 1. Auch wenn es aus heutiger Sicht vonmiraus erst in 200 Jahren mit 10MRD
    > eine Signatur knacken könnte, heißt das nicht dass das in 5 Jahren auch
    > noch gilt. In 5 jahren dauerts nämlich nicht automatisch 195 Jahre,

    "Realistische Zeitschätzung" beziehen natürlich immer die Hardwareentwicklung mit ein (Minimum ist Moore's Law, aber manche schätzen auch die Rechenleistung ab, die nicht unbedingt direkt an Moore's Law gekoppelt ist). Es mag höchstens sein, dass es hier eine sprunghafte Entwicklung gibt, also z.B. dass sich die Rechenkraft von Computern in einem Jahr auf einmal verhundertfacht oder so, dass kann natürlich niemand vorher ahnen, ist aber auch nicht sehr wahrscheinlich (und bisher in dieser Form auch noch nie geschehen, auch wenn es schon Abweichungen von Moore's Law gab, sowohl nach oben als auch nach unten).

    > Analog: Mann mit Waffe erschießt wahllos 3 Menschen in einer
    > Millionenstadt. Die Wahrscheinlichkeit, dass er mich tötet steht
    > 3/X-Millionen. Dennoch würde ich den Mann als gefährlich einstufen, auch
    > wenn er es nicht schaffen wird, die ganze Stadt auszurotten.

    Das ist schon richtig. Aber man stelle sich mal vor, die NSA könnte nicht zig Mrd Menschen im Internet belauschen, sondern nur höchstens 500 und das weltweit, glaubst wir hätten eine "NSA Affaire"? Wegen max. 500 Menschen, mit einer gigantischen Wahrscheinlichkeit, dass du nicht dabei bist?

    Es gibt keinen Beweis, nicht einmal einen begründeten Verdacht, das die NSA jemals irgendwo eine Signatur gefälscht hat (MD5 oder SHA-1). Wozu auch, im Zweifelsfall erzwingen Zugang zu den Root CAs und erzeugen nicht "gefälschte", sondern "echte" Signaturen. Was aber bekannt ist, ist dass die NSA RC4 knacken kann. D.h. wir scheißen uns ein wegen SHA-1, jeder vierte Server im Internet verschlüsselt aber nach wie vor seien Daten mit RC4? Wo ist da die Verhältnismäßigkeit?

    /Mecki

  15. +1

    Autor: lala1 05.02.14 - 19:27

    kt

  16. Re: Bullshit. BULLSHIT.

    Autor: chris m. unwillig 05.02.14 - 19:40

    mecki, in dem artikel auf hackaday steht, dass die forscher eine "bösartige" zertifikat-authorität erstellen konnten, mit der man dann (völlig "normale"?) weitere zertifikate herausgeben kann

    und wenn ich das ansatzweise richtig verstehe, dann konnten die das, weil der salt (oder halt serien nummer) vorauszusehen war, schliesslich hat rapidssl den salt bloß hochgezählt

    und sie mussten eben schauen, dass vom ssl anbieter md5 verwendet wird, weil da eine kollision mit den 400 playstationtagen möglich war. wieviel cpu das jetzt mit sha1 braucht weiss man ja nicht, aber laut wikipedia könnten da auch bald kollisionen machbar sein

    also, wenn der ssl anbieter bzw. irgendne nonce schlecht ist, und der hash algo ist schlecht, und man kann mit einem zertifikat andere ableiten, dann ist das schon ne art gau, behaupte ich jetzt mal

  17. Re: Bullshit. BULLSHIT.

    Autor: /mecki78 05.02.14 - 20:18

    chris m. unwillig schrieb:
    --------------------------------------------------------------------------------
    > mecki, in dem artikel auf hackaday steht, dass die forscher eine
    > "bösartige" zertifikat-authorität erstellen konnten, mit der man dann
    > (völlig "normale"?) weitere zertifikate herausgeben kann

    Nein, das steht da gar nicht. Da steht, dass sie eine CA gesucht haben, die mit MD5 signiert und die Zertifikate mit RapidSSL, weil der eben vorhersagbare Seriennummern erzeugt.

    Die Zertifikate, die sie erstellt haben, habe ich auch beide herunter geladen, die liegen hier vor mir, und das sind keine CA Zertifikate. Die CA, die angeblich beide signiert hat (das echte hat sie ja auch signiert, nur die Fälschung nicht) ist Equifax.

    Hier ist das echte Cert: http://redir.ec/FCaFv
    und hier die Fälschung: http://redir.ec/UfZ9a

    Bei haben die gleiche "Signature" (nur die ersten 8 Bytes sind sichtbar) und beide sind von einer CA signiert und damit keine CA Certs.

    Durch einen weiteren Trick, der mit der Hash Kollision gar nichts zu tun hat, haben sie sich dann zu einer "intermediate certificate authority" gemacht, das ist aber nicht das selbe wie eine CA zu sein. Das bedeute gar nichts, außer, dass du mit deinem Cert selber andere Certs signieren kannst. Wohlgemerkt ist dieses Flag auf den echten Cert gesetzt, dass sie auch wirklich gekauft haben, nicht auf den falschen (Siehe Bilder, "Key Usage", nur das echte hat "Derive" gesetzt).

    Du und viele anderen, ihr versteht diesen Angriff völlig falsch: Hier ging es nicht darum, dass irgendwer ein Cert hat und du jetzt irgendwie ein anderes Cert erzeugst, dass die gleiche Signatur hat, so dass du dieses z.B. austauschen könntest (weil das würde wie gesagt aufgrund der anderen Domain sowieso nicht funktionieren!).

    Hier ging es darum die Signatur eines zukünftigen Certs vorauszusagen, so dass es möglich ist, an diesem Cert eine Änderung vorzunehmen, so dass man ein anderes (modifiziertes Cert) erhält, dessen Signatur aber nach wie vor gültig ist. Warum sollte man das tun? Nun, um sich z.B. ein "Key Usage" Flag aneignen zu können. Darum ging es eigentlich.

    Und MD5 ist nur bedingt an diesem Hack schuld, die Hauptschuld liegt daran, dass es überhaupt möglich war vorherzusagen, wie die Signatur eines Zertifikats aussehen wird, wenn man es zu einem bestimmten Zeitpunkt kaufen wird. Eine solche Vorhersage ist gefährlich, auch dann wenn man SHA-1, SHA-2, oder SHA-X einsetzt. Was glaubst du warum man üblicherweise Salts verwendet (bzw. in Protokollen wird auch gerne von NONCE gesprochen). Das macht man, damit jemand, der alle Input Daten kennt dennoch nicht vorab den Hash kennen kann, weil eben ein Datum erst kurz vor Erzeugung dynamisch und zufällig generiert wird und das kann er unmöglich können. Die Hauptschuld bei dem Hack liegt bei Equifax bzw. dem Einsatz von RapidSSL bzw. dessen grottenschlechten Seriennummern System und ggf. auch anhand der Tatsache, dass X.509 Zertifikate keinen weiteren Salt haben oder wenn sie einen haben, dieser nicht benutzt wird. Hier von MD5 auf SHA-1 oder von SHA-1 auf SHA-2 zu wechseln ist wie Aspirin bei Kopfschmerzen: Der Schmerz ist weg, aber die Ursache des Schmerzes bleibt.

    Ach ja, vielleicht solltest du mal die Thread Ansicht anschalten. Denn du hast zwar auf einem Post von mir geantwortet, aber der hatte gar nichts mit dem Hack zu tun:
    http://redir.ec/Zn0AY

    /Mecki

  18. Re: Bullshit. BULLSHIT.

    Autor: chris m. unwillig 05.02.14 - 20:53

    thread ansicht aktiviert. man sieht ohne die ja gar nicht, in wieviele threads man sich einmischt! kommt irgendwie dreist rüber sorry (:

    >Nein, das steht da gar nicht. Da steht, dass sie eine CA gesucht haben,

    ja, schon. aber es steht auch da "The team was able to create a rogue certificate authority and use it to issue valid SSL certificates for any site they want."

    letztlich weiss ich nun gar nicht mehr, was dieser satz bedeuten soll. die ssl strukturen kenne ich in der tat so gut wie gar nicht.

    aber ich find das schon interessant: man kann argumentieren, dass eine hashfunktion vor einem bestimmten implementierungsfehler schützt, indem sie gar keine solche pre-image kollision erlaubt.

    aber letztlich hast du recht, wenn man das ganze betrachtet, wäre auch ein md5 ssl sicher implementierbar. das leuchtet mir schon ein. aber rapidssl hat vielleicht bewiesen, dass denn fehler wieder jemand machen könnte, also verordnet man allen das sha-1. stattdessen könnte man auch die korrekte ssl implementierung verordnen, aber vielleicht ist das ja weniger gut zu vermitteln, weil komplexer.

  19. Re: Bullshit. BULLSHIT.

    Autor: hannob (golem.de) 05.02.14 - 21:32

    Leider sind hier ein ganzer Haufen falscher oder unsinniger Behauptungen zu dem MD5/CA-Angriff verbreitet worden. Ich hab jetzt keine Lust das alles richtigzustellen. Aber ein Tipp: Der Vortrag dazu auf dem 20C3 ist wirklich interessant und erklärt vieles, das Video davon gibt's online [1]. Schaut Euch den an wenn es Euch interessiert.

    [1] http://media.ccc.de/browse/congress/2008/25c3-3023-en-making_the_theoretical_possible.html

  20. Re: Bullshit. BULLSHIT.

    Autor: /mecki78 05.02.14 - 21:40

    chris m. unwillig schrieb:
    --------------------------------------------------------------------------------
    > ja, schon. aber es steht auch da "The team was able to create a rogue
    > certificate authority and use it to issue valid SSL certificates for any
    > site they want."

    Schlecht formuliert. Eine "rouge intermediate certificate authority" wäre korrekt. Wo ist der Unterschied? Eine echte CA hat niemanden "über sich", eine intermediate CA aber schon, hier Equifax, und d.h. wenn Equifax dieses Cert für ungültig erklärt (Certificate Revokation), dann ist es auch ungültig. D.h. Equifax behält letztlich die endgültige Kontrolle. Das dieser Mechanismus nicht gerade toll und verlässlich ist, das ist eine Folgekrankheit davon, dass das komplette Cert System nicht wirklich toll ist. Das System basiert auf dem Vorgängersystem, welches auf dem Vorgängersystem basiert und dieses kommt aus dem Jahre 1988. Das war einfach noch eine andere Welt damals.

    > aber ich find das schon interessant: man kann argumentieren, dass eine
    > hashfunktion vor einem bestimmten implementierungsfehler schützt, indem sie
    > gar keine solche pre-image kollision erlaubt.

    Natürlich sollte es eine ideale Hashfunktion unmöglich machen, Kollisionen zu erzeugen, aber ganz unmöglich kann das ja nicht sein, denn der Zahlenraum der Hashes ist ja kleiner als der der Daten, d.h. verschiedene Daten müssen den gleichen Hash haben, woraufhin die Frage nur noch ist: Wie schwer ist es hier zwei (oder mehr) zu finden?

    Für mich ist ein Hashfunktion genau dann geknackt, wenn sie nicht mehr Einweg ist, denn Einweg zu sein ist genau das, was einen Hashfunktion ausmacht. Eine Hashfunktion soll Daten auf einen Hashwert abbilden, nicht aber einen Hashwert auf Daten. Wenn ich jemanden einen beliebigen Hashwert geben kann und er mir dann irgendwelche Daten präsentieren kann, die beim Hashen genau diesen Wert ergeben, dann ist der Hash unwiderlegbar geknackt. Und das habe ich dieser Form noch nicht einmal bei MD5 gesehen, geschweige denn SHA-1.

    Bei Beispiel wo das z.B. Problemlos möglich ist, ist CRC32 (oder auch CRC16 bzw. CRC64). Wenn man also nur den CRC Wert einer Datei kennt, dann gibt es Tools, die basteln dir sofort 100 weitere Dateien, die den gleichen CRC Wert haben. Noch besser: Diese Tools können eine Datei so erweitern (also Daten dran hängen), dass die am Ende einen bestimmten CRC Wert hat. D.h. den ersten Teil der Datei kann ich selber bestimmen und hier wird es dann gefährlich! Einfach an "echte Daten" Datenmüll hängen, z.B. eine E-Mail hat oben echten Text (unten nur noch Schrott, aber da denkt mancher, die Schuld muss am Mail Client liegen), oder eine Ausführe Datei hat vorne echten Programmcode (hinten nur noch Schrott, aber soweit kommt das Programm bei der Ausführen nie). CRC ist damit unwiderlegbar seit Jahrzehnten geknackt und bietet Null Sicherheit. Dafür war es aber auch nie gedacht, sondern sollte nur Bitfehler in einer digitalen Übertragung erkennen. Es als Dateiprüfsumme zu verwenden war sowieso schon immer Missbrauch.

    /Mecki

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Evangelischer Presseverband für Bayern e.V. (EPV), München
  2. BWI GmbH, München, Meckenheim
  3. Deloitte, verschiedene Standorte
  4. Zentrum für Sonnenenergie- und Wasserstoff-Forschung Baden Württemberg (ZSW), Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. GTA 5 12,49€, GTA Online Cash Card 1,79€)
  2. (aktuell u. a. Dell-Notebook 519€, Dell USB-DVD-Brenner 34,99€)
  3. 88,00€
  4. 107,00€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Radeon RX 5700 (XT) im Test: AMDs günstige Navi-Karten sind auch super
Radeon RX 5700 (XT) im Test
AMDs günstige Navi-Karten sind auch super

Die Radeon RX 5700 (XT) liefern nach einer Preissenkung vor dem Launch eine gute Leistung ab: Wer auf Hardware-Raytracing verzichten kann, erhält zwei empfehlenswerte Navi-Grafikkarten. Bei der Energie-Effizienz hapert es aber trotz moderner 7-nm-Technik immer noch etwas.
Ein Test von Marc Sauter

  1. Navi 14 Radeon RX 5600 (XT) könnte 1.536 Shader haben
  2. Radeon RX 5700 (XT) AMD senkt Navi-Preise noch vor Launch
  3. AMD Freier Navi-Treiber in Mesa eingepflegt

Transport Fever 2 angespielt: Wachstum ist doch nicht alles
Transport Fever 2 angespielt
Wachstum ist doch nicht alles

Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
Von Achim Fehrenbach

  1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
  3. Bright Memory angespielt Brachialer PC-Shooter aus China

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

  1. EU-Kommission: Vodafone kann Unitymedia kaufen
    EU-Kommission
    Vodafone kann Unitymedia kaufen

    Vodafone kommt mit seinen angebotenen milden Zugeständnissen durch. Unitymedia und weitere Liberty-Global-Töchter in Europa dürfen gekauft werden.

  2. Cintiq 22: Wacoms preiswerteres Stift-Display hat mehr Zeichenfläche
    Cintiq 22
    Wacoms preiswerteres Stift-Display hat mehr Zeichenfläche

    Für etwa 1.000 Euro verkauft Wacom sein Cintiq-Stift-Display mit 22-Zoll-Arbeitsfläche. Für das Geld gibt es die bekannte Digitizer-Technik und den Stift. Einige Funktionen sind als optionales Zubehör erhältlich.

  3. Halbleiter: Samsung beginnt mit Massenfertigung von 12-GBit-DRAM
    Halbleiter
    Samsung beginnt mit Massenfertigung von 12-GBit-DRAM

    Der Halbleiterhersteller Samsung hat damit begonnen, 12-GBit-LPDDR5-Bausteine in der Masse zu produzieren. Der neue Speicher ist laut Hersteller rund 30 Prozent schneller als die Vorgängerbausteine.


  1. 15:22

  2. 14:50

  3. 14:25

  4. 13:50

  5. 13:22

  6. 13:00

  7. 12:25

  8. 12:01