 Natürlich das Content-Deliver-Network, das alle lieben, einen Willkommen an Nick. Okay, hallo. Ist das an? Ja, okay, hallo alle. Ich bin Nick, ich arbeite ja bei Cloudflare. Das ist der lieblings, das ist das lieblings-CDN von allen. Und ich arbeite mit Kryptografie, angewandt mit Kryptografie. Und ich werde über das Interessante Protokoll der Welt sprechen. Transport-Layer Security, also. Wenn jemand diesen Browser benutzt, kennt ihr dieses kleine Icon hier. Das ist Netscape 1.0, der erste Webbrowser der SSL entheelt. Also irgendeine Form von Layer Security. Und es gab dieses Icon hier, das vielleicht wie ein Gewehr oder ein Granatenpin aussieht. Aber wenn das also so aussieht, dann sah es sicher aus und das wurde dann verbessert, diesen kleinen Schloss-Icon. Jetzt ist dieses schöne, grüne Icon in der Adress-Bar. Das mögen wir alle. Also HTTPS SSL, dieses ganze Verschlüsselungszeug im Web. Das hat also eine Revolution ermöglicht, beginnend mit E-Commerce. Wir können zu dieser sehr schönen Website gehen mit Browser und Bücher kaufen. Oder dieses gebrauchte Zeug von nicht jemandem kaufen. Es war also wirklich eine Revolution. Um dies hier in Zusammenhang zu stellen, dies hier ist eine Zeichnung, die wir mal gemacht haben, wie das Internet aussieht. Es gab all diese verschiedenen Links, die all diese Protokolle verbinden. Aber um Websites auf so einen Fall zuzugreifen, handelt es sich wirklich um Punkt-zu-Punkt-Verbindungen. Entweder vom Telefon, zum Datensenter, oder vom Laptop-Computer zum Datensenter. Und es ist eine Art, direkt Informationen zu bekommen über Websites. Und dies, also HTP im Grundsatz Ursprung war ein klarer Reintext-Protokoll. Alles offene gesendet, alles offene auf dem Draht. Und nachdem dies herauskam, wollte Menschen dann in Sicherheit hinzufügen. Und dann wurde dieses Protokoll erfunden namens HTTPS. Das S soll für secure stehen. Aber, also sicher, aber es wurde ein anderes S-Wort in letzter Zeit. Also HTTPS heißt also HTTPS plus Security oder Sicherheit. Und was das heutzutage heißt, fast ausschließlich, ist Transport-Lay-Security, was ihr alle kennt, wovon ihr gehört habt. Und dies sorgt für Verschlüsselung und Integrität. Auch für Authentifizierung des Servers. Stellt sich aber, welchem Survey ihr wirklich redet. Also eine Art Sicherzustellen, mit wem ihr wirklich sprecht. Und das ist ein Talk über die schmutzigen Details. Der Teufel ist für immer im Detail. Also gehen wir ein bisschen zurück zum Anfang. SSL wurde, hieß Secure Sockets Layer. Das war das ursprüngliche Protokoll. Das Netscape erfunden hat in den frühen 90er Jahren, um das Web zu verschlüsseln. Wurde von diesen Typen KIP, ABHICMAN erfunden. Und ich habe Geschichten gehört, also Defcon 18. Da gab es eine Unterhaltung mit ihm. Das gab eine Geschichte über SSL 1, die präsentiert wurde. Und ich habe mit Philipp Harmenbaker gesprochen. Er hat die Umstände erzählt, in denen das präsentiert wurde. Marc Andreessen hat es etwa sechs Personen vorgestellt. Und die Menschen im Publikum haben es offenbar sofort durchbrochen, weil es überhaupt keine Authentifizierung gab. Das war also ein sehr vielversprechender Anfang für ein Sicherheitsprotokoll, völlig unauthentifiziert. Also, um zurückzugehen, das war, ich, ich, wer erzählen, wie SSL TLS wurde und etwas, was wir täglich nutzen. Aber es geht um zwei Teile. Das eine ist Kriptografie mit öffentlichen Schlüsseln. Das ist die Art und Weise, wie du und der Browser die Server-Intitiative sicherstellen und Session-Krise sicherstellen. Und dann haben wir Datenverpackung. Wir müssen also Daten irgendwie schicken und auch verifizieren. Also, das Herstellen des Schlüsseln, das passiert mit etwas, was sich SSL Handshake nennt, recht kompliziertes werden. Die Dinge, Stücke ausgetauscht, hin und zurück. Konstruieren wir uns zuerst auf diesen kleinen Haken da links. Das ist das Validieren des Zertifikates. Dies ist, wie TLS die Authentizität des Servers sichert. Die schöne Sache, die wir alle zusammengebaut haben, die gesunde Public Key Infrastructure. Also, habt etwas Geduld, wie funktioniert das? Es basiert auf etwas, was sich X509 Zertifikate nennt und Zertifikate sind Dateien mit verschiedenen Dingen, wie Identitätsangaben, wer du bist, einem öffentlichen Schlüssel und die sind übrigens digital unterschrieben von einer Zertifizierungsstelle. Und diese Zertifizierungsstelle hat selbst auch ein Zertifikat und offen ist dies durch eine andere Zertifizierungsstelle unterschrieben und es entsteht eine Kette des Vertrauens. Und solange du den dunkelbraunen Zertifikat dort vertrauen kannst und diese Signaturen korrekt sind, kann man sagen, okay, ja, dies ist jemand, dem ich vertraue, hat einen Zertifikatvorgesetz ausgestellt. Deswegen ist diese Website tatsächlich das, wer sie überhaupt ist, der Server. Das stellt sich also sehr einfach an. Wir überprüfen digitale Signaturen, stellen sich, dass die Metadaten dort drin korrekt sind. Ja, okay, also, wo waren wir da bloß so daneben? Schauen wir uns mal einige Details an, in denen das total kaputt war, Implementierungsfehler, aber Absichtigte, Schwachstellen und Vertrauensprobleme. Also, um es klarer zu machen, dies ist hier, was wir meinen, wenn wir Zertifikate validieren, dieser Haken im ersten Diagramm. Als Kleint passen wir das Zertifikat, finden ein Vorgänger ein Elternzertifikat und validieren das Zertifikat mit dem Öffnungsschlüssel des Elternzertifikats. Und wenn das dann, wenn das Elternzertifikat vertraut ist, und weil es in meinem Vertrauensspeicher ist, dann ist das okay und sonst wiederholt man den Vorgang, geht wieder zu dem Elternzertifikat. Das ist also, um sicherzustellen, dass ein Zertifikat korrekt ist. Aber wie ist es jetzt, was ist jetzt die Verbindung mit der Verschlüsselung? Es gibt hier zwei Wege, das in TLS zu tun, die RSA-Methode. In dieser Methode, als Klient, verschlüsselt man ein Pre-Secret mit Öffnungsschlüssel, verstickt das rüber. Und wenn dann der gleiche Schlüssel auf der anderen Seite dadurch hergestellt werden kann, haben wir eine implizierte Validierung, dass sie den korrespondierenden privaten Schlüssel haben. Diffy Hermann, sehr viel mehr empfohlen. Was hier passiert ist, es gibt einige Dinge hier. Also der Server schickt einige Parameter und man leitet daraus die geteilten Schlüssel ab und zwei Dinge hier. Also das Zertifikat validieren, das Zertifikat mit dem Kanal verbinden. Wenn jetzt irgendwas bricht, dann muss man irgendein unvertrautes Zertifikat benutzen. Also wenn die Vertrauensvalidierung schildschlägt, kann man nicht vertrauen, so würde ich das Zertifikat benutzen. Wenn die Kanalverifikation schlägt, hat jemand diesen Code gesehen, wir haben hier einige Hände, die sich melden. Das ist Code in einer Library, die sich Knutiel es nennt. Und was die jetzt tut, ist, was sie soll jetzt überprüfen, ob dies eine Zertifizierungsschelle ist. Und falls ihr zieh korrekt im Kopf hat, alles, was nicht null ist, ist true und null selbst ist false, Buhlwerte. Und was hier passiert ist, also ein Call hier, checkfca, wenn der fehlt schlägt, dann wird das Result zurückzugeben. Und dieses Result wird eine negative Zahl sein und deshalb wird der Antwort ja sein. Das ist eine Zertifizierungsschelle. Also dieser Bug sagt, also wenn wir einen ungültigen Aussteller übergeben, dann ist er nicht schlecht, sondern das ist völlig okay als Zertifizierungsschelle. Und dieser Code wurde eingeführt im Jahr 2005. Er entdeckt als Bug im Jahr 2014. Also in allen Tools, die Knutiel es für neun Jahre benutzten, war dieses Kanal, dieser Verreferitionscode war also falsch. Dies ist vielleicht etwas Bekannte, hat jemand das gesehen, das ist der Titel des Talks, nicht wahr? Der ist in Apple's Crypto Library wieder ein sehr einfacher Programmierfehler. Versehentlich gibt es hier 2-mal Go-to-Fail. Ich weiß nicht genau, wie man 2-mal Go-to-Fail schreibt, aber was ich verstehe ist, ist, dass Sie hier nicht Git verwenden für diese Library. Werden also irgendjemand sich erinnert, Merch-Probleme, vielleicht kommt man dazu, dass Sie da nicht verwenden wollten, vielleicht ist das, wie es passiert ist. Manche haben gedacht, dass es vielleicht subversiver war, aber ich habe da meine Zweifel. Also was dies tut, es wird immer hier zum Failed-Punkt gesprungen. Und das bedeutet, das wiederum bedeutet, ja, das ist alles in Ordnung. Also was man hier tun muss, ist einfach nur irgendein Zertifikat benutzen, dass das tgültig ist und irgendwelchen Unsinn als Signatur hineinstellen die die Authentifizierung völlig ungültig machten in TLS. Schauen wir uns etwas komplizierteres mal an, etwas ein wenig komplizierteres. Verschiedene Wege, in denen man digitale Signaturen implementieren kann, dies ist das üblichste für RSA, anscheinend der PCC-S Nr. 1 oder 1,5. Der ist ziemlich schrecklich. Sucht nach 001, einigen Fs und dann eine Null auf diesen Digest-Info, der sagt, was für eine Art von Hashes ist. Dies ist ein ESN-Objekt und falls jemand mit ESN 1 gearbeitet hat, das ist nicht sehr witzig. Und da ist ein Digest, ein Hasch also enthalten. Und 2006, während einer Kryptokonferenz, hat Daniel Bleichenbacher, ich hoffe, ich habe das direkt ausgesprochen, ich bin hier in Deutschland, also er hat herausgefunden oder entdeckt, dass man etwas Müll ans Ende hier schreiben kann und wenn man das tut, bekommt man dann eine gefälschte Signatur, die funktioniert und dies funktioniert, wenn man RSA mit einem öffentlichen Exponenten von 3 benutzt. Ich werde jetzt nicht zu sehr ins Detail von RSA gehen, aber wenn man das also, wenn man Signatur verifiziert, möchte man schnell sein und das ist jetzt eine Exponenzialfunktion mit Menschen neben 3, weil das unglaublich schnell ist, was man hier tun und tun muss, ist, dass die Nachricht nehmen und hoch 3 rechnen und dann wird man dadurch die Nachricht entschlüsseln. Stellt sich heraus, wenn man jetzt irgendwelchen beliebigen Müll verwenden kann, kann man einen Wert konstruieren, der bei der Hoch 3 Berechnung dann ungefähr so aussieht und dann kann man tatsächlich eine gültige Signatur machen und das funktioniert dann einfach und es sagt sich, dass es verschiedene Wurzeln gibt in den rootstores, in den vertrauenswürdigen Zertifikatsspeichern, die diesen Exponent benutzen. Das war also mal irgendwann nützlich, wenn man irgendeinen Müll ans Ende des Hashes, des Digest packen kann. Jetzt wird getestet, ob es tatsächlich keinen Müll gibt am Ende, aber es gab vor kurzem hier ist eine weitere Library, die NSS heißt eine sehr, sehr weit verbreitete Library von Mozilla entwickelt um die ganze Crypto in Firefox zu machen, auch in Chrome damals benutzt in frühen Zeiten. Aber es gab tatsächlich einen weiteren Coding Fehler hier in diesem Digest Info. Ich habe schon erzählt, das ist ASN1, ASN1, dass ein Format ist, um verrücktes Format zu inkludieren. Es gibt zwei Formate innerhalb von ASN1 BER, das sind also Basic Encoding Bills verschiedene Wege hier, um Daten zu inkludieren. Man kann extra Nullen hinschreiben, man kann verschiedene die Längeninformationen sind, man kann verschiedene Längenwerte hier haben und das gibt ja ein Integer Overflow in der ASN1 Länge, dass man natürlich Müll hier in die Länge hinein tun und dann mehrere Multibit Längenwerte haben und dadurch wird dann der Müll einfach übersprungen und wie im frühen Angriff jetzt kann man was konstruieren eine Nachricht, die mit Hochdrei sich in so etwas verwandelt und dann einfach immer wieder Hochdrei versuchen und mein Kollege hat die jetzt auf GitHub veröffentlicht, wenn ihr das ausnutzen wollt das sieht dann seltsam aus. Das ist nicht der übliche Anblick an der digitalen Signatur. Es gibt noch mal ziemlich viele Entropiesen lauter Nullen und wenn man das also hochdrechnet bekommt man tatsächlich etwas was so aussieht und dies wurde tatsächlich von Firefox als vertrauenswürdig erkannt für eine Weile. Es gibt also interessante Wege subtile Wege wie man das Vertrauen brechen kann dass man mit TLS bekommt aber wenn wir von diesen Problemen sprechen und der Papikierinfrastructure man muss nicht unbedingt etwas ein Back oder Schwachstelle finden hier ist ein Quiz für alle in euren Browsern zu Hause oder euren Betriebssystemen was immer ihr nutzt wenn ihr nicht paranoid seid und alles entfernt habt wie viele Länder haben Kontrolle über Zertifizierungstellen die bei euch vertrauenswürdig sind und unterschreiben können dass Vertrauenswürdig ist ratet mal zu viele ja, das ist wahr es sind 46 tatsächlich von dem FSL Observatory der Electronic Frontier Foundation 46 Länder in der Welt könnten tatsächlich beliebig Zertifikate herstellen für eure Website eine Website und das ist irgendwie ein bisschen verrückt wie vertraut man wirklich dass das immer vertrauenswürdig herausgegeben wurde also das sind Stellen aber die tatsächlich alles mögliche erstellen können und dies ist vorher herausgekommen in diesem Jahr und im Vorigen aber ein tatsächlich verbreitetes epidemisches Problem Leute schauen sich suchen nach schlechten Dingen versuchen viele versuchen Ads Werbung einzuschleusen und Superfisch ist eine Software die seine eigene vertrauenswürdige Wurzel-CA installiert hat und jeder Browser dann vertraute dieser Lenovo Wurzel-CA und verschiedene Dinge wurden dann installiert aber es passiert immer ob es nun die IT Abteilung eurer Firma ist Entivierenssoftware Superfisch, was eben über den Hardwarehersteller Lenovo oder tatsächlich Länder die sagen dass sie ein Inspezier-Proxy auf dem ganzen Land inspirieren wollen sie wollen also auch in ganzen Traffic-Entschlüsseln dann weitermachen und die werden tatsächlich ohne Fleisch spontan jede Zertifikat fälschen das demn du vertraust das ist also in sich schon schlecht aber es zeigt sich auch, dass einige dieser Proxys in sich Zertifikate nicht validieren also diejenigen die sie selbst bekommen also wenn man diese Sachen manipulieren möchte die nicht deinem Proxy sind möchte man also jetzt kann jetzt jeder ein Fake-Zertifikat also Forschung über Superfisch hat das herausgefunden nicht nur hat man hier also Werbung die eingeschläust wird in den angeblich verschlüsselten Strom jeder außen kann also jetzt Webseits fälschen extra Bonus hier wenn man hier Roots Roots-CRs in eure Vertrauensspeicher installiert dann werden Browser typischerweise diese so werden dann so Techniken wie Key-Painting nicht mehr benutzt der Browser testet dann nicht mehr das Key-Painting wenn ein Zertifikat gesehen wird dass von einer dieser extra Roots die manuell hinzugefügt werden signiert sind also Key-Painting funktioniert da nicht mehr Ups, schon wieder also Vertrauen ist schwer und es gibt eine Menge verschiedene Wege wie man wie das gebrochen wird durch schlechten Code schlechte Infrastruktur bis hin zu schlechten politischen Organisationen schlechte Politik wird darüber wer Zugriff bekommen sollte auf diese Schlüssel wenn wir uns jetzt mal tiefer ansehen die verschiedenen Bibliotheken die Krypto durchführen also wie ich schon bemerkt habe die meisten davon wurden definitiv affektiert von diesen Problemen im letzten Jahrzehnt und also das sind es die Client-Probleme es reden immer über die Geschichten auf den Servern also nun mal zum Zusammenfassen also die meisten Webseiten benutzen Archie, Microsoft ESS, EngineX IIS Verzeihung EngineX oder zum Beispiel der Internegramm von Google und die meisten davon benutzen OpenSSL und davon habt ihr bestimmt schon einiges gehört aber darüber geht es gleich früher dieses Jahrzehnt oder früher letztes Jahrzehnt tatsächlich gab es eine weitere Bibliothek die sehr sehr verweite war von WSafe Verzeihung eine der ersten robusten SSL-Implementationen und diese ganze Kryptografie diese ganzen Kryptofildinger die ich bemerkt habe die brauchen zufällige Zahlen um diese Keys zu erstellen und ich weiß nicht ob ihr davon gehört habt aber was und ich habt ihr das zweifache ECD-RBG es stellt sich heraus es gibt einen Zufallszahlengeneraten von der NSA dazu dafür modifiziert worden ist der praktisch garantiert dass eine Hintertür existiert das heißt wenn deinen Zufallszahlen dein System schlecht sind dann kann man davon zurückarbeiten und dann einen Strom entschlüsseln und selbst in den letzten Wochen kamen immer wieder wieder wieder heraus wie zum Beispiel Juniper Betriebssystem die diesen Dual ECD-RBG eben hatten nur die Parameter zu Sachen geändert die die NSA nicht wusste aber wer weiß ob sie die nicht auch wussten also Zufälligkeit ist also auch eine Schwachstelle des Systems Hartbleed es war letztes Jahr eine große Sache eigentlich es stellt sich heraus dass es auch nur ein weiterer dummer Bug in C ist nur ein drüber lesen über einen String worüber dann Informationen über den Server veröffentlicht wird das her war ziemlich schlecht weil es gibt ein anderes Architekturproblem in TLS-Server und zwar dass deine privaten Schlüssel im selben Speicherbereich also wie alles andere gespeichert sind und wenn man mal drüber denkt wie Leute die Sicherheitssysteme konfigurieren dann ist das etwas absurd weil die am weitesten verbreiteten oder veröffentlichen Systeme sind dann in seinem Speicherbereich die privaten Schlüssel und Hartbleed hat das eben veröffentlicht also so ziemlich alles benutzt OpenSSL und OpenSSL hatte das eben auch für einige Versionen also Implementationsfehler sind spaßig Leute versauen es ab und zu mal ihren Code zu schreiben es gibt Methoden das zu beheben oder zu finden und dieser Talk ist über TLS dass sie die schwer korrekt zu implementieren aber was ist denn mit dem Protokoll selbst es stellt sich raus dass das eine Katastrophale ein paar katastrophale Jahre war für das Protokoll das hier ist die Zeitlinie von TLS und SSL-Versionen also da haben wir 1984 da wissen wir nicht genau aber 1994 raus dann gab es wir so in 398 denn dann die ITA ihre Händerenkel hat ein neues Protokoll rausgegeben TLS-Version 1 wenn man die Bits und Bytes ansieht dann ist es SSL 3.1 also das ist nicht viel Anlass geworden eigentlich ist es eine stärkere Definition von Mustern aber sonst hat sich nicht viel verändert dann 2006 gab es TLS 1.1 die nicht viele Sachen geändert hat hat nur gemacht das im CBC-Mod doch wie ist da spreche ich später noch für dann gibt es noch 1.2 1.3 kommt dann so nächstes Jahr ja es sieht danach aus es würde nicht wirklich was passieren mit diesen Protokollen die erscheinen alle ähnlich aber in der Zwischenzeit haben Leute HTTP entwickelt oder weiterentwickelt und wie das Web benutzt wird das hat sich weiterentwickelt 1994 waren Webseiten einfach die sehr statische Geschichte ohne Cookies und Javascript und diese ganzen großartigen Belsen-Whistles Verschnörkelungen aber es stellt sich raus dass HTTP ist super großartig für kryptologische Angriffe wenn du wenn du wiederholte Klartext Angriffe machen kannst du brauchst nur einfach man in the middle Zugriff und als Angreifer ist das ungefähr so wie man das macht also du bist in einem lokalen Netzwerk mit jemandem und dann kannst du Arps-Boofing benutzen oder eine andere Art und Weise um man in the middle zu werden und dann kannst du einfach zufälliges Javascript einfügen und mit diesem Javascript kannst du dem Browser dazu bringen Anfragen zu schicken und in HTTPS gibt es einige Sachen mit Origin Policies, die verhindern dass man viele böse Sachen machen aber du kannst eine Sache einfügen um dann Anfragen an andere zu schicken und die Art und Weise wie Cookies funktionieren ist, dass sie immer gesendet werden selbst wenn der Server diesen Schutz aktiviert hat und dann kannst du trotzdem Cookies Anfragen schicken und es stellt sich raus dass wenn du Fehler in TLS auslösen kannst also der Browser das nochmal senden das heißt also Passwörter du kannst da alles in die URL reinstecken und du kannst das total weitaus von unpraktisch Klartextangriffe mit vorausgesuchten Klartext auszuwürfen dann gibt es Kompressionsoracke die benutzt werden um praktisch Stück für Stück Verschlüsselungsoptionen herauszugeben HTTP ist komprimiert um Platz zu sparen wir benutzen dafür zum Beispiel GZIP wie ein Kompressionsalarm der Dictionary basiert ist und wenn du zwei wiederholte Strings habt dann wird das kürzer sein als wenn du nicht zwei wiederholte Strings hast und das stellt sich raus das ist tatsächlich genug um eine gesamte Session zu entschlüsseln so was wie das hier haben kannst dann kannst du einfach immer wieder Anfragen schicken und in der Mitte kannst du einfach die Pakete umordnen und du kannst diese Anfragen mit Geheimdaten einfach weiter schicken und du kannst nicht die Sachen im Browser schicken aber du siehst einfach die verschlüsselten Daten und dann tatsächlich gibt es Crime and Breach die als praktische Implementierungen von Kompressionsorakeln also tatsächlich praktischerweise funktioniert das so du suchst deinen Padding aus dein Puffer links und rechts und das ist im Endeffekt irgendwas in dem Query String das heißt den kannst du komplett erst bestimmen und du wirst den Cookie raten und du wiederholst einfach nur die Ratschläge solange wirst du der Cookie wie dein Rat und wenn du das machst dann ist die Nachricht die Gesendete plötzlich sehr klein und wenn du das mal anguckst und das heißt angeblich, also wir versuchen jetzt einfach mal ein Bite pro Stück ein Bite pro Anfrage zu raten und wenn wir dann eben falsch geraten haben dann haben wir eine sehr lange Nachricht und wenn wir einen gut geraten haben dann haben wir plötzlich nur 4 komprimierte Blocks also wir haben weniger eins nach dem anderen unsere Werte in diesem Code entschlüsseln und das ist tatsächlich eine praktische Angriff der durchgeführt worden ist also Crime geht um TLS Komprimissung und nach dem Crime passiert ist haben alle TLS Komprimierung ausgeschaltet dann Breach geht über HTDP Komprimierung das hat niemand abgestellt aus Performance Gründen und deswegen ist es ein blieber Angriff auf viele, viele Webseiten was natürlich schlecht ist aber Komprimierung ist nicht die einzige Art und Weise wie man Oracle haben kann es gibt auch noch Puffer also Puffer oracle sind eine etwas ältere Idee die schon von Wardney 2002 beschrieben worden sind und die verlassen sich auf sehr, sehr schlechte Wartenweisen wie TLS implementiert worden und dann gibt es den Mac dann Encrypt Construction also wenn ich mir mal ansehe Block Ciphers die brauchen eine bestimmte Anzahl an Daten Blocks die da reingehen und die selbe Anzahl an Blocks kommt raus also zum Beispiel AES gibt es zum Beispiel die 16 bytes gehen rein und dann 16 bytes kommen auch wieder raus also das habt ihr bestimmt alle schon gesehen den ECB Penguin das das klassische Beispiel warum Block Chaining ist wichtig also wenn du die Blocks einfach nur so hast und die eben nicht aneinander kettest dann siehst du eben Daten mit sehr, sehr weniger Entropie du siehst diese gleichen 16 byte Blocks immer hintereinander und hintereinander und damit kannst du diese Bilder tatsächlich auch rausziehen und ansehen und deswegen ist es wichtig diese Blocks ineinander zu X Ohren und das dann erst zu verschlüsseln wir haben hier relativ viel Zufälligkeit und die Entschlüsselung passiert praktisch auf die gleiche Art und Weise du nimmst einfach diesen Vektor und ein X Ohr zudem das immer in deinen entschlüsselten Block und du kannst bis da unten und das ist CBC Mode das sieht gut aus, denken wir das ist eine gute Art und Weise Krypto und zu kombiniert also zumindest haben wir das in den 90ern so gedacht eine andere Art und Weise ist wenn wir Integrität und Verschlüsselung brauchen, was machen wir zuerst also zuerst Verschlüsselung, dann Integrität oder zuerst Integrität, dann Verschlüsselung ziemlich katastrophal in der Weise haben sie sich gedacht zuerst Integrität, dann Verschlüsselung und TLS sieht zum Beispiel so aus es gibt es erst Daten und dann HMAC und dann noch ein Puffer und die Daten selbst eben das ist alles noch aufgepuffert auf 16-byte Grenzwerte für IAS und bis zu diesen 16-byte Boundaries ist es dann eben und das wird dann eben verschlüsselt also nachdem dieser Puffer hinzugefügt wird und in dieser Daten das ist eben den Header und die Sequenznummer und das gibt dir Daten, die authentifiziert und dann verschlüsselt sind aber dieses Padding ist nicht authentifiziert was natürlich eine kritische Fehler in dem Ganzen ist also TLS oder SSL wie sieht dieses Padding aus der Abschlussbyte ist die Nummer also die Anzahl der Bytes, die noch gepadding werden und dann einfach nur noch ein paar Nullen also du kannst mit Null abschließen und dann noch Nullbytes weiter haben oder du kannst und in TLS haben wir das abgedeht dass diese Padding also diese Pufferbytes auch tatsächlich den gleichen Wert haben müssten wie das Abschlussbyte also das heißt nur wenn wir unorthofenste Daten haben dann bekommen wir damit automatisch schon ein Pufferurakel das heißt wenn ein Antengreifer zwischen dem Pufferwert den Pufferwert erraten kann dann reicht das schon aus um die gesamte Nachricht zu entschlüsseln und wie das funktioniert ist wenn du in einem Manager-Mittel bist und du kannst das letzte Byte Daten erraten oder möchtest das dann modifizierst du das vorige Cybert Ciphertext Package und dann mit deinem Rad und dann hast du plötzlich M kommt raus und das ist eben der Puffer und wenn du weißt dass der Puffer richtig ist und wenn du unterscheiden kannst ob er korrekt ist oder incorrect dann also zum Beispiel hier hast du hier ein richtiges Padding dann siehst du dass dein XOR falsch ist du kannst jetzt damit rückwärts arbeiten mit dieser XOR-Logik um dann herauszufinden was dein Wert A ist und sobald du A hast kannst du dann weiter rückwärts arbeiten um dann den Wert B herauszufinden und alles was du da tun musst um als Angreifer herauszufinden ob du in Fall 1 oder Fall 2 bist ist dieses Pufferurakel tatsächlich in das Protokoll eingebaut das war die originale Angreifer früher also du konntest herausfinden ob das Padding falsch war, der Puffer falsch war oder der Code falsch war du musst es nur alle 256 Werte für X ausprobieren und sobald du richtig ausprobiert hast gibt es dir den Fehlercode oh Fehlerhaftes Haarmack also du hast das Padding überwunden und du hast tatsächlich einen Byte dieses Problem kommt immer wieder zurück es gibt ganz viele Wege auf die Side-Channel Angreifer stattfinden können also der Fehlercode Side-Channel zum Beispiel ist Fehlerhafter Falsches Padding richtige Rad dann gibt es noch den Timing Side-Channel es zeigt sich wer man falsch geraten hat dann gibt es hier schnell, wenn man keinen Haarmack berechnen kann es ist langsam, wenn man tatsächlich das Padding richtigen kriegt man schaut einfach an wie lange es da dauert bis diese Berechnung fertig ist und voller du hast ein weiteres Padding-Orakel du musst es ein paar mal probieren um Timing Jitters zu entfernen also man kann hier im Kontext von HTTP hat man hier das Passwort herausgefunden das ist alles schön und gut aber wie gesagt die Leute die Dinge kommen immer wieder zurück Patterson veröffentlichte Lucky 13 vor 2 Jahren das verlässt sich auf eine wirklich seltsame Tatsache über die Tatsache wie Haarmack tatsächlich berechnet wird wie gesagt mit Haarmack kann man diese 8 bei Sequenznummer und dann die Daten und die Lösung für diesen Timing-Angriff wenn das Padding falsch ist dann hört man Haarmack über die ganze Nachricht und es zeigt sich da den meisten Haarmack-Implementierungen ein glückliches Byte existiert ein Punkt in dem der Haarmack länger braucht als vorher verschiedene Kompromierungsfunktionen sind hier drin und wenn man 45 Bytes hat ist es schneller als 65 oder 57 das ist ja eine gesamte 64-Bit Nachricht also 4 IS-Blocke was man versuchen kann ist nun heraus zu erraten wie das Padding ist wenn man das falsch ist wird es ein Slown-Hersch geben wenn man glücklich gehört hat und die letzten 2 Bytes das Padding korrekt erhält dann wird es schnell und voila man hat 2 Schritte gemacht zu seinem Oracle Attack und kann das den ganzen Weg nach unten verfolgen also das ist jetzt vor ein paar Jahren in Amazon eine neue Implementierung S2n meine neue TLS Implementierung von Anfang an vom Nullpunkt aus erstellt was kann hier nur schief gehen und die hatten das Problem und hier habt ihr ein Graf der hier erstellt worden ist der ist in Ghost Crypto Library geschrieben also der Autor hat als Kommentar geschrieben es gibt wahrscheinlich ein Timing-Zeit-Problem diesen Hamek ja und der hatte recht ja da war einer und das war Lucky 13 eine wirklich subtile Sache wieder die man in den 90er Jahren nicht vorausgesagt hätte die jetzt zurückkommt was man für TLS für TLS 1.0 und 1.2 war dies die einzige Art und Weise Block Ciphers zu benutzen im CBC Modus wenn man also nicht beide Servers mit TLS 1.2 hat ist man aufgeschmissen und dies ist eine weitere Idee der Downgrade Attack die Philosophie hier ist wenn man etwas altes unterstützt dann wird irgendjemand euch da hinein dazu bringen das auch zu benutzen es gibt Möglichkeiten sich dagegen zu verteidigen aber es ist wirklich schwierig das richtig hinzukriegen ein bisschen Hintergrund die sind hier Cyphersweets SSL braucht all diese Alphabet-Suppe hier um zu entschieden dann entscheiden welche Crypto-Eugrub man benutzt um es hier mal auseinanderzunehmen hier haben einen Schlüsselaustausch z.B. Hartschlüssel, Transportverschlüsselung und Integritätsfunktion und der Server bekommt eine Liste vom Klein und sucht sich davon den Favoriten seinen Favoriten aus wählt ihn aus und wenn irgendjemand drüben in dem anderen Saal war für den vorigen Talk dann wisst ihr, dass es so etwas gibt wie Export-Cyphers die lange Zeit unterstützt wurden um mit diesen antikwerten das 90er Crypto-Export-Regeln der USA übereinzustimmen und das waren sehr schlechte Algorithmen also bis hin zu diesem Jahr gibt es Server und die Tatsache der Server immer, dass den besten Algorithmus auswählt dadurch ist jeder sicher oder der Server nimmt immer den besten aber nein, zeigt sich, das ist nicht so dies hier sind mehrere Angriffe die in dem letzten Talk beschrieben wurden in denen man am Ende klein zu den Servers das zwingen kann diese wirklich schlechten, schrottigen Cryptografie-Agrippen zu nutzen und das geht zurück auf das einzige was im Handcheck ist, ist diese Schlüssel-Ableitungsgeschichte also das was man benutzt um den gemeinsamen Schlüssel abzuleiten und dies hier ist Freak wenn ihr in der Mitte sitzt, der Klein sagt hey, diesen ist mein Syphus, ich unterstütze du endest das einfach in okay, nein, ich unterstütze nur Export und deshalb sagt okay, ja, ich unterstütze Export okay, dann nutzt man das, du musst ein alter Klein sein und alles was ich dann tun muss ist diesen Export-Schlüssel schnacken, 40 Bits und okay, alles klar, von da aus weiter und in einigen Fällen muss man 512-Bit RSA-Schlüssel schnacken, was möglich ist und LogJam funktioniert auf eine sehr ähnliche Weise dies arbeitet mit RSA, Syphus Suit und hier mit Defi-Harmen und er bezieht sich darauf, dass man den kleinen Server zwingen kann diesen Defi-Harmen die Parameter schützen, für den Schlüssel aus der Schwache ist ein alter, kleine Schlüsselgrößen und dann knackt man das und als Mein in the Middle kann man dann manipulieren und alles lesen welcher Schwach ist die Ages, das Gleiche schützt sich darauf, dass einige Server Defi-Harmen Parameter schützen die verbrechnet sind und man kann also 3 Vittel deswegen ist es zum Angriff abkürzen weil die alten Selben Apache anfangend benutzen das bezieht sich also auf unartifizierten Protokoll Handshake da kommen wir noch zu mehr zu dann hier das Thema von Downgrade Attacks wieder Pudel dies ist also der Nagel im Sack für SSL 3 man kann diese Sachen wie diesen diesen Downgrade Dance machen Browser zwingen herunterzuhandeln von SS Frontiers 3 zu 1,1 zu 1,0 dann zu SSL 3 und wie vorher gesagt das Padding in SSL 3 ist nur eine Haufen von X und dann eine Zahl und man kann irgendwas einfügen und der letzte Block hat vielleicht dann nur ein relevantes Datenbitz kann also ein Padding Attack ein Padding Angriff ausführen und wenn Leute darauf kamen dann schien das so offensichtlich ist völlig kaputt TLS Pudel zeigt sich ich habe gesagt es gab eine Änderung zwischen SSL und TLS 1 eine Hauptänderung ist, dass das Padding definiert war als Wiederholung des gleichen Paddingwertes insgesamt haben Server das nicht getan Server haben sich nicht daran gehalten und man kann immer noch denselben Angriff und es gibt immer noch Server die verwirrende sind für TLS Pudel weiteres Problem für TLS alternde Krypto es geht ihm immer noch gut aber das war jetzt in den Nachrichten mit verschiedenen Signatur-Algorithmen die auf Herrschfunktion sich beziehen hier beim CCC im Jahr 2008 präsentiert einige Forscher waren in der Lage einen Zertifikat zu fälschen aus einem anderen, indem sie eine Kollision in der Herrschfunktion die in der Signaturverbindung zu finden die Details sind ein bisschen kompliziert aber sie konnten sich also als vertrautes Zertifikat aufsetzen und alles manipulieren eine alte Herrschfunktion MD5 musste aus allem rausgeschmissen werden also wie ist die Zeitleiste für all diese Angriffe hier ist SSL 3 hier sind die Angriffe die ich erwähnt habe und sie konzentrieren sich tatsächlich auf die Zeit nach TLS 1-2 Beast habe ich nicht behandelt die ist das erste von den Backronem Angriffen ich habe vergessen wie es genau war, also Browser irgendwie irgendwie man nimmt ein schönes Wort und dann hat man eine Abkürzung mit Beast Heartbleed das war diese Sache mit dem Logo der Trend mit den Logos seitdem hat jeder eingefallen Logo es gibt eine wirklich große Konzentration in den letzten 3-4 Jahren also wie gesagt das war 2008 2012 benutzt es niemand dies ist von SSL Parts sogar 2014 SSL 3 ist immer noch fast universell unterstützt, jetzt sind wir in einer besseren Lage aber es dauert sehr sehr lange für Server sich zu aktualisieren gleiche Sache mit Clients jetzt sehen wir 70 75% von Verbindungen haben TLS 1-2 das ist großartig aber TLS 1-2 löst die meisten diese Probleme aber die meisten Browser sind in den Jahren 2003, 2004 herausgekommen also jetzt haben wir hier mindestens 5 Jahre später es dauert also eine Weile bis die Dinge aktualisiert werden das ist also ein übles Bild eigentlich ein dunkles, düsteres Bild was ja gezeichnet wird für diese Verundbarkeiten zumindest wir können hier ein paar Dinge lernen und eine ist wenn ein Angreifer allen Bit-Informationen identifizieren kann im plaintext dann ist es eigentlich schon vorbei die Art und Weise wie STTP arbeitet man kann Sachen wiederholz senden und dieses einen Bit ausdehnen auf die gesamte Nachricht es gibt Seitenkanäle überall Timing, Berechnungen es gibt Forschung über Seitenkanäle im Cloud Computing wenn man hier Cache Timing also einen Prozess und Krypton im anderen Prozess und man kann herausfinden wie lange diese Dinge brauchen das ist sehr, sehr gefährlich all diese ganzen Dinge die ich erwähnt habe haben Oracle die sich auf unertifizierte Daten stützen und unertifizierte Daten MacFirst, then Encrypt sogar Padding, Padding ist unglaublich wichtig und das zu überprüfen ist unglaublich schwer wie sich zeigt wir haben es so oft falsch gemacht AEADs also Authenticated Encryption with Additional Data Authentifizierverschlüsselung mit Zusatzdaten das ist etwas mit TLS12 eingeführt wurde wir sollten definitiv das benutzen und CBC vergessen fallen lassen CBC ist wirklich schwieriger und kaputte Konstruktion hat uns gut gedient für eine Weile aber es gibt viele Wege das anzugreifen in der Zukunft X509 die Struktur für Zertifikaten die ASN1 das ist wirklich sehr schwer, das korrekt zu implementieren es sind mindestens neun Jahre älter als SSL selbst diese Protokolle und sie werden euch Probleme verursachen und Downgrade Angriffe also wenn man unsicherere Kryptoprotokollen unterstützt dann ist es euer eigenes Risiko denn Leute werden in der Lage sein euch herunterzustufen auf diese Protokolle ich habe hier einiges übersprungen es gab Tonnen Tonnen weitere Probleme hier ASN encryption oracle es gab ein execution bug Triple Handshake Remote Execution Remote Code Execution das ganze Zertifikatsstellen Ökosystem ist völlig in Unordnung da habe ich überhaupt nichts zu gesagt RC4 Schwächen also wir haben diesen Stream Cipher Patterson hat zur selben Zeit die Lucky 13 herausgefunden dass man den gesamten TLS Stream entschlüsselt wenn man RC4 benutzt es gibt Schwachstellen in Bignum Libraries es gibt Forward Secrecy TLS ist absolut geladen mit Problemen, alles von der Implementierung bis zu den Protokollen selbst also gerade genügend Komplexität um mit sich selbst aufzuhängen ich würde nur sagen das ist das Ende aber nur noch eine Sache ich würde gerne als Gedankexperiment noch etwas anderes anderer Angriffe noch behandeln die wir gesehen haben vorher also es gibt diese anderen negotiation Angriffe mit TLS also wir haben zum Beispiel über Freak gesprochen und Logjam welche Defi-Hamming-Gruppe nehmen wir oder welchen Schieferen nutzen wir und es gibt noch andere Verhandlungen die da behasten, zum Beispiel NPN und AIPN das sind Protokolle die aufwahrt die ATP2 abgrafen können und dann auch die Frage welche eliptischen Kurven unterstütze ich das ist tatsächlich sehr interessant TLS unterstützt nämlich eine Tonne verrückter eliptischer Kurven was zum Beispiel wenn wir eine Downgrade Angriff darüber fahren haben wir, finden wir eine neue Schwachstelle Miss Curve Swap das ist das selbe Model wie Freak oder Logjam was wir machen ist wenn wir als Männer in der Mitte sind dann nehmen wir die unterstützenden Schieferen und wir tauschen sie aus mit den schwächsten und kleinsten möglichsten Kurven aus die beide Parteien noch unterstützen wir stellen sicher dass eine eliptische Kurve eine Schlüsselaustausch und beide Parteien nehmen also diesen kleinere Kurven um ihre Schlüssel zu errechnen und wir wissen noch nicht genau wie wir das lösen können aber hört mal weiter zu das ist noch etwas was wir noch nicht jetzt in diesem Augenblick können aber bei ganz kleinen Kurven könnte das möglich sein also bevor wir da jetzt mal das weiter anschauen ist, lass uns mal über nachdenken dass wir diese Kurven eigentlich unterstützt werden es gibt zum Beispiel eine Gruppe von Kurven, die heißt Secti also 163-Bit Kurven es ist eine binäre Kurve das heißt nicht die Art Kurve die wir normalerweise benutzen aber als eliptische Kurve normalerweise standardisiert worden sind da hatten wir dann Primzahlen Kurven und Binär Kurven und die beide ungefähr equivalent waren wenn wir mal die Daten anschauen und ich habe mal eine Umfrage gemacht 4.3% aller Klienten unterstützen diese schwache Kurve und das ist ungefähr so stark wie RSA 1024 sagen wir mal so selbst wenn wir eine Verhandlung durchführen und erwarten dass wir eine starke starke Kurve erwarten, wie zum Beispiel der 255-Bit wäre so ein Zepstand der Männermittel euch runterfahren auf diese kleine nette Kurve und als Angreifer kann man dann den diskretten Logismus von dieser Kurve knacken dann haben wir 4.3% der Alexa Top 100 Seiten geknackt weil wir sie beide dazu bringen können diese sehr schlechte Kurve zu benutzen um den Schlüssel auszutauen also was war es ja natürlich schon euer Gekicher Gekicher angedockt, noch niemand hat der DLP-Kurven für diese Größe geknackt, also das größte was geknackt worden ist bisher sind 110-Wit ungefähr aber es gibt einen Grund warum wir binäre Kurven nicht mehr benutzen sie sind aus der Mode gekommen es gibt Index Berechnungstechniken die angeblich besser sind als Brute Forcing also die Leute sehen sie als schwach an und wir wissen noch nicht genau was für Forschung heimlich gemacht worden sind über diese binären Kurven aber ja die gute Nachricht ist dass in TLS 1.3 der neue Standard wurden alle diese Kurven rausgeworfen also viele dieser Bugs wurden entfernt aus dem Protokoll aber es war ein langer steiniger Weg für TLS und das war's Okay, let's start at number one please Hi, Frage Könntest du etwas sagen über Cloudflash Strategie um SHA nicht nicht abzuschaffen? Liebend gern also genau wie alle dieser Protokolle oder Kryptografie Arten die kaputt sind oder alt sobald sie definitiv kaputt oder alt sind sollten wir sie komplett wegwerfen also es gibt einen Plan SHA 1 zu verwerfen Anfang 2017 also Ende nächstes Jahr und dass die Zeitfenster in dem das passieren soll ist noch debattierbar und es gibt die Frage ist sollten wir oder sollten wir nicht SHA 1 als etwas als eine Bedrohung dem nächsten Jahr passieren könnte ansehen oder nicht oder eher als eine Bedrohung die es in den nächsten fünf Jahren wirklich akut wird also ob wir oder ob wir nicht SHA 1-Zertifikate ausgeben sollten dass die Frage die das ist eine große eine große Diskussion die gerade passiert hallo aber wenn das nun vergleicht mit MD5 wir haben also jetzt hier Kollisionen vor dem Start ja es hat zwei Jahre gedauert ja so eine Sache die man auf jeden Fall im Hinterkopf behalten sollte bei dieser Sache ist also ich kann die Folie nochmal anzeigen über die MD5-Kollision also die Sache dass wir eine Kollision in SHA 1 haben das ist noch nicht genug um einen Zertifikat zu färschen also was wir da bräuchten ist wir müssten trotzdem den die Zertifikatsautidiretate zu bringen eine entsprechende Zertifikat vorher zu sagen und dann genau das sollte genau sich auf jeden Fall alleine mit dem Zertifikat das verfärschen wollen und tatsächlich also Zufälligkeit und Entropie helfen uns da irgendwie ein bisschen also ja es gibt eine Kollision und es könnte sein dass wir in einigen Monaten schon die erste Kollision sehen aber trotzdem ist es noch eine andere Geschichte ob wir das cracken können Internet bitte werden wir jetzt in einer besseren Situation wenn SHA TTP das Reden vor HTTPS gewonnen hätte und warum gehen wir nicht über so etwas wie SPKI oder SDS SPKI also also jetzt auch mal wir kontrollieren einen Teil dieser Gleichung und also wie bei jedem Sicherheitsprotokoll müssen wir voll den Client als auch den Server dazu bringen zu einigen was sie benutzen und die Evolution des gesamten Marks welchen Algorithmen oder welchen Protokollen wir benutzen also jedenfalls HTTPS hat da gewonnen über Langzeit weil das einfach am meisten entwickelt und genau wie all diese Geschichten der Gewinner nimmt dann alles mit Geschichte Nummer 3 bitte ja hi wir haben offensichtlich richtig scheiße bei implementieren und und es wird immer wieder Rechen geben also aktualisieren von Browsern ist schwierig man muss wesentlichen, ich muss ein AVM-Schnapshot machen vor einem Upgrade weil es sonst schwierig ist warum gehen nicht Browsers die gehen weg von GNUD-PG also ein völlig separates Stück Software wo die Kommunikation überstandet imstande auch passiert und das separat aktualisiert werden kann ok die Frage ist können wir TLS nicht aus dem Browser heraus lösen und woanders implementieren also eine der interessantesten Dinge die im Ökosystem von TLS und HTTPS passieren ist dass viele Browser das tatsächlich machen für die Zertifikatvalidierung also in das Betriebssystem selber lösen die das raus Firefox zum Beispiel hat den ganzen PKI-Stapel stack rausgelöst also ich glaube es gibt historische Gründe echt ernsthaft warum also Chrome und Firefox updaten sich automatisch und sie tun das deswegen weil sie sich sicher sein wollen dass sie die neuesten und großartigsten Sachen haben und die Strategie dass wenn dein Browser sich upgraded und dann kaputt geht dann hast du Pech gehabt das ist so deren Strategie und ich bin kein Browser Verkäufer und brauche ein Browser Hersteller ich arbeite also auch nicht für diese Firmen deswegen kann ich auch also wirklich nicht sagen warum sie Sachen machen oder nicht Nummer 2 Danke Du hast erwähnt in diesen Abwehr und Tiefen Zugang Ich weiß das Cloudflash Schlüsseloses SSL anbietet was ich mag aber ist es nicht vielleicht nicht nur ein Geschäftsvorteil für euch sondern auch ein realistisches Sicherheitsmarschnahme für vieles selber dass der private Schüssel irgendwo hinausgelagert in ein extra layer ausgelagert wird Ja ich glaube dass das eine Sache ist die definitiv weiter anwendbar ist und es ist auch was was die letzten IETF treffen war ein Vorschlag mit Private Key Operationen von TLS rauszulösen und das wurde aufgebaut als RFC beim IETF und ich definitiv schaute das an Signal Angel bitte Franky zwar möchte wissen ob IP Version 6 Verschlüsselung TLS ablösen könnte oder einiges das Problem wirklich abmeldern könnte IPv6 Verschlüsselung Ja also ich glaube ich sehe das nicht als Ersatz für TLS ich sehe verschiedene Schichten der Verschlüsselung also ob es jetzt TCP Verschlüsselung oder irgendwo weiter unten in der Schicht ist als zusätzlich Verteidigung gegen Angriffe also die gute Sache wie über TLS ist, dass es Sachen einkapselt in HTTP Nachrichten, das heißt das ist eine Punkt zu Punkt es erlaubt dir den Server direkt zu vertrauen dagegen Verschlüsselung auf niedrigeren Eberen das ist großartig und das ist super wir haben Verschlüsselung auf vielen verschiedenen Protokollen WLAN ist verschlüsselt 3G, 4G Signale sind verschlüsselt mehr Verschlüsselung ist besser und ich glaube nicht, dass eine Verschlüsselung in einer niedrigeren Eberen Ebene einen daran hindern sollte Verschlüsselung in einer höheren Ebene hinzuzufügen also du hast gezeigt wie langsam der TLS Standards sich weiterentwickelt und wie noch langsamer die Adoption und die Anerkennung ist und das heißt die Frage ist Stimmst du zu, dass wir stark investieren sollten in den Standards dass diese Standards einfacher anwendbar und einführbar sind und habt ihr dafür konkrete Pläne und Vorschläge wie das erreicht werden könnte ich habe keine konkreten Pläne und Vorschläge über diese ich finde das eine gute Idee und ich denke, dass hohe Upgradebarkeit eine der schwierigsten Probleme ist bei diesen Protokollen weil wir haben gesehen, in all diesen verschiedenen Versionen gab es Probleme und sie mussten auf verschiedene Artenweise behoben werden und zum Beispiel das Internet der Dinge, ein Buzzword über das wir alles brechen das sind Embedded Devices die haben eine Kopie eines Protokolls und es ist ein niedrig Firmware dazu zu bringen einen guten Upgradezyklus zu haben da habe ich also keine Lösung davon aber ich sehe das als eine der größten Probleme Protokolle die potenziell unsicher zu sind zu verwenden Nummer 6 bitte Hi, danke für diese Erinnerungen hier irgendeine Idee wie es bei finalisiert sein wird und wenn ich es endlich am Handbrave Server aktivieren kann noch nicht ich habe noch kein konkretes Datum dazu es sollte innerhalb des nächsten Jahres passieren Internet bitte warum haben wir eine Cloudplay eine Elliptic Curve DSA obwohl es auch wieder hier mit einem Pseudo-RNG das ist eine gute Frage zum erwähnen Zufallsgeneratoren sind sehr wichtig für sichere Kryptografie und jeder andere DSA basierte Algorithmen braucht Entropie für alle zumindest braucht das Entropie es gab spätere RFCs wie man DSA als deterministischen Algorithmus benutzen wird wo man nicht mehr so viel Entropie hat und Cloudplay hat das auch implementiert für unsere DSAs Zufalls-Rundern sondern mit einem deterministischen Algorithmus das heißt wenn du eine Zufallsgeneratoren-Kollision hast dann ist das nicht so wichtig für uns Nummer eins bitte Also nach diesem Talk mit einem Haufen von Kalamitäten frage ich mich ob es irgendwelche Sachen gibt die dich glücklich machen oder optimistisch für diese Angriffe waren kurz nach Snowden also vielleicht achten Leute letztendlich auf sowas die Sache mit dem CA-Browser die will comments werden 2004 finalisiert also XP und Android 2 Tod sind es wird besser, gibt es irgendwelche Dinge die toll sind Ja, also einige Dinge die mich interessieren und die mich auch freue und mich aufregen ist das MyTLS-Projekt das formal verifiziertes TLS Versuch zu erreichen eine Sache, dass ich verloren habe war die dreifache Handshake das wurde doch deren Analyse bekannt und ich glaube dass die Arbeit die passiert in TLS 1.3 um schlechte Kurven zu eliminieren oder den RSA Handshake komplett zu eliminieren sind vielversprechende Schritte um es könnten noch weitergehen und noch viel weiter Dinge rauswerfen zum Beispiel X509 rausnehmen und diese ganze andere Legacy Code den wir da noch rumtragen den könnten sie auch noch rausnehmen Sorry, fast das nicht zu es war leider nicht so optimistisch Nummer 2 Heyo Was ist deine Meinung ich bin einfach nur neugierig was deine Meinung über TLS Encrypt Ich glaube TLS Encrypt ist großartig und soweit und so viel ich auch über TLS geranted habe Verschlüsselung egal welcher zu haben ist definitiv bevorzugt gegenüber keine Verschlüsselung zu haben Danke und ich glaube der Großteil je mehr vom Web verschlüsselt ist desto besser und ich persönlich ich würde mich unglaublich freuen wenn wir all jede Webseite dazu bringen können HTTPS Only zu sein und TLS Encrypt ist da ein großartig Teil davon und wir glaubt fair wir bieten es kostenlos an andere nicht aber das ist eine großartige Option um kostenlose Verschlüsselung zu haben zwei weitere Fragen angenommen wir haben einen Kunden der auf jeden Fall SSL Version 3 benutzen möchte und wir brauchen diesen Kunden wie überreden wir den abzugraden wie überzeugen wir den Upgrade, gute Frage es gibt Leute die alte Systeme haben also SSL 3 wie wir gesehen haben 100% auf Unterstützung auf Servern bis Pudel heraus kam es gibt also Tonnen verschieden der kleinen Diapers die nur SSL 3 benutzen ein Beispiel ist Bingdom ein beliebtes Werkzeug um zu überprüfen ob deine Webseite online ist benutzt SSL 3 ab wenn die erste Verbindung 4 schlägt wird dann tatsächlich zu TLS hochgestuft also haben wir herausgefunden als wir SSL 3 abgestellt haben also es ist ein schwieriger Verkaufsangelegenheit wenn wir einen Kunden haben denn als Protokoll benutzen möchte und es ist nur für einige spezifische Klienten in Benutzung die nicht aktualisiert werden können dann ist es besser als gar keine Verschlüsselung zu haben das ist ein starkes Argument hier Nummer 2 bitte mach es kurz bitte Cloudflare scheint immer noch das Leben schwer zu machen für Tour User wann wird das stoppen wann wird es das aufhören Cloudflare und Tour User also es gab einige Leute ganz vorne mit denen ihr sprechen solltet den du sprechen solltest wir arbeiten dran Danke, Nick noch einmal