 Ja, prima. Dann fangen wir an. Herzlich willkommen von meiner Seite aus, liebe Freunde des Misstrauens oder vielleicht des gesunden Pferdstrauens. Wurde ich eher sagen, ich möchte heute über Vertrauen ist gut, Kontrolle ist besser sprechen. Warum wir eigentlich Zertifizierungsstellen vertrauen und Zertifizierungsstellen kennt ihr wahrscheinlich alle, also die Absicherung von HTTBS für Schlüssel- und Kommunikationsverkehr. Aber bevor ich anfangen, ich will mich kurz vorstellen. Mein Name ist Andreas Sperbe. Ich arbeite in der IT-Sicherheitsberatung Aramido. Ich bin Gründer, einer der Gründe. Ich beschäftige mich hauptsächlich mit der Sicherheit von Web-Anwendungen. Und wenn ich mal ein bisschen Freizeit habe, dann gerne auch mit Hobbybierbrauen. Und ja, wir müssen hier endlich mal sowas durchziehen. Also ein bisschen Bierbrauen hier außen vielleicht wäre eine coole Sache. Ich blogge auch auf aramido.es-blog und wir haben auch ein Twitter-Account, wo wir immer mal ein bisschen was zu den Themen berichten. Ich möchte heute über vertrauenswürdige Zertifizierungsstellen sprechen. Und wenn ich das jetzt schon so sage, dann gibt es möglicherweise ja so einen Punkt, dass Zertifizierungsstellen nicht immer vertrauenswürdig sind. Und dann auch über einige Möglichkeiten der Absicherung gegen eben nicht vertrauenswürdige Zertifizierungsstellen sprechen. Es gibt dann eine ganze Latte, das Problem ist nicht neu. Und es gibt jetzt in Kürze eigentlich ein paar Neuerungen und die möchte ich euch vorstellen. Wenn man das ganze mal betrachtet, es war 2011 und ein iranischer Bürger. Also Iran ist dieses rote Punkte. Ein iranischer Bürger wollte seinen E-Mails abrufen per Gmail und hat in seinem Browser eben google.com slash Gmail eingegeben und dann hat er auf einmal eine Zertifikatswarnung bekommen. Und das war sehr komisch, weil es war auch was ganz was Neues. Und dann hat dieser Benutzer sich per Tor zu Gmail verbunden und dann hat er diese Warnung nicht bekommen. Dann hat er gesagt, komisch, der hat sich ein bisschen technisch ausgekannt, hat sich die Zertifikate dann angeguckt und er hat quasi über Tor ein Zertifikat ausgeliefert bekommen. Und über seine normale Internetverbindung nicht getunkelt, hat er eben ein anderes Zertifikat ausgeliefert bekommen. Und das hat er an Google kommuniziert in übern Forum. Die haben den Vorfall natürlich gleich untersucht und dann hat sich hat ausgestellt, dass eine bestimmte Zertifizierungsstelle, das Namen ihr wahrscheinlich kennt, ein sehr bekannter Fall, Dignota, ein Zertifikat ausgestellt hat für die Domain asterisk oder subdomain.google.com. Das Ganze ist auch passiert für Zertifikate, wie zum Beispiel Windows Update für das Torprojekt. Aber auch, finde ich ganz witzig, den Mossad oder den MI6, die hat es auch getroffen und was ich natürlich krass finde, das war zum Beispiel so ein Zertifikat, ja, also nicht schlecht, also Punkt org übrigens auch in Summe wurden über 500 Zertifikate ausgestellt und alle von Dignota. Und das ist natürlich ein krasser Fall. Und ihr könnt euch vorstellen, dass diese Zertifikate nicht an die Domain-Holder ausgestellt wurden, sondern an andere Leute. Und es hat sich dann herausgestellt, dass ein Hacker namens Komodo Hacker diesen Hack gemacht hat, der auf PaySpin eine ganz coole Story dazu veröffentlicht, wie er das gemacht hat und was er gemacht hat und hat sich da 21 Jahre angeblich, hat sich da als sehr cooler Typ hingestellt, wie cool er doch in diese Systeme eingedrungen sei und eben diese Zertifikate geklaut hat und sich die halt ausstellen lassen. Jetzt, wenn man sich anguckt, was ist da passiert? Die Firma FoxIT hat diesen Vorfall untersucht und wenn man sich überlegt, dass eine Zertifizierungsstelle, die ja doch eine wichtige Komponente im Internet für sichere Kommunikation, also IT-Sicherheit ist, dann hat diese Zertifizierungsstelle meiner Meinung nach ihre IT nicht ganz so im Griff gehabt. Also sie haben IT-Sicherheit nicht unbedingt so drauf gehabt. Sie haben zum Beispiel, hat eben FoxIT dann berichtet, keine oder eben nicht aktuelle Virenscanner auf den Servern am Laufen gehabt. Sie haben viele, viele ungepatchte Systeme gehabt. Das ist natürlich Hausaufgabe Nummer eins, einfach Software-Updates installieren. Wenn ich eine Software fingerprinten kann und dann einfach bekannte Schwachstellen ausnutzen kann, das ist ja, sage ich mal, lame. Also wenn wir uns in Richtung Zero Day Exploits bewegen, dann ist es natürlich ein bisschen anspruchsvoller, aber ungepatchte Software. Was sie auch noch nicht hatten, war ein zentrales Logging. Sie haben ihr Logging auch nicht irgendwie gemonitert. Und dann haben sie zum Beispiel so coole Kennwörter gehabt wie ProdAdmin. Find ich auch gut. Also für Production Administrator Account hatten sie das Kennwörter ProdAdmin und das war für alle Domänen so definiert und damit konnte natürlich relativ schnell viel übernommen werden. Wie es dazu kam, ist eigentlich egal, weil das Problem in dem ganzen System ist, eben es ist ein Systemfehler. Wir vertrauen Zertifizierungsstellen bei unserer sicheren Kommunikation und es genügt eine von diesen beispielsweise im Firefox Browser gibt es über 100mcas, die wir quasi implizit akzeptieren und es genügt eine Zertifizierungsstelle um dieses gesamte System eben in Mitleidenschaft zu ziehen und das war beispielsweise eben beim Hack von Diginotar der Fall, aber es gab ja auch andere Beispiele. Also es gab Beispiele Komodo, Symantec letztes Jahr oder dieses Jahr Digizert. Also es gab zahlreiche Beispiele, die eben falsche Zertifikate ausgestellt haben, unzulässige Zertifikate. Und das ist natürlich ein großes Problem in diesem Trust-Modell. Aber schauen wir uns vielleicht nochmal kurz an, wie dieses Trust-Model eigentlich funktioniert, bevor ich da loslege. Ihr wart sicherlich alle auf der Webseite Gulasch und habt gesehen, dass die per HTTPS mit eurem Browser kommuniziert und die Betreiber, also Entropia, die haben sich ein Zertifikat geholt, das haben sie sich geholt bei Let's Encrypt, das heißt, die haben einen sogenannten CSR, ein Certificate Signing Request an Let's Encrypt gestellt und Let's Encrypt hat dieses, das ist ein öffentlicher Publiki und Let's Encrypt hat nach einer Überprüfung bestätigt, die Domain Gulasch passt zu dem Publiki. Also dieser Publiki wird quasi mit dieser Domain verbunden und das zertifizieren wir. Die haben also mit ihrem Schlüssel, mit ihrem Schlüssel haben sie das zertifiziert und damit an Gulasch eben dieses Zertifikat ausgestellt. Und jetzt haben wir diese fesche junge Dame hier links unten und diese Dame, die ruft eben Gulasch auf, HTTPS Gulasch.ch und der Webserver liefert ein Zertifikat aus und zwar eben genau das Zertifikat, was sie von Let's Encrypt bekommen hat. Und wie funktioniert das Ganze? Sie muss ja jetzt überprüfen, also sie bekommt einen Publiki, einen Schlüssel, mit dem sie verschlüssel kommunizieren kann. Und sie muss ja jetzt überprüfen, ist es tatsächlich der Schlüssel von Gulasch? Weil, woher will ich denn das denn wissen? Angenommen, ich würde der Dame hier links unten meinen öffentlichen Schlüssel schicken und mich ausgeben, als wäre ich Gulasch.ch, dann könnte ja, bezeichnen wir sie als Alice, könnte ja Alice sagen, ja, passt. Und dann würde sie mit dem öffentlichen Schlüssel von mir Daten irgendwie verschlüsseln, schicken und ich könnte sie mitlesen. Könnte sie dann weiterleiten an die Website und die Website würde gar nichts merken. Also gibt es im Browser vom Alice einen sogenannten Truststore und in dem Truststore liegen Route-Zertifikate, Route and Intermediary Certificates und diese Zertifikate dienen, um dieses Zertifikat, was von Gulasch.ch oder Gulasch.ch ausgeliefert wird, zu bestätigen. Und damit schließt sich also der Kreis Alice vertraut bestimmten Zertifizierungsstellen, die in ihrem Browser bereits vorinstalliert sind. Also wenn sie sich beispielsweise einen Firefox oder einen Chrome runterlädt, dann sind da dann Wurzelzertifikate und Zwischenzertifikate enthalten und diese mit diesen Zertifikaten kann eben ein Zertifikat von einer Website verifiziert werden, mathematisch bestätigt werden, dass eben dieses Zertifikat gültig ist, weil nur die Signatur eben von Let's Encrypt stimmen muss. Also das ist ja wichtig in dem ganzen Verlauf, dass das klar ist, aber das sollte ja, denke ich, allen klar sein. Also wenn irgendwie eine Frage aufkommt, stelle sie bitte gleich. Und wie gesagt, das Problem, wenn man sich das jetzt mal anschaut, das Problem, was bei Diginota aufgetreten ist und auch in vielen anderen Fällen war eben, dass die Zertifizierungsstelle hier in dem Fall Let's Encrypt einfach Zertifikate an irgendjemanden beliebigen ausgestellt hat, ohne dass das berechtigt war, ohne dass der Betreiber eigentlich der Website das so genehmigt hat. Und damit konnten eben sich andere als man in der Mittel in die Kommunikation zwischenschalten und eben die Kommunikation mitlesen. Und dieses Problem ist nicht neu. Also man kennt das Problem schon seit viel, geraumer Zeit. Man hat sich da schon viele Gedanken gemacht, wie man dieses Problem in den Griff bekommen kann, weil, wie gesagt, warum vertraut Alice Let's Encrypt? Das macht sie implizit. Die Zertifikate sind vorab installiert und dazu kommt noch der Betreiber der Website, der vertraut ja eigentlich an sich implizit zumindest auch Let's Encrypt, weil er sagt Let's Encrypt, da gehe ich hin, da hole ich mir mein Zertifikat, aber es gibt ja eben so viele andere Zertifizierungsstellen und es genügt eine Zertifizierungsstelle, um das Ganze kaputt zu machen und beispielsweise entropia vertraut man hat wegen den ganzen anderen vielleicht irgendwelchen chinesischen Zertifizierungsstellen nicht, aber die Wahl hat sie nicht. Und deswegen muss man sich überlegen, wie kann man das Ganze also absichern? Und es gibt unterschiedliche Ansätze. Ich möchte eben mal ein paar vorstellen, dass es eine Liste, die nicht vollständig ist, aber auf ein paar Beispiele möchte ich eben eingehen. Es gibt beispielsweise DNS-basierte Ansätze. DNS-basierte Ansätze, also die, das Domain Name-System verwenden. Und da gibt es beispielsweise Certificate Authority Authorization, CAA, kurz. CAA funktioniert so, dass man in den DNS-Eintrag Informationen hinterlegt, wer für einen eben Zertifikate ausstellen darf. Es funktioniert allerdings andersrum, also es bewegt sich nicht auf Seiten von Website und Betreiber oder auf der Seite von Alice, sondern die Zertifizierungsstelle, die Zertifikate ausstellt, muss prüfen, welcher DNS-Eintrag, also welcher CAA-Eintrag ist gesetzt und darf ich überhaupt für diese Domain Zertifikate ausstellen oder nicht. Also es ist quasi kein wirkliches Enforcing. Aber da gibt es also eine Neuerung und zwar ab September 2017, das wurde jetzt beschlossen im März, ab September 2017 müssen alle Zertifizierungsstellen genau diese Informationen zumindest prüfen. Das heißt, definiert sie in euren Domains, in euren DNS-Einträgen, um eben euren Schutz etwas zu verbessern. Dann gibt es noch Dane, sage ich jetzt nichts dazu, kommt nämlich gleich ein bisschen umfangreicher. Außerdem gibt es notarbasierte Ansätze. Notarbasierte Ansätze wie beispielsweise Perspektive oder Convergence, das funktioniert so, dass man zum Beispiel ein Browser-Plugging hat und es gibt ein dezentrales System. Ich möchte zu einer Seite verbinden, erhalten ein Zertifikat und frage bei diesen Notaren an, passt dieses Zertifikat? Und wenn dieses Notarsystem irgendwelche Unregelmäßigkeiten bemerkt, dann, also es ist quasi kein zentrales System wie bei OCSP, sondern diese Notare sind eben dezentral und wenn irgendein Notar irgendwas Verdächtiges feststellt, dann kann er eben eine Warnung ausgeben. Vermutlich oder die wenigsten von euch, wenn wahrscheinlich Perspektives oder Convergence kennen. Es ist ein System, was sich bis heute eigentlich nicht durchgesetzt hat. Deswegen möchte ich da gar nicht weiter drauf eingehen, aber es ist wichtig, also zu sehen, diese notarbasierten Ansätze sind eigentlich auch eine Möglichkeit, eben sich über Rogue Certificates informieren zu lassen. Weiterhin gibt es pinningbasierte Ansätze. Sehr interessant, HPKP, HTTP Public Keep Pinning. Darauf gehe ich gleich ein. Dann gibt es beispielsweise noch TEC. TEC ist ein Projekt von Moximal & Spike, der das recht weit voranträgt. Es gibt also einen TEC-Key, mit dem dann wiederum eigene Zertifikate signiert werden. Also man entkoppelt die... Oder man gibt nicht so viel Vertrauen zu der Zertifizierungsstelle, sondern hat die Möglichkeit, dieses Vertrauen ein bisschen in die Richtung des Betreibers zu schieben. Dann gibt es noch DNS Chain, ein interessanter Ansatz über so einen Hashtree. Will ich jetzt heute gar nicht drauf eingehen. Also pinningbasierte Ansätze möchte ich eben HPKP vorstellen. Und zuletzt, um diese Liste zu vervollständigen, gibt es noch transparenzbasierte Ansätze. Sehr interessant, der Ansatz Certificate Transparency, auf den möchte ich eingehen. Davon habt ihr sicherlich schon gehört. Ein anderer Ansatz wäre beispielsweise Sovereign Keys, der auch auf das Pattern Transparenz eben Wert legt. Also das sind alles Möglichkeiten und Stoßrichtungen, dieses Problem, dieses Vertrauensproblem zu lösen, um uns bei ausgelieferten Zertifikaten zu schützen und darauf hinzuweisen, dass es möglicherweise ein böses Zertifikat. Okay, schauen wir uns mal das Erste an. Das ist den DNS-Based Authentication of Named Entities, die Langform. Möglicherweise habt ihr davon schon mal gehört, würde für unsere Webseite folgendermaßen ablaufen. Wir haben einen DNS-Server, den kontrolliert beispielsweise die Entropia. Und der DNS-Server wird ein Eintrag definiert, welche Zertifikate gültig sind. Und da gibt es mehrere Möglichkeiten, darauf gehe ich gleich noch ein. Aber der Webseitenbetreiber hat die Macht, zu sagen, die Zertifikate akzeptiere ich, wie auch immer. Dann ruft Alice wieder die Webseite auf. Das kennen wir ja schon. Und sie macht eine DNS-Abfrage und erhält dann die Information, okay, es sind nur bestimmte Zertifikate eben gültig. Und letzten Endes liefert ja natürlich das Zertifikat für Gulasch noch ausgeliefert. Und dann hand diese Information, kann jetzt Alice überprüfen, welche ist das Zertifikat gültig oder verwerfig ist und stelle ich eben eine Warnung da. Und das Gute an dem Ansatz ist eben, dass der Betreiber dieser Webseite die Macht darüber hat, weil er den DNS-Server eben kontrolliert. Und Dane setzt auf DNS-Sack auf. DNS-Sack ist quasi DNS über eine sichere Verbindung und darauf baut also Dane noch zusätzlich auf. Und wir müssen also diesen Eintrag definieren. Da gibt es drei Möglichkeiten, um diesen DNS-Eintrag zu definieren. Es gibt die sogenannten Service-Zertifikat Constraints. Da würden wir definieren, dieses eine Zertifikat wird akzeptiert und es muss auch noch diese Vertrauensprüfung bestehen. Also ganz normaler Ansatz, ähnlich vielleicht wie Pinning. Dieses eine Zertifikat ist gültig, alle anderen bitte verwerfen. Und das ist natürlich klasse, weil wir haben uns ja immer gesagt, es gibt die Zertifizierungsstellen, die ihr beliebige Zertifikate ausstellen können. Und dann würde natürlich jedes beliebige, gültige Zertifikat akzeptiert werden. Und jetzt haben wir die Möglichkeit, dieses eine Zertifikat zuzulassen und einzuschränken. Es gibt auch noch die Möglichkeit, dass man ein ganz bestimmtes Zertifikat in dem TLSR-Record mit ausliefert. Also der Eintrag, der DNS-Eintrag, nennt sich TLSR-Record, in dem das Ganze definiert wird. Und in diesem TLSR-Record kann ich auch noch ein spezielles Zertifikat mit angeben und nur dieses ist gültig. Und damit kann ich das natürlich, kann ich ein beliebiges Self-Sign-Zertifikat zum Beispiel angeben und kann komplett auf Zertifizierungsstellen verzichten. Also ich erstelle selber ein Zertifikat, liefert es aus, Alice bekommt über meinen DNS-Record, TLSR-Record, das Zertifikat, was ich mir self-signed ausgestellt habe und ich liefert es aus, sie sagt, das ist in Ordnung. Keine Zertifizierung stellen mehr. Yay! Die dritte Möglichkeit wäre, einen Trust Anchor zu definieren. Das heißt, ich kann sagen, vertraue genau diesen Trust Anchor und führe dann die Prüfung aus. Also ihr wisst, so eine Zertifizierungsstelle mit ihrem Root-Zertifikat ist ein Trust Anchor, also quasi der Endpunkt in dieser Validierungskette und ich bekomme ein Zertifikat ausgeliefert und das wird signiert von vielleicht einem Zwischen-Zertifikat, vielleicht noch einem Zwischen-Zertifikat und am letzten Endes dem Root-Zertifikat und diese Kette nach oben, die muss an einem ganz bestimmten Trust Anchor enden und das kann ich eben als dritte Möglichkeit in diesen TLSR-Record definieren. Das heißt, ich bekomme als Webseitenbetreiber schon sehr viel Macht und kann das ganze System eben über meinen DNS-Eintrag steuern. Also wir haben viel Kontrolle, wir können es implementieren, wir müssen es aber nicht und das ist natürlich schon eine coole Macht, so was zu machen. Ich kann als Webseitenbetreiber mit meinen Benutzern der Webseite wirklich die Kontrolle übernehmen und meine verschlüsselten Verbindungen selbst gestalten und ich muss nicht darauf vertrauen, dass irgendjemand irgendetwas richtig macht. Das Problem ist natürlich, dass das Ganze auf DNS-Sec aufbaut. Als ich schon mal mit DNS-Sec beschäftigt hat, es ist alt und zu den Zeiten war Verschlüsselung noch etwas CPU-intensives und damals gab es nicht so viel CPU. Das Ganze baut auf 1024-Bitschlüsseln auf, es wird beispielsweise nur signiert und nicht verschlüsselt, also diese DNS-Abfrage und demnach ist das Ganze eigentlich schon nicht unbedingt auf sicheren Beinen aufgestellt. Da müsste es eigentlich eine Novellierung geben, dass man das DNS-Sec wieder neu aufbaut, um eben für Dain eine gute Grundlage zu schaffen. Aber das ist eigentlich die Hauptkritik, dass Dain auf DNS-Sec aufbaut und DNS-Sec an sich ist nicht sicher oder gilt als nicht sicher. Dann war natürlich die Frage, ob Dain jeder so eine CA betreiben kann. Da haben wir gesagt, ich kann hier zum Beispiel mir so ein selbst signiertes Zertifikat erzeugen und das ausleihen und sagen, dem muss ich vertrauen oder ich kann beispielsweise das Ganze auf einen bestimmten Trust-Anker zurückführen. Und wenn das Zertifizierungsstellen nicht hinbekommen, zumindest nicht einwandfrei, kriegen es dann wirklich alle Webseitenbetreiber gut hin? Die Pro ist schon klar, kein Thema. Aber es geht ja um ein System, das wirklich die komplette Internet-Kommunikation sicher ist. Und jeder, der so einen blöden Web-Server betreibt, muss das richtig hinbekommen. Das heißt, er muss ein richtiges Zertifikat erzeugen, kein Zertifikat, das irgendwie zehn Jahre lang gültig ist, was die richtigen Hashing-Werte, keinen Share One und so weiter verwendet und all diese Dinge, die werden ja eigentlich von Zertifizierungsstellen schon professionell gemacht, die werden auditiert, die müssen bestimmte Richtlinien erfüllen und die sollten das eigentlich können. Also das heißt, es ist fraglich, sage ich mal, ob jeder das so hinbekäme. Und dann sind natürlich auch durchs Dane bestimmte Reflection- bzw. Amplification-Angriffe möglich. Das heißt, der DNS-Eintrag durch diesen TLSR-Record, wenn ich dann ein Zertifikat reinpaste mit, keine Ahnung, 4.096 Bit oder so, schön langer Schlüssel, dann wird das schon ein bisschen dick. Und diese DNS-Einträge, die werden dann schon ein bisschen größer und dann kann ich natürlich so Amplification-Angriffe sehr gut machen im DNS-System. Also ist das DNS-System eigentlich dafür gut geschaffen. Also das sind so die Hauptkritikpunkte, wenn man sich jetzt anguckt, wer das einsetzen möchte. Es gibt tatsächlich Plugins für Browser. Es gibt für ziemlich alle Browser bis auf den Internet Explorer. Wer verwendet Internet Explorer? Ja, sorry, kein Dane für you. Ja, also es gibt eigentlich Plugins für eigentlich alle gängigen Browser und damit kann Dane verwendet werden. Also wer sich da mal ausprobieren möchte, kann da ein bisschen mehr aus sich testen. Allerdings, es hat bisher noch keine weite Verbreitung gefunden. Es wurde eben noch nicht weit implementiert und deswegen ist es kein wirklich guter Ansatz, sage ich mal, um die Masse wirklich abzusichern. Weil keiner installiert sich extra, um Zertifikate abzusichern. Vielleicht dieses Plug-in, dieses Browser-Plug-in. Jawohl, kommen wir zum nächsten Ansatz. Also das war quasi der DNS-basierte Ansatz. Der ist so, na ja, geht so, hat sich noch nicht richtig durchgesetzt. Und da gibt es sicherlich noch einiges zu arbeiten, muss weiter vorankommen. Jetzt schauen wir uns mal Public Key Pinning an. Hatte die Public Key Pinning, also HPKP in der Abkürzung, ein pinning-basierter Ansatz. Wir haben wieder die Webseite, die ihr mir unten schon kennt. Und wir haben die Zertifizierung stelle Let's Encrypt, die ein Zertifikat ausstellt. Soweit erst mal nichts Neues, das kennen wir schon. Dann erstellt der Betreiber der Webseite oder des Dienstes einen... Ach so, alles fragt noch an, natürlich. Sie möchte ja die Webseite haben, GetRequest, was auch immer. Und dann liefert eben der Betreiber das Zertifikat zurück und zusätzlich allerdings noch seinen Public Key Pin. Der Public Key Pin ist ein Fingerprint des SPKI-Eintrags, also die Subject-Public-Key- oder die Subject-Public-Key-Information. Das heißt, die Verbindung aus dem öffentlichen Schlüssel und der Domaininformation. Und diesen Fingerprint sende ich als Header mit. Wir werden uns gleich noch mal anschauen. Das heißt, Alice bekommt das Zertifikat und sie bekommt den Fingerprint oder diesen Public Key Pin. Und das Pinning läuft so ab, dass der Webseitenbetreiber definieren kann, welches Zertifikat für die Absicherung der Kommunikation gültig ist. Und alle anderen Zertifikate werden wir verworfen. Das heißt, Alice vertraut Let's Encrypt, wenn der Public Key Pin gültig ist. Wenn der Public Key Pin schon nicht gültig ist, dann lasst ihr die Verbindung nicht zustande kommen. Wenn der Public Key Pin zulässig ist, muss natürlich noch die Zertifikatsprüfung erfolgreich sein und dann wird die Verbindung aufgebaut und eine Kommunikation findet statt. Das heißt, dieser Public Key Pin, über den Public Key Pin kann ich definieren, welche Zertifikate ich akzeptiere und welche nicht. Schauen wir uns mal so einen Public Key Pin an. Es ist, wie gesagt, ein HTTP Header. Der ausgeliefert wird in der Form. Wie ihr hier seht, sind es Schad 256 Pins oder Hashes von offensichtlich ja zwei Zertifikaten. Ich komme gleich darauf zu sprechen, warum zwei Zertifikate, aber in der Verbindung, die Alice mit Gulasch aufbauen möchte, muss quasi eines dieser Zertifikate in der Zertifikatskette vorhanden sein. Es wird eine Max-Age von 1.209.600 Sekunden. Wie viele Tage sind das? Zwei Wochen. Zack, zwei Wochen. Das heißt, wir haben hier offensichtlich eine Gültigkeit, wo dieser Eintrag über vor zwei Wochen im Browser gecashed wird. Das heißt, 15 Minuten, was haben wir da? Naja, also eine bestimmte Zeit, 1.209.000 Sekunden. Und in dieser Zeit sagt der Firefox Chrome, was auch immer, der Browser von Alice, ich akzeptiere nur diese zwei Pins. Das heißt, wenn mir ein anderes Zertifikat ausgeliefert wird, den ich das ab. Das ist eine Frage. Ja, also die Frage war, ob irgendjemand als Mann in der Mittel den PIN modifizieren kann, wenn er eben in dieser verschlüsselten Verbindung dazwischen setzt. Sehr gute Frage. HPKP folgt dem TOFU-Prinzip. TOFU bedeutet Trust on First Use. Das bedeutet, Alice ruft das erste Mal die Webseite auf und dann ist die Verbindung quasi nach dieser Maßgabe noch ungeschützt. Erst dann erhält sie ganz normale verschlüsselte Verbindung mit dem Zertifikat von letzten Crypt wird ausgehandelt und es erhält in dem Moment dann die Information. Wenn bei dem ersten Aufruf es jemand schafft, ein falsches, also quasi ungültiges, aber nicht autorisierte Zertifikat auszuliefern und diesen Header zu verändern, hätte er Alice. Es gibt aber die Möglichkeit für Preloading. Preloading kennt ihr vielleicht von HSTS, also HTTB Strict Transport Security. Ich kann mich in eine Liste eintragen lassen und kann meine Pins bereits bei der Installation und bei Updates vom Browser in den Browser direkt mit installieren lassen. Dadurch weiß mein Browser, obwohl ich noch nie auf der Seite Gulasch war, die und die Pins sind notwendig. Also ich werde nur die und die Zertifikate akzeptieren. Es sitzt natürlich im Kontext von letzten Crypt schwierig. Eine Gültigkeit von, was haben wir aktuell, 90 Tage. Also eine maximale Gültigkeit ist das natürlich schon recht knapp bemessen. Also bei längeren Zertifikaten geht es vielleicht. Bei den kurzgültigen Zertifikaten von 90 Tagen bei letzten Crypt ist es natürlich schwierig zu machen. Aber wenn bei dem ersten Verbindungsaufruf es jemand schafft, sich in die Verbindung zwischenzuschalten, sprich also man in the middle Angriff zu machen und beispielsweise über Digenotar sich ein Zertifikat ausstellen lässt. Digenotar gibt es nicht mehr, die mussten leider nach dem Vorfall Konkurs oder wie nennt man das Insolvenz anmelden. Aber es gibt genügend andere. Also man kann sich ja anderen Zertifizierungen stellen bedienen. Und wenn das also funktioniert, dann wäre es möglich, diese Header zu verändern. Angenommen, das wäre jetzt nicht möglich, dann würden die Header also an Alice kommuniziert werden, Alice cash diese Information in ihrem Browser und dann akzeptiert sie nur noch diese zwei Pins, bis sie natürlich wieder nen neuen Aufruf macht und vielleicht der Webseitenbetreiber neue Pins ausliefert. Jetzt ist es nen sehr coolen Ansatz, weil er gibt dem Webseitenbetreiber volle Kontrolle. Wir hatten ja das Problem, ich möchte verhindern, dass ein beliebiges Zertifikat für mich ausgeliefert wird. Für Gulasch beispielsweise, oder für AndreasSperber.de oder was auch immer. Und mit dem Public Key Pining kann ich den Kleinen sagen, nee, es sind nur diese Zertifikate gültig. Ich hab übrigens die Möglichkeit, ich kann die Blätter pinnen. Das heißt, die tatsächlichen Zertifikate. Ich hab die Möglichkeit, aber auch in dieser Zertifizierungskette, in der Zertifikatskette bis zum Root Zertifikat, alle anderen Zertifikate auch zu pinnen. Also zum Beispiel das Intermediary Zertifikat oder das Root Zertifikat. Angenommen, ich würde beispielsweise jetzt das Intermediary Zertifikat, das Zwischenzertifikat von Let's Encrypt pinnen. Dann würde ich natürlich theoretisch ein Zertifikat akzeptieren, was von Let's Encrypt ausgestellt wurde und zwar unautorisiert. Aber wenn ich sag, ich vertraue Let's Encrypt, dass die keine nicht autorisierten Zertifikate ausstellen, dann kann ich eigentlich Risiko ein bisschen wegnemen. Auf das Risiko komme ich gleich zu sprechen. Und ich sag, die werden ihr Zertifikatsmanagement schon im Griff haben und ich pinne quasi deren Zertifikat und nicht mein Zertifikat. Weil das Problem ist natürlich, was passiert? Ich liefe diese zwei Pins aus. Und das sind ja zwei Pins von jeweils zwei Zertifikaten, sprich, ich habe einen Private Key dazu und ich werde gehackt. Oder ich verliere warum auch immer diesen Private Key. Dann kann ich diese Zertifikate nicht mehr verwenden. Alice casht ihr aber für nur zwei Wochen, ich glaube, es waren zwei Wochen, es könnte aber auch länger sein, diese Information. Und wenn ich diese Zertifikate, die ich da definiert habe, vorab nicht mehr ausliefern kann, dann bin ich selber gedost, weil sie kann ja nicht mehr auf die Website zugreifen. Das ist das Problem. Wenn man seine Pin-Aktualisierung nicht wirklich im Griff hat, gerade bei Let's Encrypt muss man das wirklich gut im Griff haben, weil es passiert ja alle, glaube, 60 Tage, passiert früher, dann muss ich, wie gesagt, diese Pins richtig kommunizieren. Und das ist eigentlich ein großes Problem. Also diese Pin-Aktualisierung muss eben sehr robust sein, der Prozess muss sehr gut funktionieren. Und jetzt kann ich, wie gesagt, sagen, na ja, ich vertraue aber Let's Encrypt. Und deswegen bin ich einfach das Zwischenzertifikat oder vielleicht das Root-Zertifikat. Und die haben ja deutlich längere Laufzeiten und die haben ihr Zertifikatsmanagement schon im Griff. Und damit bin ich für meinen Teil, wenn ich meine Schlüssel nicht ordentlich im Griff habe, raus, dann nehme ich quasi Risiko von dem ganzen Weg und hab nicht so das große Risiko, dass ich mich dosse. Das funktioniert eigentlich ganz gut, weil es ist ja vor allem auch besser als Status quo. Status quo wäre, ich vertraue allen Zertifizierungsstellen. Und jede Zertifizierungsstelle auf dieser Welt, China, irgendwelche Amerikaner, Seifhaberabkommen, würde mich ja mal interessieren, ob wir tatsächlich immer noch irgendwelche Zertifikate für irgendjemanden ausstellen. Ich bin immer noch besser als der Status quo. Ich verlasse mich dann zumindest mal auf eine Zertifizierungsstelle und sage, nur die darf Zertifikate für meine Domain ausstellen. Also, das ist eigentlich ein ganz guter Mechanismus. Und vor allem, das Coole ist, die meisten Browser unterstützen es. Also, ihr könnt mal gucken auf Can I Use. Eigentlich fast alle aktuellen Browser unterstützen eben HPKP. Aber Missbrauchspotenzial ist natürlich vorhanden. Folgendes Szenario. Ich verwende als vielleicht unwissender Benutzer oder Betreiber einer Website HPKP nicht. Wer verwendet von euch HPKP? Gut ist dünn. Eine. Okay, also ihr verwendet HPKP nicht. Monitort ihr eure Seite, dass kein Pin ausgeliefert wird. Weil es könnte ja passieren, dass jemand euren Server hackt und einen Pin ausliefert. Und zwar irgendein beliebigen Zufallswert und einen, der zu eurem aktuell ausgelieferten Zertifikat passt. Und er lässt diesen Pin für zehn Jahre cashen. Dann holt ihr euch ein neues Zertifikat. Less Encrypt nach 60 Tagen ist Schluss. Dann habt ihr ein Problem. Weil ganz viele Clients haben natürlich diese Information gecashed und sagen, ich erwarte jetzt diese zwei Zertifiz-, entweder das Zertifikat oder jenes Zertifikat von euch. Aber das könnt ihr nicht liefern. Und dann habt ihr euch gedost oder dossen lassen. Also wie gesagt, das ist ja das Missbrauchspotenzial, dass eben jemand, der das nicht überprüft, der das nicht im Griff hat, damit gedost werden kann. Und als Webseitenbetreiber hat man ja da nicht die Macht, zu sagen, hey, user, löscht mal euren HPKP Cash. Das ist also ein großes Problem bei Certificate Transparency. Es gibt Ansätze dagegen oder dafür beispielsweise ähnlich wie vielleicht OCSP. Also, dass man ein bestimmtes Pinning revocaten kann. Aber so ein Mechanismus gilt es also noch einzuführen. Da sind wir quasi noch nicht so weit, um genau das wirklich stabil für die breite Masse zu machen. Okay, nächster Ansatz, Certificate Transparency. Habt ihr sicherlich schon gehört, coole Sache, Projekt vom Google. Ja, kann man so sagen. Und das kennt ihr alles schon. Also, Gulasch braucht ein Zertifikat von letzten Crypt, holt sich das Zertifikat, Alice fragt an und Alice bekommt das Zertifikat ausgeliefert und sie vertraut eben der Last Encrypt Zertifizierungsstelle. Es wird jetzt gleich ein bisschen voller. Deswegen beleuchtet das mal so ein bisschen aus. Certificate Transparency funktioniert wie folgt. Wenn Gulasch ein neues Zertifikat beantragt bei Last Encrypt, dann wird Last Encrypt dieses Zertifikat oder ein Pre-Zertifikat in ein Log eintragen, und zwar eben in ein CT, ein Certific Transparency Log. Dieses Log antwortet mit einer sogenannten SCT, das ist die Signed Certificate Time Stamp. Das ist ein Zeitstempel, bis zu welchen Zeitpunkt dieses Zertifikat auf jeden Fall in das Log eingetragen wird. Ich kann euch wahrscheinlich vorstellen, es gibt ein Log, und wenn alle Webseiten dieser Welt oder alle Dienste dieser Welt mit einem mal so ein neues Zertifikat beantragen, dann hat dieses Log ganz schön, also CPU technisch, zu tun. Das Log ist ein Hash Tree, also ein Hashbaum, ein Merkle Tree, und der muss entsprechend berechnet werden. Deswegen erfolgt es in bestimmten Zeitabständen, stündlich beispielsweise, und diese SCT sagt spätestens bis zu dem und dem Zeitpunkt, dann trage ich dir das Log ein, und dann kann letztendlich dieses Zertifikat ausstellen und an die Webseite kommunizieren. Es gibt mehrere Wege, wie dieses SCT, das ist nämlich eine sehr wichtige Information, es gibt mehrere Wege, wie dieses SCT übertragen werden kann. Das SCT kann beispielsweise an das Zertifikat als X509 Extension mit angehängt werden. D.h. der Webseitenbetreiber bekommt einfach dieses Zertifikat, packt es in seinen Server, z.B. in den Webserver, liefert es an Alice aus, das Zertifikat, eben jetzt mit dem SCT. Das ist eine zusätzliche Information. Und dann gibt es in dem ganzen Prozess noch einen Monitor. Also neben dem Log hat Certificate Transparency auch noch die Entity Monitor. Und der Monitor wacht über verdächtige Vorgänge, über verdächtige Zertifikate. Also beispielsweise Zertifikat für stern.stern.com. Man kann auch so einen Monitor-Dienst sagen, hey, liefer mir doch alle Informationen für z.B. Gulasch. Und wenn ein neues Zertifikat für Gulasch beantragt wird, dann dauert es nicht lange. Und der Monitor sagt, hey, da gibt es ein neues Zertifikat. Und man selber kann sagen, oh, passt oder passt nicht. Und dann halt irgendwelche Gebenmaßnahmen ergreifen. Aber das macht also der Monitor. Und dann gibt es noch einen Auditor, den SpongeBob, der prüft die Logs. Der guckt nämlich, ob diese Logs richtig arbeiten. Und das, was er da als SCT ist, bekommt, sind dir richtig eingetragen. Hat bestimmte Verifikationsmöglichkeiten. Und das ist an sich so das ganze System von Certificate Transparency. Führt also drei neue Instanzen, den Auditor, das Log und das Monitoring mit ein. Ich hatte schon gerade gesagt, Log sammelt also Zertifikate. Nichts anderes. Das ist ein Append-Only-Hashbaum. Das heißt, es ist ein Binärerbaum. Immer zwei Zertifikate werden verhashed zum Parent. Und das wird gemacht bis zum Root. Und ich muss einfach nur den Root überprüfen. Stimmt also quasi die Hash-Information. Stimmt, dann passt's. Ist ja cool, weil ich kann zum Beispiel nachträglich nichts mehr aus dem Baum rauslöschen. Ich kann auch nichts mehr hinzufügen. Also, der Baum ist eben fälschungssicher und manipulationssicher für nachträgliche Änderungen. Dann gibt es eben den Monitor. Und der Monitor wacht eben über verdächtige Zertifikate. Das haben wir gerade gesehen. Ich kann euch da gleich noch ein Beispiel zeigen, und die Auditors, das könnte beispielsweise eine Browser-Komponente sein. Das heißt, euer Firefox, Chrome, was auch immer, oder der Internet Explorer. Ich glaube, er hat's nicht. Er hat ein Modul, ein Softwaremodul, und das SCT wird damit überprüft. Das heißt, das SCT hat Informationen, in welchem Log das Ganze eingetragen ist. Können wir uns das mal kurz angucken. Und überprüft dann diese Logs. Wie vielleicht davor noch ein kurzes Beispiel für den Monitor. Der Monitor läuft also regelmäßig, und sobald ein neues Zertifikat eingetragen wurde, bekommt man eine Information. Zum Beispiel habe ich die am 29.04.bekommen, da habe ich ein Zertifikat für ftpr.mido.de beantragt. Und dann hat Searchspotter, das ist ein Dienst einfach. Es gibt unterschiedliche, man kann so einen Monitor selbst betreiben. Ein bisschen festplattenintensiv, weil so ein Log ist natürlich auch dick. Aber zum Beispiel Facebook oder Searchspotter, das sind so Dienste, Facebook bietet sowas auch an, es sind so Dienste, die einen informieren können. Einen als Website oder Dienstbetreiber. Und wie gesagt, das habe ich bekommen, dann sage ich, cool, neues Zertifikat. Zum Beispiel jetzt jeden Montag, wenn mein Let's Encrypt-Script durchläuft, und mich informiert, gibt ein neues Zertifikat, dann sage ich, oh Gott, nein, neues Zertifikat, passt es? Ah ja, okay. Script ist durchgelaufen, es wurde tatsächlich ein neues Zertifikat ausgestellt durch mein Script. Und dann bekomme ich eben kurze Zeit später von Searchspotter diese Information. Dann sage ich, als Website und Betreiber, passt. Wenn ich eben diese Information bekomme und ich habe kein Zertifikat ausgestellt, dann ist was kaputt. Und ich muss das Zertifikat revocaten. Ich muss eben was dagegen unternehmen. Aber das ist cool, weil ich habe endlich mal die Transparenz. Ich sehe, was macht dieses System. Und wir können uns mal kurz angucken. So, jetzt gibt es zum Beispiel CTSH. Könnt ihr euch mal angucken. Wir schauen uns jetzt mal an, ob Gullerste eingetragen ist. Oh, das ist natürlich schlecht. Was ist denn los? Wer hat das Internet ausgeschaltet? Vielleicht hat jemand vorhin das WLAN-Replay, und hat sich mittlerweile verabschiedet, weil es gibt auch dieses GPN Open. Mal gucken, ob wir auf GPN Open ein Zertifikatsfehler bekommen. Also, jetzt muss ich nur noch mal eine Maus finden. Oli, cool, da ist es also. Wir haben hier das ... oder alle Zertifikate für Gulasch, die jemals eingetragen wurden. Offensichtlich wurde das Ganze ab 2014 begonnen. Und das Zertifikat, was jetzt aktuell gültig ist, müsste eben genau dieses sein. Das ist logged am 29.03. Und eben ist ab 29.03. angültig. Sieht so aus. Und hier oben haben wir die Certificate Transparency Einträge. Das ist also in drei Logs eingetragen. Das ist auch sehr wichtig. So ein Zertifikat soll in mindestens zwei Logs eingetragen werden. Je mehr, desto besser. Ich würde jetzt sagen, drei Google Logs. Really? Also, angeblich werden die von unterschiedlichen Verantwortungsbereichen betrieben, aber ... Na? Ja, gleiches Chef. Also, wäre gut, wenn es unterschiedliche Log-Betrage gäbe, die auch wirklich organisationell getrennt sind und dieses Zertifikat unterschiedliche Logs eingetragen wird. Und da kann man das eben sehen. Das kann man auch sehen kann. Ich kann halt alles sehen. Also, ich kann sehen, welche Zertifikate erstellt wurden. Das heißt, es gibt natürlich vielleicht ein gewisses Privatsparenproblem. Wo ist wieder meine Maus? Es gibt vielleicht ein gewisses Privatsparenproblem. Und das ist natürlich die Downside von dem ganzen Ansatz. Also, Pro ist auf jeden Fall Certificate Transparency, Schafttransparenz. Und genau das brauchen wir. Es gibt ja nicht, welche Zertifizierungsstellen es gibt. Wir wissen ja gar nicht, welche Zertifikate die überhaupt ausstellen. Man weiß ja nie, bis halt eben so was auffällt, ob es jetzt ein Zertifikat für meine persönliche Domain gibt. Und das ist eben sehr wichtig. Certific Transparency schafft hier die notwendige Transparenz. Und vor allem, es sind eigentlich kaum Infrastrukturänderungen notwendig. Ihr müsst euch einmal überlegen, wenn man zum Beispiel Dane einfügt, führt, also jede Webseitenbetreibung muss diese DNS-Enderungen machen und so weiter, und die auch wirklich im Griff haben. Das heißt, wenn man so einen neuen Ansatz einführt, dann muss der auch praktikabel sein für die Öffentlichkeit. Und Certificate Transparency erfordert insbesondere bei den Zertifizierungsstellen natürlich Änderungen und bei den Logbetreibern und so weiter. Aber die liefern eben die Zertifikate aus und ändern eigentlich, und die Webseitenbetreiber ändern eigentlich kaum was an ihrer Infrastruktur. Nachteile sind eben, dass es nicht wirklich Zertifikat zum Brauch verhindert. Also es ist immer noch möglich, dass die Genota ein Zertifikat für mich ausstellt und es eben eine gewisse Zeit lang braucht, bis ich das merke. Das heißt, ein paar Stunden kann es zum Beispiel sein, dass das falsche Zertifikat oder das nicht autorisierte Zertifikat verwendet wird. Und dann fällt es allerdings relativ schnell auf und dann kann ich was dagegen unternehmen. Aber ich muss natürlich als Webseitenbetreiber aktiv werden. Also wenn ihr euch da noch nicht auf so einen Monitordienst habt eintragen lassen, macht das. Tragt euch da ein, weil dann seht ihr, wann eben ein Zertifikat für eure Domain ausgestellt wird. Also wichtig, dass es Infrastrukturbetreiber gibt. Die Logs, die sind ziemlich groß. Das heißt, Hardware muss vorhanden sein. Es muss Leute geben, die die wirklich Real-Time als Real-Time-Dienst zur Verfügung stellen. Es braucht Monitoring-Infrastruktur und die Auditoren müssen auch vorhanden sein. Das heißt, es muss Leute geben, die dieses Projekt eben vorantreiben. Und Google ist aber ein großer Player in dem Markt. Das heißt, er treibt das Projekt ordentlich voran. Privatsphäre haben wir gerade gesehen. Es wird natürlich sehr interessant, wenn wir zum Beispiel Pentes machen, dann fragen wir uns immer, welche Domains und Subdomains gibt es denn in dem Betrieb? Jetzt ist es natürlich cool, jetzt gucken wir halt einfach das Log an. Und dann kommen schon mal ein paar Domains und Subdomains raus, wenn sie die dann dort eintragen. Jawoll, aber alles in alle. Google Chrome wird es ab Oktober 2017, also dieses Jahr verpflichtend einführen. Das heißt, jede Zertifizierungsstelle, die nicht sich in ein Log eintragen lässt und da gibt es eigentlich nicht mehr so viele, aber angenommen, wenn das passieren würde, dann würde Google Chrome eben einen Fehler werfen. Das funktioniert oder das würde ja dann damit auffallen, wenn Goulash ein Zertifikat ausliefert und da ist kein SCT dabei, dann sagt der Browser, hey, wo ist SCT? Und dann funktioniert das nicht mehr, ne? Genau, Firefox oder Mozilla ist da noch ein bisschen vorsichtig. Die werden das testweise mit einbauen. Man kann das sich in der Bout-Config irgendwo einstellen. Die werden aber nicht ab Oktober gleich mitziehen, erst nach einer Testphase. Aber cooles Konzept, also ist eine gute Sache, um die Transparenz in dieses BKI-System einzuführen und eben die notwendige Überwachung möglich zu machen. Jawohl, drei Ansätze, unterschiedlicher Couleur, die ich vorgestellt habe. Fazit würde ich sagen, dass das Vertrauen ganz gut ist in diese Zertifizierung stellen, aber die Kontrolle besser. Das heißt, werdet aktiv, tragt euch in solche Monitordienste ein, verwendet beispielsweise als Webseitenbetreiber HPKP, setzt solche Dienste ein und sichert verschlüsselte Kommunikation eben ab. CT und HPKB sind dann ganz viel versprengt. Vielen Dank. Jetzt gibt es noch ein paar Minuten vielleicht für Fragen. Wir haben da ein Mikrofon. Schnappt euch das? Ja, mit dem SCT und dem Prüfen im Chrome. Wie ist das mit CAs, die ich Firmenintern betreibe, für interne Dienste? Die werde ich ja wohl ungern irgendwo in ein Public-Lock schieben. Was macht der Chrome dann? Ja, ganz genau, guter Punkt. Also, zum einen hast du die Möglichkeit, neben der Zertifizierungsstelle selbst Zertifikate in die Locks zu kommunizieren. Das ist natürlich dann die Möglichkeit, wenn du das mit Chrome nicht mehr machen kannst, das entweder wahrscheinlich in Chrome zu deaktivieren. Irgendwie gibt es das wahrscheinlich in den Einstellungen oder einen anderen Browser zu verwenden. Aber es ist ein gewisses Problem, der Privacy in diesem ganzen Konzept. Wir werden sicherlich Gewissheit haben ab Oktober 2017, was Google da jetzt genau macht. Man genommen, jemand hätte ein Zertifikat auf meiner Seite ausgestellt. Wie kann ich das zurückrufen? Ich habe den entsprechenden privaten Schüssel gar nicht um zu sagen, ich will das Zertifikat nicht. Wie kann ich das denn dann sagen? Also, das Revocation-Management läuft meistens über OCSP. Das heißt, der Browser fragt bei der Zertifizierungsstelle an, ist Zertifikat noch gültig? Und diese Zertifizierungsstelle müsste diese Zertifikat dann eben revocaten. Angenommen, du bemerkst das, da müsstest du zu der Zertifizierungsstelle hingehen und sagen, hey, das Zertifikat habe ich nicht erstellt. Ich kann nachweisen, dass ich owner bin von dem Ganzen. Was hast du da gemacht? Und wie hat das Ganze funktioniert? Ich würde da wahrscheinlich relativ schnell eben zu Google oder eines der Logs gehen, um das Ganze ein bisschen zu eskalieren. Da muss ein bisschen Dampf dahinter sein, weil in der Vergangenheit haben sich die Zertifizierungsstellen nicht unbedingt immer sehr aufdeckend gezeigt. Weil es heißt dann ja, wenn du das definitiv nicht warst, dann hast entweder du nicht deinen Server in der Hand. Da müssen wir mal gucken. Oder die Zertifizierungsstelle hat tatsächlich einen Fehler gemacht. Und entsprechend muss man das dann melden. Also entweder bist du gehackt worden oder die Zertifizierungsstelle. Hinten noch eine, ja? Im Beispiel hat man gesehen, es gab drei Logs auf Google. Und was kann da passieren, wenn der Betrieb gleich mehrere Logs auf Betreibt? Also alle Logs auf einem gleichen Betreiber sind. Und habt mir als Serverbetreiber irgendwelchen Einfluss drauf, welcher Logsverband der jetzt genommen wird? Also es gibt mehrere öffentliche Logs. Ich kann euch da die Seite... Ich kann euch da die Seite certificatetransparency.org mal gucken. Jawohl. Empfehlen. Und dann gibt es hier die known Logs. Und hier habt ihr den known Logs. Es gibt von Google also das Pilot, Icarus, Rocketier und so weiter. Es gibt ein eigenes Log für certificate... äh, für Let's Encrypt-Zertifikate. Und dann können wir hier mal gucken. Es gibt von DigiZert1. Es gibt von Symantec1, noch eins. CNNIC, StartSSL, GDCA. Also du siehst, es gibt einige... öffentliche Logs, in die du deinen Certificat auch unabhängig rein pushen kannst. Du müsstest natürlich dann das SCT noch mit ausliefern. Das ist natürlich in dem Certificat schon drin. SCTs können auch über OCSB-Stabling zum Beispiel ausgeliefert werden. Also da gibt es mehrere Möglichkeiten. Oder beim TLS-Verbindungsaufbau. Und dann hast du also die Möglichkeit, mehrere Logs noch zu verwenden. Aber grundsätzlich gibt es also mehrere Logs. Mindestens in zwei Logs muss dieses Certificat eingetragen werden. Und wenn eben Logs von einem und dem gleichen Anbieter betrieben werden, dann ist es natürlich nicht unbedingt state-of-the-art und so, wie das System gedacht ist. Es sollte nach Möglichkeit organisationell getrennt sein. Prima. Dann, wenn es keine weitere Fragen mehr gibt, bedanke ich mich durch herzlich. Und viel Spaß noch bei den weiteren Vorträgen und auf der GPR. Danke.