 einen kurzen Fragen- und Antworten-Session. Einen warmen Applaus für unsere Redner. Thank you. Danke. Mein Name ist Gert Römerich. Ich bin bei von der University of Michigan. Und ich habe Rede darüber, was wir über diese großen Datenanalysen über Hard-Bread machen. Letztes Jahr haben Sie von mir davon gehört, meine Arbeit über Zen-Map oder darüber, wie wir letztes Jahr das gesamte Internet-Gescannt haben über Keys und darüber, was passiert ist, als Hard-Bread das Internet getroffen hat. Und was danach passiert ist. Im April 2014 hat OpenSSL eine Information darüber gesagt, dass ein Fehler in der hat OpenSSL ist. Das schließt alles ein von Webservern wie Apache Engine X, unter anderem auch Troor, unter anderem auch noch viele andere Arten von Software. Am Ende hat es den Angreifern erlaubt, aus der Ferne die Login-Daten, die im Ramm lagen zu stehen, zum Teil auch möglicherweise die Kreditkarten-Details, die man gerade bei Amazon benutzt hat. Es hat auch viele Seiten beherrscht. Ein großer Teil des Internets wurde damit reingestimmt. 25% aller SSL-Seiten hatten am Anfang dieses Problem, das ist der Fehler das erste Mal. Das Ziel ist Hard-Bread Extension. Viele habe ich davor gehört, aber wenigsten haben wir davor gehört. Diese Erweiterung wurde 2012 geschält und hat überhaupt jeden Teil eines Kommunikations darüber zu fragen, ob er noch da ist. In der anderen Worte sagt, ich bin noch da. Es wurde größtenteils nicht benutzt, weil TLS über TCP benutzt wird. Das funktioniert halt direkt über TLS. SSL wird benutzt, auch wenn keine TCP dabei ist. Es wird immer noch versucht zu fragen, ob alles noch funktioniert, ohne eine neue Session aufzumachen. Irgendeiner der beiden Endpunkte der Kommunikation fragt, hallo, bist du da? Und sendet eine kurze Date und ein bisschen Daten und bittet den anderen, diese Daten zurückzusenden. Wenn es immer noch zurückkommt, dann ist der Partner immer noch da und läuft weiter. Der Fehler war darin, dass der Lange-Länge als auch die Daten direkt weitergegeben wurden. Wir haben dem vertraut, dass die Länge die richtige Information ist. Also wurden diese Menge an Daten weitergegeben, egal wie viele Daten dabei waren. Das heißt, auch wenn vier Bits Daten lang waren und wenn nur vier Biten Daten gesendet wurden, dann wurden gerne die acht Bits zu klein, der hinten zurückgesetzt. Wir schicken das Lange-Datei. Wenn die Länge größer ist als die der Datei, dann löschen wir den Request einfach. Nach 16 Bits, nach den Daten, wurden zurückgesendet. Das könnte unter anderem die Login-Daten gewesen sein. Das könnten Kies, die benutzt wurden, sein. Das hat sehr viele verschiedenen Softwares betroffen. Unter anderem bei Engine X und bei Apache ging es darum, dass HTTPS-Seiten betroffen waren. Wenn man seine Geldbäuse an einen betroffenen Server geschickt hat oder auch, wenn man sich zu einem Torrelay verbunden hat, eine ganz große Menge an Services. Wir haben uns primär auf Web Services beschränkt. Aber es hat alle betroffen. Mail-Server, Datenbank-Server und so weiter. Als diese Schwachstelle erst mal aufgetreten ist, wollten wir ihr Auftreten tracken und die Auswirkungen auf das ganze Internet. Wir haben das gemacht, indem wir das ganze Internet für diese Wundbarkeit gescannt haben, indem wir Setmap modifiziert haben und Datenbank und Mail-Server gescannt haben. Wir haben es auf einem speziellen Weg gemacht. Wir wollten die tatsächliche Verwundbarkeit ausnutzen während des Scans. Wir wollten keine Daten von den Servern veröffentlichen oder bekommen. Und deswegen haben wir uns einen Phänomen zur Nutze gemacht und das LFC gelesen, indem die Extension verwendet wird. Wir haben also ein Zero-Byte-Request gesendet, das nicht gemäß der Spezifikation war. Aber diese spezielle Version von OpenSSL hat anstatt den Request abzulehnen geantwortet. Und wir haben also unsere Antwort bekommen und das hat nur diese spezielle verwundbare Version von OpenSSL gemacht. Die gepatchede Version, zum Beispiel in verschiedenen anderen Bibliotheken wie GNU-TLS, hatten nicht dieses Phänomen. Wir konnten also den Check machen ohne die Verwundbarkeit tatsächlich auszunutzen. Also eines der interessantesten Sachen, die am meisten interessiert sind, die haufeichhundert benutzten Seiten. Die meisten hatten Apache Sachen. Die meisten Seiten wurden innerhalb der ersten Stunden gepatched. Wir können nochmal zurückschauen. Die großen Situationen sind in der Spotlight der Medien. Und sie haben sehr früh Journalisten gearbeitet. 45 Prozent der Webseiten waren verantwortbar. Viele Organisationen haben diese Fragen nie beantwortet. Sie haben keine Informationen darüber veröffentlicht. Aber das war von denen, die diese Informationen veröffentlicht haben. Und einige der Webseiten waren nach 24 Stunden immer noch problematisch. Und zum Beispiel Yahoo. Und dort sind viele Angriffe gestartet worden, wie zum Beispiel Yahoo e-mail-Accounts. Bis 24 Stunden innerhalb der, nachdem der Hilfs veröffentlicht wurde. Innerhalb von 48 Stunden war alles gepatched. Die top 100 Seiten sind sehr wichtig. Die haben nicht nur dedikierte Systemadministratoren, sondern die haben Teams von Systemadministratoren. Wir haben erst einen Scan, ungefähr zwei Tage nachdem die Feder zuerst veröffentlicht wurde. In den ersten zehn Stunden haben 45 Prozent aller Webseiten HTTPS benutzt. Und das war ein bisschen problematisch. 60 Prozent der HTTPS-Seiten haben HardBeat supportet. Andere Seiten, aber sie waren nicht unbedingt problematisch. Einige Vulnerabilities waren aber nicht. Wir haben es eben weitergebracht. Und viele Seiten haben TLS-Verbindungen benutzt. In dem Server Agent Strom haben wir es gesehen. Viele haben zum Beispiel andere Softwarehersteller wie Microsoft EES haben viele der Webseiten waren, aber trotzdem verwundbar als HardBeat zuerst rauskam. Das ist die obere Grenze. Die untere Grenze können wir abschätzen anhand von zwei Funktionalitäten der HardBeat Funktionalität in 2012. Keiner hat sich, als sie auf eingeführt wurde, wirklich für HardBeat interessiert. Sie haben sich für TLS 1.1 und 1.2 interessiert. Ich tue regelmäßig bei SSL Labs, gucken, ob SSL sites richtig konfiguriert sind und habe mich über die Verwendung der neuen Protokolle informiert. Ich habe herausgefunden, dass viele Webseiten TLS 1.2 vor der HardBeat-Attacke ausführten. Das gibt uns eine gute Abschätzung, dass zwischen 50 und 65% der Seiten verwundbar waren. Es war wirklich so, dass ein sehr großer Anteil des Internets zum damaligen Zeitpunkt angreifbar waren. Wie sieht es aus, wenn man sich den restlichen IPv4-Adress-Raum ansieht? 11% aller IPv4-Hartbeats haben den HardBeat-Fehler unterstützt. Von denen waren wiederum insgesamt 6% angreifbar. Man handelt es sich hier bei hauptsächlich Kameras, Router und Haushalt. Diese benutzen in der Regelzeit sehr vereinfachte HTTPS-Software. Die haben diese HardBeat-Exensions nie benutzt. Alle die meisten Embedded Devices, die dieses Problem hatten, sind heutzutage immer noch problematisch. Die meisten sind in der Regel nicht gepatcht. Darum sind sie heutzutage immer noch problematisch. Wir haben viele unterschiedliche Geräte gesehen. Zum Beispiel Daten und in einem Fall ein Pizza-Verkaufsplatz. Und die war federhaft. Als wir auf die Spatchingbehälfte angeschaut haben, haben wir am Anfang sehr gut funktioniert. In den ersten 100 oder ersten Millionen Seiten waren 45% problematisch. Problematisch haben wir nur noch 11% innerhalb der 84 Stunden bekommen. Das ist sehr gut. Als Betreiber-Situation haben wir sehr gut daran gearbeitet. Was ein bisschen schader ist, wenn man auf den IPv4-Adresse schaut, oder dass dann auch diese Top-Adressen nicht mehr überprüft werden. Und die Nummer hat sich seitdem nicht mehr wirklich geändert. Das sind immer noch Seiten in der millionen häufigsten Webseiten. Und viele davon sind immer noch problematisch. Hier ist ein sehr interessanter Sprung, wo ungefähr die Hälfte der problematischen Geräte immer halb des Internets umgestellt wurden. Es gibt sehr große Shared-Hoster-Provider. Und alle Vulnerabilities auf deren Seiten war problematisch. Und als sie ihre virtuellen Maschinen gepatched haben, wurde die Anzahl der Probleme deutlich reduziert. In dieser Zeit haben drei große Organisationen gepatched. Und wenn man sich das ausschaut, dann haben die wenigsten Leute es wirklich gepatched und repariert. Die Frage ist, ist das immer noch schnell genug? 25% waren wahrscheinlich problematisch am Anfang. Und als wir anschauen, wann die Angriffe zuerst gestartet haben, dann haben unglaublicherweise die Angriffe gestartet, bevor wir unsere Tests gemacht haben. Wir haben den ersten Scan ungefähr 20 Stunden nachdem der Angriff veröffentlicht wurde gemacht. Und wir haben es also nicht wirklich gut genug gemacht. Wir haben das ganze Internet gescannt. Gezielte Angriffe haben deutlich davor angefangen. Das hat deutlich angefangen, deutlich bevor diese HTTP, wie ganze HTEPF4, das Hand wurde. Schauen wir mal auf einen Hornipot, auf einem server, virtuellen Server. Und wir schauen uns an, was da passiert ist. Wir wollten sehen, welche Angriffe aus diesen verschiedenen Netzwerken kamen. Wir haben vor niemanden davon bekannt gegeben. Es gab möglicherweise bereits zielgerichtete Angriffe. 24 Stunden nach der Veröffentlichung der Lücke haben wir ungefähr 6.000 verschiedene Angriffe auf die Hardbleed-Verwundbarkeit festgestellt. Und es gibt eine Seite, die hat sozusagen große Spikes. Und das eine war eine Seite, die getestet hat. Und das andere war ein Office. Nur 11 Leute haben das anscheinend das gesamte Netzwerk getestet. Sowohl Amazon als auch das Test in Boatway. Nur 6 Hosts insgesamt haben mehr als 100 Hosts gesendet. Nur 6 Hosts, von denen, die viele gescannt haben, waren wissenschaftliche Organisationen. Es waren aber vier andere Hosts, auf zwei davon in chinesischen, die wir keine Ahnung haben, wer das war. Es könnten akademische Organisationen oder Angriffe sein, wir wissen es nicht. Wir wissen, dass sie den Fehler wirklich ausgebeutet haben. Auf der anderen Seite gab es eine sehr große Anzahl von Hosts, die unseren HTTP-Honipot ausprobiert haben. Aber wir haben 200 Leute haben versucht, dieses Haus anzugreifen. Viele Leute haben einfach in diesem Dresdbereich von Amazon 2 überprüft. Nach zwei Wochen nach der Veröffentlichung waren 600.000 Hosts am Internetreform noch verwundbar. Wir merken, wir sollten jeden Notifizieren der eine verwundbaren Host hatte auf dem Internet. Das ist das erste Mal gewesen, als eines der großen Internetverbundbarkeitsveröffentlichungen passierte. Wir haben die betroffenen Hosts in zwei Gruppen geteilt, als wir jeden mit einer verwundbaren Host kontaktiert haben, haben wir das in zwei Wochen Gruppen getan. Das Resultat ist spannend für die Forschergemeinschaft. Und wir dachten uns, dass der Zeitraum der Benachrichtigung wenig zu tun hatte, damit er tatsächlich gepatched wurde. Wir haben aber herausgefunden, dass eine frühzeitige Notifizierung 47% in Patching bringt. Was wir herausgefunden haben, ist, dass Leute trotzdem aufpassen. Obwohl wir keine Antworten auf die E-Mails bekommen haben, lesen die Leute diese und handeln. Und sogar in Fällen, in denen wir Bounce bekommen haben, hat die E-Mail es zu einer zweiten Person gebracht, die Bescheidwurste und den Patch ultimativ durchgeführt hat. Das sollten Sie beachten, wenn Sie diese großen Internetweiten Dinge durchführen. Patching ist nicht genug, denn auch kryptografische Schlüssel waren nur trocken. So Heartbleed führt dazu, dass kryptografische Schlüssel veröffentlicht werden. Jeder, der Apache oder EngineX benutze, konnte darüber einen kryptografischen Schlüssel holen. Man musste den Server patchen und danach den Key. Die traurige Geschichte ist, dass die Keys nur 10% der Webseiten tatsächlich ihr Zertifikat ausgetauscht haben. Noch schlimmer, 14% der Webseiten, die es ausgetauscht haben, haben denselben verwundbaren privaten Schlüssel verwendet. So kein wirklicher Schutz. Vier Prozent der Webseiten, die verwundbar waren, haben ihr Zertifikat zurückgerufen. Das sind schlimme Zahlen. Da ist viel Raum für Verbesserung. Was haben wir daraus gelernt? Ich denke, das erste, was heraustritt, ist, wenn diese großen Open-Source-Projekte, auf die wir alle vertrauen, OpenSSL, 60% der Webseiten vertrauen darauf für HTTPS. Wir sollten mehr Unterstützung diesen Projekten zukommen lassen, um diese Art von Bugs frühzeitig zu erkennen. Sie brauchen mehr Unterstützung bei uns. Das HTTPS-Ökosystem ist sehr angreifbar. Leider kann man nicht sagen, dass es die einzige Verwundbarkeit ist, die sie dabei gezeigt hat. Wenn wir an Poodle denken oder an S-Channel, die waren zwar nicht ganz so gravierend, aber es gab trotzdem eine Verwundbarkeit, die erlaubt hat, Code auf dem Remote-System auszuführen. Das ist ziemlich gravierend. Wir haben vor wenigen Wochen bereits Poodle 2 gesehen. HTTPS ist weiterhin sehr angreifbar. Die Internet-PKI ist nicht in der Lage, eine groß angelegte Rückrufung von Zertifikaten durchzuführen. Nur 4% der Webseiten haben überhaupt probiert, ihr Zertifikat zurückzurufen. Andere können das gar nicht. Webbrowser waren auch nicht in der Lage, das zu erkennen. Und wir müssen als Community bereden, wie wir in Zukunft mit einer Massenzurufung von Zertifikaten klarkommen. Wir müssen berücksichtigen, dass wir zukünftig jedes Zertifikat im Internet zurückrufen können müssen. Die neulichen Verbesserungen beim Scan haben dazu geführt, dass wir die Auswirkungen schneller bemerken konnten. In einem guten Licht können wir sogar sehen, ob und wie schnell das Patching passiert. Das ist ziemlich motivierend, obwohl das fragilen Ökosystems. Zur gleichen Zeit müssen wir zurückschauen und sagen, es ist viel Raum für Verbesserungen. Mit diesen Worten gebe ich über an Nick. Danke. Sieht gut aus. Hallo, ich bin Nick. Ich bin der führende Sicherheitsingenieur bei Cloudflare. Ich erzähle heute etwas über Hardbleed, deswegen schon langweilig. Besonders rede ich über meine persönlichen Erfahrungen bei Cloudflare mit dem, was passiert ist, während Hardbleed, als es gerade rauskam. Und was danach noch passiert ist. Hat jemand bereits diesen Artikel gelesen? Das ist ein Ausschnitt aus The Verge. Das ist ein semi-authentisches Stück über das, was mit Hardbleed passiert ist. Ich will das kurz zusammenfassen. Benutzt sie DTLS? Nein, ich benutze es nicht. Benutzt es irgendjemand? Wie sieht es denn aus mit TLS Hardbleeds? Was ist denn ein TLS Hardbleed? Zu diesem Zeitpunkt wusste niemand wirklich, was das war. Es war ein sehr selten genutztes Feature. Die Antwort war, okay, sie sind dämlich und es ist ein Bug. Man sollte es einfach ausschalten. Okay, dann kompiliere ich einfach OpenSSL ohne Hardbleed neu. Ein paar Stunden später war Hardbleed ausgeschaltet und wir haben es ausgerollt. Wir sollten die Öffentlichkeit informieren gegen den 9. April. Dann haben die Leute gefragt, warum sollte man Cloudflare sagen? Lassen Sie mich kurz erklären, was Cloudflare macht. Wir sind ein Reverse Proxy. Das heißt, wenn Sie eine Webseite haben und trosten, dann sitzen wir davor. Wir schicken dann gecached Inhalte an den User. Aber das verringert den Load auf Ihrer Seite. Aber dazu muss unser Server näher an Ihrem Haus sein als der Benutzer. Wir sind näher an den Benutzer als der normalen Server. Das sind ungefähr eine Million von Seiten auf Cloudflare. Zum Beispiel Banken und große Klinik-Auszage-Systeme. Reddit zum Beispiel oder die Internet-Tagfosten. Mehr und mehr. Viele Seiten. Und was Cloudflare macht, ist sehr einfach. Wir haben drei Services. Drei. Domain Name Server, HTTPS und HTTPS, was bei OpenSSL gemacht wird. Und Engine X. Die Architektur ist sehr einfach. Jede verschiedene, die wir haben, kann jede Seite ausliefern. Das heißt, wenn man ein Hard-Blade zurückdenkt, ist das ja ein wirklich, wirklich großes Problem, wenn man ein Hard-Blade uns trifft. Wie dem auch sei. Es hat sehr früh passiert, April 7, um 10.27 Uhr, OpenSSL veröffentlicht diesen Advisory. Und wir wurden russend kurz davon. Eine halbe Stunde war, wusste jeder. Eine Stunde später haben wir gesagt, dass wir, sagen, unsere Kundenseiten sind gepatched. Es war etwas. Es war ein Back-Und es wurde größer. Und ungefähr eine Stunde nachdem es groß wurde, kam ein Tweet von Code Nomicon. Und jeder weiß, was es ist. Was ist der nächste Tag? Es ist Hard-Blade itself. Es wurde auf einmal eine Marke. Und es kam in die Massenmedien. Und es wurde ein wirklich großes Problem. Hard-Blade.com hatte ein Logo. Es wurde mit der großen Nachrichten-Seiten. Hard-Blade-Virus war da draußen. Und ich wusste, dass es wirklich schlimm wurde, als meine Mutter mich angerufen hat und gefragt, hey, was läuft denn hier? Also, es war eine relativ große Sache. Und wir waren fertig, damit diese ganzen Fehler zu beheben. Also haben wir Probleme, hätten wir genug Zeit. Wir wussten, da haben wir beschlossen, drei Sachen zu machen. Also zuallererst haben wir versucht, diesen Scanner, den Philippo hat, Fahrfahrt von Quatern zu machen. Also dem haben wir unser ganzes Netzwerk in, ein Honnin-Netzwerk umgewandelt, um zu sehen, was angriffen wurde. Dann haben wir beschlossen, was wir über unsere Zertifikate machen. Und viele der Seiten, die wir machen, sind Zertifikate. Und wir hatten ungefähr viele Zertifikate. Und am Tag der Nachweis war es noch nicht wirklich klar, dass man die Zertifikate zurückrufen musste. Okay, reden wir ein bisschen über den Hard-Blade-Scanner, den Philippo gemacht hat. Der in Cloudfair Engineer war. Er hat den Go-Man, den Benutzernamen, den Netzwerkname rein. Und der schaut, ob schlechte HTTPS-Hard-Beat-Sachen sind. Es sollte keine wirklichen Informationen veröffentlichen. Wir haben es auf einmal gemacht. Und wir haben es hinter Cloudfair gemacht. Und wir haben vielen... Das ist, wie Philippo's Server aussah. Apple-Aids haben wir bis zu 120.000 Hits pro Minute gehabt. Das ist so gut wie nichts. Das ist die nächsten zwei Wochen. 2.000 ist das ganz unten. Bis zu 10 mal zu viel. 10 bis 20.000 Hits am Tag. 10 bis 20.000 Scans pro Minute für die nächsten Woche. Und wir hatten 200 Millionen Tests innerhalb der ersten zwei Wochen. Wir hatten dann den Scanner laufen. Und danke an Philippo. Er ist glaube ich hier im Raum irgendwo. Bitte steht doch mal kurz auf. Vielen Dank für das Tool. Jedenfalls, das ist was wir dabei gefunden haben. In Anzahl der Domains, die betroffen waren, war es ziemlich übel. Das ist kurz danach. Ein zwei Tage danach waren es bis zu 30 Prozent aller Seiten, die wir gescannt haben, war anverwundbar. Viele Leute haben das bei ihren automatischen Tests verwendet. Wir sind trotzdem relativ schnell runtergekommen auf eine sehr niedrige Zahl. Bei Cloudfair haben wir dann entschlossen, was man will machen. Wir können im Prinzip jeden Hartblied Angriff versuchen zu langen. Eine falsche Größe hat. Das sind unsere Logs vom April 9. 69 Prozent aller Pakete hatten eine Größe von 16.384. Das werden Sie als eine Potenz von zwei wieder erkennen. Man erkennt es auch als eine Zahl, die in dem Tool SSLtest.py hardcoded war. Deswegen kann man davon ausgehen, dass es von diesem Tool generiert wurde. Viele der Pakete, die wir gefunden haben, haben das Null-Längen-Paket benutzt. Eine Woche später war es ungefähr dasselbe. Es gab viele Leute, die das im großen Stil als Angriff gegen verschiedene Webseiten ausgenutzt haben. 20 Prozent waren immer noch Philippos Tests. Viele Leute waren einfach nur interessiert daran, die gleichen Tests auszuführen wie Philippo. Nur 1 Prozent der Scans von Philippo war gegen Cloudflare gegangen. Hier haben wir eine IP-Landkarte. Man sieht hier merkwürdige Spitzen, die man auf Island sieht. Da sollte man nicht zu viel reinlegen. Ich halte nicht so viel von solchen IP-Karten. Warum ist das jetzt so gefährlich? Warum war Hartblied so schlecht für uns? Es geht hier um einen Ebenen-6-Problem im OZI-Layer. Man lockt normalerweise nicht Handshakes. Wenn man jetzt 64K weit vom Speicher eines Servers abgreifen kann, dann hat man möglicherweise TLS-Privatschlüssel mit erhalten. Wenn man sich dieses Diagramm anschaut, das ist eine Heap-Map. Alles, was oberhalb von dem Heap ist, konnte man theoretisch abgreifen unter anderem Passwörter, Cookies. Die Frage ist, was war da wirklich drin? Also haben wir uns den Code angesehen. Was sagt der Code? Der Code sagt, das kann eigentlich gar nicht passieren, zumindest nicht in Engine X. Der Schlüssel wird gleich geladen und müsste deswegen auf dem niedrigsten Level des Stacks liegen. Das heißt, jedes Mal, wenn ein neuer Request reinkommt, müsste der Speicher dafür weiter oben im Stack liegen. Jetzt ist Engine X Single-Freaded. Das heißt, es kann nicht passieren, dass ein anderer Fret zwischendrin irgendwie in den Speicher reingreift und es dann trotzdem ausliest. SSL benutzt viel Speicher und die ganzen kryptografischen Speichern werden von SSL sofort überschrieben, wenn es nicht mehr benötigt wird. Das haben wir zumindest gedacht. Wir waren nichts anderes sicher als bei CloudFair. Ich habe nur ein bisschen Code geschaut, warum haben wir diese CloudFair Hardbeat Challenge gestartet? Wir haben geschaut, ob man eine Antwort davon hat. Wir hatten einen Standard Engine X außerhalb eines CloudFair mit einem problematischen SSL-Version. Und wir haben sie alle gebeten, versucht es zu finden. Schaut, was wir gemacht haben. Und dem Beweis zeigen uns eine Nachricht, die mit diesem privaten Schlüssel signiert wurde. Also das haben wir gefunden. Den ersten Stunden war traurig. Und sie sich vielleicht schon vorstellen, wenn irgendwie anscheinend das gemacht haben hier. Hauptsächlich irgendetwas, was auf der Seite war, wurde in die Speicher geladen. Und Leute haben private Schlüssel gepostet und Sachen, die so aussehen, wie zum Beispiel mein Name oder die Password Datei. Also jeder war sehr durcheinander. Da ist ein privater Schlüssel. Aber es war nicht der wirkliche Schlüssel, bis wir das hier gesehen haben, diesen Tweet. Und wir haben nachgeschaut. Das ist unser Büro. Und wir schauen auf den Bildschirm. Und ja, er hat das gelöst. Also er hat sich einen Glückwunsch zuviel da. Er war nicht der Einzige. Das hier waren die, die es ungefähr in den ersten 24 Stunden geschaut haben. In den ersten 48 Stunden haben es 12 Leute gefunden und haben einen Beweis zu uns gesendet. Okay. Immer noch kann man als private Schlüssel machen? Ja. Wir haben es innerhalb von 10 Stunden. Und wir sind als private Schlüssel absolut sicher waren. Wir haben geschaut, wo in Memory die Sachen gespeichert sind. Und schauen, wo die private Schlüssel am Anfang gespeichert sind. Aber die waren nirgends in derselben Position. Okay, wir wurden das jetzt wirklich gemacht. Es war ein zweiter Fehler in OpenSSL. Es hat sich rausgestellt, es gab noch einen zweiten Fehler in dem Code. Wie hätte man sich das nur denken können, wenn man sich den Code anschaut? Wenn man sich den Speicher ansieht von so einem Request, dann sieht man all die Stellen, die rot markiert sind, sind mögliche Private Schlüssel. Das ist der Code, den wir verwenden, um den Müll hinterher auch wieder aufzuräumen. Ja. In bestimmten Fällen in der Montgomery Multiplikation wurden einfach nicht die Zwischenergebnisse wieder gelöscht danach. Deswegen lassen wir kurz erklären, wie es funktioniert in RSA. Also man hat verschiedene Dinge. Unter anderem ein Privatschlüssel, das nennt man den. Das ist der private Exponent D. Dazu gibt es noch die öffentlichen Schlüssel. Das ist PQ, das ist mit dem öffentlichen Exponent E. Wenn man Teile davon kriegt, hat man schon den ganzen Schlüssel. Das heißt, die Leute haben jetzt einfach jeden 128-byte Block genommen, den sie gefunden haben, und haben ihn durch den RSA-Modul geteilt. Wenn es sich teilen ließ, dann hat man den Faktor gefunden. Von den zehn Leuten, die uns eine Lösung geschickt haben, haben neun Leute es auf diese Art und Weise gelöst. Wenn man eine größte Anzahl an Request schickt bis zu 10.000, dann hat man gelegentlich einfach Glück. Dann gab es noch eine Lösung von Rubing Sue, der hat die Koppersmith-Attacke gefahren. Dazu muss der öffentliche Schlüssel klein sein. Man braucht aber nur 60 Prozent des öffentlichen Schlüssel P oder Q. Das funktioniert aber wirklich nur, wenn der öffentliche Exponent klein ist. Und der öffentliche Exponent by RSA ist immer klein. Und er hat es innerhalb von 50 Anfragen gelöst. Das war richtig interessant. Okay, private Schlüssel sind weg, sind veröffentlicht. Okay, was bedeutet das? Revocation-Dime, Zurückrufzeit. Okay, das Internet wurde dafür gebaut, so was zu machen. Die, die diesen öffentlichen Schlüssel, dann werden Leute ihre Schlüssel die ganze Zeit zurückrufen, so designen wir das System. Okay, das waren hauptsächlich wir. Aber hauptsächlich war das Cloud-Fair, was das ganze Netzwerk zurückgerufen hat. Unten sind die zurückgerufenen Zertifikate, und das ist April 7. Das war, als alle ihren Schlüssel zurückgerufen haben. Der grüne Spitz, dass es als Cloud-Fair ihre Schlüssel zurückgerufen hat. Und sie die ganzen Zertifikate zurückgerufen haben. Aber das war erst gestellt. Das ist nicht wirklich viel bedeutet. Die selben Zertifikate wurden weiterhin von den Browsern akzeptiert. Ich könnte kurz noch mal reinschauen. Es gibt drei Methoden, wie man das Schlüssel zurückruft. Diese zurückrufen von Schlüssel, und von diesen drei Methoden gemacht. Okay, zuerst ist es ein Zertifikats-Zerückrufungsliste. Es ist einfach nur in der Tie mit einer Reihe von Zertifikaten, die zurückgerufen werden. 100.000 Zertifikate zurückgerufen, und das zerstört diese Liste. Diese Liste von Global CLR wuchs von 22 Kilobyte zu 4,7 Megabytes. Und 30 Gigabits pro Sekunde und 100 Gigabits pro Sekunde war sehr problematisch. Wirklicherweise für Global Signing war Cloud-Fair vor ihren Servern, und ja, sonst wären sie in die Knie gegangen. Wir können damit umgehen. Alle drei Stunden waren diese Wellen, und das ist darüber, wie CLRs auf anderen Seiten abgedatet wurden und wie Intellect Explorer die runterleiten. Das ist ziemlich stark. CLRL ist kaputt. OSCP, Online-Zertifikat-Status-Protokoll. Frage, Antwort, ist dieses Zertifikat zurückgezogen? Ja oder nein. Es ist ziemlich kaputt. Chrome weiß das schon seit einer Weile, und überprüft es nicht. Und wenn man wirkliches Problem hat, dann kann man spezielle Probleme nicht machen. Wenn man nur ein leicht kleines Problem hat, kann man einfach auf dem Weg diesen Zertifikat fallen lassen. Diese Überprüfung fallen lassen. Darum hat es nicht wirklich funktioniert über der Rhein-O-C-S-P. Und wie war das jetzt mit CRLS-Sets? Das ist das, die Version von Google. Google macht damit alle Zertifikat-Listen und macht sie alles zusammen und steckt sie in den Browser. Das heißt, man kriegt neue Updates mit dem Browser. Nicht alle Listen, aber spezifische Zertifikate. Und das ist, was wir herausgefunden haben. Sie machen nur manche. Sie fragen nur manche. Und wenn der Browser keinen Update bekommt, dann kriegt man auch keine neue Liste. Und das ist auch ziemlich problematisch. CloudFair hat die ganzen Zirch gerufen. Und das war kein EV-Zertifikat, aber Chrome hat es auch trotzdem zurückgezogen. Aber keins der 100.000 plus CloudFair-Zertifikaten waren in dieser Liste. Also war im Endeffekt nur ein Hack, dass dieser eine Seite zurückgerufen wurde. Das waren die effektivsten 4-Zahlen von Zertifikaten in Chromium. Das ist ein Hack, das kann man nicht so anbinden. Aber das ist, wie es gemacht werden sollte, weil es keine möglichen Wege gab, die zurückgerufen durchzuführen. Das Zurückgerufsystem ist kaputt. Also, was können wir machen? Okay, es gibt kürzere Zeit, die Zertifikate gültig sind, machen kann. Das wir mussten nicht die alten Zertifikate sehr lange speichern in diesen Listen von zurückgerufenen Zertifikaten. Es gibt auch die Möglichkeit, dass der Server dieser UTSP-Zertifikatlisten weiter senden muss. Das könnte dieses auch lösen. Aber wir sind alle nicht weit angewendet und werden nicht häufig benutzt. Okay, also zusammenfassend kann man sagen, dass wir drei Sachen gemacht haben, nach Hartbleed. Wir haben dafür gesorgt, dass der Scanner läuft. Wir haben unsere Seite in einen Hornipot verwandelt. Wir haben festgestellt, dass man Zertifikate auf jeden Fall zurückrufen muss. Es gibt keine Ausrede, das nicht zu tun. Es gibt mehrere Sachen, die man noch darüber lernen kann. Ich will nicht derjenige sein, der allen Leuten erklärt, was man tun sollte. Aber bei Open Source ist Veröffentlichung relativ wichtig. Das war das erste in diesem Jahr. Wo wir festgestellt haben, dass noch viele weitere kommen sollten. Andere Sachen, die offensichtlich sein sollten, aber offensichtlich nicht waren. Niemand sollte OpenSSL 1.01. Niemand, der OpenSSL 1.0 installiert hatte, wollte, Hartbleed. Von daher sollte es als Schlussfolgerung sein, dass man Features, die man nicht unbedingt braucht, standardmäßig deaktiviert. Dann natürlich erwartet das unerwartete, dass es zwar immer war in der Computersicherheit, das sollte man immer erwarten, aber das kam trotzdem wieder mal als Schock. Viele der Angriffe, die wir gesehen haben, waren eigentlich nur Scans, die sehen wollten, ob die Seiten funktionieren und ob sie verwundbar waren. Crowdsourcing war effektiv. Das ist ein sehr beruhigendes Zeichen. Ist jemand hier in der Runde vielleicht jemand, der die Cloudflare Challenge gewonnen hat? Wenn ja, dann bitte jetzt den Armin. Okay, ich sehe niemand. Ich habe leider keine Brille dabei. Wenn dann viel Glückwunsch, auf jeden Fall. Und das Letzte ist natürlich, Rückruf braucht eine Lösung. Was wir daraus lernen, ist, dass wir OpenSSL unterstützen müssen. Das ist eine... Ich muss den Mikrofon hier festhalten. Vielen Dank. Wirklich, das ist ein Teil von der kritischen Infrastruktur der ganzen Welt und nicht nur der Webseite, sondern auch von anderen Sachen, wie zum Beispiel eingebettetem Gerät. Und diese Leute brauchen Unterstützung. Also bitte unterstützt OpenSSL. Und damit bin ich fertig. Okay, quick announcement before we start the Q&A. If you are going to leave the room, please get up now. Go out quietly without talking so we can do this. If you want to leave the room, please do it. Moment, could you leave the room? Okay, if you have any questions, please go to the microphone. We start with microphone number 1. Okay, nicht wirklich eine Frage. Vielen Dank für die Präsentation. Wir haben diese Sache verfolgt über das Papier, das Sie veröffentlicht haben. Es fehlen irgendwie noch ein paar Informationen. Zuerst andere fehlen innerhalb der ersten 24 Stunden nach dem Disclosure waren wir. Wir haben nicht wirklich angegriffen. Wir haben den Scanner angefangen zu arbeiten innerhalb von 24 Sekunden. Und wir haben diese Regionen gezeigt. Wir haben verschiedene Methoden ausprobiert und wir haben während viel gearbeitet haben, dass möglicherweise Firewalls veröffentlicht werden innerhalb von denen, oder die manche Pakete stoppen. Das heißt, wir haben verschiedene Pakete in jedem Anfrage gemacht. Das war auch eine der Scanners, die Sie da entdeckt haben. Ist er Mike Lana? Ja. Noch eine kurze Unterbrechung. Wenn Sie gehen auf dem Grasis, bitte benutzen Sie nur die vorn links und vorn rechts die Tür. Wenn Sie da oben sind, können Sie irgendeine Tür benutzen. Aber wenn Sie hier unten sind, bitte benutzen Sie nur die Tür vorn rechts und vorn links. Und so geht der Mikrofon. Vielen Dank für den Kommentar. Ich kann leider nicht sagen, ob ich das speziell gesehen habe, aber das ist eine von den Sachen, wo es sehr schwer ist zu sagen, ob es jetzt ein bösartiger Angriff ist oder ob es sich einfach nur um den Scan handelt. Wir haben einfach nur den Host gesehen und da hat uns unter Umständen die Informationen gefehlt, was dir Hintergrund davon war. Hallo, ich habe eine Zweige über Cloudflare. Könnten Sie bitte aufhören, Torusal zu benutzen? Also blockieren? Sie machen die Seiten zentraler jeden Tag und diese Arbeit ist so ein kleines Problem und Sie können das so einfach machen, aber Sie blockieren alle Tor benutzen. Danke, wir denken darüber nach. Wir denken darüber nach, ob wir eine Lösung dafür finden können, wie wir mit Tor umgehen. Das Hauptproblem ist, dass Tor einfach ein unglaublicher Spamquelle ist für Webseiten und es ist sehr schwierig durchzusuchen, was davon gut und was davon schlecht ist. Warten Sie ab. Dieses Jahr werden wir noch etwas präsentieren, wie wir mit Torios an umgehen wollen. Nächste Frage von unserem Signal Angel über Internet Relay Chat. Die maximale TLS, der enge 16 Kilobytes, wie konnte man 64 Kilopytes zurückbekommen? Man kann ein Hardbleed-Request über mehrere Pakete aufspannen. Ich bin ziemlich sicher, dass es so funktioniert hat. Mikrofon 1, bitte. Was ist Ihre Meinung über Libre-SSA? Sag du. Ich bin nicht sicher, ob ich die qualifizierteste Person bin, um darüber zu reden, aber ich glaube, es ist wirklich gute Absichten dahinter. Ich glaube, die Gemeinschaft hat erkannt, dass da große Probleme vor allem bei der Maintenability sind bei OpenSSL, aber ich bin nicht sicher, ob der Ansatz da richtig ist. Ich denke, es funktioniert dahingehend, dass Sie ihr Ziel erreichen werden, das Sie haben. Gibt inzwischen eine öffentlich, übertragbare Version für andere Betriebssysteme außer OpenBSD. Das ist deutlich sauberer Quellcode und OpenSSL versucht immer noch viel zu viele alte Systeme wie Windows 16-Bit-Systeme zu unterstützen. Die Vertreubarkeit wird noch für eine Weile dabei bleiben. Ich stimme Ihnen zu, dass OpenSSL eine wirklich große Anzahl an Plattformen unterstützt, aber die große Zahl an neuen SSL-Bibliotheken, die rausgekommen sind, Patches untereinander austauschen, insofern muss man das in der Gesamtssicht sehen. Hallo, vielen Dank für Ihre Gespräche. Sie haben beide Zahlen, die kleiner werden und später wieder größer werden. Wenn Sie das erklären? Ich glaube, es gab einfach kleine Spikes, das Leute kamen und gingen. Es glaubt nicht, dass Seiten wirklich neuer Ding, also nachträglich verwundbar wurden. Ich glaube eher, dass das Artefakte von der Messung sind. Ich glaube nicht, dass es wirklich große Sprünge gab. Das ist den Daten, die ich vorhin gezeigt habe, aus Philippos Scanner. Es war nicht so, dass immer die gleichen Domains an jedem Tag gescannt wurden. Insofern kann es schon sein, dass wir immer einen anderen Subset hatten. Vielen Dank, und bitte geben Sie uns ein Pröf.