 Und ich habe ihn übersetzt. Dies ist Heino Berg. Ich denke, viele von euch kennen ihn schon, denn er ist ein bekannter deutscher Journalist und viele von euch haben vielleicht etwas gelesen in Magazinen, in denen er schreibt. Er spricht darüber, dass das Abfangen von TLS als harmvoll angesehen wird, als schlecht angesehen wird. Hier geht es nicht nur um Verschlüsselung, sondern auch um Identitätsnachweis und wem wir vertrauen, wer entscheidet, wem wir vertrauen und wie das angegriffen werden kann. Ja, viel Spaß. Also TLS Abfangen, das ist ein Problem, das aufkam in diesem Jahr, früher in diesem Jahr, als es dieses Software Superfisch gab, die erkannt wurde und die schwere Sicherheitsmängel hatten, aber dies stellte auch einige Dinge, Probleme heraus, viele Software tut dies. Dies ist ziemlich frag, eine fragwürdige Art, Dinge zu erledigen, Dinge zu erreichen. Und ich möchte einen Überblick über dieses Thema geben. Und kurz über mich, wie schon gesagt, bin ich ein Journalist. Meistens schreibe ich für das Solch IT News Magazine, Nachricht Magazine Golem. Aber ich mache auch Arbeit im IT Sicherheitsbereich für eine Infrastruktur Initiative für die Linux Foundation und hauptsächlich Fuzzing. Also ich versuche, die freie Software zu verbessern, die bereits läuft. Ja, also ich möchte einen Schritt zurückgehen und erst mal gemein ein wenig über TLS sprechen und die Diskussionen, die wir in der Vergangenheit in den letzten fünf Jahren etwa hatten. Wir hatten viele Schwachstellen. Ihr habt vielleicht einigen gehört. Hartlead hat die meiste Aufmerksamkeit vorbekommen, aber auch die Dinge wie Beast, Crime, Lucky 13, Puto. Ja, also viele. Wir hatten viele Aufmerksamkeit für die Sicherheit von TLS und die Verbindungen. Und es gibt Dinge, die davon gelernt werden können. Ein Beispiel war zum Beispiel der sogenannte Beast Schwachstelle. Die, als die Beast Schwachstelle präsentiert wurde, war dies bereits ein bekanntes Problem, das alle bekannten, alle Versionen von TLS Probleme mit dem CBC Modus hatten, ein bestimmter Verschlüsselungsmodus. Cipherblockchain ist, glaube ich, das Problem ist nun, dass das alte TLS Version im Einsatz waren, immer noch viele Websites heutzutage unterstützen nur noch nur TLS 1.0, noch nicht die neueren Versionen, die also als Reparatur eingesetzt werden können, 1.1 oder 1.2. Oder als Workaround, wenn man eine Art Aufteilung der Datenpakete erreichen kann, dann ist diese Schwachstelle nicht wirklich vorhanden. Dann gab es ein Problem namens Crime, das mit Komprimierung in TLS zusammen hingen. Diese Komprimierung liegt dann Informationen über den Inhalt. Also die Lösung war einfach TLS Komprimierung nicht verwenden, was ein bisschen schwierig ist, weil HTTP auch Komprimierung einsetzt. Das ist ein bisschen schwieriger, das zu verhindern. Was auch interessant ist, dass wir hier ein Problem ist, dass Teil des Protokolls ist, ist nicht nur ein Bug in der Software. Das TLS Protokoll selbst hat hier ein Sicherheitsproblem gehabt. Und dann gab es Lucky 13, ein Problem mit der Art und Weise, wie TLS die Mac und Padding und Verschlüsselung kombiniert. Also generell ist es heute so, dass der als einzig als sicher angesehene Weg ist, zuerst zu verschlüsseln und dann Mac anzuwenden. Die Mac ist dafür da zu garantieren, dass das Paket sie nicht verändert hat auf dem Weg. Es gab einen Timing-Seitenkanal, also abhängig davon, welcher Fehler in einer Verbindung auftritt, konnte ein Angreifer etwas herausfinden über den Schlüssel. Und der Workaround hier war alles einfach mit sicherem Timing zu führen, das ist aber schwer. Die Lösung wäre, diese Verschlüsselungsmodi nicht mehr zu benutzen. Gibt zurzeit nur einen Verschlüsselungsmodus in TLS12, der diese Schwachstelle nicht hat. Das ist AES im GCM-Modus. Es gibt auch RC4, aber das hat andere Schwachstellen. Also wir wollen das nicht benutzen. Und dann gab es Pudo. Was also eine Schwachstelle in der sehr alten SSL3-Version war, das sollte eigentlich kein Problem sein, weil es so alt ist, dass SSL3 gar nicht mehr benutzt werden sollte. Aber viele Leute setzen es tatsächlich noch ein. Es gab also einen Downgrade-Angriff, der möglich war. Und dann gab es etwas Interessantes. Es gab Geräte, die tatsächlich dieselbe Schwachstelle auch in TLS hatten, weil das Problem war, dass es in einem alten SSL3 ein Padding gab. Und es war nicht definiert, was in diesem Padding verwendet werden sollte. Es konnten beliebige Werte verwendet werden. Das konnte für einen Angriff ausgenutzt werden. TLS hat definiert, dass dieses Padding ein bestimmter Wert sein muss. Aber einige Implementierungen haben das nicht überprüft. Sie haben das also, es war also möglich, die Schwachstelle sozusagen zu portieren vom alten Protokoll, in dem man das neue Protokoll schlecht implementierte. Ja, es gab auch einige Debatten über etwas, was sich Forward Secret nennt. Ein Feature von Verschlüsselungstechniken, bei der man einen Schlüssel für jede Verbindung neu erzeugt. Und die Idee ist, dass man diesen Schlüssel nach der Verbindung zerstört. Und dann, wenn dein privater Schlüssel später gestohlen wird, ist die Folge, das sind die Folgen nicht so schwerwiegend, weil Verbindungen aus der Vergangenheit immer noch nicht entschlüsselt werden können. Aber es gibt Modi in TLS, die Forward Secret haben und andere, die das nicht haben. Und es gibt wirklich keinen guten Grund, Forward Secret nicht zu benutzen. Es ist außerdem inzwischen einig, die Einigkeit, dass TLS 1, 3 nur noch Forward Secret Modi hat. Alles andere wird entfernt werden, ja. Das ist also die Debatte, die wir in den letzten Jahren über TLS hatten. Es gab noch ein paar andere Verwundbarkeiten. Aber ein paar Delektionen, die wir hier lernen können, ist, dass wir Sicherheitslöcher im Protokoll haben. Das bedeutet, dass selbst, wenn das Protokoll korrekt implementiert wird, wie es im Standort steht, trotzdem Sicherheitslücken auftreten können. Wir müssen also all diese Workarounds kennen und wie man die und was man abschalten muss, um eine Sicherheitslöcherung von TLS heute zu bekommen. Und nur in der neuesten TLS-Version mit AIS im GSM-Modus und Forward Secret wird heutzutage noch halt sicher angesehen. Aber man muss TLS 1.0 immer noch unterstützen, weil es immer noch sehr viel Server gibt im Internet, die, wenn ihr das abschalten würdet, nicht mehr mit denen reden könntet und viele Webseiten nicht mehr erreichen könnt. Das ist ziemlich schwer, weil es all diese Timingproblemen gibt. Und wenn man das sicher machen will, ist es sehr kompliziert. Und dann haben wir das Problem mit den Zitifikatsautoritäten. Wie ihr wahrscheinlich wisst, wenn ihr ein SSL-Zertifikat haben wollt, dann müsst ihr mit einer dieser CAs reden, davon gibt es Hunderte. Und jede dieser CAs kann wiederum untergeordnete CAs haben. Wir wissen also gar nicht genau, wie viele CAs es im Interfekt gibt. Im alten System war es so, dass jedes CAA einen Zertifikat für beliebige Domains ausgeben konnte. Das bedeutet also, dass das ganze System nur so sicher ist, wie die schlechteste CAs im System. Wenn also eine gehackt wird, haben alle ein Problem. Das bedeutet auch, dass es relativ egal ist, welche CAs ihr auswählt. Wenn du also sagst, ich gehe zu einer CAs, die besonders vertrauenswürdig ist, warum auch immer, das macht keinen Unterschied. Und das hatte auch praktische Folgen. Wir hatten eine Menge Fälle in den letzten Jahren, wo CAs einfach Zertifikate ausgestellt hatten, zum Beispiel für Google.com, aber nicht an Google, sondern an jemand anders. Es gab ein paar Probleme mit Komodo und Turktrust, CNNIC, der chinesische, der von der chinesischen Regierung kontrollierte CAs, in die SCCA, die ging unter, die später beim Kot ging, an sie, ein französischer, auch von der Regierung kontrollierte CAs. Für viele verschiedene Gründe, manche davon wurden gehackt. Manchmal ist einfach das Problem, dass die chinesische CAs einen Unterzertifikaten, einen ägyptischen Firma verkauft hat, die es dann benutzt haben, um traffic in ihrem eigenen Netzwerk abzufangen. Aber jedenfalls eine Menge Probleme, wo die CAs die Regeln nicht befolgt haben, wo Zertifikate an Leute ausgegeben haben, die diese nicht hätten bekommen sollen. Und über die Jahre gab es viele Debatten darüber, wie man das beheben könnte. Und es gab eine Idee, die hieß Sovereign Keys, die war interessant, aber sehr kompliziert. Es war von ein paar Jahren einen Trock-of-Kongress dazu. Tag ist eine Art Keypinning-Vorschlag. Bei Convergence war die Idee, dass man Zertifikat von verschiedenen Punkten im Netzwerk ausprüft und dahin, was auf DNS-Sech basiert und das ins DNS aufnimmt. Aber alle diese Lösungen haben gemeinsam, keine davon breit davon eingesetzt wurden. Jetzt kurzlicht gibt es aber einen Standard, der heißt HTTP Public Key Pinning, HPKP, den ich sehr gerne mag. Die Idee ist, dass es eine Website sagen kann, okay, das ist mein Key, das ist mein Zertifikat. Und hier ist ein Back-Abschlüssel und der Browser sollte diesen Schlüssel und den Back-Abschlüssel speichern für später und in der Zukunft nur diese Schlüssel akzeptieren für diese Website. Das heißt, zusätzlich zu den CAs haben wir jetzt auch noch ein Trust-on-First-Use-System. Bei der ersten Menutzung wird die im Schlüssel oder dem Zertifikat dann vertraut. Das bedeutet dann, dass nicht jedes C.A. einen Zertifikat dafür ausgeben kann, die nachher benutzt wird. Die Browser in total haben außerdem mehrere schon vorgepinnte Zertifikate. Wenn ihr also ein Zertifikat für Google.com bekommt, dann wird es nicht funktionieren, zumindest nicht in Chrome und Firefox, weil diese Browser bereits wissen, welche Keys Google hat und welche Zertifikat und CAs Google benutzt. Man kann also mit einem selbst angelegten Zertifikat nichts erreichen. Das Problem daran ist, warum das es nicht so weit verbreitet. Das ist gerade neulich ein Statistik über die Alexa Top 1 Million, die meine millionen beliebesten Alexa-Website und fast keine davon nutzen diesen Herder. Es gab mal vier Seiten. Jetzt ist es nur noch eine von einer Million, also auch nicht weit verbreitet, was sehr schade ist, weil es auf jeden Fall ein großer Fortschritt gegenüber der aktuellen Sicherheit des CLS-Systems darstellt. Schließlich gibt es das Konzept der Zertifikatstransparenz, vor allem von Google entwickelt. Und die Idee hier ist, dass wir ein öffentliches Logbuch aller Zertifikate haben, dass man nur anhängen kann. Also ähnliche Bitcoins ein bisschen. Jeder, der möchte, kann das verifizieren und das hat alle Zertifikate enthalten. Die Idee ist, dass man mehrere solcher Logs hat. Also sehr vielversprechende Idee. Es verhindert keine Angriffe mit Zertifikaten, aber es stellt sicher, dass man diese Angriffe nicht verstecken kann. Es geht also eine recht hohe Wahrscheinlichkeit, dass wenn hier ein Zertifikatsstransparenz deployet ist, dass man dann relativ bald merkt, dass ein genacktes Zertifikat im Umlauf ist. Es ist noch nicht besonders weit verbreitet, aber Chrome hat schon vorläufige Unterstützungen dafür und Google wird es wahrscheinlich bald für Extended Validation Zertifikate erzwingen und später auch für andere. Also es passieren Dinge in diesem Raum, um diese Probleme mit CLS zu umgehen. So, nach vielen, vielen Jahren dieser Probleme haben wir jetzt also endlich ein paar Möglichkeiten, das Problem anzugehen. Aber die Schlussfolgerung hier ist, dass wenn ihr ein TLS-Zertifikat verifizieren möchtet, müsst ihr diese Dinge wissen, eure Implementierung müssen darüber Bescheid wissen. Und ihr müsst immer aktuell bleiben, was sich gerade in der TLS-Sicherheit so entwickelt. Eine kürzliche Entwicklung ist noch, dass viele Menschen jetzt dafür sich einsetzen, dass hat der DPS überall verwendet wird. Google hat in diesem Bereich relativ viel gemacht, Mozilla hat jetzt auch vor HTDP-Seiten als unsicher zu markieren. Zertifikate kosten nicht mehr so viel, sind nicht mehr so teuer wie früher. Es gibt jetzt CAC-Zertifikate kostenlos abgeben und Let's Encrypt wird bald auch noch starten, dann gibt es auch noch einen Talk dazu später. Und ich denke, das ist generell eine ganz gute Sache. Ich denke auch, dass es eine gute Sache ist sogar, wenn ihr keine geheimen Daten auf Webseiten habt. Denn was viele Menschen vergessen, ist, dass HTDP und HTDPS garantieren, dass die Daten verschlüsselt übermittelt werden, aber auch, dass es Integrität, dass die Daten integer sind. Das heißt, die Seite, die die Nutzer sehen, ist genau die Seite, die das Server geschickt hat. Und das wurde nicht auf dem Weg manipuliert. Also selbst wenn die Daten an sich nicht geheim sind, wollte eure Daten trotzdem immer korrekt haben. Es gibt auch auch Menschen, die denken, dass es eine gefährliche Entwicklung ist. Hier ist ein Bild, das sie auf der Blackout-Konferenz neulich gemacht haben. Eine Firma namens Blue Code, vielleicht hat der von Ihnen gehört. Sie haben ein paar fragwürdige Ideen, wie man mit Sicherheitsforschern umgeht. Sie sagen, dass TLS-Traffic ein Risiko darstellt. Man kann es auch nutzen, um etwa ins Persistent Threads, also länger anwährende Routekits zum Beispiel zu verstecken. Und klar, das ist für die alles gefährlich. Und natürlich haben sie auch eine Lösung. Sie haben eine Möglichkeit, ihren TLS-Traffic abzufangen und anzuschauen. Es gibt viele andere Firmen von Five, und hier weiß ich gar nicht, welche Firma das ist. Die verkaufen euch irgendwelche Produkte und damit soll es euch dann erlaubt sein, verschlüsselten Traffic anzuschauen und zu analysieren. Also es gibt eine Menge Produkte, die das behaupten. Wir haben diese Enterprise-Sicherheitsprodukte, Blue Code und Five und so. Wir haben Antivierendprogramme, die das zu tun behauptet. Wir haben Jugendschutzsoftware, Elternkontrollsoftware, Erdblocker und diese Malware. Die Werbung in eure Browser-Session einbaut. Also eine Menge Tools, die man eigentlich nicht will, dass sie an den Traffic manipulieren. Wie machen sie das nun? Dass die ADP nicht einsehen kann, wenn er verschüsselt ist, weil das die Idee enthalten der DPS ist. Die Lösungen, die diese Leute haben, ist also, dass sie einen Zertifikat im Browser der User installieren, und zwar als CA-Zertifikat. Und dann führen sie quasi eine endende Mittelattacke aus und generieren eine Fly-Neue-Zertifikate für eure Abfrangen. Jetzt hatten wir Anfang des Jahres eine Software namens SuperFish, die manche Menschen auf ihrem Laptop gewonnen haben. Es war vorinstalliert von Lenovo-Seite. Und was es tut, ist, wenn ihr das Netz geserved seid, hat das Bilder analysiert, hat versucht, Objekte auf diesen Bildern zu erkennen und dann passende Werbungen dazu anzuzeigen. Also, ich weiß nicht, vielleicht surft ihr über eine Webseite zum Thema Camping und dann seht ihr eine Werbung, die euch sagt, wo ihr ein Zelt kaufen könnt. Was es auch hervorhebt, ist, dass es jetzt einen sehr merkwürdigen Markt gibt, dass es Firmen gibt, die Software produzieren, die niemand eigentlich will, die aber andere Firmen wie Lenovo zum Beispiel dafür bezahlen, um es auf den Laptops ihrer Kunden vorzuinstallieren. Was auch passiert, ist, dass dieses Software bannlingen, wo man eine Software installiert und der Installer fragt, dann möchtet ihr vielleicht noch diese tolle Toolbar installieren oder was auch immer. Und wenn ihr dann versehentlich den falschen Knopf drückt, habt ihr irgendwas installiert, was ihr niemals installiert haben wolltet? Das Problem mit Superfish war, dass sie einen Man in the Middle Proxy eingesetzt haben, wie beschrieben, und so gab es dasselbe Zertifikat auf allen Installationen oder dasselbe private Schlüssel auf allen Installationen und dieser Schlüssel natürlich ist Teil der Software. Es war also einfach möglich, diesen Key zu extrahieren und zwei Tage später hat das jemand getan, so dass der private Schlüssel öffentlich wurde. Und mit diesem Schlüssel konnte man nun jeden Attackieren, jeden Angreffen der einen Laptop mit dieser Software benutze. Ja, das war ein großes Publications Disaster für Lenovo. Sie haben dann gesagt, es tut uns leid, sie haben einen Entfernungswerkzeug, einen Entfernungs-Software angeboten und haben gesagt, wir werden vorsichtiger sein in Zukunft, wir haben das gelernt. Und kurz danach merkte man, dass Lenovo jetzt BIOS Foodkit benutzt, um Software zu installieren, also haben sie wirklich irgendwas gelernt. Und dann, noch interessanter, haben Menschen herausgefunden, dass Superfish ein Software-Modul von einer Firmen namens Komodia benutzt. Und dieses Modul wurde in vielen Anwendungen auszutun. Sie, alle diese Anwendungen hatten dieses Problem der gleichen Schlüssel und nun wurden also Schlüsse von vielen Produkten extrahiert. StaffCorp, Custodio, Gehs-Gemuss-Kontrolle, VPN-Software, Ad-Aware, ein Anti-Adware-Tool. Also zeigt, was auf eurem System ist, dass ihr nicht wirklich wollt. Also ja, es zeigte sich also, dass dieses Problem sehr viel größer war als nur die Superfish-Angelegenheit. Es gab sehr viele Software, die genau die gleichen Schwachstellen hatte. Und dann, Philippo Valzoda, der Engineer bei Cloudflare von Terraus, dass es einen Trick gab, wie man Zertifikate erzeugen konnte, alle diese Komoderprodukte akzeptieren würden. Also zuerst hieß es okay, wir haben ein Schlüssel für diese Produkte und dann gab es diesen Trick, weil was passierte ist, wenn diese Software sich mit einer Website, mit einem ungültigen Zertikat sich verbinden würde, würde es dieses Zertifikat austauschen mit einem Zertifikat, das von diesem Man in the Middle Proxy unterschrieben worden war, aber mit einem ungültigen Hostnamen. Das Zertifikate auch ein Feld Subject Alternative Name haben, wo ein weiterer Hostname für ein Zertifikat untergebracht werden kann. So, und diese Felder wurden unverändert gelassen. Also diese Zertifikate, die von irgendeiner CA unterschrieben waren oder bei eurer eigenen, selbst unterschriebenen CA, konnte man verwenden, man konnte den Hostnamen für die Websites, die man attacken möchte, in diesen Subject Alternative Name-Feld einbauen und jede Software, die dieses Modul, Komodiamodul hatte, würde dieses neue Zertifikat dann akzeptieren. Und dann gab es diese ziemlich lächterliche Sache, LavaSoft hat also diese Ad Aware Software, sie schrieben auf ihrer Facebook-Page, dass LavaSofts letzter Release von Ad Aware Web-Kompagnien nicht mehr diese Fähigkeit enthält, sodass wir also nicht mit Sicherheit bestätigen können, dass die Komponente, die hier komprimentiert worden war, dass die Zertifik entfernt worden ist. Sie haben eine Firma, die ein Sicherheitsprodukt erstellt. Sie haben eine solche Firma, die sagen, wir hatten ein schweres Sicherheitsproblem und wir wissen nicht, ob wir es wirklich gelöst haben. Das ist wirklich ein bisschen lächerlich und es hat mich etwa 15 Minuten gekostet, um herauszufinden, dass sie tatsächlich immer noch verwundbar waren. Ich habe dieses Facebook-Posting kommentiert. Ja. Und dann, einige Tage später gab es ein IRC-Kanal, wo Leute, die in diesem Thema interessiert waren, dann postete jemand einen Link, jemand fragte, ich habe eine Software namens PriftDoc auf meinem System, einer wollte wissen, ob dies so etwas wie SuperFish ist. Und es zeigte sich, dass dies eine Software ist, eine Firma entwickelt wird von CEO von Kimono Merich Abdul Hayolu gegründet wurde und sie identifiziert Anzeigen, die als gefährlich erkannt wurden, die Kriterien unklar, nicht klar, was die Folgen für die Privatsphäre ist, aber diese Anzeigen wurden auch ausgetauscht und dadurch machte diese Firma natürlich Geld. Und dann habe ich mir das angeschaut und habe gesagt, okay, dies verbindet kein geteiltes Zertifikat, nicht so wie SuperFish. Aber was es aber getan hat, war, es hat einfach am anderen Ende jedes Website Zertifikat akzeptiert. Also, man könnte irgendwelche Software, irgendwelche Zertifikate einsetzen und es wurde akzeptiert. Und dann habe ich mir den Traffic dieser Software angeschaut und dann habe ich mich dann in der URL, die man besuchte, im Klartext zu einem Server dieser Firma. Dann habe ich einen Blog-Poster übergeschrieben, es war etwas spät am Abend und da habe ich mich dann schlafen gelegt und am nächsten Tag hat mich NBC angerufen. Es gab ein Riesen, sehr viel Interesse in Medien, dass das Problem wirklich war, Komodo. Komodo ist eine Firma, die TLS-Zertifikate verkauft, ist verbunden mit einem Produkt, das diese Sicherheit bericht. Es war also kein Komodo-Produkt, aber sie hatten enge Verbindungen. Komodo bewarb dieses Produkt und Komodo hatte auch einen Browser, der mit diesem Produkt gebündelt war, mit PrifDoc. Aber die Version eben Komodo-Browser war tatsächlich nicht betroffen von der Sicherheitslücke, sondern ein Browser, nicht als ein Mittelproxy. Ja, das ist ein anderes Problem, wo das TLS-Abfang Proxy tatsächlich erhebliche Sicherheitsprobleme auslöste. Und dann habe ich mir andere Produkte angeschaut, die auch TLS-Traffic abfangen. Es gibt einige Antivirus-Programme. Ich habe mir besonders Avira, Kaspersky und E-Set angeschaut, diejenigen sind, die frei erhältlich sind, konnte ich also sehr einfach testen. Und keine von denen hatte eine schwere Verwundbarkeit, wie jetzt Superfish, PrifDoc, aber alle hatten etwas, was die TLS-Verbindung verwundbar machte. Das größte Problem war, dass Kaspersky immer noch verwundbar war für Freak. Freak war die Schwachstelle, bei der man Verbindungen im Export-Modus, also Export-Verschlüsselung aus den 90er-Jahren, damals war es verboten, starke Kryptografie einzusetzen und es wurde herausgefunden, dass man also OpenSSL dazu bringen konnte, diese Verbindungen zu benutzen. Sehr kurz danach, einige Tage nachdem die Freak-Schachstelle publiziert wurde, postete jemand im Kaspersky-Forum, ihr habt dieses Problem mit Freak. Dieses wurde mir nicht lange ignoriert. Ich habe dieses Problem nochmal gefunden in Kaspersky. Und dann habe ich vorher über diesen Key-Panning-Standard, diesen Head-in-HTTP berichtet. Man könnte sich denken, okay, wenn man dieses Key-Panning hat, dann sollte dieses ganze TLS-Abfangen-Proxy-Ding nicht mehr funktionieren. Der Browser hat jetzt ein Google-Zertifikat, auf das es festgelegt ist und wenn dies nun ersetzt wird durch einen TLS-Abfangen, das eine Art Kompromiss einbauen mussten, denn es gibt bereits so viel Software, die dieses TLS-Abfangen, die das ausführt. Es war unmöglich, all dieses Software unbrauchbar zu machen. Und die Idee ist also, wenn man ein manuell installetes Root-Zertifikat im Browser hat, dann wird der Key-Panning-Header ignoriert. Nicht wirklich gut, aber man kann etwas verstehen, warum Browser das tun. Was tatsächlich passieren sollte, wenn man es richtig machte, dann sollten diese Produkte diesen Header selbst testen, dieser Abfangprodukt im Backend, aber keine der Softwareprodukte, die ich mir angeschaut habe, tun dies. Also ich habe keine Software gesehen, die TLS-Abfangen und den Key-Panning-Header überprüft. Wenn ihr also so etwas tut, wenn ihr TLS-Abfangen-Proxy implementiert, dann seid ihr verantwortlich für die Sicherheit dieser Verbindungen. Und es kommt dann darauf an, wie gut eure Implementierung der Zertifikatzvalidierung ist. Und ihr solltet euch fragen, sind diese Firmen, diese Produkte produzieren tatsächlich qualifiziert, dies durchzuführen und meine Antwort ist wahrscheinlich nicht. Denn Browsers haben tatsächlich große Sicherheitsteams, die sind sehr involviert in den Debatten über TLS allgemein. Sie folgen also dem, was tatsächlich aktueller Stand der Technik ist und eine Firma, die irgendeine superfischälnische Software produziert ist, wahrscheinlich nicht so involviert. Und dann gibt es einen Blog-Post über die Antivirus-Applikation unter meinem Blog-Post über antivirusproduktisch fragte jemanden nach einer Software namens ArtGuard, die auch so etwas installiert und fragte mich, ob ich mir das anschaue und ich tat das und dachte mir, okay, ja. Es erzeugt in jeder Installation ein neues Zertifikat, benutzt aber immer den selben privaten Schlüssel. Und dann später fand ich, okay, ich habe die kontaktiert und bekam meine Antwort von den Entwicklern. Was sie taten war, sie wählen einen von acht privaten Schlüsseln aus, abhängig von der CPU des Rechners. Wenn man es auf demselben System installiert, bekommt man also den gleichen Schlüssel. Das macht nicht wirklich Sinn. Man kann diese Schlüssel einfach extrahieren von einem Fall, das mit dieser Software geliefert wurde. Es gab acht verschiedene Schlüssel. Und ich habe diese Schlüssel publiziert. Also es gibt ein GitHub-Pool, wo ich das alles publiziere. Ich habe den Link später für euch. Dann dieses ArtGuard hängt ab von einer Software namens Netfilter SDK. Es gibt tatsächlich einen Fall namens Protokollfilters.dll. Es war also recht einfach. Ich habe einfach ein Python-Script erzeugt, das nach etwas was man mit dem Byte sucht, das für einen privaten Schlüsselintel es markiert. Dann habe ich diesen Abschnittedatei einfach an OpenSSL übergeben, geschaut, ob man SSL das tatsächlich lesen kann und habe dann diesen Schlüssel ausgegeben. Und dies hat mich eine Flasche erinnert. Das Protokollfilter bündelten auch eine sehr alte ArtGuard. Ich habe das auch in PrivDoc gesehen. Und dann habe ich herausgefunden, dass PrivDoc auch diesen geteilten Schlüssel, dieses Problem mit geteiltem Schlüssel hat. Das war nicht nur gebrochen, dass die Zertifikate auf der anderen Seite nicht validiert werden. Es hatte außerdem nur einen gemeinsamen Schlüssel. Also auch wieder ein zusätzliches Risiko, wenn Menschen jetzt also PrivDoc hat. Und dann habe ich mich gefragt, gab es noch irgendwas anderes, was Protokollfilters.dll benutzt, dieses Softwaremodul. Und ich habe viele Websites gefunden, die Berichte enthalten darüber und viele sind Scrapware nicht gewünschtes Software Sachen, die man auf dem PC findet, ohne dass man weiß, woher das kommt. Aber unglücklicherweise habe ich viele Produkte zum Download finden können. Es gibt normalerweise Firmen, die nur für kurze Zeit im Geschäft sind und dann aufhören. Und ich habe eine Menge Informationen über dieses Softwareprodukte gefunden, aber nichts zum Downloaden. Also wenn irgendjemand Zugriff hat auf diese Sachen, wäre ich sehr interessiert. Dann, was ich für kurzem sah, es gibt auch Menschen, die versuchen, das gleiche für andere Protokolle zu tun. Hier ist Symantec eine Lösung für E-Mail-Verschlüsselung. Im Wesentlichen also pgp wird hier gepasst, wird jetzt als Symantec Desktop-Equipsion verkauft und dieses Software sagt, man sollte TLS deaktivieren. Wenn man also jetzt das installiert hat und E-Mail in Thunderbird aufsetzt einen Konto, dann gibt es eine Meldung, dass man das TLS ausschalten sollte und dann wird die Verbindung abgefangen. Thunderbird zeigt dann eine Warnung, eine sehr ängstlich aussehende Warnung, absolut das Richtige. Man holt hier seine E-Mail ohne Verschlüsselung, also da sollte vorgewarnt werden. Ja. Und dann habe ich ein Sniffer gestartet und habe mir angeschaut, wie sieht diese TLS Verbindung aus und es macht natürlich TLS 1.0 ohne Forward Secrecy. Also wenn ihr ein Produkt habt, dass euch E-Mail-Verschlüsselung verkaufen möchte und eine sehr veraltete Version von TLS verwendet und einen sehr veralteten Verschlüsselungsalgorithmus hier einsetzt, das ist natürlich... Was also jetzt noch übrig ist, als Frage ist, sind diese Enterprise Appliances, also so Geräte, wir hatten dieses Bild von BlueCode, also Geräte, die verkauft werden, die sich in den Nutz-Traffic einklinken. Ich weiß nicht, wie gut oder schlecht sie sind, die Geräte habe, aber sie haben wahrscheinlich ähnliche Probleme. Und es gibt vielleicht auch ein bisschen Hinweise, in sogenannten Enterprise-TLS-Anwendungen gibt es viele seltsame Bugs in der Vergangenheit. Das eine der seltsamsten Dinge, die in TLS vielleicht passieren ist, dass F5 ein Gerät verkaufte, dass einen TLS Handshake verwendete, der nur zwischen 256 und 512 Bytes lang sein durfte. Also längere Handshakes führten dazu, dass die Verbindungen nicht erlaubt wurde. Es gab Menschen, die neue Features in TLS einbauten, die Handshakes wurden größer und F5 hat dann diese Verbindungen nicht mehr zugelassen. Es gab dann also eine Erweiterung um das Handshake zu ergänzen. Das erste Mal denke ich, dass eine spezielle TLS-Erweiterung nur für einen bestimmten Hersteller es gemacht wurde. Ich habe auch das Pudel-TLS-Problem angesprochen, wo also ein Bug von einer alteren SSL-Version zu neueren TLS-Versionen geportiert werden konnte und dies wurde in einem großen Bereich von Geräten gefunden. F5, ACN, CSCO, Checkpoint und so weiter. Also sehr offen sind die Firmen, die Enterprise Abfang Geräte verkaufen. Etwas, was vor kurzem rauskam, war ein Bug namens Maze wo Geräte die Marktprüfzimmel nicht prüften und so wusste man also überhaupt nicht, ob die Daten, die ankommen wirklich korrekt sind. Ich würde diesen Firmen nicht vertrauen, meinen TLS-Traffic abzufangen und dann fragt man sich vielleicht, was sind die Alternativen und zunächst denke ich, das ist vielleicht die falsche Frage, denn für die Produkte würde ich eigentlich grundsätzlich anzweifeln, ob sie überhaupt existieren sollten. Das ist offensichtlich für etwas viel Superfisch. Eine Software, die auf deinem Laptop instelliert, ohne deinen Einverständnis und dann wird Werbung eingeblendet. Ich denke, gibt es irgendjemand hier im Publikum, der denkt, es müsste mehr Werbung im Internet geben? Ich glaube nicht. Aber auch für Sachen, wenn man irgendwelche Firebots oder Antivirus-Produkte hat, eine gute Idee den Traffic zu inspizieren für Antivirus-Produkte funktionieren eigentlich nicht mehr, wenn sie überhaupt jemals funktioniert haben. Viele dieser Produkte würde ich einfach infrage stellen, ob dies ein vernünftiger Weg ist, IT-Sicherheit durchzuführen. Wenn man Verschlüsselungen bricht, dann führt man ein großes Risiko ein. Wenn man das aus Sicherheitsgründen macht, das scheint also sehr fragwürdig zu sein. Es gibt natürlich legitime Gründe, warum man Traffic abwandeln möchte in bestimmter Weise. Aber wenn man das tut, dann bitte macht das nach der Verschlüsselung. Also was man sich vorstellen kann, ist eine Browser-Erweiterung. Es gibt viele Dinge, diese was tun, wie HTTPS Everywhere oder Privacy Badger oder irgendwelche Sachen, diese Art. Aber dies sollte also nach der Entschlüsselung passieren, mit Einverständnis des Benutzers. Ja. Also meine Lektion, was ich mitnehme, es gibt also dieses Problem mit diesen potenziell unerwünschten Anwendungen Appware, Crapware, Bloatware, wie man das auch mal nennen will, das ist ein schweres Sicherheitsproblem. Sollte nicht unterschätzt werden. Die Idee, dass man einen Laptophersteller bezahlt, irgendwelche Software auf meinem Gerät zu installieren, die ich nicht will, das ist ein legitimes Geschäftsmodell. Und auch die Idee, dass man Software bündelt mit etwas anderem und dann den User überlistet, hier okay anzuklicken und dann zu sagen, der User hat sich einverstanden und erklärt, diese Dinge sind so oft auf eine Weise gemacht, dass es sehr leicht ist den falschen Knopf anzuklicken. Ich habe vielleicht gehört, dass in Sourceforge jetzt Sourceforge hat viele Softwareprojekte gehostet und sie liefern Installer aus die anderen Produkte mit Huckepack tragen. Bei Gimpf start das zum Beispiel auf. Dies ist wirklich etwas, was absolut nicht akzeptabel ist, in meiner Meinung nach. Wenn ihr eine Software installieren möchtet auf dem Computer eines anderen Personen, dann müsst ihr das Einverständnis haben. Absolut, das klare Einverständnis. Und dieses ganze CLS-Abfangzeug ist generell gefährlich. Wenn ihr eine Software gesehen, die es richtig hinkriegt und sogar viele Sicherheitsprodukte kriegen es nicht richtig hin. Ich denke, dass das ein absolut fehlgeleiteter Ansatz ist. Verschlüsselung ist aus einem bestimmten Grund da. Sie heißt da, um deine Information zu schützen und zu garantieren, dass die Information unverändert übertragen wird. Und damit sollte man nicht herumspielen. Ja, also hier ist so, wo ich die Zertifikate gesammelt habe. Und jetzt nehme ich an, dass wir etwas schneller waren als ich dachte. Wir haben also viel Zeit für Fragen, für Diskussionen. Ja, danke für diesen Talk. Ich denke, wir haben viel gelernt. Und es gibt bereits mindestens drei Fragen. Fragen Willings an. Hallo. Hi. Eine gute Idee wäre, alle Browserhersteller als Erdon oder API für Softwarehersteller etwas anbieten würden. Eine Art SpamPod auf dem Wut, dass das eine gemeinsame API, du möchtest etwas wie eine Browser-Erweiterung, die auf allen Brousern existiert? Ja. Ich denke, dass die Hersteller so eine Funktionalität haben wollen. Das könnte eine Idee sein. Ich habe nicht darüber nachgedacht. Es könnte eine machbare Idee sein. Auch von dieser Seite vielen Dank für diesen großartigen Talk. Was ich mich gefragt habe, was wirklich mit der letzten Frage zusammenhängt, ich denke, wir alle sind uns einig, dass Superfish furchtbar ist. Aber Bluecoat hat das Compliance-Problem. Es gibt Firmen, die SSL abfangen wollen. Also einfach zu sagen, macht es gar nicht. Es wäre schön, aber wird nicht funktionieren. Vielleicht sollten wir so etwas wie davon Abstand nehmen. Vielleicht einen expliziten Standard haben. Dass man also seine TLS-Geheimnisse mit einer vertrauten Partei teilt. Dass man was anzeigen kann, wie dies wird beobachtet von deiner Bluecoat Appliance. Also, das ist vielleicht der bessere Ansatz als das, was du sagst. Neben du sagst, das einfach böse tut es gar nicht. Was du eigentlich möchtest, ist, dass ich eine Lösung anbiete, mit etwas zu reparieren, was ich nicht mag. Ich denke, dass es generell falsch ist. Ihr möchtet eine bessere Lösung haben für etwas, was ich einfach nicht legitim finde von Anfang an. Ich denke, du sagst, du magst es nicht, du möchtest loswerden. Ich werde keine Vorschläge machen mit etwas zu verbessern, was ich abschaffen möchte. Also, auf einem praktischen Hinsicht wird es aber nicht weggehen. Es gibt Firmen, die einen Bedarf haben. Ich frage, warum gehst du nicht und versuchst einen besseren Standard, um das komplett zu ignorieren. Denn du möchtest das Problem ignorieren, dass es einen Bedarf gibt. Ja, du kannst das versuchen, aber ich werde das nicht tun. Ich werde hier nichts vorschlagen, was meiner Ansicht nach gar nicht erst passieren sollte. Okay, Frage von rechts. Hi, ich bin wirklich neugierig. Ich frage mich wirklich, was der Bedarf ist, um CLS zu brechen. Ich frage mich, ob der Bedarf an den Sprecher aber an den Menschen, der gerade weggegangen ist. Da steht wieder auf. Komm bitte zurück, wenn du möchtest. Danke. Ich habe zu tun mit SSL abfangen. Ein wenig, aber nur im Open-Source-Brecher, aber kein kommerzielles Interesse. Meine Sichtweise ist, das Problem ist, wenn du SSL abfangen durchführst auf dich traditionelle Weise, SSL-Zertifikatsmanagement im Proxy, dann hast du diese Probleme, die wir ja mit SuperFesh und so gesehen haben. Wenn man aber eine legitimen Seitenkanal hat, wo man so ein hartes Master Secret, dann bekommt man mindestens ein expliziten Weg. Man hat eine zur Endverbindung mit einer dritten Partei, die aber mithören kann. Ich denke, protokollmäßig wäre das interessanter. Für HTP2 gab es also die Pfangproxies, da es sehr stark diskutiert wurde. Aber das war nur für Jugendschutzer, so Elternkontrolle, nicht für HTTPS-Verbindungen. Ja, sicher. Ich denke, Blutgut und so weiter haben einen Geschäftsfall hierfür. Dieser Fall wird nicht verschwinden. Sie werden das immer noch tun. Man kann das nicht einfach wegschieben. Das ist grundlegend das Problem. Bitte geht es zum Mikrofon, es gibt gerade Einwände, Proteste. Um es klarzustellen, ich mag das selbst nicht. Ich wäre froh, wenn es weggeht, aber es gibt Firmen einen Compliance-Problem. Wenn man diese Compliance-Leute anspricht, dann hört man, dass die Leute das weitermachen werden. Das ist also sehr viel schwieriger, das völlig zu verschwinden bringen zu wollen, als eine bessere Lösung zu finden, ein besseres Protokoll. Ihr werdet es nicht schaffen, dass es weggeht, indem man technische Lösungen findet, die es besser hinkriegen, die die Situation verbessern, wenn es bleibt. Der Weg, um es zu verschwinden zu lassen, ist, indem man alles zu verschwinden bringt. Kein Zugriff vereinbaren ins Protokoll, man macht ein sicheres Protokoll, man implementiert es und Leute werden damit leben und werden damit umgehen. Es gibt einfach mehr abgefangene Verbinde, wo nicht weniger. Ich möchte auch sagen, meine Hoffnung ist, wenn man mehr Analyse durchführt, dann werden wir wahrscheinlich mehr Schochstellen finden und dann haben wir mehr Möglichkeiten, diesen Devices einen schlechten Ruf zu bringen. Das wäre mein Ansatz dafür. Ich kann auch noch mal was sagen. Aber wenn man den Punkt sieht, wenn wir jetzt ein Superprotokoll haben, dass diese Dinge einfach nicht zulässt, dann werden die Hersteller wie du gesagt, Prouser-Extensions bauen, die die Sachen auch machen. Also, ich denke, das ist das, was er haben möchte, einen gemeinsamen Weg, wie man all diese Dinge auf all diese Dinge zugreifen kann. Also, wir bewegen uns voran, aber ich denke, was Neues ist, bevor wir eure bisherigen Ansätze zu nicht machen, benutzt vielleicht diesen besseren Weg. Das wäre vielleicht konstruktiv oder nicht. War das eine Frage? Ich denke, die erste Frage, die ich immer stellen möchte, ist, ist das Produkt etwas Legitimes, was überhaupt Legitimes, tut das Produkt etwas Legitimes? Für viele dieser Produkte, denke ich, ist die Antwort Nein. Ja, aber Menschen zahlen viel Geld für diese Produkte. Ja. Also, es gibt einen Markt und sie werden nicht aufhören, dafür Geld zu zahlen. Okay. Die Person in Rot, die schon lange wartet hat. Ich denke, ich bin auf der Seite des Pro-Apfang. Sie möchte Leute erinnern, nicht jeder hat 40 Gigabyte pro Sekunde für die Produkte. Warum wir haben für teure Verbindungen teure Produkte mit 100 Tänzen arbeiten? Wir hätten gerne Proxies für die User, für die sie sich entscheiden können auf eine einfache Art und Weise mit TLS möchten gerne eine Lösung haben, ohne Hacking umzufangen. Leute, die im Wohnzimmer gute Internetverbindungen haben wollen, denken einfach Verschlüsselung, Verschlüsselung und denken aber nicht an man in the middle. Es ist also, wenn man eine gute Verbindung hat, es ist einfach die anderen Fälle zu vergessen. Ich denke, da war keine Frage. Ein Kommentar nur. Wir sind ein bisschen privilegiert hier und wir sollten darüber nachdenken, aber der Anliegen ist, dass Proxies auch Caches sein können. Das wäre ein Einsatz. Das Problem mit Caching ist, man kann weniger und weniger caching sowieso, weil Content mehr dynamisch wird und Caches haben sehr wenig gute Anwendung heutzutage. Die zusätzliche Sicherheit durch TLS und Besserungen ist viel wirkungsvoller als das, was man mit Caching erreichen kann. Ich bin nicht ganz in der Meinung. Ich sehe den Punkt ja mit Web 2.0 weniger weniger caching, aber wir haben ziemlich große Medien, die Mediendateien, die doch groß profitieren könnten davon. Nächste Frage von rechts. Ich möchte nur sagen, einige Punkte hinzufügen. Ich habe diesen Mediendatei auch ich glaube, wenn er warst sie brechen kleinen Zertifikate. Das ist etwas, was vielleicht nicht erwähnt wurde. Das habe ich nicht bemerkt, danke für diesen Hinweis. Ich habe mir aber erst angeschaut, aber ich habe nicht bemerkt, dass sie kleinen Zertifikate brechen. Das kleinen Zertifikate natürlich offensichtlich im Browser überprüft das nicht oder berücksichtigt das nicht. Hast du eine Idee wie man irgendwelche Eingriffe durch polukale Prozesse verhindern oder in die TLS-Session verhindern kann? Denn ich habe auch denke auch, dass das eine schlechte Praktik ist und sollte überhaupt nicht gemacht werden. Ein gemeinsames Interface würde einfach missbraucht von Werbeeinblendungsoftware. Ich denke, dies kann nur passieren wenn man Zugriff auf dem Klein hat. Diese Software muss etwas installieren in deinem Browser. Die Lösung hier ist, sei vorsichtig, was du installierst auf deinem Computer. Wenn du schlechte Software installierst auf deinem Computer, dann bekommst du schlechte Dinge. Ich verstehe aber, wenn wir eine Firmenumgebung haben, wo eine SSL-Injizierung üblich ist und der User hat wahrscheinlich keinen sinnvollen Weg, das zu beeinflussen, was auf dem Computer installiert ist, auf diese Weise können wir vielleicht etwas tun auf der Browser-Seite, es ist nicht sehr einfach solche Sachen zu machen. Grundsätzlich gibt es keinen Weg, wenn du Software auf dem Klein hast, die mit deinem Browser etwas anstellen möchte, dann gibt es keinen Weg um das zu verhindern. Das ist das Mehrwertproblem. Also etwas auf deinem Klein ist in Kontrolle. Ja, guter Punkt, danke. Es scheint kein anderer da doch, da ist noch eine Frage. Hi. Wenn es um Tierlässigkeit geht, warum kann ich keinen Kier auf eine Seite pinnen? Warum kann ich nicht einfach den Kier rausfinden? Du kannst den Kier pinnen. Also der Keypinning funktioniert so, dass der Key der Seite zugeordnet wird und du trägst ein Firefox T-Shirt, Firefox unterstützt das nicht. Doch Firefox unterstützt das seit zwei oder drei Versionen. Okay, ich erkanne mal auf dich zu und du musst mir das zeigen. Also es gibt diesen HTTP Public Keypinning-Standard, das jetzt ein RFC ist vom Server aus, nein, ich meine, als User möchte ich einen bestimmten Key auf eine bestimmte Seite pinnen und ich möchte es sehen, so dass ich es von Hand prüfen kann. Und das ist nicht möglich und ich weiß nicht, warum, besonders weil ich den Fingerprint des Zertifikats sehen kann. Du denkst über sowas nach wie die Zertifikatskontrolle und das Plug-in. Ich glaube, das benutzt ein Notar-Service. Ich denke nicht über Notar-Services. Also es hat ein paar Notzwerkeitsprobleme, wenn das Zertifikat sich ändert. Weißt du nicht, ob es eine legitime Änderung ist oder eine bösartige Angriff. Ja, aber dann habe ich die Möglichkeit, es nachzuschauen. Ich bin skeptisch bei allen Lösungen, wo der Nutzer wissen muss, was ein Zertifikat ist und wie es funktioniert. Denn das ist einfach nicht besonders benutzbar. Aber es können wir später diskutieren. Okay. Scheint, als wäre das die letzte Frage gewesen. Okay, bitte nochmal einen Runde Applaus für Hanno.