 Der nächste Talk handelt über den Drown-Attack. Und das wird Spaß. Hat Sebastian Chinsel der Referent gesagt, er hat sich für IT-Sicherheit interessiert, seit einer langen Zeit. Er hat einen Doktortitel an der FH Münster und erinnert euch vielleicht an seine Talks von 31C3, 28C3 oder sogar 29C3. Heute geht es um den Drown-Attack und wie man TLS angreift mit einem Server der SSL-Version 2 unterstützt. Bitte gibt einen Jubiläums-Applaus für Sebastian Chinsel. Vielen Dank für die Einführung. Es ist großartig, wieder hier zu sein und ich bin sehr froh, dass jetzt niemand geht, denn wir haben hier eine neue Verwundbarkeit von SSL 2. Das ist irgendwie koalte. Aber der Attack hat einen Namen und hat eine Website und sogar ein Logo. Und als ich das gesagt habe, bin ich jetzt sehr froh, dass niemand geht. Auch deswegen, der Talk geht um einen Einbruch in TLS. Und ich denke, werder weniger alle in diesem Raum verwenden, TLS wahrscheinlich sogar jetzt genau in diesem Moment, weil eure Mobiltelefone jetzt auf Twitter nachschauen, was los ist, oder Facebook, also HTTPS benutzen, oder ihr schaut nach euren E-Mails über dem Browser oder über ein E-Mail-Programm. Ja, es ist also wirklich wichtig und der Drown-Attack hat 15 Autoren, die natürlich nicht alle herkommen konnten. Sechs von uns auf dem Bild hier, das ist die größte Anzahl von Menschen, die wir auf einem einsten Bild unterbringen konnten. Und wenn ihr genau hinschaut, ich bin hier sehr froh, dass wir den ersten Pony Award bekommen haben für den besten Krypto-Angriff 2016. Wir sind sehr, sehr froh darüber. Aber wenn wir über SSL Version 2 reden, was ist das eigentlich? SSL Version 2 wurde im Jahr 1995 erstellt und sofort im Jahr 1995 auch gebrochen. Im gleichen Jahr nur nach wenigen Monaten. Wie sah das Internet damals aus in dieser Zeit? Naja, ziemlich genau so wie hier auf diesem Bild. Das ist das Internet der 1990er-Jahre mit einigen kryptografischen, einfachen Dingen wie DS, RC4, RC2. Die meisten davon sind also schon gebrochen und einige wirklich interessante Dinge. Also hier zum Beispiel 40 Bits für Exportstärke. Also eine Kryptografie-Reguritmus der aus politischen Gründen erzeugt wurde. Kryptografische Regulierung in den 1990er-Jahren sagten, dass für Export nur Kryptografie verwendet werden durfte mit einer bestimmten Stärke, mit einer bestimmten Maximalstärke für Export aus den USA heraus. Und das sehen wir hier. Im Jahr 1995 ist die SSL Version 2 sofort gestorben. Und der Grund ist, dass die Ersteller-Netscape hat das veröffentlicht, nicht den Handshake authentifiziert haben. Also ein aktiver Mensch in der Mitte konnte einfach den Handshake abfangen und dann den Server auf beiden Seiten, Server und Kleintag, zwingen, eine sehr, sehr schwache Verschlüsselung zu verwenden. Und das konnte man nicht fixen. Das war ein Protokoll-Problem. Das war also nicht fixbar. Ein Jahr später, 1996, gab es SSL Version 3, was immer noch die Basis auf der Protokoll-Ebene ist für all das TLS, was wir heute sehen und das wir benutzen. Wir können also sagen, SSL Version 2 wurde 1995 veröffentlicht und gebrochen in 1995. Niemand, jeweils wird das noch benutzen, oder? Ich habe einige Daten für euch. Dies ist ein internetweiter Scan des IPv4-Internet im Jahr 2016. Und was ihr hier seht, ist nicht die Anzahl Haus, sondern der Prozentanteil von all den TLS und SSL unterstützenden Systemen auf dem Internet. Und hier seht ihr zum Beispiel, dass 28 Prozent aller Servers, die auf Prots 25 SMTP zuhören, SSL Version 2 verwenden. Was wirklich sehr seltsam ist. Ich komme zu diesem Punkt später noch, was war der Grund? Und sogar für HTTPS, also Port 443, sehen wir immer noch 17 Prozent aller Hosts da draußen, die direkt SSL Version 2 unterstützen, was wirklich seltsam ist, oder? Man könnte also direkt sagen, diese alten Dinosaurier, die kommen alle zurück irgendwie und verfolgen uns User im Internet. Um euch einen Überblick zu geben, worum geht es bei Drown? Drown ist ein ziemlich geschickter, eine Kette von Exploits. Und es wird einige Zeit brauchen, all die Puzzlestücke zu erklären. Also nur ein kurzer Überblick über die Voraussetzungen, die ein Angreifer braucht, um einen Drown Exploit zu fahren. Zunächst mal können wir also eine von 1000 TLS Verbindungen brechen, nicht alle, nur ein Promille. Das heißt also im Wesentlichen, um eine eurer TLS Verbindungen zu brechen, muss der Angreifer im Durchschnitt 1000 Verbindungen von euch einsammeln zuhören können. Es kann Verbindung sein, die vor langer, langer Zeit vor der Bekanntheit von Drown entstanden sind. Es ist ein passiver Angriff. Also einfach auf Rekord zu klicken in eurem Wireshark reicht bereits aus. Und wenn ihr dies nun beim Kongressvortreiter für Jahre gemacht habt, dann könnt ihr die TLS Verbindungen, die ihr damals aufgezeichnet hat, jetzt unter bestimmten Voraussetzungen vielleicht noch brechen. Okay. Das ist nicht kostenlos. Ihr braucht etwa zwei hoch 50 Verschlüsselungen durchführen. Das ist fehl. Das ist machbar, aber wir müssen ziemlich gute Hardware brauchen, ziemlich fette Hardware. Und wir müssen etwa 40.000 Verbindungen zu diesem Server aufbauen, der dieses SSLV2 noch unterstützt. Und ein sehr wichtiger, ein sehr wichtiges Ding ist, Clients unterstützen eigentlich SSLV2 nicht mehr seit langer Zeit. Der letzte Browser, der das uns schützte, war Internet Explorer 6 auf Windows XP. Okay. Also selbst Internet Explorer 6 würde immer SSL Version 3 bevorzugen. Wenn es also Version 3, wenn es möglich war, Version 3 auszuhandeln, würde das immer benutzt werden. Es ist also so, dass wir wirklich TLS brechen wollen. Das, was eure wirklich aktuelle Client benutzt unter der Voraussetzung, dass derselbe Server auch SSL Version 2 unterstützt, was wirklich seltsam ist. Aber wir machen das so. Wir brechen TLS unter Benutzung von SSLV2. Okay. Wir haben einen Exploit gemacht und wir haben auch eine Menge Aufwand verwendet, diesen Angriff zu optimieren. Und das Beste, was wir machen konnten, ist eine einzelne TLS-Verbindung auf Amazon IS2 für 400 Dollar zu brechen. Also wenn jeder von euch vielleicht 50 Cent spendet, das würde bereits ausreichen, um eine einzige TLS-Verbindung zu brechen. Und ich muss nicht viel TLS-Verbindung brechen, nur eine einzige reicht aus, eine, die euer Pop3-Mail-Client vielleicht pro Minute verwendet, um eure E-Mails abzurufen. Und da ist dann euer Passwort drin, im Klartext, wenn das, wenn die Verschlüsselung gebrochen ist. Und wenn wir das haben, dann können wir natürlich alles ermögliche weitere brechen. Also eine einzige Verbindung, die richtige Verbindung, reicht in den meisten Fällen aus. Okay, ich habe gesagt, dass wir viele Puzzlestücke haben, die wir brauchen. Und ich versuche die jetzt mal zu gruppieren in Haufen, um das besser verdaulich zu machen. Das erste, was ich reden werde, ist ein besonderer Angriff, über den ich vor zwei Jahren bereits berichtet habe. Ich werde kurz erklären, wenn ihr euch interessiert dafür in die Details für den Bleichenbacher Angriff, also 98, dann schaut euch meinen Talk beim 31 zu 3 an. Ich werde euch ein neues Protokollproblem in SSL Version 2 zeigen und ich werde erklären, was das mit den 40-Bit Export- kriptografischen Algorithmen zu tun hat. Und wenn wir diese drei Stücke kombinieren, haben wir einen praktischen Angriff gegen SSL Version 2, was nicht wirklich relevant ist, weil niemand eigentlich mehr SSL Version 2 im Internet spricht. Wir müssen aber die Server finden, die das immer noch unterstützen. Wir konnten keinen Klein finden, der immer noch SSL Version 2 aushandelt in der Kommunikation. Eine zweite Sache, die wir brauchen, ist geteilte Schlüsse zwischen verschiedenen SSL- oder TLS-Versionen. Wenn ihr also einen SSL Server aufsetzt und unterstützt SSL Version 2, 3 und TLS 1.0 bis zu 1.2, werden eigentlich immer dieselben RSA-Schlüsselpaare benutzt. Und wenn wir das berücksichtigen, dann wird auf einmal down ein praktikabler Angriff gegen viele TLS-Server. Es ist machbar, in einem akademischen Sinne praktikabel, immer noch teuer, aber durchführbar. Wir können uns das leisten, wenn wir zum Beispiel das Geld zusammenlegen. Und wenn wir jetzt zwei, wir haben zwei Implementierungsfehler, außerdem in OpenSSL, wenn wir also all das verbinden, dann können wir eigentlich alle SSL Version 2 Implementierungen brechen, die es dort gibt. Und hier schauen wir uns jetzt zwei Implementationsfehler in OpenSSL an. Und wenn wir das kombinieren mit dem bereits vorhandenen Drown Attack, haben wir auf einmal einen trivialen Angriff. Das heißt, es braucht dann vielleicht ein paar Minuten auf einem Lacktop-Geben sehr viele TLS-Server. Okay, also fangen wir an mit Bleichenbachers Angriff von 1998. Bevor ich mit dem anfange, möchte ich nur schnell wiederholen, was der RSA-Schlüsselaustausch für TLS ist, wie der aussieht. Es gibt verschiedene Wege, die Schlüssel auszuhandeln. Wenn ich sage Schlüssel, dann meine ich den symmetrischen Schlüssel für die Session. Also als symmetrische Verschlüsselung mit RSA, zum Beispiel, ist sehr teuer. Deswegen machen wir einen Schlüsselaustausch für einen symmetrischen Schlüssel über RSA. Das ist also nicht sehr viel, nicht sehr viel Daten. Und dann die eigentliche, der Inhaltsverschlüsselung für das, was man wirklich austauscht oder die SSL oder TLS-Verbindung, wird dann AIS oder Triple Des oder AC4 oder irgendwas für den Inhalt benutzen, eine symmetrische Verschlüsselung. Und was wir uns jetzt anschauen, ist also nur diese Aushandlung des Schlüssels für die symmetrische Verschlüsselung. Wir haben also ein TLS-Client und ein TLS-Server. Der TLS-Client fängt immer mit einem Client Hello an und darin halten ist eine Zufallszahl des Clients. Das ändert sich mit jedem Request. Der Client ändert diese Zahl mit jedem Request. Und dies wird im Klartext versendet, so der Angreifer kennt diesen Schlüssel. In der Antwort des TLS-Servers ist dann das Server Hello. Dort drin enthalten ist auch eine vom Server generierte Zufallszahl und auch diese ändert sich mit jeder neuen Verbindung. Und auch die wird im Klartext ausgetauscht. Also beide Seiten sind einem Angreifer bekannt. Und außerdem wird dann dieses Zertifikat übersendet, was man zum Beispiel von Commodo oder der anderen Zertifizierungsstelle kauft. Also das kann man vielleicht auch mit Last Encrypt kostenlos bekommen. Und in diesem Zertifikat ist ein öffentlicher RSA-Schlüssel enthalten. Und dieser öffentliche Schlüssel wird mit dem Zertifikat also gesendet. Und mit der nächsten Nachricht, mit dem kleinen Key Exchange, wird der TLS-Client etwas erzeugen, was ein Primast, was sich Primast the Secret nennt. Und dies ist der einzige Teil, der wirklich völlig geheim ist in den ganzen Austausch. Dies wird also nicht im Klartext gesendet, sondern verschlüsselt über RSA mit dem Schlüssel des Zertifikats, das gerade vom Server empfangen wurde. Und das wird dann wieder gesendet. Im nächsten Schritt, und dies ist ein sehr wichtiger Schritt, wird der TLS-Server, den das Primast the Secret entschlüsselt, das er gerade empfangen hat. Und davon leitet er, leiten sowohl Klein als auch Server denselben symmetrischen Schlüssel ab, okay? Also das heißt, der Angreifer kennt die Zufallszahl des Kleins und die des Servers und er sieht eine verschlüsselte Version des Primast the Secret. Und wenn der Angreifer dies entschlüsseln kann, dies Primast the Secret, dann kennt er das Master Secret, also den symmetrischen Schlüssel, der für die Inhaltsverschlüsselung verwendet wird. Mit welchem Algorithmus auch immer. Das ist also der heilige Graal, den wir brechen wollen. Der brechenbacher Angriff in 1998 erreicht genau das. Das ist wichtig. Was ich außerdem erwähnen muss, ist, diese Entschlüsselung kann fehlschlagen. Wenn der Angreifer, sagen wir mal, einen beliebigen Cyphertext, irgendwelche Junkdaten sendet, muss der Server dies zunächst entschlüsseln, diesen Cyphertext, um herauszufinden, ob dies ein gültiges Primast the Secret ist oder nicht. Um das zu machen, wir brauchen ein Oracle. Das ist ein cryptographischer Word. Das bedeutet ein Service, das bekommt ein beliebiger Cyphertext. Davon geht nur zurück mit ein 1 oder 0. Das hängt an, ob etwas gut verschlüsselt war oder nicht. Wenn diese erste Verbindung sieht valide aus, dann wäre das entweder mit 1 oder 0 oder mit 1 oder 0 zurück schicken. Wir haben einen Client und Server und einen Angreifer, das in der Mitte zuhört. Dann vielleicht verändert einige Parameter in dieser Verbindung. Dann können diese Oracles etwas unverschlüsseln und davon wissen, ob es etwas gut gemacht war oder nicht. Jedes Mal, dass ein Oracle mit einem 1 zurückkommt, weiß dieser Angreifer, dass etwas gut unverschlüsselt war. Wenn ein Angreifer das macht, so für 1.000 Mal gemacht, kann ein Angreifer der wahre, versicherte Verschreibung verstehen. In dem Original Bleichenbacher Papier hatte er das normale TLS-Error-Message. Es gab eine Fehler-Nachricht, dass das ganz klar zurückkommt. Die haben nicht versucht, diese TLS-Standard zu verbessern. Wir machen als eine falsche Idee, dass ein unversichertes PMS, wenn wir es mit dem Flow weitermachen, gibt es später Fehler. Es gibt verschiedene Schlüssel und die Entschlüsselung, Also aus wie hier, das Server wird das Primaster Secret entschlüsseln und immer ein zufälliges Primaster Secret erzeugen. Und abhängig davon, ob die Entschlüsselung erfolgreich war oder nicht, wird Folgendes passieren. Im Erfolgsfall wird das Primaster Secret entschlüsselt und falls das Fehl schlägt, wird ein neuen Zufalls Primaster Secret fortgefahren und das bedeutet, dass all die Implementierungen, die wir angeschaut haben, sind in diesem Punkt gleich. Dadurch wird es im AfD ja so eine Implementierungsverbesserung eingebaut worden, es ist da nicht zu unterscheiden von außen, ob das Fehl geschlagen ist oder nicht und wir haben jetzt einen neuen gleicherbacher Angriff entwickelt. Schauen wir uns also mal SSL Version 2 an, das Protokoll. Es ist ein wenig unterschiedlich zur Version 3, aber das ist jetzt nicht so wichtig. Wir haben also auch ein Kleinhello und ein Serverhello und wir haben auch diesen kleinen Key-Austausch nur mit einem anderen Namen, in dem wir diesen symmetrischen Schlüssel, der beim Kleinhello erzeugt wird, senden und dann würden beide ihre symmetrischen Schlüssel erzeugen und was hier interessant ist, ist, der erste, der mit einer verschlüsselten Nachricht antwortet ist der Server und das hat sehr wichtige Schlussfolgerungen, Erfolgerungen folgen, wenn der Klein, das Server Verify ist also ein Hörflüsse-Nachricht mit einem Schlüssel, dem Master Key, den beide Seiten jetzt wissen sollten und der Klein erhält diese Nachricht, ohne beweisen zu können, dass er denselben symmetrischen Schlüssel hat. In SSL Version 3 und TLS ist das anders, diese Nachricht wird nur gesendet, nachdem der Klein benutzt hat durch eine fertige Nachricht, dass er denselben Schlüssel besitzt. Wir bekommen jetzt aber eben einen Ciphertext, der mit einem unbekannten Schlüssel verschlüsselt ist, denn wir kennen den Schlüssel eigentlich noch nicht und die Frage jetzt, bitte akzeptiert das, dies ist eine wichtige Frage ist, die wir aufwerfen müssen und ich werde das in den nächsten paar Folien erzählen. Können wir diesen Schlüssel kennenlernen? Wir bekommen diesen Ciphertext. Können wir den Schlüssel kennenlernen, der mit der Verschlüsselung dieser Nachricht verwendet würde und wenn wir uns die Spezifizierung von SSL Version 2 anschauen, dann sehen wir, dass es sogenannte Export-Krypto-Algorithmen gibt, die nur 40 Bit stark sind. Dies ist also wie eine Cipher Suite vom Namen aussieht, also die Namen haben ein solches Format, sagt und es gibt eine symmetrische Verschlüsselung, ein Algorithmus hier RC2, es werden 128 Bit Schlüssellängen verwendet, es wird CVC als Verschlüsselungsmodus benutzt und es wird Export 40 mit MD5 als Hash Algorithmus verwendet. Wir haben also 128 Bit Schlüssel, aber nur 40 Bit von diesen 128 Bit sind wirklich für die Verschlüsselung. Ich habe gesagt, der Klein erzeugt den Schlüssel und verschlüsselt das mit dem öffentlichen Schlüssel des Servers und sendet das und hier ist es so, dass also nicht 128 Bit voll verschlüsselt sind, sondern nur 40. Und diese 40 werden verschlüsselt und 68 werden im Klartext versendet und können von allen gesehen werden. In den 90er Jahren hat die Clinton-Administration diese Regel aufgestellt und gesagt, okay, also 40 Bit sind genug, um Leute mit Online-Banking oder so zu schützen, aber offensichtlich wollte die US-Regierung in SSL Verbindungen hineinschlüffeln, was auch von den Ländern, allen Ländern, die so was verwenden. Wenn wir uns zur Implementierung anschauen, dann wurde der Master Schlüssel auf eine Weise gebaut, dass die Klartext-Bits angehängt wurden an die verschlüsselten Geheimen 40 Bit. Und für Nicht-Export-Crypto-Agorithmen hat man dieselben Cypher ohne diese Export-40 Markierung. Das ist also, dann ist es so, dass die Länge der Bits, die Anzahl der Bits, die unverschlüsselt sind, werden einfach Nullist. Also vielleicht nicht so die allerklarste Art, das zu tun auf der computerwissenschaftlichen Sicht, aber es ging so in den 90er Jahren. Okay, schauen wir uns nun dieses Server Verify an. Dieser eine Nachricht, die wir bekommen und in der wir wissen wollen, was der Schlüssel ist. Wenn wir uns die Spezifizierung anschauen, sehen wir, dass das Server Verify nichts anderes ist als dass die Zufallstelle des Klein, die gerade empfangen worden ist. Wir kennen deswegen den Klartext dieser Nachricht und das wurde dann mit dem Master Key verstößt. Wir kennen also den Plain Text und wir kennen den Cypher Text und wir möchten außerdem, wir wissen auch, wenn das mit 40 Bit Export Cypher ausgranelt wurde und das können wir erzwingen, dann sind nur 40 dieser Master Key-Bits wirklich geheim. Und das heißt, wir können jetzt einen Brut-Force Angriff, eine Brut-Force Suche machen. Wir haben den Plain Text, wir haben Cypher Text und wir können den Schlüssel suchen und brauchen dafür nur 240 Möglichkeiten, die wir durchprobieren müssen. Und das dauert auf fette Hardware ein paar Sekunden oder vielleicht Minuten. Aber wir könnten das in einem Tag auch auf meinem Laptop machen. Das ist also nichts wirklich kritisch schwieriges. Okay, lasst mich nun sagen, warum das wichtig ist und warum das ein neues Bleichenbacher Oracle ist. Nehmen wir an, dass wir einen neuen Geheimtext, ein neues Verschlüssel des Primaster Secret erzeugen und 40 Bit geheim halten und das senden. Und das tun wir zweimal mit dem gleichen Cypher Text. Dann haben wir zwei Server Verify Nachrichten. Wenn wir nun den Schlüssel berechnen, den der Server verwendet für das Server Verify, falls das Primaster Secret nun korrekt war, können wir diesen Part hier gehen und fangen dann weiter mit dem entschlüsselten PMS. Das Primaster Secret ist gleich, da ist auch das Master Secret gleich und dann haben wir denselben Master Key. Falls das Primaster Secret ungültig war, folgen wir diesem Fahrt. Und das bedeutet, dass der Master Key für beide Server Verify Nachrichten verschieden sein wird, weil der Server ein neues Primaster Secret generiert für jeden neuen Versuch, der reinkommt. Und das können wir unterscheiden als Angreifer. Und dies ist dann ein neues Bleichenbacher Oracle mit dem einzigen Bedingung, dass wir, wenn wir keine Fehlermeldung vom Server kriegen, alles ist korrekt verschlüsselt, wie in dem Standard Dokument im RFC. Das Problem ist aber, wenn wir den gleichen Text senden mit dem Server Verify, wird der Server für das Server Verify den selben Schlüssel zweimal verwenden und dann wissen wir, dass es ungültig war. So, wenn wir das gemacht haben und es wäre eine viel große Gruppe, dass dieser Angreif gefunden hat, dann haben wir eine praktische Angreif für SSL 2. Version. Man muss vorstellen, dass viele akademische Leute ganz froh, das gefunden zu haben, so in Ivory Tower gefunden, aber es ist gar nicht, für gar nicht relevant. So müssen wir ein bisschen weiter suchen. Was kann man dann, das ist ein cooles akademische Angreif, aber wie ist das im Internet relevant? So, wir müssen jetzt besser verstehen, wie man echt SSL und TLS benutzt, wie es es konfiguriert. Wenn man ein Server baut mit Apache oder Engines oder sowas, es gibt keinen Weg zu sagen, wenn ein Klient eine Verbindung macht mit TLS 1.2 und dann noch eine Verbindung mit SSL Version 3 bekommt, bekommt man zwei verschiedene Keys. Jetzt, wenn man ein Server baut oder ein System baut, ist es immer die gleichen privacy und öffentlich Key Schlüssel gibt. Was ist auch sehr wichtig, das ist sehr interessant. Eine Valid Frage ist, wer Leute die gleichen TLS-Zertifikat für verschiedene Protokollen benutzen? Zum Beispiel, wenn jemand ein Zertifikat vom Last & Crib kauft und dann mal es benutzt für SMTP, IMAP, POP3 und alle die andere verschiedene Protokollen, normalerweise machen Leute das. Und das ist jetzt problematisch, weil jeder schaut HTTPS an, aber Leute schauen die TLS-Konfiguration für die andere Protokollen, SMTP, IMAP, POP3 und sowas. Und dann geht man in die Richtung von Bleichenbach Tag und es geht gegen RSA Cypher Text. Und es hängt nicht an welchen TLS Version benutzt, es geht für alle Typen von TLS Versionen. So, wenn man zehn verschiedene Systeme hat und alle die gleichen Zertifikat haben und nur eine von diesen Systemen kann man von Drown angegriffen werden, dann sind alle zehn Systemen vielleicht auch angriffbar von Drown. So, zum Beispiel, es ist klar und wenn es in Server gibt, dass TLS SSL erlaubt, dann kann man einen Angreifer, kann man auf diese TLS Verbindung analysieren und dann kann man dieses System als Bleichenbacher Oracle benutzen, um diese Schlüssel zu verbrechen. So, wenn man System SSL Version 2 erlaubt ist, kann man auch die anderen Versionen verbrechen. So was hier neu ist, wenn man zwei Systeme hat und dann die beiden die gleichen Schlüssel oder die gleichen Schlüssel aber vielleicht verschiedene Zertifikat benutzen. Zum Beispiel mit Heartbleed haben wir bemerkt, dass Heartbleed angreift wird diese Keys und Komprimieren. Mit Heartbleed-Angriff könnte man diese Privatschlüssel lernen. So, dann muss man eine neue Zertifikat kaufen und was viele Leute gemacht haben. Dann haben Leute eine neue Zertifikat gekauft, aber mit die gleichen RSA für Schlüssel und das ist gar keine Idee. So, es ist auch möglich, dass die zwei benutzen die verschiedenen Zertifikat, aber benutzen immer noch die gleichen RSA-Schlüssel. In diesem Fall sagen wir als Beispiel, vielleicht ist diese zweite Server nicht zum Drown reichbar oder angriffbar, zum Beispiel dann kann man auf diese erste Verbindung zu dieser unangreifbar Server schauen und dann zu einer zweiten greifbarer Server diese gleichbar angreif machen. So, wenn wir durch diese Internet schaut. So, wenn wir benutzen die gleichen RSA-Schlüssel Paar von verschiedenen Ports und es gibt eine zustandzielle Nummer von Schlüsselpaar, die so gleich sind. Hier ist man nicht so, diese erste für diese Column von Port 25 SMTP. Wo hat man diese Zertifikat auf einer anderen Port gefunden? So sicher, so für alle Systeme, die SMTP hat, haben wir auch gefunden, dass 30 Prozent haben diese gleichen Zertifikat am Portrier und 31 oder 29 haben einem ab. Und was interessant ist, ist, dass Leute diese gleichen Schlüsselpaar über gleichen Protokoll benutzen. Zum Beispiel mit HTTPS. Für viele Servers auf HTTPS haben wir bemerkt, dass sie viele Servers angreifbar sind. Man schaut auf die Konfiguration von HTTPS, aber man schaut auf die Konfiguration von SMTP nicht so viel. Für SMTP, wenn man nicht eine TLS-Verbindung bauen kann, es wird sehr schnell zurück zum plaintext zurückgehen. So für SMTP bessere, schlechter Verschlusslung ist besser als plaintext. Aber das bedeutet, dass wenn man, wenn man eine Schwachheit in SMTP findet, kann man auch etwas auf 4v3 HTTPS verbrechen. So das bedeutet, dass ungefähr zweimal zu viele Systeme sind. Jetzt sind die möglich, die sind angreifbar zu drown. Und wenn diese Angriffe weitermachen, sogar wenn es ein System, das HTTPS nicht zum Drown angreifbar ist, aber wenn wir eine andere Report anschauen, können wir sehen, dass diese andere Report auch angreifbar ist. So das bedeutet, dass 50 Prozent von SMTP-Servers von Drown angreifbar sind. Für Port 4v3, das bedeutet ungefähr ein Drittel von allen Systemen sind angreifbar, weil irgendwo die gleichen Schlüsselpaar ist auf einer anderen Port benutzt. Es ist wirklich substanziell, wie viel dieser Angreif erweitert ist bei dieser Fehler. Und so, wir wissen, dass Drown immer noch ziemlich schwierig ist. Es ist nicht eine einfache Angriffe. So wie können wir es mehr effizient machen? Wir müssen 2 zum 40. Stärkeit. Wir müssen ungefähr 1.000 Oracle Verbindungen machen. Wir haben einige Coach-Schnitten von OpenSL gemacht. Dann haben wir eine Implantation von MD2 und RC4 an OpenSL gemacht. Das bedeutet, dass für einen Vollangreif, das ist ungefähr 50 Tage, dann haben wir Leute von HashCat gefragt. Das war eine von HashCat-Team. Es ist auch eine Mitschreiber von Drown. Wie kann du uns helfen, weil es ist wirklich ähnlich zu, wie wenn man ein Kennwort sucht. Es ist wirklich ähnlich zu Kennwort-Kracken. So dass er über Nacht etwas 30 Mal so schnell gemacht, wenn wir diese optimale HashCat benutzt haben. Und das war unglaublich schön. Dann haben wir es zum Amazon EC2 gemacht und für nur 440 $ könnte man das in 8 Stunden machen. Das ist eine substantielle Verweiterung von dieser Angriffe. Jetzt haben wir einen praterer Angriff für viele SSL Servers. Das ist die Drown-Angriffe, das geht gegen jede SSL Version 2. Jetzt haben wir noch zwei weitere Fehler in OpenSL, dass Drown wirklich verbessert. Zuerst haben wir etwas mit dieser Cipher Suite. Wenn man SSL oder TLS-Konfiguration hat, wir haben immer eine Protokoll-Version und eine Cipher Suite. Und mit jeder neuen Protokoll-Version gibt es einen Haufen neuen Cipher Suites, die herausgekommen sind. Und was nun viele Leute machen, ist die Konfigurieren ihres Cipher Suites. Sie sagen, wir nehmen nur doch die sicheren Cipher Suites für der Krypto-Argument und nehmen also Dinge heraus wie SSL Version 2, um den Pudelattack zu verhindern. Aber SSL Version 2 wird aber jetzt nicht explizit deaktiviert. SSL Version 2 deaktiviert aber nicht alle Cipher Suites, also Krypto-Argumenten werden auch explizit ausgeschlossen. So sollte Drown nicht funktionieren. Also wie macht nun SSL Version 2 das Aushandeln der Cipher Suite, das Algorithmus? So funktioniert es im Klein, gibt es das Hello? Der Klein fragt, hey Server, möchtest du mich gleich mit Export Krypto-Argument unterhalten? Und die Antwort in SSL Version 2 würde den Leuten, nein, tut mir leid, ich mache keine Export Krypto-Argumenten. Und der Klein würde dann sagen, SSL Version 2, oh schade, okay, tschau, klangts zum nächsten Mal oder man versucht eine andere, eine Protokoll-Version, eine andere. Und dies hier ist der relevante Code, der benutzt wird, danach, nach dem Handshake, den ich euch gerade gezeigt habe. Nehmen wir also an, der Klein sagt, nicht tschau, tut mir leid, zu schade, dass wir nicht mit Export Krypto zu Algorithmen reden können. Wenn der Klein aber stattdessen sagt, okay, ich werde auch nicht Export verwenden, schauen wir mal, was dann der Code macht. Also hier empfangen wir die Daten aus dem Netzwerk. Dies ist also die Nachricht, die das verschlüsselte Primus Resecuit enthält und außerdem den Krypto Algorithmus, den der Klein gerade ausgewählt hat für die Aushandlung und dann bekommt man also die Cypher Suite über den String, der hereinkam, also über den K, das Zeichen, jede Suite hat ein Zeichen, gibt so ein Byte, das einen bestimmten Krypto-Ageritmus angibt und dadurch bekommt man einen Point dazu, den jeweiligen Crypto-Code und wenn das nicht erfolgreich war, was bedeutet, dass der Krypto-Ageritmus, dass ein Krypto-Ageritmus ausgehandelt werden soll, der nicht im Code einkompiliert ist. Wenn er einkompiliert ist, wird er benutzt. Aber wer sieht nun den Teil, der wirklich die Konfiguration überprüft? Er ist nicht da, also wir haben ihn nicht gefunden. Und was also wirklich passiert ist, eine Nicht-Standard SSL-Version, zwei Implementierungen, die sich nicht an den Standard hält, kann also erzwingen, dass ein Krypto-Ageritmus verwendet wird. Also können dann sagen, okay, wir verwenden trotzdem Export 40 Algorithmus und das wird dann auch funktionieren, das wird dann passieren. Die Geschichte dahinter ist also die folgende Nimrod hat das getan, hat SCAPI, eine sehr schlechte SCAPI Implementierung verwendet, Implementierung eines Scanners, um zu schauen, wie viele Systeme im Internet SSL-Version 2 unterstützen. Ich habe den ersten Scan ausgeführt und ich fand diese unglaubliche Anzahl von Servern die SSL-Version 2 unterstützen. Dann nahm ich einen anderen Scanner, der auch nach SSL-Version zu suchte und der sagt uns dann ganz oft, nein, wird nicht unterstützt und dann habe ich Debakt und Debakt und was Nimrod ist einfach zu faul und diese Nachricht zu passen. Also Nimrod hat dann gesagt, ah, du magst nicht gern Export 40, egal, ich rede trotzdem Export 40 und es war immer so egal, was der Server ausfällt und das war also der Unterschied, warum dieses Scanner so viel mehr fand und da hatten wir einfach Glück, dass wir diese Implementierung verwendet haben, diese Scanner Implementierung. Wenn wir diesen Fehler in der Scanner Implementierung nicht gehabt hätten, hätten wir vielleicht gar nicht diesen Buck in OpenSSL bemerkt. Also unabhängig von eurer Konfiguration, in eurer Krypto-Algorithmen Konfiguration. Diesen Buck gegen OpenSSL zu verwenden bedeutet, dass ihr alles Mögliche aushandeln könnt über OpenSSL, was ihr wollt, mit einer Implementierung, die sich halt nicht genau an die Standards hält, mit einem Kleinen, der sich nicht genau an die Standard hält. Das heißt, dieser Server ist dann angreifbar mit Drown und das ist cool. Das zweite Ding ist ein spezielles Drown, das ist es wirklich sehr speziell. Das ist ja auch ein Fehler in der Implementierung, nicht in der Implementierung, ein Fehler. Verwenden wir also wieder diese Export 40 Cyphersuite, RC228 Bit Schlüsseln, aber wir übertragen alle Wiss auf 40 Bits im Klartext, das habe ich schon erklärt, das heißt, nur 40 Bits sind effektiv die Verschlüsselung. Und es ist nun durch eine Implementierungstheorie erlaubt, dass diese Klartext Bits benutzt werden können, auch in Kombination mit Nicht-Export-Krypto-Algorithmen, mit stärkeren Algorithmen. Also ein Kleint, der sich an den Standard hält, würde jetzt für einen Nicht-Export-Krypto-Algorithmus alle 16 Bits oder 128 Bits verwenden und die würden alle mit dem geheimen Teil des Schlüsseln, den wir gerade aus dem verschlüsselten Primaster Secret Enorm haben verwenden, wenn wir aber vier Klartext Bits senden. Zusammen mit einem 16-Bit Primaster Secret, das verschlüsselt war, wird dies immer noch vorne angehängt an das verschlüsselte Primaster Secret und das heißt, dass das Schlüssel 15 oder 13 bis 16 einfach wegfallen. Wenn wir also jetzt 15 Klartext Bits senden, dann auf einmal haben wir ein Server Verify, das verschlüsselt wurde mit einem 128-Bits Schlüssel, bei dem wir alle bis auf ein Bid kennen und damit können wir eine Brutforce Suche im Durchschnitt 128 Verschlüsselungsversuchen. Und wenn wir das nun schrittweise tun, wir schicken 15 0 Bits im Klartext, dann haben wir ein Bid, dann lernen wir Bid 1 des Schlüsseln, dann im nächsten Schritt senden wir 14 0 Bits. Wir empfangen bereits das bekannte Bid 1 in Nummer 15 und das nächste Bid können wir dann herausfinden mit Brutforce und das können wir dann schrittweise tun. Wenn wir also in diesem Fall, dass wir 0 0 Bits senden und bereits die ersten 15 Bits kennen, dann müssen wir eben nur für das letzte Bid wieder nur eben durch 128 Verschlüsselungsversuche für Brutforce ausführen. Das ist also dieses Special Down, also eine spezielle Version dieses Angriffs. Das generische Down hat immer noch die Komplexität 2,40 pro Oracle Request und wir müssen sowas für 1.000 Oracle Request durchführen. Das ist also relativ viel, aber mit dieser 240 Komplexität, diese 240 Komplexität verringert sich jetzt auf 15 Probeverbindungen und in jedem Schritt brauchen wir 128 Angriffe. Das sind also insgesamt 1920 Verschlüsselungsversuche und das kriegen wir in wenigen Minuten auf einem normalen Laptop hin und das ist also wirklich ein neuer Schritt. Was hier interessant ist, ist, dieser Bug wurde gefixt bei den Entwicklern von OpenSSL, ohne zu wissen, dass dieser Bug vorhanden war. Es wurde also ein Bug-Report eingereicht, der überhaupt nichts mit Down zu tun hatte. Das war vor eineinhalb Jahren, da war Down noch gar nicht bekannt und OpenSSL hat einen Patch veröffentlicht und dieser Bug wurde gepatched, ohne den Bug erkannt zu haben. Also nicht wirklich ein geheimlicher Fix, sondern ein Fix, in dem niemand gesehen hatte, was eigentlich los war. Und später fanden wir aber heraus, dass es eben ein sehr wesentliches Problem war und warum erkläre ich das? Wir können jetzt gerne wieder das Internet danach scannen und suchen, wer hat ihre seine OpenSSL-Implementierung nicht gepatched, obwohl der Patch eineinhalb Jahre alt ist. Und dies ist also die Anzahl der Internet-Houst der Server, die eine Art, irgendeine Verschlüsselung verwenden mit OpenSSL, mit einer Version von OpenSSL, die über als eineinhalb Jahre alt ist. Die Leute patchen also nicht wirklich. Wenn man das vergleicht mit der Anzahl des Servers, die für Down angreifbar sind, dann wird ihr sehen, dass die meisten eben dieses OpenSSL-Problem haben. Die Anzahl ist sehr ähnlich. Okay. Also fast mit zusammen. Einsatz, den ich nur sagen muss, uralte SSL Version 2 bricht immer noch heutiges TLS und wir machen nichts anderes, müssen nichts anderes tun, außer SSL Version 2 zu deaktivieren und dann ist das für immer erledigt. Also wen müssen wir jetzt hier, wie müssen wir die Schuld geben für Down? Wer hat den Fehler gemacht? Also zunächst mal sehr offensichtlich. Wir haben einen Fehler im Krypto-Design aus den 90er Jahren. Das ist also nicht so überraschend. Etwa vor 20 Jahren passiert natürlich viele Dinge seitdem. Dann haben wir einige Fehler in einer Krypto- Inventierung aus den 90er Jahren, die OpenSS-Leute würden sagen, okay, ich habe mir niemals irgendeinen SSL Version 2 Code angeschaut. Also das ist eine uralte Implementierung. Was ein größeres Problem ist, sind die Probleme in der Krypto-Konfiguration. Weil Leute also ihre Server konfiguriert haben auf eine sehr schlechte Art und Weise. Und was auch sehr interessant ist, die Export 40 Krypto-Algorithmen sind ein wesentlicher Teil von Drown. Drown wäre kein praktikabler Angriff, wenn wir nicht durch die Politik, durch die Clinton-Administration, die Tatsaraten, dass eine Regulierung aufgezwungen wurde, nämlich dass eben Export-Kryptografien nur 40 Bit stark sein darf. Okay, was sind nun die Möglichkeiten, dies abzumildern für Administratoren? Die aktiviert SSL Version 2 und wo ihr gerade dabei seid, die aktiviert auch gleich SSL Version 3. SSL ist unsicher, verwendet es nicht mehr. Aktualisiert euer OpenSSL regelmäßig. Das ist etwas, was ihr für jede Library tun solltest. Jede Library, die irgendwie was mit ihr durch die Security zu tun hat. Das ist also etwas, was die Admins tun können. Was Bürgerinnen und Bürger tun können, ist stimmt ab gegen Hintertüren in Kryptografie. Vielen Dank. Vielen Dank, Sebastian. Haben wir Fragen aus dem Publikum? Okay, wir haben eine Frage, glaube ich, wir fragen mal mit dem Mikrofon 3 an. Es gibt zwei Fragen. Erste, wie spezifisch ist das für RSA? Wird es auch für Diffy-Helven-Besirte-Füssigungen? Und nachher blieb, haben viele Leute durch OpenSSL geschaut und auch Volks gebaut. Hat diese Sinn-Sachen mit OpenSSL verbessert? Ja, die erste Frage war also, ist das nur bei RSA vorhanden, das Problem? Ja, wir können den Server hier nun, die Rolle des Servers einem wirklich guter Hardware können, den Server nachspielen, schwer zu erklären ohne Folien dafür. Also schaut euch das, schaut ihr den Aufsatz an. Wir können Diffy-Helmen brechen, aber das ist kein Offline-Angriff mehr, da brauchen wir einen aktiven Angreifer in der Mitte. Das war die erste Frage. Und das ist dann beschränkt auf RSA, ja. Also Diffy-Helmen können wir so nicht angreifen. Die zweite Frage ist, ist OpenSSL oder andere Implementierungen verbessert? Also dieser Bug ist nicht in einer Code-Überprüfung vorgefunden worden, wahrscheinlich, weil die Leute sich gar nicht mehr um SSL Version 2 gekümmert haben. Das ist ja sowieso völlig kaputt. Also das war eigentlich eine gute Code-Überprüfung. Okay, danke. Haben wir Fragen aus dem Internet? Nein, die Mikrofone eins, bitte. Ein Nachricht, wenn man sagt, dass man OpenSSL ein Update machen muss, man kann nicht nur ein Update machen, aber man muss auch alle die Prozesse weiterbauen. Und weil alle die rennende Prozesse sind, sind immer mit die andere Prozesse verbunden. Ja, und so macht euch natürlich eure tolle Abtime von 1000 Tagen kaputt, ja. Aber muss sein. Das ist die Faktor von 1000, das zu 4.16. Wovon kommt das? Das kommt vom Algorithmus in Breichenbacher. Als der Algorithmus von Breichenbacher 98 publiziert wurde, hieß es der Million-Vereinfragen-Angriff, weil man musste inbüchern eine Million Nachrichten verschicken zwischen Kind und Server, um eine Entschlüsselung des Ciphertexts hinzukriegen. Das hat sich nun dramatisch geändert in den Jahren seitdem. Es gibt viele Paper, die hier Verbesserungen des Angriffs hobiziert haben, und nun sind es 1000, ungefähr. Das hängt von der Größe ab, vom Primaster Secret, aber im Durchschnitt 1000 Verbindungen sind nötig. Okay? Eine parenotische Frage. Wenn man das für ein Library benutzt und wenn man sagt Disabled Protocols, bedeutet das, dass man ein Funktion-Kohl macht. No SSL Funktion. Warum schaut man das nicht daran? Wie sind wir sicher, dass wir geschützt sein werden, wenn wir sagen No SSL V2, wenn ich eine Verbindung oder ein Library baue? Also OpenSSL hat diesen Code gelöscht, nachdem wir das Ihnen gesagt haben. Also aktuell ist einfach OpenSSL und dann ist das weg und nicht mehr im Repo. Und startet euren Server neu. Oder zumindest den Serviceprozess. Microphone V, V in the back please. Dankeschön. Ich würde gerne fragen, haben Sie auf andere Kryptolibräer anders das OpenSSL geschaut? Ja, also die meisten modernen Kryptolibräes mit modernen, meine ich, solche, die in den letzten paar Jahren herausgekommen sind, die implementieren einfach SSL V2 gar nicht mehr. Libre SSL zum Beispiel haben den Code einfach gelöscht. Die andere auch, also die Python-Libräes zum Beispiel haben das nicht mehr implementiert und so weiter. Aber all diejenigen, die wir angeschaut haben, zum Beispiel der Code in IS im S-Channel drin ist, der unterstützt immer noch SSL V2 und hat denselben Protokollfehler. Also wenn ihr SSL V2 unterstützt, seid ihr verwundbar, unabhängig von eurer Implementierung, egal was eure Implementierung ist, jedenfalls soweit wir das gesehen haben. Warum die Name Drown? Ja, warum ertrinken? Drown, eine gute Frage. Also Nimrod hat diese Ursprungsidee gehabt und das ist sein Lieblingsfilm, spielt ja eine Rolle, dann haben wir einen Backgroundim ausgeführt, dass ich es gar nicht mehr im Kopf habe. Es steht im Papier, sorry. Ich weiß nicht mal mehr, wie das Backgroundim heißt. Das ist ein Arbeitstitel gewesen und der hat sich dann fortgesetzt. Und natürlich mehr Informationen im Fahrplan. Okay, weitere Fragen? Okay, in dem Fall habe ich eine Frage. Normalerweise sagt man, welche Politiker wollte, wir sind zwei Sicherheit abschwächen. Auf der Bühne hört man sie nicht so gut. Also eine allgemeinere Frage. Wir haben die Politiker, die versuchen die Sicherheitsabzuschwächen. Wer war das noch gleich? Das war die Clinton-Administration. Also alle Politikerinnen und Politiker wollen das im Wesentlichen Terrorismus und so, ja, weil wir alle so schlimme Leute sind. Also wenn wir das jetzt machen, wenn wir jetzt Kryptoregulierungen haben in neuen Projekten, dann sollten wir versuchen, dass in fünf bis zehn Jahren mit neuen Kryptodoktoranden, die das dann hoffentlich angreifen. Das ist vielleicht eine gute Folge davon, aber generell ist es keine gute Idee. Andere Fragen in der Tischenzeit? Ist das eine Frage? Nein, setz dich noch hin. Ah, hier ist eine Frage. Hi. Du hast gesagt, für ein Mail-Server ist immer noch keine gute Erinnerung, dass man all die Krypto erlauben. Da habe ich das nicht verstanden? Also es gibt ein Argument dafür, SSL Version 3 zu unterstützen, obwohl es gebrochen ist. Es ist gebrochen in einer Weise. Na ja, der Pudelangriff ist verbraucht, offensichtlich mehr Aufwand, um Version 3 zu brechen, als den plaintext zu lesen. Mit dem Drown-Angriff ist es eine andere Sache, denn selbst wenn man sichere TLS-Verbindungen verwendet, kann man die immer noch brechen, indem man SSL Version 2 für den Angriff verwendet. Also das nennt sich opportunistische Verschlüsselung. Irgendwelche schlechte Verschlüsselung ist immer noch besser als keine Verschlüsselung. Dieses Motto ändert sich durch Drown, weil hier etwas ist, was sich über Protokoll-Grenzen hinweg auswirkt. Kompromiert das nicht diese RSA-Privatenschüsselung? Man muss keine neuen Schlüssel kaufen, also RSA-Schlüssel. Man sollte einfach nur Version 2 aus der Konfiguration entfernen, den Server Neustarten oder die Services und OpenSSL aktualisieren und dann seid ihr fein raus. Okay, irgendwelche andere Fragen? In dem Fall, bitte, gibt einen Jubiläums-Aplaus an Sebastian Schinzel. Ja, und gibt uns Feedback in der Besetzungskabine einen weiteren Sebastian.