 Ich bin froh, hier zu sein. Sie wahrscheinlich auch. Und wir werden jetzt anfangen mit dem ersten Vortrag für heute. Es ist ein Sicherheits-Researcher bei SBA Research und er ist auch im CC Wien Teilnehmer. Heute werden wir einen Vortrag darüber hören. Alles, was Sie über Zitifikatsterspital wissen wollten. Und damit gebe ich weiter und einen großen Applaus für Martin Schmidiger. Vielen Dank für diesen schönen Einleitung und netten Worte. Ich bin Teilnehmer vom CCWien und wenn Sie irgendein Kommentar haben oder mich anschreiben wollen, dann finden Sie die Witternick auf den Lesungsfolien. So, worum ist dieser Vortrag? Worüber werden wir reden? Wir reden über Zitifikatstransparenzität. Das ist eine neue Idee im TLS-Ekosystem. Das heißt, viele Leute wissen nicht so viel darüber und werde ich eine kurze Übersicht darüber reden, was Zitifikatstransparenzität ist. Und wir werden uns auch anschauen, wie es wirklich funktioniert und wie man damit spielen kann. Eine der wichtigen Sachen bei mich, ich bin ein großer Fan von Internet Memes und obwohl diese wunderschöne Bilder sind oder witzige Bilder, die ich online gestellt habe, ich denke daran, dass HTTPS ein wichtiges Thema ist und Sie Internet Banking machen oder Google benutzen oder was auch immer Sie online machen, HTTPS ist da, um Sie zu schützen und Ihre Privatsphäre zu schützen und in einigen Ländern, und das wurde von der Geschichte gezeigt, stimmt das nicht. Es gibt landesweite Inspektionsgeräte, die die TLS aufbrechen und den Inhalt anschauen und Menschen werden von der Sicherheitspolizei besucht werden, die an der Tür klopfen. Gerade diese Woche ist es in der Türkei passiert, wo Leute Sachen auf Facebook gepostet haben und deswegen festgenommen wurden. Obwohl das ein paar sehr witzige Fotos drin sind, es ist ein sehr wichtiges Thema und es ist auch nur eine Hilfe meines Vortrags. Für mich ist SSL ein sehr wichtiges Thema und CT, also Zertifikationsdansperität, ist ein sehr wichtiges Thema. Warum gibt es diese Zertifikationsdansperität überhaupt? Wenn ihr eine Zertifikationsauthorität seid, dann müsst ihr eure eigenen Zertifikate, die Sie ausgestellt haben, veröffentlichen. Und es gibt sehr viele Geschichten und Werkzeuge. Es begann alles mit einem Hack. Das 2011 war diese niederländische Zertifikationsautorität und die wurden übergenommen. Sie wurden wirklich komplett übergenommen. Sie haben alles verloren. Sie haben alle ihre Zertifikate verloren. Und das Teil dieses Zertifikats wurden 500 falsche Zertifikate ausgestellt und nicht nur irgendwelche Zertifikate, nicht nur letzten Crypt, wenn man ein freies Zertifikat bekommt, dann vielleicht wird die eigene internen Systeme für den Zertifikat benutzen können. Nein, wirklich große, wichtige Domain-Zertifikate. Groß, wichtige Zertifikate. Zum Beispiel Google.com. Wenn man dort mitlesen kann, wenn die Information dort an E-Mails gesendet wird, ist es wichtig. Oder WindowsUpdate.com. Das ist die Hintertür für einige der Windows-Systeme. Mozilla.com. Damit könnte man ein Firefox-Download mit den Zertifikatsignieren und über anscheinend sichere Webseiten veröffentlichen. Und genauso Torprojekt. Das war 2011. Und das war nicht nur ein kleiner Vorfall, es war nicht nur eine kleine Zertifikations-Utzerität, sondern es war eine ganz normale Zertifikations-Utzerität mit ganz normalem Business. Und was noch mehr ist, diese Zertifikate wurden dann benutzt, um die Kommunikationen abzuschniffeln. Und Leute, die ihre E-Mails gesendet haben. Firmen, die das nachher untersucht haben, haben gemerkt, dass mehr als 300.000 E-Mail-Adressen zu Google.com sich verbunden haben und haben danach dieses falsche Zertifikat bekommen. Die waren größtenteils aus dem Iran. Und anscheinend waren das Zertifikate aus dem Iran. Leute dachten, sie wären sicher mit HTPS verschlüsselt, Google anschreiben. Aber sie waren es nicht. Und das ist eine wunderschöne Folie aus dem Video, die Leute von FoxIT, die diesen Vorfall untersucht haben, die haben OCSP Request untersucht. Jedes Mal, wenn sie das Zertifikat bekommen, muss überprüft werden, ob dieses Zertifikat immer noch gültig ist, ob es zurückgerufen wurde. Wenn es zurückgerufen wurde, dann wäre es gut, es nicht mehr zu benutzen. Eine dieser Ideen, wie man das benutzen kann, ist dieses OCSP. Dieser Klein fragt bei der Zertifikations-Autorität, hey, ist dieses Zertifikat noch gültig? Und diese wurden mitgeschrieben. Jeder der dieser Requests war ein Klein, der dieses Zertifikat sah, dieses falsche Zertifikat sah und DIGINOTAR nachgefragt hat, hey, ist dieses Zertifikat immer noch gültig? Und wie Sie sehen können, die meisten Verbindungen sind, bewegen sie, man sieht sie und wir Leute schlafen und wieder aufwachen. Und die meisten Leute sind aus dem Iran. Also, wie wurde DIGINOTAR übernommen? Sie wurden wirklich, wirklich schlimm gehackt, weil sie überall Verwundbarkeiten hatten. Ihr System war unverständlicherweise unsicher für eine CA und Experten sind der Ansicht, dass wenn du eine CA betreibst, dann muss man das nötige Fundament bauen, um eine sichere Infrastruktur zu betreiben. Und wenn man so was macht, dann ist der Eindruck der Leute, dass man das sicher tun sollte. Und DIGINOTAR hat das nicht getan. DIGINOTAR hatte ungepatchte Software, eine alten Version. Sie hatten keinen Antivirus auf den Maschinen, die diese Zertifikate ausstellten. Sie hatten keine starken Passwörter für ihre Admin-Accounts. Der Report ist zwischenzeitlich öffentlich geworden. Den kann man online lesen. Mit Empfehlungen der Anise, die auch die ganzen Abweichungen und die Zertifikate, die bei DIGINOTAR aufgetreten sind. Alle Zertifikate wurden in einer Windows-Domain ausgestellt. Und was auch relativ schlecht war von DIGINOTAR, sie haben den Incident geheim behalten. Sie wollten dem Internet nicht berichterstatten, dass bei ihnen was passiert ist. Sie haben das vertuscht über mehr als zwei Monate, nach zwei Monaten. Wenn es öffentlich wurde und das Internet rausfand, dass bei DIGINOTAR wirklich ein großer Angriff stattfand, dann ging DIGINOTAR Bankrot. Das ist das traurige Ende der Geschichte. Das ist aber nicht nur eines der Probleme, die CAs haben. Wenn man eine CA betreibt, dann verifiziert man die Identität in seiner Kunden und stellt Zertifikate aus. Man kann aber auch Sub-Root-Zertifikate ausstellen, Zwischengeschalt Zertifizierung stellen. Wenn man einen Kunden für vertrauenswürdig hält, kann man dem selber die Macht geben, selber Zertifikate auszustellen. Das ist wie das Business-Model von HTP. Das ist wie das Business-Model von HTTPS und von X509 funktioniert. Die CA kann solche Zertifikate ausstellen, kann auch die Berechtigung ausstellen, weitere Zertifikate auszustellen. Das Ziel solcher CAs ist es, in den Truststore eines Browsers oder vor der Betriebssysteme zu kommen. Jeder Browser, jedes Betriebssystem, hat einen Truststore, in dem es eine Liste der Zertifizierung stellen, die von diesem Produkt vertraut werden. Diese Truststore Tours werden aber nicht im Detail auditiert. Die Zertifizierung stellen müssen zwar aufzeigen, dass sie in ein Audit gemacht haben, aber wenn sie mal in einem Truststore drin sind, dann ist die Motivation relativ schwach, weiter saubere, laufende Audits zu machen, weil sie bereits vertreten sind. Das kann dazu führen, das kann zu vielen Problemen führen. Eine andere CA Trustwave hat 2011 eine Sub-CA ausgestellt, also eine untergelagerte Zertifizierung Stelle, die weitere Zertifikate ausstellen durfte. Diese CA wurde benutzt für Traffic Introspection, also für das Aufbrechen von sicheren Verbindungen für Appliances, die zum Beispiel in Firmen-Netzwerken eingesetzt werden können, bei Großfirmen, um den Web-Traffic ihrer User zu überwachen. Ein anderer Fall war Lenovo. Superfish war eine lokal installierte Man-in-the-Middle-CA. Die hatte TPS-Verbindungen aufgebrochen hat, damit dieses Produkt auf dem lokalen System Werbung in die Webseiten initiieren konnte. Sogar wenn man Gmail benutzt, mit diesem schönen, eleganten Interface ohne offensichtliche Werbung, konnte Superfish die Verbindung zwischen dem Browser und Gmail aufbrechen und konnte in Gmail drin riesige Overlay-Werbung anzeigen. Lenovo hat aufgehört mit Superfish zusammenzuarbeiten. Das war auf einigen Lenovo-Notebooks. Diese CA war auf dem lokalen System installiert, damit Superfish diese Verbindungen aufbrechen konnte. Was noch interessanter ist, ist, dass alle CA's auf jedem dieser Lenovo-Notebooks denselben Key hatten und dieser Key, dieser CA, im Arbeitsspeicher des Lenovo-Geräts waren. Das heißt, alle Nutzer eines solchen Lenovo-Geräts konnten den Key aus ihrem Arbeitsspeicher auslesen und mit diesem Key konnten sie alle Verbindungen unterbrechen, die auf einem Lenovo-Gerät endeten. Das heißt, auch auf anderen Gräten nicht nur dem eigenen. Mittlerweile tun sie das nicht mehr, sagen sie. In China, CNNIC hat ebenfalls eine Sub-CA für Introspection ausgestellt. Die Firma wollte Appliances verkaufen, die harte TPS-Verbindungen aufbrechen konnten, um in den Traffic ihrer User reinzuschauen. Und dieses Jahr gab es einen Incident bei Symantec, die Test-Zertifikate ausgestellt haben, mit Certificate Transparency unter anderem. Man hat das Zertifikate für Google.com, die wahrscheinlich Google nicht mochte. Das Ding mit diesem Incident ist es, dass Symantec Certificate Transparency schon installiert hatte. So, Traffic Introspection. Das ist ein gültiger Anwendungsfall. Wenn man zum Beispiel eine flotte Flugzeuge hat, die verbunden sind mit teuren Satellitenverbindungen und die Anwender viel bezahlen für die Verbindung, dann möchte man als Betreiber dieses Systems wahrscheinlich Netflix zum Beispiel blockieren, um zu vielen tollen Traffic zu verhindern. Ein Beispiel ist GoGo. Die hatten Traffic Introspection-Device in ihren Flugzeugen und haben Zertifikate ausgestellt, die nicht vertrauenswürdig waren, um diesen Traffic einzusehen. Adrian Porterfeld, die bei Google arbeitet, hat bemerkt, dass GoGo in den Flugzeugen Zertifikate ausgestellt ist und den sichtbaren Tweet getweetet. Auch wenn Traffic Introspection wirklich schlecht tönt, ich kann mir vorstellen, dass es Situationen gibt, in denen es ein gültiger Anwendungsfall ist. Wenn man eine Bank betreibt, wenn man eine Firma betreibt, dann kann es sein, dass man sowas tun muss. Es muss aber transparent sein und die Anwender müssen wissen, dass jede Verbindung unterbrochen wird und alle Bewegungen sichtbar sind. Also, das ist das Big Picture, wieso wir Certificate Transparen Sie brauchen. Damit wir sehen, welche Zertifikate von einer CA ausgestellt wurden, einige kleine Probleme, nicht wirklich klein, ist, dass TLS seine Probleme hat, egal, ob diese Zertifikate ausgestellt wurden oder nicht. Die Verifizierung eines Zertfikats ist ziemlich kompliziert. Sobald ein Zertfikat ausgestellt wurde, ist es gültig bis zum Ablaufzertfikat, dass ein Zerti, Ablaufdatum, das ein Zertfikat ersichtlich ist. Das kann bis zu drei Jahre dauern. Wenn man so bei der ersten Anwendung eines Zertfikats sieht, dass das Zertfikat revoziert werden sollte, dann kann ein Kunde trotzdem noch bis zum Ablaufdatum dieses Zertfikat einsetzen. Eine zweite Limitation ist, dass alle CA-Zertifikate für alle Common Names, alle Website ausstellen können. Die 1800 CA's, die es gibt, und Sub-CA's, können Zertifikate für Google.com oder Facebook.com oder jede andere Domain ausstellen. Es gibt keine Verhinderung durch außer Social-Social-Kontrolle und Verträge, um dies zu verhindern. Dass die Zahl von 1800 CA's und Sub-CA's war von einem Paper von 2013, seither gibt es ja wahrscheinlich mehr. Ein zweites Paper in 2014 hat aufgezeigt, dass ein Drittel dieser 1800 CA's und Sub-CA's niemals ein einziges HTTPS Zertfikat ausgestellt haben. Es stellt dann die Frage, wieso sind diese CA's in den Trusts oder Doors? Was tun die da? Und der Verdacht ist, die sind wahrscheinlich, wenn die eingesetzt, Umzertifikate zu generieren, die dann in privaten Netzwerken verwendet werden, die gar nicht das breite Internet treffen. Dann gibt es natürlich Implementation-Issues. TLS hat eine lange Geschichte von Implementation-Problemen, z.B. Logjam, Poodle und so weiter. Die sind eine komplett andere Kette von Problemen, aber die Issues betreffen natürlich auch die Sicherheit von Devices, und zwar laufend. Ein bekanntes Beispiel ist IOS, das z.B. ein fehlendes Go-to-Fail Bracket in der Kurzseile hatte, das gescheitert ist. Viele Embedded Devices haben das Problem dass sie bei der Pood Sequence keinen Zugang zu starker Entropie haben und deshalb dort denselben Key generieren, den sie dann für TLS-Verbindungen verwenden. Wie auch bereits erwähnt, wir haben verschiedene Trusts oder Doors pro Produkt, pro Betriebssystem, Browser und so weiter. Das heißt, jedes CA muss versuchen, in jeden dieser Trusts zu auszukommen und in jedem dieser Updates vertreten zu sein, nicht abhanden zu kommen. Wir haben eine große Diversity, eine große Vielfalt von CAs in verschiedenen Trusts. Und dann gibt es auch noch viele Ausbreitungsprobleme. SSL Version 2, jeder versenkt, dass es tot ist, aber anscheinend ist es immer noch lebend. Sebastian Schinzel wird da einen guten Vortrag überhalten morgen über den Drown Attack. Und dort wird SSL V2 Probleme in E-Mail-Transport benutzt werden. Nur weil es aktiv ist und dieselben Schüssel benutzt, kann man dort drüber gute TLS 1.2 Verschüsselungsmethoden angreifen. Nur weil es immer noch da ist. Das ganze Problem mit dem SHA-1-Zertifikaten und Zertifikationsautoritäten, die sollen kleine SHA-1-Zertifikate mehr ausstellen. Einige machen es immer noch, bei anderen wird es herausgefunden, dann gibt es Cypher-Suits, es sind mehr als 500 krypografische Verfahren für unterschiedliche TLS-Versionen verfügbar. Und jeder Administrator möchte gerne eine möglichst sichere Version benutzen. Aber welche soll er bis sie benutzen? Sobald Geld dabei ist, z.B. Emerson, dann müssen sie zusammen funktionieren mit Intellexpress 6 und weiter und so weiter. Es ist wirklich, wirklich kompliziert. Und dann natürlich E-Mail und Statt-TLS. E-Mail war noch nie daran gedacht worden, dass sie Sicherheit und Authentifikation integriert haben. Also haben sie es einfach noch drauf gebaut und mit Statt-TLS dran geflencht. Das Problem mit Statt-TLS ist, dass es unterbrochen werden kann und Menschen werden Plaintext benutzen, wenn Statt-TLS nicht funktioniert. Perfektive Forward Secrecy ist auch so ein Problem. Verbreitung ist noch so ein großes Problem, was eigentlich auch noch seit einem eigenen Vortrag wird. Und außerdem werden Zertifikationsautoritäten standarddärmermäßig gekauft und übernommen. Symantec ist eine der größten Zertifikationsautoritäten, die große Teile des Zertifikationsautoritäten veröffentlichen. Und BlueCode wurde in arabischen Frühling benutzt. Die hatten Proxies, die dort SSL unterbrochen wird und die von einem ISP in Syrien benutzt werden. Die wurden überall ausgestellt. Und wenn Sie jetzt darüber nachdenken, dass Symantec eine der größeren Zertifikationsautoritäten BlueCode kauft, dann sieht das komisch oder zumindest gefährlich aus. Natürlich versprechen Sie, dass Sie niemals Symantec Zertifikate benutzen, um Benutzer auszuspielen. Das ist der Situation, der wir sind. Das ist okay. Es ist nicht in Ordnung. Aber Leute denken immer noch, dass es HTPS sicher ist und es hat uns ein Jahrzehnt gedauert, bis wir Leute beigebracht haben, dass sie das Schloss-Icon anschauen müssen. Aber sie müssen gar nicht wissen, wie das Schloss-Icon funktioniert. Aber das ganze Schloss ist nur eine Show. Wir sitzen jetzt in einem Raum mit Flammen und alles ist nicht so, wie es scheint. Dieses, wo Zertifikationstransparenz ins Spiel kommt. Zertifikationstransparenz hat das Ziel schlechte Zertifikate und Zertifikationsautoritäten zu finden. In der perfekten Welt würde jede Zertifikationsautorität alle Logs veröffentlichen. Alle Zertifikate, die es ausführt, veröffentlichen. Also, sobald ich ein Zertifikat für Schmidikat.net zum Beispiel finden würde, dass ein Teil des öffentlichen Schlüssels es kann öffentlich sein. Und wäre es nicht schön, die Zertifikationsautorität veröffentlichen würde, dass sie gerade eine Zertifikation für Schmidikat.net ausgestellt hat. Grundsätzlich, ja, Zertifikationsautoritäten wollen dies aber nicht tun. Es ist besonders nicht, wenn sie komischen Ländern oder Firmen, die ihr Geld mit solchen Verkehrsanalyse-Tools benutzen. Und die Idee ist, dass alle Zertifikationsautoritäten für jede Zertifikationsautorität veröffentlicht würden. Sagt, hey, die ich habe in dieses Zertifikat ausgestellt. Jeder könnte sich anschauen und verifizieren. Und es wäre eine bessere Welt. Ja, dies würde dabei helfen, Probleme sehr früh zu finden. Also, wenn eine kleine niederländische Zertifikationsautorität veröffentlichen würde, für Google.com oder für theTropHodger.org, dann würde man das sehen. Das ist eine kleine Zertifikationsautorität. Die sollten wirklich überrascht sein, wenn Google mit ihnen eine Zertifikation ZFTFG Card bestellen würde. Das würde diese Angriffsmöglichkeit reduzieren, die Zeitliche. Und auch die Idee, dass eine Möglichkeit diese schlechten Zertifikationsautoritäten zu bestrafen. Wenn eine Zertifikationsautorität aktuell Probleme hat, dann müssen sie extra schwer Sachen nachbeweisen und wieder in die Zertifikationsautorität zurückwerfen. Das, was Google getan hat, Google hat beschlossen, dass sie, dass Internetmäßig entsicherer wird. Warum hat Google das beschlossen? Google ist eine sehr große Firma. Sie unterstützt, sie haben den Browser und den Clients, z.B. auch bei Android. Aber sie haben auch einen großen Anteil der Server, das ist unsere Erholkontrolle. Jeder benutzt Google, außer die, die Bing benutzen. Okay, nein, das wäre so ein Spaß. Was Google gemacht hat, ist, dass sobald Diginotar sicher war, haben sie ihre Zertifikate gepinnt. Da Google einen sich guten Zertifikations, ein Update-Zeikel hat, dann veröffentlichen sie die Zertifikate, die sie vermuten mit den Browser-Updates. Wenn der Browser im Hintergrund geupdatet wird, dann kann es die spezifischen Zertifikate, die sie zu sehen vermuten für Google.com oder YouTube.com, überprüfen. Außerdem hat das einen sehr großen Market-Anteil. Mehr oder weniger 50 Prozent, die man erzählt, Chrome und Chromium sind ziemlich beliebt. Und außerdem sind sie ein häufiger Angriff zu zählen. Also, wenn jetzt ein Diktator beschließt, die allen Verkehr, unser Benutzer-E-Mails zu unterspritzen, dann versuchen sie, in der Regel Gmail zu untersuchen. Sie haben eine gute Sicherheit. Sie haben keine anderen bekannten Hintertüren, um zu dem Inhalt vorzudrehen. Und dieser Angriff auf Gmail ist ein sehr drastischer Angriff. Diese Veränderungen in Chrome können Sie jetzt diese Angriffe erkennen. Das war schon zurück in 2011. Seitdem, zum Beispiel, seitdem ich zum Beispiel seit dem Android-Porter-Feld-Tweet, den ich euch gezeigt habe, seitdem, wenn man auf einer Website geht mit Chrome und ein betrügerisches Zertifikat sieht, das von Google, auf einer Google-Seite, dann warnt Chrome den Anwender. Was Google-Seite getan hat, ist, einen Standard vorzuschlagen, wie man transparent solche Logs veröffentlichen kann, die erstellt werden, welche Zertifikate ausgestellt wurden. Die Idee dieses RFCs ist es, dass jedes Zertifikat ausgestellt wurde, öffentlich ist. Das ist implementiert in einem öffentlichen Append-Only-Log, einem Log, an das man nur anhängen kann. Google hat eine API, eine Schnittstelle, auf der man jedes Zertifikat melden kann. Dann wird kryptografisch versichert, dass dieses Zertifikat öffentlich gelockt wurde und das ganze System ist offen für alle. Man kann auf einer Website den QR-Code runterladen, kann eine eigene Certificate-Transparency-Log, einen CT-Log-Server laufen lassen und den veröffentlichen. Das Ziel ist es, CAs festzustellen, die sich falsch verhalten. Die CAs machen Audits durch, die haben Regulationen, aber nicht auf der Stufe der Zertifikate. Mit Certificate-Transparency kann die Öffentlichkeit nachvollziehen, welche Zertifikate ausgestellt wurden und sehen, ob eine CA ein Zertifikat für zum Beispiel Google.com ausgestellt hat. Also, beim Lesen des RFCs erkennt man drei verschiedene Entitäten dieses Systems. Es gibt Logs, Protokolle, die eigentlich riesige Staubsauger, die sammeln alle Zertifikatsinformationen, die ihnen zugestellt werden und signieren diese kryptografisch und veröffentlichen dann eine Bestätigung, dass dieses spezifische Zertifikat aufgezeichnet wurde und nicht verändert wurde. Dann gibt es Monitors, die verdächtige Zertifikate identifizieren. Das sind normalerweise die CA selber, die solche Monitors laufen lassen und zum Schluss gibt es Auditors. Diese sind normalerweise im Browser implementiert und die verifizieren, dass die ausgestellten Zertifikate wirklich gelockt werden in einem Protokoll. Wenn wir das im Detail anschauen, ist die Rolle des Monitors und des Auditors ungefähr austauschbar. Eines kann als das andere handeln. Was der Monitor macht, ist, es sammelt alle Zertifikate. Man hat diese riesige Sammlung von Zertifikaten, die kryptografisch verifiziert wurden. Was wir gleich sehen werden. Und der Monitor, der sammelt alle diese Zertifikate. Es gibt einen semantischen Check, der prüft, ob ein Zertifikat für meine Domain ausgestellt wurde. Gibt es eine Sub-CA, die die Möglichkeit hat, einen Zertifikat für Traffic Introspection auszustellen und so weiter. Was mit diesen Daten auch tun können, ist, sie können Lock-Operators identifizieren, die sich falsch verhalten. Diese Locks sind gigantische Sammlungen der Arten und die müssen auch geprüft werden natürlich. Die haben eine Machtposition, weil sie diese riesige Sammlung an Zertifikaten verwalten. Und es ist nötig, dass man auch diese Locker prüft, dass man auch deren Sicherheit sicherstellt. Das machen die Monitors. Jeder Kleint, zurzeit, ist das Chrome. Chrome prüft die Certificate Zertifikationsinformation. Die Browser und alle anderen Kleins, die können die Integrität des Locks prüfen. Im Backend produziert das Lock ein Hashtree, eine Baumstruktur von Hashes, zu der wir in ein paar Sekunden kommen werden. Monitors und Auditors fragen ab, ob die Lockentität richtig funktioniert. Es wäre also ein gutes Ding, wenn China als zu Google gehen könnte und Google darauf hinweisen könnte, dieses Zertifikat muss weg und Google sich dann entscheiden kann, ob es weg muss oder nicht. Mit Certific Transparency wäre dieser Prozess nachvollziehbar. Das Gute ist, jeder hier von euch in diesem Raum, jeder Anwender, kann eine Log-Entity starten, kann Zertifikate sammeln, spielt keine Rolle, ob ihr eine Zertifikatsautorität seid. Ihr könnt einfach ein öffentliches Lock starten und Anwender und CAs können dorthin Zertifikate pushen. Zurzeit ist das nicht der Fall. Normalerweise lassen die CAs diesen Monitors und Locker laufen, aber das ist nicht so vorgesehen oder nicht so notwendig. Jeder kann das tun. Das Problem ist die Verfügbarkeit. Auch wenn ich ein Lock für ein Zertifikat veröffentlichen kann, ich muss sicherstellen, dass mein Lock 7x24 online und verfügbar ist. Mein ISP hat keine Freude an mir, wenn ich dafür nicht sehr, sehr, sehr viel mehr zahle, als ich das jetzt tue. Wie funktioniert das? Heute, wenn ich ein Zertifikat möchte, gehe ich zu einer CA und sage, ich habe diese wunderbare Domain und ich möchte dafür ein Zertifikat. Die CA stellt dieses Zertifikat dann aus. Weiter mit Certific Transparency muss die CA, beim Ausstellen des Zertifikats, egal welches CA es ist, es kann jede Zertifizierungstelle sein, Let's Encrypt oder eine andere, die müssen das Zertifikat aufzeichnen und es zu einem der Locks senden. Das Lock, um das Zeichnet dann oder bestätigt dann den Erhalt des Zertifikat und sendet sofort eine Bestätigung zurück, ein Blob, ein SCT, den Sign Certificate Timestamp. Dieser SCT kann dann den Zertifikat angehängt werden zur Bestätigung, dass das Zertifikat in einem Lock ist. Der wichtige Punkt, der springende Punkt hier ist, ist, dass, sobald der Server das Zertifikat zurückerhalten hat, dass das SCT hinterlegt ist und der Browser sofort prüfen kann, dass das Zertifikat in einem Lock ist. Vielleicht habe ich hier schon ein paar Leute verloren. Tut mir leid. Hier ist es nochmal bebildert. Das sind die Bilder von der Certificate und Resparency Website. Danke, dass Sie sie gemacht haben. Meine Skills sind nicht so gut, das hätte ich nicht so schön machen können. Zur Zeit gibt es die Certificate Authority, die ein Zertifikat ausstellt. Und die Website installiert es dann im richtigen Ordner des Webservers. Der Kleint prüft es, prüft die Verschlüsselung und die Verbindung ist verschlüsselt. Und der neue zusätzliche Schritt, das ist die schöne Sache, die kann passieren, ohne zusätzliche Schritte auf der Serverseite, das ist nämlich nur was, dass die CA die Certificate Authority machen muss, um nur das Zertifikat auszustellen, müssen Sie zusätzlich das Zertifikat auch an ein Lock setten. Vom Lock erhalten Sie sofort diesen Science Certificate Timestamp, SCD, zurück, der das Certificate in das Zertifikat eingebaut wird, bevor es zum Kleinen zurückgeschickt wird. Und der... Wenn man eine kleine Verbindung aufbaut, kann er den Server fragen, ob dieses SCD drin ist oder nicht. Die SCDs, die vom Lock zurückkommen, sind enthalten Timestamp, Zertifikat und die Lock-ID. Was auch interessant sein wird in der Zukunft, ist, dass ein Zertifikat mehrere Lock-Einträge haben kann. Der SCD ist wie ein Versprechen. Der Lock-Operator verspricht, dass er dieses Zertifikat in seinem Lock aufnimmt und jeder kann später prüfen, ob dieses Lock wirklich das Zertifikat aufgenommen hat. Oder ob die CA vergessen hat, das Zertifikat einzureichen. In der Zukunft können verschiedene SCDs in einem Zertifikat untergebracht werden. Das heißt, als CA kann ich verschiedene Lock-Operator benachrichtigen, dass ich ein Zertifikat ausaustelle und alle diese SCDs in das Zertifikat einbauen. Diese Signatur ist öffentlich und muss nicht privat gehalten werden. Es wird ein bisschen technisch. Es gibt verschiedene Wege, wie der Client verifizieren kann, ob das Zertifikat einen SCD hat. Einer davon ist OCS Pea Stapling. Wenn ich jetzt ein Zertifikat habe, kann ich den Online Certificates Protocol Report an das Zertifikat anhängen, um damit dem Client sofort zu bestätigen, dass das Zertifikat noch aktuell ist. Wie funktioniert es? Auf der Lock-Seite gibt es ein Merkel-Hash-Tree. Es ist eine wunderbare Datenstruktur. Es ist eigentlich nichts Neues und nichts besonders kompliziert. Es ist auch nicht die Blockchain. Der Merkel-Hash-Tree ist ein binärer Baum. Jeder Knoten in diesem Baum hat zwei Kinder. Und der Hash-Wert, der übergeordneten Knoten, hängt von seinen zwei Kindern ab. Das heißt, der Wert dieser beiden Kinder wird gehasht und kommt in deren übergeordneten Knoten. Das läuft immer so weiter. Das ist sehr platzeffizient. Um den ganzen Baum zu verifizieren, muss ich nur den obersten Knoten des Baumes prüfen. Und alles andere ergibt sich daraus. Daraus kann ich auch die untergeordneten Werte rekonstruieren. Certificate Transparency benutzt SH256 für diesen Tree. Und alles unter diesem Knoten ist verantwortlich für einen Hash in einem jeweiligen Knoten. Wenn ich einen Knoten verändere oder verschiebe, dann ändern sich die Hash-Werte aller übergeordneten Knoten. Jeder der Log-Betreiber nimmt dann versprechen, dass sie ein Zertifikat in das Log aufnehmen werden. Verspricht auch eine Maximalzeit, um das Zertifikat in das Log aufzunehmen. Das kann nicht immer sofort geschehen. Das Versprechen kommt sofort, aber das Einbindenden-Log kommt nach dem Maximum-Merch-Delay, das auch in diesem Versprechen enthalten ist. Normalerweise sind das 24 Stunden. Das Gute an dieser Datenstruktur des Merkle-Hash-Trees ist nicht nur, dass er Daten noch effizient ist und sehr klein. Es ist auch nicht möglich, Elemente in die Vergangenheit geschoben, Zeitstempel einzufliegen. Es gab in der Vergangenheit Fälle, wo CA's Zertifikate ausgestellt haben mit einem Datum in der Vergangenheit, mit SHA1-Zertifikaten. Man kann auch keine Elemente entfernen. Zum Beispiel, wenn Symantec ein Testzertifikat entfernen möchte, dann würde das auch auffallen. Wenn man eines dieser Blätter, einen Knoten aus dem Hash-Tree entfernt, dann ändern sich die Hashes alle Elemente bis zum Root, bis zum übergeordneten Element. Ich kann auch keine Elemente anfügen. Auch in diesem Fall würden sich die Hash-Werte alle übergeordneten Elemente verändern. Wie funktionieren nun diese Logs? Was sie normalerweise tun, ist jede Stunde, bekommen sie die Zertifikate und jede Stunde bauen sie sie in den Hash-Tree ein, in das Log. Das sind schon etwas viele Details. Die bauen dann einen separaten Hash-Tree und berechnen aus diesem Hash-Tree den neuen Root-Hash-Tree und berechnen daraus den neuen Hash-Wert, der dann versendet wird. Das Schöne an diesem Hash-Tree ist es, es gibt verschiedene Wege, wie man bestätigen kann, wenn man einen Tegrenn Hash-Tree hat. Man kann zum Beispiel prüfen, ob der Log-Operator ehrlich handelt oder nicht. Wenn der Operator ein Zertifikat entfernt, dann wird er sichtbar, indem alle betroffenen Knoten verändert werden. Das ist auch sehr effizient. Hier ein Foto vom CT, von der CT-Website. Auf der linken Seite hat man ein Merkle-Tree mit einigen hinzugefügten Zertifikaten angehängt, Zertifikaten. Wenn ein Monitor, ein Auditor das Log herausfordert, zu einem Audit, zum Bestätigen, ob diese Zertifikate 6 und 7 richtig angehängt wurden, dann muss der Log-Operator nur die markierten Notes einsenden. Das sind die Knoten, die jede Stunde überarbeitet werden. Die Zertifikate sind öffentlich, weil es Zertifikate sind. Und wenn nun jemand verifizieren will, dass nicht nur diese Zertifikate eingebunden wurden, das ist sehr einfach, wenn man nur den ganzen Weg aufrechnen muss, sondern auch verifizieren muss, dass alle anderen Zertifikate immer noch da sind, dann müssen sie nur drei Hash-Values prüfen, übermitteln. Und der Auditor kann dann alles nachberechnen, durchrechnen und überprüfen, und am Ende müssten die die Hash-Values übereinstimmen. Ein weiterer Beweis, der möglich ist, ist, dass ob ein spezielles Zertifikat immer noch im Log ist. Es ist nicht nur die Konsistität, an das ganze Log anzuzweifeln, mit alten Daten, sondern es ist auch möglich zu verifizieren, dass ein spezifisches Zertifikat immer noch im Log enthalten ist. Oder überhaupt in den Log gekommen ist. Dieses SCT, das sofort passiert, ist nur das Versprechen, diesen Zertifikat in den Log einzufügen. Und zu einem späteren Zeitpunkt kann irgendjemand, jeder Auditor, diese Log-Operator herausfordern, ob dieses Zertifikat wirklich eingefügt wurde. So, wieder, wenn ich das prüfen möchte, dass ein spezielles Zertifikat in diesem Log eingefügt wurde, dann weiß ich ja nicht, dieses Zertifikat, das ich herausfinden möchte. Und dann brauche ich nur diese drei Knoten. Alle anderen Knoten, diese J-Knoten wird berechnet. Wenn ich das Zertifikat habe, dann habe ich das Hash, das Zertifikat. Ich brauche diesen Hash, dann kann ich diesen Wert berechnen und so weiter. Bis zum Routknoten. Okay. So viel bei Merkel-Hash-Trace ist gut. Ein Problem dieses Zerlocks ist, dass sie immer nur weiter erwachsen sind. Kein einziges Wort darüber, wie man ein Zertifikat rauslässt mit gültigen Gründen. Sie wachsen die ganze Zeit. Und natürlich gibt es nichts, das für immer ist. Und was Log-Operatoren machen ist, sie rotieren die Logs. Zu einem spezifischen Zeitpunkt wird der Log gespeichert. Der Baum ist dann statisch. Und es wird ein neuer Log eingefügt für neue Zertifikate. Vor Kurzem hat Evierter von Google eine Pause gemacht. Es waren 64 Millionen Zertifikate. Ein kleines Problem mit dabei so einem Blog zu frießen. Solange ein Zertifikat in diesem Blog, in diesem Baum immer noch gültig ist, muss dieser Blog immer noch verfügbar sein. Sobald eine Zertifikate in dem Blog ausgelaufen sind, kann man ihn löschen. Aber bis zu diesem Zeitpunkt muss der ganze Baum verfügbar sein, um diese Beweise durchführen zu können. Ein der Probleme ist, dass im Moment nur wenige Log-Operatoren sind. In der Zukunft sollen da deutlich mehr sein. Nicht hundertausende, aber vielleicht hunderte. Und die müssen Informationen austauschen. Ein paar der Information der Logs muss erscheinen, wo die Logs mit den Kleinen reden. Dass sie auch dieselben Status des Merkel-Trees sehen. Und das wurde auch in einem Paper im letzten Jahr veröffentlicht. Im Moment ist die Idee noch nicht implementiert. Und es wird auch noch nicht notwendig. Das ist das Problem, wenn man Memes auf dem Zug benutzt. Der Regel, sehr schlechte Memes, anscheinend das Gossip Girl. Ich habe sie noch nie benutzt, aber wenn man die Gossip und Memen Google dann ist das, was man bekommt. Wer arbeitet jetzt an diesen Logs? Natürlich ist Google bei den meisten der Logs vorhanden. Die haben das Ganze vorgeschlagen. Die haben wegen Quakecode geschrieben, diese Logs durchzuführen. Und sie haben die großen, alle offenen Zertifikate. Drei sind aktuell offen. Das ist nur für Let's Encrypt-Zertifikate. Und ein Leiterer ist nur für nicht Let's Encrypt-Zertifikate. Natürlich veröffentlicht Let's Encrypt viele Zertifikate. Zum Glück haben sie die ja ausgeschossen. Die Mailing-Listen ist, dass diese drei offenen Logs geographisch und administrativ unterschiedens werden. Das sind unterschiedliche Organisationen, die sie laufen lassen. Die haben den selben Chef. Irgendwo wäre es besser, wenn es mehr offene Logs gäbe. Symantec hat auch einen Wohlsign, hat auch einen. Aber jedes Mal, wenn Google ein schlechtes Zertifikat für Google.com hat, werden diese Zertifikationsautoritäten... Also jedes Mal, wenn Google ein falsches Zertifikat findet, dann müssen diese einen Zertifikationszertibilität laufen lassen. Google hat Zehntes von Millionen Zertifikaten. Und die haben wirklich ein offenes Zertifikat. Und auch jeder kann dort Zertifikate herausschreiben. Digital Zert und Symantec sind ein bisschen groß. Und alle anderen Listen haben 100.000 Zertifikate, was nicht sehr viele sind. Im Vergleich zu 50 Millionen oder 60 Millionen bei Google. Im Moment verlangt Google schon Zertifikationsautoritäten für Extended Validity-Zertifikate. Wenn man nicht nur das grüne Schloss sieht, sondern auch diesen grünen Balken oder großen Namen und viel, viel grün, dann ist das ein Extended Validation-Zertifikat. Und Google verlangt, dass alle Extended Validation-Zertifikate zwei hat. Firefox ist dabei, das zu einzuführen. Und ja, außerdem funktioniert Transparenz weil wenn Google ein Zertifikat veröffentlicht hat, dann sagen sie, hey, ich habe 23 Testzertifikate gefunden. Symantec sagt, es hat 23 Testzertifikate ausgestellt. Aber die Logs sind öffentlich. Man kann sich das anschauen innerhalb von Sekunden, kann man sehen, dass Symantec auch noch 164 andere Zertifikate ausgestellt haben für andere Domains und 2.500 Zertifikate für nicht existierende Domains. Nur bei diesem ein Problem. So, wir müssen ein bisschen beheilen, es ist wenig Zeit. Ein paar Probleme mit Zertifikations- Öffentlichkeit und Zertifikat, die man kann, wenn man das Internet hat und das Internet ist nur innerhalb des LANs erreichbar und man möchte den Browser-Warning umgehen wenn man dieses Interface benutzt, dann kann man ein Netz-Inkrep-Zertifikat anfordern, aber da nicht nur Zertifikat öffentlich ist, sondern auch gelochte ist, können Leute sehen in den öffentlichen Logfurtastein, in der Domain eingetragen werden. Außerdem müssen Log-Entries den gesamten Chain zu einem vertrauenswürdigen Grundzertifikat hast. Das heißt, selbst signierte Zertifikate können dort nicht hinzugefügt werden, auch keine von DNE, also über den ESSEC veröffentlichte Zertifikate, unter diese beiden keine vertrauenswürdigen Grundzertifikate haben, können diese nicht für Zertikats- außerdem möchten sie da durch die Daten sehen, sie wollen da mit rumspielen und grundsätzlich kann man alles mit JSON abrufen, also wenn sie mit JSON was arbeiten können, dann kann sie mit Transparatels Zertifikat Transparatels arbeiten. Dieses ist die URL DNE-Logserver antwortet mit dem aktuellen Rout mit der Zertifikat mit dieser URL und interessantesten steht dort auch die Anzahl der Zertifikaten und Timestamp sieht aus so das ist das Aviator-Log, der jetzt festgeschrieben wurde paar Millionen Zertifikate die Hashwert des Merkel-Baums und die Signatur außerdem können sie die einzelnen Zertifikate herausfallen mit Konsistitizbeweise sie haben zwei Stati des Baums und der Log muss beweisen dass er dazwischen nichts verändert hat und außerdem kann man verifizieren, dass spezielles Zertifikat in dem Baum ist mit dem zweiten Antrag und außerdem können sie die Zertifikate dahin posten mit ein Post-Request sie die öffentlich ist wenn es ein Zertifikat ist und wenn sie in Lockerbarter sind dann müssen sie das jetzt inkludieren jedes Webseite die nicht benutzen müssen nur ein paar Post-Request senden nix weiter ein paar Bildschirmen Seiten des Internas desfigur.com Netinternals Ansicht und was sie sehen können ist dass alles geprüft wurde und gültig ist und alles geprüft wurde Google und Chrome alles funktioniert super zu der Letzt Commodore hat auch eine große Such CRT da ist er wo öffentliche Zertifikate gesucht werden können außerdem hat Facebook das heißt wenn sie eine Domain-Name besitzen und eine Identität wenn sie ein Domain haben können sie Updates bekommen wenn das Zertifikat sich verändert also sie überprüfen auch die öffentlichen Logs und sobald zum Beispiel Facebook.com ein neues Zertifikat benutzt dass in einem CT gelockt wird dann können sie dort eine Funktion bekommen aber ich denke Facebook hat auch BGP E-Mails senden das heißt es wird auch nichts an irgendjemandem gelegt und dieser Screenshot wurde ausgeliebt noch ein paar weitere Punkte vor wenigen Monaten hat Google gesagt dass sie Zertifikations-Sensität erfordern ab Oktober 2017 das heißt wenn sie ein Zertifikat mit DLS haben müssen sie vor diesem Datum überprüfen ob ihre Zertifikation Zertifikations-Transferität veröffentlichen ich erwarte dass dann mehr Zertifika veröffentlicht werden in der weiten Zukunft ist die Idee dass das ganze Merkelbaum für alles offen ist dass sie auch Keymanagement für die Releases da reinschreiben das Team für Google das es gebaut hat hat auch ein Prototyp dafür geschrieben das ist Australia macht überprüfbare Datenstrukturen und bevor wir jetzt zum guten Ende kommen und Fragen und Antworten machen da gibt es den Unterschied natürlich können sie dieses Problem mit Blockchain lösen aber ein Merkel-Hash-Tree ist sehr viel effizienter ist sehr eleganter und als ich den Kollegen damit gefragt habe, sagten natürlich können sie auch das Log in die Blockchain schicken aber ist nicht dasselbe also vielen Dank das war den sehr schönen Vortrag, wir haben noch ein paar Fragen für Fragen wenn sie irgendwelche Fragen haben stellen sie sich bitte hinter einen Mikrofon und frage sie ihre Frage bislang denken Fragen haben ein Fragezeichen damit wenn sie jetzt gehen bitte leise und durch die vordere Tür bitte nur durch die vordere Tür gehen da hinten ist eine Frage hallo ja ok können sie Software vorschlagen wo man ein TLS Handshake vom kleinen Seite das SCT unterstützt nicht ganz spontan wenn es Teil des TLS Zertifikat ist dann kann OpenSSL das wenn sprechen fällt auch alles was aus CSP kann das kann das die CT extension nicht kennen einfach diese extension nicht kennen aber der Rest ist aus CSP Handshake müsste funktionieren hallo willkommen wie viel Platz braucht man um den ganzen Logs zu speichern ich hatte die selbe Frage aber weiß es leider nicht nein was sie speichern ist der ganze Tree und die ganze Cater ohne die Route-Zertifikate wahrscheinlich zwei, drei, vier Zertifikate pro Eintrag was ich denke das an einem normalen Elektronik-Diskount da kann man ein Hard Drive kaufen dass es auf das ein ganzes Log passen müsste nächste Frage hallo vielen Dank für den Vortrag auch ob wir zwei SCTs für erweiterte Quality weil eine einzelne Entität möglicherweise was Falsches machen könnte bescheisen könnte auch wenn man weiß dass man das erkennen könnte dann gäbe es immer noch eine Verzögerung wenn man zwei Entitäten hat dann ist die Wahrscheinlichkeit kleiner dass beide Entitäten zusammenarbeiten würden ich bin ein bisschen überrascht weil Google dafür versucht die Server hallo so klein wie möglich zu machen und das veröffentlich vergrößert das Service hallo mit dem SCP und sie versuchen auch OSCP zu machen also es macht es noch größer und das sind chart 256 also sind das 256 bits und noch ein Wetter und eins reicht nicht ne noch nicht es ist für größer die Größe frei ist wohin geht das das verhält mir einfach die ganzen Kosten aufbrauchen oder können wir die Kosten bezahlen ich denke die Kosten sind klein verglichen mit den Vorzügen die man durch HDB2 bekommt und wenn man die Daten durch eine Verbindung durchschläuzt dann sind die Kosten nicht mehr so groß aber du hast recht es ist eine Entscheid wie viele die man verwenden will um FROD zu verhindern soll dies Sachen wie das SSL Observatory ersetzen soll und außerdem wie funktioniert das mit Leuten die ihre Zertifikate nicht öffentlich haben können für interne Netzwerke wenn das Zertifikat nicht veröffentlicht werden darf dann ist wahrscheinlich der bessere Weg zur Zeit dass man eine CA verwendet die CT nicht verwendet in der Zukunft wird das viel teurer man muss dazu sein eigenes CA laufen lassen die man in den eigenen Truststores verteilen kann die Zertifikate selber signieren in Oktober 2017 wenn alle Zertifikate die keinen Timestamps haben was mache ich dann? Use Edge Edge verwenden I'm sure you can disable it somehow but it's raw was ist okay sorry sorry nicht verstanden ist es möglich das ohne Zertifikationsautorität zu machen über SCT ja ja ich hab jetzt auch die Frage mich zu 100% verstanden die Frage scheint zu sein ob man eine DHT eine verteilte Hashtable machen könnte und die Antwort ist eher nein es wäre sicher möglich eine Browser extension zu machen die eine solche DHT verteilt führt aber zurzeit ist sowas nicht vorgesehen aber die Qualco ist offen ich hab die Frage wie funktioniert es mit der Endzertifikate dass man zurückruft in den Baum wenn der Baum festgefroren ist und wie funktioniert es wenn der Baum feststeht gute Frage das Ziel von CT ist nicht die Revozierung zu unterstützen der Revozierungsfahrt funktioniert ganz regulär aus CSP ist davon nicht beeinträchtigt CT soll nicht die Revocation unterstützen sondern nur sagen dass das Zertifikat ausgestellt wurde wenn Zertifikat aus dem Tree entfernen ein Revuziertes Zertifikat aus dem Tree zu entfernen ist nicht Teil und nicht Ziel der Spezifikation aber wenn man alle Logs sich anschaut und dann wissen möchte ob irgendwas passiert ist nicht passieren sollte sollte man nicht wissen ob das Zertifikat zurückrufen wurde ja, da sollte man wissen ob die CT Logs denn diese Logs haben nur zum Ziel aufzuzeigen ob die CA ein Zertifikat ausgestellt wurde und ob dieses richtig gelockt wurde die Revozierung ist ein unterschiedlicher Prozess ein anderer Prozess eine andere Baustelle die nicht durch certificate transparency soll verändert werden okay, das ist alle Zeit die wir haben für Fragen und Antworten