CAs und Let’s Encrypt

Simon Kölsch: Willkommen zum INNOQ Security Podcast. Heute mit dem Thema Certificate Authorities und Let‘s Encrypt. Ich bin der Simon und ich unterhalte mich hier mit dem Christoph. Hallo Christoph!

Christoph Iserlohn: Hallo Simon!

Simon Kölsch: Wir wollen über ganz verschiedene Themen dabei sprechen. Wir wollen ein bisschen klären was eine Certificate Authority ist, so zum Einstieg. Wir wollen uns ein bisschen damit beschäftigen, wo da so ein bisschen die Probleme bei liegen und was Let’s Encrypt damit zu tun hat. Und zu guter Letzt was eigentlich Mark Shuttleworth, der Spender in der Ubuntu, mit Certificate Authorities zu tun hat. Was ist das denn überhaupt?

Christoph Iserlohn: Was ist eine Certificate Authority oder was hat Mark Shuttleworth damit zu tun? Womit fangen wir denn an?

Simon Kölsch: Na, das klären wir doch am Ende auf, oder?

Christoph Iserlohn: Ja, okay. Das klären wir am Ende auf. Fangen wir mal damit an, was denn eine Certificate Authority ist. Das können wir mal unterscheiden in einmal sozusagen die Software Komponente, die Zertifikate ausstellen kann. Also das haben wir in einer anderen Folge schonmal besprochen, was so ein Zertifikat ist und wo wir das alles brauchen. Und irgendjemand muss einem so ein Zertifikat ausstellen und das ist diese Software dazu. Und das andere ist irgendwie die Institution oder Körperschaft oder wie man das auch nennen will, die dahintersteht. Die das betreibt, diese Software. Und das können ganz verschiedene sein und eine wollen wir heute eine Besondere davon etwas detaillierter besprechen. Das ist dann Let’s Encrypt, aber da kommen wir später zu.

Simon Kölsch: Okay. Das heißt wir haben in den vorherigen Folgen ja schonmal generell darüber gesprochen wie das technisch funktioniert, wenn zwei Parteien verschlüsselt miteinander kommunizieren wollen. Du hast mit Lucas in der zweiten Folge über Zertifikate gesprochen, die das Schlüsselmaterial und Metainformationen enthalten. Was wir bisher aber einfach außen vor gelassen haben ist, dass diese Zertifikate ja nicht magisch einfach irgendwie mal da sind. Und wir irgendwie die Frage beantworten müssen: Rede ich eigentlich mit der korrekten Partei mir gegenüber oder steckt da irgendwer dazwischen mit dem ich eigentlich kommunizier? Also irgendwer, der die Verbindung abhört? Wo kommt denn dieses Vertrauen jetzt her, dass ich weiß: Mein Gegenüber ist jetzt wirklich der Gegenüber, als der er sich ausgibt? Wie kommt da die CA ins Spiel zu?

Christoph Iserlohn: Das Vertrauen wird halt durch ein Zertifikat hergestellt das sagt: Okay, hier mit diesem Schlüssel, mit dem du sprichst, das gehört auch der folgenden Entität. Zum Beispiel bei einer Bank, mit der ich gerade spreche. Wo es ziemlich wichtig ist, dass wir da verschlüsselt sprechen und dass nicht zwischendurch manipuliert werden kann auf dem Transport. Das Problem ist, warum glaube ich jetzt dem Zertifikat, dass wenn das darinsteht. Das ist jetzt meine Bank oder irgendeine andere Entität, der ich vertrauen möchte. Warum glaube ich das dann? Also nur weil das irgendwo geschrieben steht, muss das jetzt nicht unbedingt wirklich so sein.

Simon Kölsch: Also das könnte Harry Hacker sein, der seine Fishing-Seite aufgesetzt hat und auf Kundschaft wartet.

Christoph Iserlohn: Genau und deshalb sind halt Zertifikate immer signiert von einer anderen Entität und die beglaubigt das. Und jetzt ist man halt in so einer Kette drinnen. Okay dann muss ich aber der anderen Entität irgendwie glauben, die das signiert hat. Und damit diese Kette halt nicht endlos weiter geht, also deren Zertifikat kann wieder signiert sein und das weitere Zertifikat auch wieder und so weiter und so fort. Das wäre ja eine endlose Kette, also muss halt irgendwo Schluss sein. Und das ist typischerweise bei einem so genannten Root Zertifikat, das dann nicht von einer anderen Entität signiert wurde, sondern das selbstsigniert ist. Und diese Root Zertifikate werden halt von den CAs ausgestellt, beziehungsweise die sind in dem Besitzt dieser CAs. Und denen vertraue ich, weil entweder mein Browser oder mein Betriebssystem deren Root Zertifikat schon mitbringt und dem von vornherein vertraut. Warum die denen vertrauen, da kommen wir vielleicht später noch zu. Da gibt es so gewisse Anforderungen, die so eine CA erfüllen muss, bevor sie überhaupt in das Betriebssystem kommen oder den Store von dem Browser. Aber denen wird dann einfach vertraut und da ist diese Kette zu Ende und wir sagen: Denen vertrauen wir. Und genau das ist eine CA, die solche Zertifikate hat und damit dann andere Zertifikate ausstellt und andere Zertifikate signiert.

Simon Kölsch: In welcher Form treten die denn auf? Also sind das privatwirtschaftliche Unternehmen? Ist das die Bundesregierung, die die Zertifikate ausstellen kann? Mache ich das bei der Telekom?

Christoph Iserlohn: Das ist unterschiedlich, das kommt ein bisschen auch auf den Verwendungszweck an. Also im Prinzip kann erstmal jeder eine CA betreiben. Also ein Root Zertifikat ausstellen. Da sind ein paar Zeilen auf der Kommandozeile nötig mit OpenSSL und damit könnte ich weitere Zertifikate signieren. Jetzt ist halt die Frage: Wer vertraut dem? Das kann ich dann machen, wenn ich jetzt intern sowas betreibe in meinem eigenen System. Zum Beispiel im Heimnetzwerk, da könnte ich das Root Zertifikat auf allen meinen Rechnern installieren und dann wird halt dem vertraut. Wenn ich das jetzt vielleicht im professionellen Umfeld mache, dann kann man das ähnlich machen. Zum Beispiel nehmen wir an wir haben irgendwie eine IoT-Installation und da sind viele Endgeräte irgendwo draußen in der Welt verteilt, die sollen aber ab und zu halt mal mit den Servern, irgendwelchen Backend Servern, kommunizieren. Und das sollten sie am besten ja auch über TLS machen, also verschlüsselt. Also müssen die ja auch irgendwie den Zertifikaten vertrauen. Und wenn das jetzt ein geschlossenes System ist, also nicht öffentliche Backends, dann könnte ich in diese IoT Geräte von vornherein zum Beispiel ein Root Zertifikat installieren dem vertraut wird, weil sie es selbst ausgestellt haben. Also dann betreibe ich das halt selbst. Oder nehmen wir ein anderes Beispiel, wenn wir jetzt in der Cloud sind und wir betreiben irgendwie Microservices auf Kubernetes und ich möchte die Kommunikation zwischen diesen einzelnen Microservices auch bei TLS verschlüsseln, dann könnte ich zum Beispiel auch eine eigene CA da betreiben. Und wenn ich den Microservice-Deploy, den direkt das Root Zertifikat mitgebe, dem vertraut werden soll oder die Root Zertifikate, denen vertraut werden sollen. Also sowas macht zum Beispiel ein Service Mesh wie Istio oder Istio kann sowas machen. Das betreibt dann im Hintergrund eine eigene CA. Und die andere Sache ist, wenn ich im Internet unterwegs bin und jetzt mit öffentlichen Seiten spreche, dann wird natürlich nicht meinem eigenen Root Zertifikat vertraut werden. Sondern das sind, wie ich das vorhin schonmal erwähnt habe, welche die schon der Browser mitbringt oder das Betriebssystem. Und wenn ich Zertifikate von so einem Root Zertifikat signiert haben will, beziehungsweise, dass die Kette bis zu diesem Root Zertifikat geht, dann muss ich mich an eine typischerweise kommerzielle Entität wenden. Da gibt es ganz viele CAs, also ein paar Namen, die man so kennt. Es gibt IdenTrust, das ist glaube ich so ziemlich die Größte; DigiCert, die haben vor kurzem Symantec übernommen, die kennt man so aus dem Anti-Virus Bereich; Sectigo, die hießen vorher Comodo, den Namen kennt man vielleicht. Oder GoDaddy oder GlobalSign, da gibt es ganz viele und da kann man dann halt Zertifikate kaufen. Beziehungsweise man kauft eigentlich die Signatur ein, also das Zertifikat und den Schlüssel erstellt man selbst und dann schickt man das dahin und die signieren einen das dann. Und dann gibt es noch CAs, die sozusagen ein Zwischending sind. Die zwar öffentlich sind, aber dann nicht kommerziell sind. Das ist CAcert, das ist nicht so bekannt und was wir heute noch etwas genauer besprechen wollen Let’s Encrypt.

Simon Kölsch: Okay. Das heißt wir müssen so ein bisschen unterscheiden. Eine CA ist erstmal ein Konstrukt in dem ganzen Protokoll und stellt mir erstmal nur Vertrauen für eine Kette von Zertifikaten her. Das Ganze kryptographisch dann realisiert über Unterschriften und dann unterscheidet man zum einen: Was ist das für eine Organisation? Brauch ich diesen Trust in meinen Browser oder habe ich die Möglichkeit, weil das eigene Infrastruktur ist und ich das in meinem Backend benutz, das quasi einfach entsprechend selbst auszustellen? Du hast erwähnt, da gibt es quasi technische Komponenten. Das sind ein paar Befehle auf der Kommandozeile, um Schlüsselmaterial zu generieren. War es das denn? Also was brauche ich denn eigentlich, um sowas selbst umzusetzen? Beziehungsweise, wie sieht denn da das Tooling drumherum aus?

Christoph Iserlohn: Vorhin hatte ich ja erwähnt, dass man OpenSSL benutzen kann, um sich so ein Root Zertifikat auszustellen. OpenSSL kann ich auch dazu benutzen, um mit diesem Root Zertifikat andere Zertifikate zu signieren. Und theoretischer Weise könnte ich das sozusagen, wenn ich das benutze und eine Webserver baue der CGI para OpenSSL Befehle aufruft, könnte ich so eine ganze CA aufbauen. Das ist dann natürlich ein ziemlich fragiles System, von daher würde ich das nicht empfehlen. Wenn man das selbst machen will, gibt es verschiedene Software-Lösungen aus dem Open Source Bereich die man da einsetzten kann. Da gibt es einmal OpenXPKI, das ist glaube ich so ziemlich die Älteste, die ich jedenfalls kenne. Dann gibt es EJBCA, das ist eine Java EE basierte CA-Software. Und dann gibt es Boulder, das ist der Softwarestack den Let‘s Encrypt benutzt intern, den haben sie als Open Source Software veröffentlicht. Und darauf würde ich dann zurückgreifen, anstatt das alles selbst von ‚scratch‘ zu machen. Weil Zertifikate sind dann ja doch schon ein sehr sensibler Bereich und wenn ich da etwas falsch machen, dann kann das sehr böse Auswirkungen haben. Von daher sollte ich da einen Softwarestack nehme, der vielleicht ganz gut abgehangen und ausgereift ist. Und die übernehmen dann halt auch viele Sachen, die man sonst manuell löst, sind dann da auch automatisiert möglich. Also, dass man Zertifikate nach einem bestimmten Profil ausstellt, also wenn zum Beispiel: Will ich Zertifikate haben für TLS? Wo wir meistens jetzt drüber gesprochen haben, also für das Web? Will ich vielleicht auch E-Mail-Zertifikate habe für S/MIME und dann kann ich zum Beispiel bei der EJBCA so ein Profil hinterlegen wie so ein Zertifikat aussehen soll und dann werden alle entsprechend diesem Profil ausgestellt. Und die unterstützten meistens auch automatisierte Protokolle, wie man so an so ein Zertifikat kommt. Da gibt es einmal das Simple Certificate Enrollment Protocol und dann das Enrollment over Secure Transport, was so ein bisschen der Nachfolger von dem Erstgenannten ist. Mit denen kann ich dann sozusagen automatisiert ein Zertifikat anfordern und kriege das dann automatisch ausgestellt. Das ist zum Beispiel, wenn ich jetzt so auf IoT zurückkomme, was ich am Anfang als Beispiel genannt habe, ja auch wichtig, dass man sowas automatisieren kann und kein manueller Prozess dazwischensteht. Weil so ein Gerät, wenn es irgendwo in der Pampa steht, kann ich ja nicht immer einen Servicetechniker dahinschicken, der dann ein neues Zertifikat dann bestellt und das dann von Hand installiert. Ein drittes Protokoll, dass besprechen wir aber später, das ist das ACME Protokoll, das Automatic Certificate Management Environment. Das ist nämlich das was Let’s Encrypt benutzt. Das ist dann speziell auf TLS Zertifikate ausgerichtet.

Simon Kölsch: Okay, das heißt wenn es mir nur darum geht irgendwie einen Service und zwei Clients miteinander eine verschlüsselte Verbindung aufbauen zu lassen, dann kann ich das einfach realisieren indem ich ein entsprechendes Zertifikat generiere. Ich kann da auch ein eigenes Zertifikat anlegen, mit dem ich andere Zertifikate signiere und sollte dann halt dafür sorgen, dass das Schlüsselmaterial an einer sicheren Stelle liegt. Sobald das aber eine größere Infrastruktur wird, zum Beispiel eine Microservice Landschaft oder ähnliches, habe ich ja auch das Problem, dass ich zum Beispiel die Zertifikate irgendwie regelmäßig erneuern muss. Lange Laufzeiten sind immer problematisch, weil wenn dann ein Zertifikat ungültig werden soll, revoked wird, dann muss ich irgendwo eine Blacklist führen solange wie das Zertifikat am Anfang Gültigkeit gehabt hätte. Das muss ich alles dementsprechend publizieren. Wenn ich kurze Laufzeiten habe, dann muss ich öfters die Zertifikate tauschen. Das wollen wir eigentlich ja mit Software lösen und nicht manuell die ganze Zeit irgendwie Dateien hin und her schubsen. Das heißt eigentlich bin ich dann gezwungen eine eigene PKI zu betreiben, also public-key-infrastructure und das könnte ich dann mit einer entsprechenden Software-Lösung oder Stacks entsprechend vereinfachen.

Christoph Iserlohn: Genau und das könnte man nicht nur, das sollte man auch. Weil man das wahrscheinlich a) von Hand nicht hinkriegt und b) auch nicht mal eben so selbst runterschreibt. Du hast das gerade so erwähnt, also es geht ja nicht nur um die Zertifikate, die ausgestellt und signiert werden müssen, sondern auch so um einen Name Service für so eine PKI. Zum Beispiel, du hast gerade das Beispiel von so einer Liste genannt, wo die zurückgezogenen Zertifikate sind, also eine CRL oder ein OCSP Responder, der das selbst macht, aber online, sozusagen on the fly. Solche andere Software Komponenten brauche ich auch für die PKI. Und das ist halt ganz schön viel, dass man nicht ebenso selbst schreiben kann.

Simon Kölsch: Okay. Sicherlich auch nichts was man nebenbei im Projekt mit betreibt. Also das ist nicht der nächste Service, den man irgendwo aufsetzt und dann so nebenbei wie einen DNS-Server betreibt, sondern da steckt durchaus ein gewisser Aufwand dahinter. Idealerweise ist natürlich im Unternehmen schon eine PKI da und man kann die Infrastruktur entsprechend mit nutzen, aber das Glück hat man ja nicht immer.

Christoph Iserlohn: Das hat man nicht immer und was vor allem dafürspricht, dass sich da dediziert jemand drum kümmert, ist halt die Sicherheitsanforderung. Also das kann ich halt nicht so einfach mal neben bei in der Cloud machen, sondern ich muss mir da auch Gedanken drüber machen. Die Software Komponenten brauchen halt Schlüsselmaterial. Die brauchen das Root Zertifikat und den privaten Schlüssel dazu oder die intermediaten Zertifikate, mit denen die eigentliche Signatur geschieht. Aber auch dazu brauchen sie ja die privaten Schlüssel. Und da muss ich mir halt ein bisschen mehr Gedanken machen, wie ich das deploye, wie ich da den Zugriff absichere und so weiter und so fort. Und das wird wahrscheinlich dann auch nicht unbedingt in dem gleichen Kubernetes-Cluster laufen, wo ich meine Microservers habe. Das sollte ich halt schön getrennt halten und das ist eine Menge Arbeit und erfordert meines Erachtens ein dediziertes Team, das sich damit beschäftigt und die auch wahrscheinlich auch ein bisschen mehr Kenntnisse und Erfahrungen im Bereich Sicherheit haben als vielleicht der normale Microservice Developer.

Simon Kölsch: Okay, das heißt dafür bezahle ich eigentlich bei so einer certificate authority letztendlich Geld. Also ich habe mein eigenes Zertifikat und ich hätte jetzt gerne das public Browser, ganz normal in Internet, mir vertrauen. Wie würde das denn funktionieren? Also wie wird denn sichergestellt, dass ich ich bin und wie sind denn da die nächsten Schritte?

Christoph Iserlohn: Genau, das sind halt in dem Fall kommerzielle Entitäten, die dir Zertifikate ausstellen können. In diesem Fall, denen dein Browser vertraut und die sind halt kommerziell, weil wie wir gerade gehört haben, ist das ja eine Menge Aufwand und das gibt es halt nicht umsonst. Und Geld wollen sie natürlich auch noch verdienen, aber das sind erstmal Kosten, die die haben. Und wie das normalerweise ist, bei dem TLS Zertifikat, was wahrscheinlich die Zertifikatsart ist, die am meisten eingesetzt wird. Also es gibt ja x-Millionen und vielleicht auch Milliarden Internetseiten, die über TLS erreichbar sind. Da ist es so, dass man zu einen diese CAs hingeht und ein CSR macht, ein certificate signing request, also das heißt ich erstelle einen Schlüsselpaar (private/public) und dann in diesen in diesen certificate signing request kommt dann halt der public key rein und dann die Adresse, also die Domain, wofür ich das haben will, das Zertifikat, und so weiter. Und alle Metadaten, die möglich sind und dann beantrage ich da, dass mir dafür bitte ein Zertifikat ausgestellt wird. Und das kostet dann meistens Geld, ganz unterschiedlich je nachdem welche Art von Zertifikat das ist und bei welchem Anbieter man da ist, weil die Anbieter haben halt auch verschiedene Dienstleistungen. Also das geht davon, dass man sich irgendein Siegel draufmachen kann, auf die Seite, dessen Nährwert stellen ich jetzt mal in Frage. Aber gut, manche wollen das halt. Dann gibt es Kundenservice, den man anrufen kann und ob der zu den Bürozeiten oder 24/7 erreichbar ist und je nachdem gestaltet sich dann der Preis, den man dafür bezahlen muss. Das kriege ich dann natürlich auch nicht einfach so, sondern es muss ja auch irgendwie gewährleistet werden, dass ich für diese Domain auch das Recht habe ein Zertifikat zu bekommen. Und dann wird das halt validiert in verschiedenen Formen, dass ich da entsprechend auch der Domaininhaber bin.

Simon Kölsch: Das funktioniert dann ähnlich wie, ich bekomme dann einfach eine E-Mail zum Beispiel und bestätige auf einem Link, dass ich die bekommen habe und deswegen irgendwie berechtigt bin E-Mails an diese Adresse zu empfangen. Wird das dann über eine DNS-Eintrag gelöst, oder?

Christoph Iserlohn: Es gibt verschiedene Möglichkeiten, also das mit der E-Mail gibt es auch, dass an eine bestimmte Adresse, eine vordefinierte Adresse, ich weiß nicht welche das jetzt genau ist, aber nennen wir sie einfach mal [email protected] und dass man da die Mail hinschickt, um das zu bestätigen.

Simon Kölsch: Meinst du die bekommen viele Mails dort?

Christoph Iserlohn: Da gibt es bestimmt ganz viele Mails, die da kommen. Die auch nicht alle immer den Hintergedanken haben, dass man jetzt ein Zertifikat bekommen soll, sondern halt auch sonst irgendwo klickt, wo man halt besser nicht klicken soll. Aber das ist ein anderes Thema. Aber diese Überprüfungsmöglichkeiten sind halt verschieden und es gibt was wir vielleicht erwähnen sollten, neben dieser Domain-Validation. Also es wird validiert, dass ich Besitzer dieser Domain bin oder dafür Zertifikate entsprechend beantragen darf, gibt es auch noch die Extended-validation und die Organizational-validation. Bei denen wird dann halt nicht nur überprüft, dass ich halt sozusagen Kontrolle über diese Domain habe, sondern da wird auch wirklich die Identität überprüft. Da müsste man vielleicht dann je nachdem mit dem Ausweis hingehen oder wenn eine Organisation überprüft wird, dann halt verschiedene Dokumente, die diese Organisation ausweisen, werden dann überprüft und dann kriegt man ein so genanntes Extended-Validation oder Organizational-Validation Zertifikat ausgestellt, wo diese Informationen dann auch nochmal in dem Zertifikat kodiert sind. Das machen dann typischer Weise zum Beispiel irgendwelche kommerziellen Entitäten. Also eine Bank zum Beispiel hat das oft in ihrem Zertifikat drinnen, das sie so eine Extended-Validation haben, wo in dem Zertifikat dann zum Beispiel auch ein Kontakt hinterlegt ist und genaue Adresse und so. Weil eine Domain sagt jetzt auch noch nicht so viel aus. Weil eine Domain klicke ich mir irgendwo für einen Euro und wenn ich dann eine Fishing-Seite mache und irgendwie mich als Bank ausgebe, dann wäre es schon gut, wenn man mehr überprüfen kann, als nur ‚mir gehört diese Domain‘.

Simon Kölsch: Wobei man sagen muss, also das ist schön, dass wir unterschiedliche Levels der Zertifikation haben. Aber für einen normalen Nutzer im Alltag mit seinem Browser, spielt das eigentlich keine Rolle, oder?

Christoph Iserlohn: Ja, die Idee ist halt ganz gut, aber in der Praxis sieht es dann anders aus. Diese Extended-Validation Zertifikate, die wurden von Firefox und Chrome, bei Safari weiß ich es jetzt nicht, früher auch anders angezeigt. Das schöne Schloss in der URL-Leiste war dann grün und das hat natürlich kein Nutzer bemerkt irgendwie oder einen Unterschied bemerkt. Weil das wichtige war halt Schloss da oder Schloss nicht da, oder Schloss zu/Schloss offen.

Simon Kölsch: Wenn überhaupt noch.

Christoph Iserlohn: Wenn das überhaupt einer beachtet. Und Google Chrome und Firefox haben das in den, ich weiß nicht wie vielen Versionen das jetzt her ist, noch nicht so lange, auch abgeschaltet, dass die irgendwie anders aussehen die Zertifikate. Aber die werden immer noch verkauft und in manchen Regularien sind die auch noch vorgeschrieben. Von daher, ich glaube gerade im Banken-Sektor gibt es diverse Regularien, wo es auch vorgeschrieben ist das ein Extended-Validation Zertifikat da ist und nicht einfach nur eins für die Domain. Aber von daher…

Simon Kölsch: Die Kreditkartenverarbeitung zählt da ja auch mit dazu und so.

Christoph Iserlohn: Genau, sowas zum Beispiel. Da gibt es das noch. Für den Endnutzer macht das von der UX wahrscheinlich wenig Unterschied und ich glaube auch die wenigsten Endnutzer erkennen den Unterschied.

Simon Kölsch: Okay. Man könnte fast sagen da ist über Jahre bei den CAs auch einfach nicht so wahnsinnig viel passiert dann. Das war so der Status-Quo. Es gab in den ganzen letzten Jahren massive Security Vorfälle mit unterschiedlichen CAs. Du hattest erwähnt: Es gibt CAcert. Wie ist das eigentlich entstanden? Was war da der Hintergrund? Und wie ist denn da heute der Stand?

Christoph Iserlohn: Ja, CAcert ist halt ein gemeinnütziger Verein, beziehungsweise, das ist in Australien beheimatet oder Neuseeland, dass weiß ich gar nicht genau. Und deren Organisationsform ist halt so vergleichbar gemeinnütziger Vereine in Deutschland, ich weiß nicht, ich kenn mich da nicht aus, wie es Down Under so aussieht. Also welche Rechtsformen die da genau haben. Und das wurde gegründet, dass auch normale Leute für ihre Domain, die die jetzt nicht professionell betreiben, so die einen privaten Webserver haben, zum Beispiel eine private Homepage hosten oder so, auch an Zertifikate kommen. Oder auch um an E-Mail-Zertifikate zu kommen, weil so ein Zertifikat auch nicht so billig ist, beziehungsweise das nicht so billig war und dass dann die wenigsten Leute, die eine private Homepage gehostet haben, sich das Zertifikat besorgt haben. Und die haben dann Zertifikate ausgestellt, da musste man sich dann halt anmelden. Da gibt es dann auch nicht so eine Riesen Überprüfung dafür, so ein bisschen abgestuftes System, wer da was ausstellen darf und so weiter und so fort. Und dann hatte man sich halt Zertifikate besorgen können. Also für seine Domain, für E-Mail oder für andere Zwecke, also zum Beispiel als Client Cert. Das Problem dabei ist, dass diesen Zertifikaten halt die großen Browser oder Betriebssysteme nicht vertraut haben. Und das heißt, immer wenn ich eine Seite damit aufgerufen habe, die eine TLS Verbindung gemacht hat und dann CAcert, von denen ausgestelltes Zertifikat für die TLS Verbindung genutzt haben, dann gibt es eine Warnung. Und die haben dann mal versucht auch in den Browser aufgenommen zu werden, aber…

Simon Kölsch: Ich erinnere mich selbst mal noch ein Root Zertifikat von CAcert installiert zu haben, aber es ist ja schwer genug überhaupt ein gewisses Gefühl dafür zu schaffen, dass es wichtig ist, wenn man verschlüsselt kommunizieren will. Dass dann ein Schloss angezeigt wird und so weiter. Der durchschnittliche Benutzer installiert ja nicht nochmal eigene Root Zertifikate. Und gefühlt ist es dabei immer so ein bisschen stehengeblieben, oder?

Christoph Iserlohn: Ja, also wie ich gerade gesagt habe, sie haben es mal versucht. Das ist aber so ein bisschen im Sand verlaufen, weil es gibt halt bestimmte Anforderungen, da kommen wir später noch zu, wie die sich so genau zusammensetzen. Damit man zum Beispiel bei Mozilla in den Trust Store kommt oder bei Google oder bei Microsoft in den von Windows-Betriebssystemen. Und diese Anforderungen konnten sie halt nie erfüllen, weil die hatten da nie die finanziellen Mittel. Also die sind ziemlich hoch. Da geht es um Prozesse und um Technik und alles Mögliche, wie gesagt später mehr dazu. Und das konnten die halt einfach nicht erfüllen und das ist jetzt so ein bisschen im Sande verlaufen. Das ist jetzt schon seit Jahren so, dass die das anstreben, aber da tut sich jetzt nicht so viel. Besonders nicht seit es jetzt Let’s Encrypt gibt, die ja sozusagen da in Konkurrenz getreten sind.

Simon Kölsch: Genau, das wäre dann so ein bisschen fast forward, 2016 ist das glaube ich gelauncht. Und man kann bestimmt sagen, dass Let’s Encrypt diesen ganzen Zertifikatmarkt da eigentlich ganz schön aufgeräumt hat. Was machen die denn anders?

Christoph Iserlohn: Ja, Let’s Encrypt…, vielleicht sollten wir erstmal sagen was das ist. Let’s Encrypt ist auch ein non-profit, also auch gemeinnützig. Das wurde gegründet von Mozilla, der Electronic Frontier Foundation, heute sind dann noch Google dabei und Facebook und Cisco und die Internet Society und noch mehr, die Linux Foundation zum Beispiel. Und die hatten sich das Ziel gesetzt dann großflächig halt eine verschlüsselte Kommunikation im Internet herzustellen, und zwar in dem man kostenlos TLS Zertifikate bekommt. Und zwar welche denen auch vertraut wird im Gegensatz zu CAcert, habe die es geschafft, dass denen vertraut wird. Dass die halt in dem Browser Storage sind und in den Betriebssystemen-Stores. Was haben die denn anders gemacht? Also a) stehen da natürlich gewichtige Institution und Firmen hinter, das war schonmal ein großer Startvorteil. Also die haben wahrscheinlich viel mehr Geld, um ihre CA zu betreiben. Also ist halt kein Hobbyverein.

Simon Kölsch: Naja und stückweit sind ja die Browserhersteller mit an Bord, also…

Christoph Iserlohn: Genau! Nicht nur ein stückweit, sondern die sind da halt mit… Also Google und Mozilla sind ja wahrscheinlich… und Microsoft ist auch, obwohl Microsoft weiß ich gar nicht. Nein, die sind bei Let’s Encrypt nicht dabei. Aber trotzdem die werden ja wahrscheinlich über 50 Prozent Marktanteil haben. Von daher haben die natürlich eine gute Startbedingung dafür. Gut, aber was machen die jetzt anders? Also sie machen es deutlich professioneller als CAcert, aber sie machen es auch anders als die kommerziellen CAs. Da war es halt so, du hast es gerade erwähnt, da ist ziemlich langer Stillstand gewesen. Also weil, da gab es halt nicht so viel Konkurrenz und es war auch nicht so einfach als Konkurrent sich zu etablieren, weil so eine CA aufzubauen dauert halt unglaublich lange. Also auch wenn ich die Anforderungen an so eine CA erfülle, sodass ich bei Microsoft vielleicht in den Trust Store komme oder bei Apple und auch bei Mozilla.

Simon Kölsch: Wie wird das denn entschieden? Also gibt es da ein Board, dass das managed, oder?

Christoph Iserlohn: Ja, das ist das CA/Browser Forum, das können wir später nochmal vielleicht, also das würde ich gerne noch zurückstellen. Was ich sagen wollte ist: Das dauert sehr lange und auch wenn ich da jetzt aktuell drin bin, es gibt ja x Altgeräte. Also wie viele Android Telefone gibt es, die keine Updates mehr kriegen oder IoT Geräte, die nicht geupdatet werden oder sonst alte Betriebssystem Versionen. Also es gibt ja immer noch Windows XP im Internet. Von daher, die kriegen dann halt die neuen Zertifikate nicht und das heißt ich brauche ja erstmal so und so viele Jahre, damit mir überhaupt genügend Leute eigentlich vertrauen können.

Simon Kölsch: Ja, das geht nicht ohne ein entsprechendes Anfangsinvestment.

Christoph Iserlohn: Genau und das dauert halt sehr lange, deshalb hat sich bei den CAs wenig getan. Also die haben sich vielleicht gegenseitig mal aufgekauft, also da gab es Bewegung im Markt. Aber nicht durch irgendeinen großen Newcomer, weil das halt sehr, sehr lange dauert, bis man da Fuß fasst. Und deshalb was das Ganze auch ein bisschen verkrustet. Also so ein Zertifikat zu bekommen, das war oft eine sehr manuelle Sache. Also das CSR machen und den dann da einreichen und so. Das waren viele manuelle Schritte, die da gemacht werden mussten, für jemanden, der ein Zertifikat haben wollte. Und auch die UX war oft grauenhaft. Also ich erinnere mich immer noch an den Provider von dem ich ein E-Mail Zertifikat habe für S/MIME. Also das macht man im Browser auf seiner Webseite und die funktioniert mit allen aktuellen Browsern nicht mehr. Also man muss sich eine alte Browser Version installieren, damit man überhaupt da ein Zertifikat beantragen kann.

Simon Kölsch: Ich erinnere mich da auch an furchtbare Kleinzertifikate, wie für den Zugriff, um dann mit irgendwelchen java applets, die auf der Seite embedded waren, zu reden.

Christoph Iserlohn: Ja, alles ganz grausam. Und was jetzt Let’s Encrypt anders gemacht hat: Die haben von Anfang an auf totale Automatisierung gesetzt. Ich meine sonst könnten sie das wahrscheinlich auch nicht managen, auch mit ihren Ressourcen nicht, auch wenn sie mehr haben als zum Beispiel CAcert. Aber sie haben einen wesentlichen Beitrag dazu geleistet, dass das automatisiert ist. Und das haben sie gemacht indem sie das ACME Protokoll, das Automatic Certificate Management Environment, hatte ich vorhin mal erwähnt, entwickelt haben und die Sicherung auch ans IETF gegeben haben, also die Internet Engineering Task Force und damit kann ich halt Zertifikate sozusagen vollautomatisch beantragen, installieren, erneuern, zurückziehen und alles was ich so brauche. Also eigentlich betreiben die keine CA, wo irgendwelche Menschen groß die Dienstleistung bringen und wo irgendwelche manuellen Schritte sind. Sondern die betreiben halt einen Service, einen Self-Service, an den man dann entsprechend sich programmatisch dranwenden kann in die API und dann funktioniert das alles wie geritzt. Und die Leute, die da arbeiten sind da eher für die Softwareweiterentwicklung zuständig und den Betrieb der Systeme.

Simon Kölsch: Das heißt, da habe ich eigentlich entsprechendes Tooling, was ich einfach nutzten kann. Es gibt auch entsprechende Erweiterung für die gängigen Webserver. Und das heißt, ich generiere da nicht mehr manuell irgendwo die Zertifikate, sondern eigentlich am Ende packe ich ein Modul, zum Beispiel in meine Nginx oder mein Apache und bekomme da das Zertifikat automatisch generiert, solange meine Endpunkte öffentlich erreichbar sind.

Christoph Iserlohn: Ganz genau, also das ist eine wichtige Einschränkung, die Let’s Encrypt hat. Die stellen halt nur TLS Zertifikate aus und zwar nur welche, die über die Domain validiert werden. Und das heißt nicht öffentliche, die nicht erreichbar sind, kann die Domain natürlich nicht validiert werden. Dafür gibt es keine Zertifikate und es gibt E-Mail-Zertifikate oder Kleinzertifikate, die muss ich immer noch bei einer anderen CA machen. Beantragen und dann bekommen und bezahlen. Auf jeden Fall, was du gerade erwähnt hast, ist richtig, man braucht wenig tun. Also sie haben damit geworben, ich weiß nicht ob sie es immer noch tun, dass man auf so ein Linux System mit zwei Kommandozeilenbefehlen, das so einrichten kann, dass man dauerhaft Zertifikate auf seine Apache oder seinen Ngnix hat. Also was man machen muss, es gibt halt viele Clients für diese API und es gibt den so genannten Certbot, das ist sozusagen der offizielle Client, obwohl der jetzt auch ein bisschen Übergang hatte sozusagen Freiheit, die haben den initial entwickelt. Haben den jetzt aber abgegeben und was macht das Stück Software? Was macht die? Die spricht mit der API, um dir ein Zertifikat zu holen und installiert dir das auch noch direkt. Also der unterstützt erstmal out of the box Apache und Ngnix und macht dir dann auch bei denen Beiden direkt die ganze Konfiguration fertig. Und dann wird der halt in den Cron gehängt. Also so ein Unix-Demon, der halt bestimmte Programme in gewissen Zeitintervallen, die ich einstellen kann, aufruft und das heißt der macht dann auch direkt eine Erneuerung. Also er guckt immer: Wie alt das? Aha, das brauch ich noch nicht erneuern, kann ich mich schlafen legen und wenn es dann irgendwann soweit ist, dann wird der das einfach irgendwann von sich aus erneuern und ich brauch gar nichts mehr tun. Diese Installation von den Certbot ist auch so ein Debian System halt in zwei Zeilen und dann ist das durch.

Simon Kölsch: Das ist natürlich ein Vorteil, wenn ich Dinge automatisiert habe. Ist ja ähnlich wie bei Passwörtern, wenn ich die von meinen Services, irgendwie von functional usern oder so, Passwörter rotieren will, dann kann ich das natürlich viel öfters tun, wenn das einfach automatisiert ist und man nicht manuell irgendwie Resets einmal im Jahr macht oder ähnliches. Das ist dann ja ein ähnlicher Effekt, das heißt bei den Laufzeiten ändert sich dann auch etwas.

Christoph Iserlohn: Ja, die Laufzeit ist viel kürzer als bei Zertifikaten, die von anderen CAs ausgestellt werden. Bei Let’s Encrypt sind es 3 Monate, also 90 Tage ist das gültig. Und wenn ich sonst ein TLS Zertifikat von einer normalen CA nehme, dann ist die typischerweise 1–2, sogar 3 Jahre gültig. Also von daher, der Automatisierung, der macht das dann halt nicht so viel aus, ob das jetzt ein Jahr ist oder alle 90 Tage. Sie könnte wahrscheinlich auch locker alle 30 Tage das machen. Das ist jetzt nicht das Problem.

Simon Kölsch: Okay. Das heißt, um das Zertifikat zu bekommen, lasse ich da einen Certbot laufen und mache dann die Identifizierung einfach über das ACME Protokoll.

Christoph Iserlohn: Ganz genau, da brauche ich mich nicht drum kümmern. Das heißt, dass ist auch für Administratoren, die nicht mehr so ganz tief in der Materie stecken, also irgendwelche Hobbyadministratoren, die irgendwie ihre eigene Homepage…. Ein wenig Wissen haben, aber das jetzt nicht professionell machen. Wie gesagt, die installieren sich den und der macht alles automatisch. Es gibt noch ganz viele andere Clients für das Protokoll, da kann ich das halt ein bisschen anders steuern. Wenn ich zum Beispiel sagen will: Ich möchte jetzt nicht auf einen Webserver irgendeine Software haben, die da an der Konfiguration rumfrickelt oder so. Oder ich habe eine ganze Serverflotte denen ich Zertifikate geben will, kann ich auch einen anderen kleinen nehmen, der dann auf einen extra Server läuft und der dann die entsprechenden Vorgänge halt auch automatisiert steuert, aber die dann halt ein bisschen anders sind, sodass ich da auch eingreifen kann. Ich kann mir auch so einen Client selbst schreiben, das sind ja wenige Zeilen Curl, weil dieses ACME Protokoll ist einfach HTTP JSON über den ich das steuere.

Simon Kölsch: Okay, da ist einfach eine API gegenüber und mit der kann ich dann ganz normal über eine definierte Schnittstelle kommunizieren, ohne dass das viel Aufwand ist.

Christoph Iserlohn: Ganz genau. Also diese API ist HTTP JSON, die benutzten dann auch zwei Standards, das ist JWS und JWK. Das ist JSON Web Signature und JSON Web Key…, keine Ahnung.

Simon Kölsch: Ja, Web Key. Das ist einfach das Format von dem Schlüssel selbst.

Christoph Iserlohn: Ja, genau. Also das eine ist halt um in JSON so Schlüssel zu identifizieren oder dazustellen, also kryptographische Schlüssel. Und das JWS ist halt für Signaturen, um zu sagen, wie muss ich denn das kodieren und eine entsprechende Signatur darüber legen, über so ein JSON Dokument. Und diese API hat gar nicht so viele Funktionen. Also das erste was man immer machen muss, ist einen Account registrieren. Damit verbinde ich halt den Schlüssel, den ich habe. Also ich habe einen Account und dann kommen ein paar Informationen wer die Zertifikate später haben will, so ein paar Metadaten. Das ist das erste und mit diesem Account kann ich dann Zertifikat ordern. Einen CSR, also ein certificate signing request einreichen, wenn ich das geordert habe und später das Zertifikat runterladen. Das sind die Grundfunktionen. Und die API macht noch einen weiteren Schritt. Wenn ich so ein Zertifikat geordert habe, dann muss sie ja überprüfen: Darf ich das überhaupt? Gehört mir diese Domain und bin ich im Besitz des Schlüssels? Und dafür gibt es zwei Möglichkeiten in dem ACME Protokoll. Das eine Mal über HTTP und das andere geht über DNS. Bei HTTP ist es so, wenn ich sage, ich will jetzt so einen Cert haben, dann sagt die API einen ja: Okay, ich habe hier einen Token und leg das doch mal bitte unter eine bestimmte Adresse. Und das ist dann unter meiner Domain, da ist dann .well-known/acme-challenge, da lege ich das dann drunter unter diese Adresse abrufbar und dann noch mit meinem Schlüssel-Identifier, den bei der ersten Aktion, also bei dem Account anlegen, angelegt habe. Und das Ganze ist eine signierte Antwort mit meinem Schlüssel, da kann der auch überprüfen, dass das auch wirklich von mir war. Und dann sage ich: Okay, das liegt jetzt da. Und dann wird das überprüft. Dann ruft der irgendwann meine Domain auf und guckt, ob diese Challenge, die er mir geliefert hat, ob die da hinterlegt ist. Und wenn das soweit ist, dann kann ich halt ein Zertifikat beantragen und das runterladen. Also erster Schritt, ich order das, dann lege ich das dahinter, dann pull ich soweit, wenn wird das dann überprüft, das geht dann meistens recht schnell. Ich muss halt schauen bis er soweit ist. Ich kann einfach warten und dann liefern mir die API einen Status irgendwie: Is pending oder is verified. Und wenn es verified ist, dann hole ich mir das ab. Und die zweite Möglichkeit ist, um das zu überprüfen ist halt nicht über HTTP, sondern über DNS. Da muss ich einen speziellen DNS Eintrag machen, der ist dann auch irgendwie __ACME-challenge.meinedomain und das im textrecord und da steht dann halt dieses Token, also die Challenge, der Token daraus und der Key Identifier und dann kann das damit überprüfen. Und so ist dann klar, ich habe Kontrolle über diese Domain und ich habe die Kontrolle über den Schlüssel. Und dann läuft das Zertifikat, aber wie gesagt, das sind alles HTTP chords, beziehungsweise HTTPS chords und dann brauche ich da kaum eingreifen. Also normalerweise muss ich gar nicht eingreifen.

Simon Kölsch: An der Stelle kann man nochmal erwähnen, warum das überhaupt so wichtig ist, mit diesem signing request. Die CA könnte ja auch einfach direkt ein Zertifikat generieren und mir dann liefern. Das Problem ist, dann hätte die certificate authority ja Zugriff auf die Kommunikation. Das heißt es ist wichtig, dass man selbst natürlich den Schlüssel generiert und dieser dann nur unterschrieben wird von der CA. Und alle Varianten, in denen man nicht selbst diesen Schlüssel generiert, sollte man sehr kritisch beäugen. Da gab es auch in der Vergangenheit Probleme schon mit. Da gab es einen Vorfall mit einer authority, die wollte, dass die Zertifikate revoked werden. Und in der darauffolgenden Diskussion, weil das natürlich auch so einen Blacklist relativ auch aufbläht, hat dann der CEO von Trustica damals dann 23.000 Zertifikate, also die private keys entsprechend vor umgeposted und damit die komplette verschlüsselte Kommunikation halt kaputt gemacht. Und dann musste das revoked werden und so Sachen will man einfach vermeiden. Da hat die CA einfach beim generieren Schlüssel erzeugt und mal weggespeichert. Da sollte man aufpassen, wie man die Validierung macht.

Christoph Iserlohn: Ganz genau. Man sollte also nie seinen privaten Schlüssel aus der Hand geben. Es gibt auch bei den bekannten CAs so ein paar Funktionen, dass man das Zertifikat sozusagen direkt auf der Webseite generieren kann. Das heißt da gibt es dann Java Skript, der auf der Webseite ist. Der generiert mir dann ein Zertifikat, das kann ich mir dann runterladen. Angeblich bleibt das nur in meinen Browser, aber das ist natürlich auch…, ich finde das eine sehr Praktik. Weil man weiß halt nicht. Also a) müsste man erstmal das Java Skript überprüfen, ob da nicht wirklich irgendwer nach Hause telefoniert oder das vielleicht was weiß ich wo noch zwischenspeichert in meinem lokalen Storage im Browser, wo der private Schlüssel nicht hingehört oder…

Simon Kölsch: Genau. Technisch ist das zuverlässig umsetzbar über die webcrypto API, aber was das Java Skript dann wirklich tut…

Christoph Iserlohn: Ja und wenn die dann mal irgendwie da eine XSS haben, also cross site scripting Lücke oder so, dann kann derjenige, der die ausnutzt vielleicht auch den Schlüssel dann doch irgendwo anders hinschicken und so. Das ist sehr zweifelhaft diese Praktik. Die wurde halt eingeführt, weil es dann einfacher ist als auf der Kommandozeile mit OpenSSL, die jetzt von der UX auch nicht so besonders toll ist. Das man da ein Zertifikat sich richtig erstellt ist halt schwieriger, als wenn ich im Browser klicke und dann heißt er: Bewege mal die Maus ein bisschen hin und her damit wir ein bisschen Zufall-Generieren können. Ist schon einfacher, aber ich würde davon abraten das so zu machen.

Simon Kölsch: Gut. Bei Let’s Encrypt haben wir das Ganze dann zumindest mit Open Source Software automatisiert. Haben dann auch da den entsprechenden Schlüssel liegen und das automatisch gemanaged. Wie hat sich das den mit Let’s Encrypt weiterentwickelt. Also wir wissen wir haben dieses Tooling und haben da entsprechend breiten Support aus der Industrie. Wird das dann in der Breite eingesetzt? Gibt es da irgendwie nochmal etwas bei zu beachten?

Christopher Iserlohn: Ja, also, du hattest gerade erwähnt: 2016 war das öffentlich verfügbar. Die ersten Zertifikate und auch eine public Beta gab es seit 2015. Wenn wir mal von da rechnen jetzt in Februar 2020, also dieses Jahr, hat Let’s Encrypt eine Milliarde Zertifikate bereits ausgestellt. Und von daher, gestartet sind sie 2012 mit den ersten Arbeiten, das sind keine 10 Jahre. Und da muss man sagen ist schon eine extrem gute Leistung und da kann man sagen, die sind etabliert. Also alleine die Anzahl der Zertifikate, die sie ausgestellt haben. Die ganzen Browser vertrauen denen dabei und von daher ist das schon eine Riesen Leistung, die es da gibt. Vielleicht sollte man zwei Aspekte erwähnen, die denen natürlich ordentlich Vorschub geleistet haben. Also einmal sind das die Enthüllung von Edward Snowden, danach kam ja auch auf, dass man eigentlich viel mehr verschlüsseln sollte im Internet und das kam so kurz nach der Gründung von Let’s Encrypt, waren die ersten Veröffentlichungen, also 2013. Von daher war das ein großer Anschub, sodass dann auch Leute, die immer gesagt haben: Ich brauche nicht verschlüsseln, ich habe jetzt keine wichtigen Informationen oder ist mir zu teurer oder welche anderen Argumente oder Scheinargumenten es gab, um jetzt kein TLS anzubieten. Die waren dadurch ja alle erstmal in Frage gestellt und wenn man das Zertifikat jetzt auch umsonst bekommen hat, von da war es jetzt relativ einfach. Dadurch konnte sich Let’s Encrypt sehr gut durchsetzen. Und der andere wichtige Punkt, der, glaube ich, für die Durchsetzung wichtig ist, ist das HTTP2 Protokoll. Also zuerst wollte, als das spezifiziert wurde, ging es darum, ob man HTTP2 nur über TLS Verbindungen sprechen kann. Das hat sich dann in der Standardisierung nicht durchgesetzt, aber keiner der Browserhersteller hat das implementiert, dass man HTTP2 über eine cleartext Verbindung machen kann. Alle Browser haben das nur für TLS Verbindungen durchgesetzt oder implementiert. Und das war natürlich auch der Druck darauf, dass man seine Seite über HTTP2 auch gerne natürlich anbieten will. Das man auch ein Zertifikat hat und TLS sprechen kann. Das sind zwei wichtige Faktoren, die den Erfolg ermöglicht haben.

Simon Kölsch: Genau, ich würde das noch ergänzen: Selbst im Backend mit HTTP2 Client-Libaries, da H2C, also die cleartext Variante von dem Protokoll zu sprechen, wird man nicht so ohne weiteres irgendwie einbinden können. Da wird man sicherlich noch weiteren Implementierungsaufwand haben. Was auch noch, vielleicht als Ergänzung zu dem Thema Traffic-Verschlüsseln und was da bei Snowden rauskam, so ein bisschen der Punkt ist: Natürlich wird wenn die NSA eine Verbindung von oder eine Kommunikation von einer Person abhören möchte, wird sie das, wenn sie das gezielt tut früher oder später auch irgendwie schaffen. Was aber Snowden gezeigt hat ist, dass einfach im großen Rahmen Daten, die im cleartext im Netzt unterwegs sind, einfach abgefischt und gespeichert werden. Und da ist es einfach wichtig in der Breite auch vielleicht dafür zu sorgen, dass Kommunikation eben nicht so einfach öffentlich zugängig ist, wenn man irgendwo einen Netzwerkstecker in den Switch steckt und halt irgendwie den Traffic dammt. Sondern dass da zumindest noch einmal ein Verschlüsselungslayer drüber ist, der auch irgendwie halbwegs erstmal Behörden davon abhält da großspurig Filter einzubauen oder ähnliche Inhalte auch nochmal weiter auszuwerten.

Christoph Iserlohn: Ja, NSA und wahrscheinlich auch weitere Geheimdienste in anderen Ländern haben ja diesen take-it-all Ansatz. Speichern erstmal alles und saugen alles ab was geht und schauen dann, was man halt daraus machen kann. Und das ist halt dadurch erheblich schwerer geworden. Weil wie du das sagtest, wenn die gezielt das machen wollen, dann kommen sie halt irgendwie an deinen privaten Schlüssel dran, weil sie deinen Rechner hacken oder wie man das in dem schönen XKCD Comic hat, dass sie dir einfach die Pistole an den Kopf halten. Oder in dem Comic ist es so beschrieben, so lange auf dich einprügeln bis du dein Passwort rausgibst dafür. Da gibt es Methoden, aber dieses: Wir machen einfach allen, holen uns alles was wir kriegen können, das geht nicht mehr. Und was auch unterbunden ist, was jetzt gar nichts mit Geheimdiensten oder so zu tun hat, ist natürlich diese naive Vorstellung: Ja, aber das ist ja nicht kritisches, was ich hier habe. Das kann ja ruhig unverschlüsselt übertragen werden. Es gibt ja noch ganz andere Gefahren. Es gab ja mal den Fall, dass so ein Internetprovider einfach in den Traffic immer irgendwelche Java Skripte injiziert hat, um Tracking zu machen für Werbekunden und das verkauft hat. Das will ich ja eigentlich auch nicht haben. Und wenn ich meine Seite ausliefere, irgendeine statische Seite, wo ich Informationen zu meinem Hobby habe, das derjenige der das abruft, auf einmal irgendein Java Skript untergejubelt bekommt und seine Daten da…

Simon Kölsch: Jetzt kann man natürlich sagen: Ja, macht ja mein Provider nicht, ich habe meinen Vertrag irgendwie beim seriösen ESP. Ja, man bewegt sich durchaus auch mal in öffentlichen Netzen, man ist mal in einen Internet Café, nutzt mal irgendein öffentliches W-LAN, mal ist ein Zug unterwegs. Das sind alles Punkte, wo Traffic durchgeht, wo man vielleicht einfach eigentlich eine verschlüsselte Verbindung haben möchte.

Christoph Iserlohn: Das für den Selbstschutz und für den Schutz von Anderen. Ich weiß ja auch gar nicht mit welchem Provider die unterwegs sind und durch welche Providernetze das alles durchgeht. Also auch wenn ich jetzt sage: Ich habe jetzt einen Provider, der macht das nicht, aber die Leute, die dann auf meine Homepage gehen, die dann weltweit vielleicht herkommen, woher soll ich wissen welchen Provider die haben? Und die auch nicht in einem Land sind, wo der Staat das auch macht. Also von daher bin ich der Meinung prinzipiell sollte aller Traffic einfach verschlüsselt sein. Gerade wo es jetzt kaum noch Aufwand macht.

Simon Kölsch: Ja, mit dem Thema staatliche Probleme mit den CAs, das ist ein ganz gutes Stichwort. Da gab es ja auch oder gibt es eigentlich ja auch Iran zum Beispiel eine gängige Praxis.

Christoph Iserlohn: Also nicht nur im Iran, aber glaube ich wo du drauf anspielt ist halt, das war so 2010 oder 2011 rum, dass DigiNotar, eine CA, gehackt wurde und man da halt Zertifikate ausgestellt hat, unteranderem für G-Mail, also von Google und für Facebook und die im Iran gezielt genutzt hat für man in the middle angriffe und denen dann halt entsprechend die Leute ausspioniert hat damit. Und zwar konnte man das dann nicht unbedingt merken, weil das war ja ein legitimes Zertifikat. Also DigiNotar war eine CA, die in den Browsern halt drin war und in den Betriebssystemen und wenn die halt Zertifikate an Leute ausstellen für Domains, für die sie eigentlich keine ausstellen dürften, dann war das natürlich ein Riesen Problem. Und es gab auch mal einen Vorfall, da hat jemand sich als Microsoft ausgegeben und bei Verisign ein Zertifikat für Microsoft bekommen. Das ist natürlich ein erhebliches Problem, das es bei Zertifikaten missbrauch gibt. Und wenn man jetzt bedenkt, in den Browsern ist zum Beispiel Türktrust, das ist eine halbstaatliche Stelle in der Türkei, eine CA, die Zertifikate ausstellt. Da würde ich sagen in der jetzigen politischen Lage bin ich mir auch nicht so sicher, ob die nicht auf Druck der Regierung sowas auch machen würden und dann mal Zertifikate für Google, Facebook, Apple, sonst wen ausstellen würden and den Staat und nicht an die entsprechenden Firmen. Von daher muss man schauen, da gibt es halt… Also es wird dagegen gearbeitet, Maßnahmen ergriffen, dass das nicht gerade passiert.

Simon Kölsch: Was gibt es denn da für Gegenmaßnahmen bei sowas? Das gehört ja auch so ein bisschen zum CA-Ökosystem dazu.

Christoph Iserlohn: Genau. Also zwei Sachen gibt es, die auf jeden Fall erwähnenswert sind. Das ist einmal das CA Browser Forum und das certificate transperancy. Fangen wir mal mit dem CA Browser Forum an. Das ist ein Zusammenschluss von den CAs. Eigentlich fast allen, also allen die in irgendeinen trustvollen Browser oder Betriebssystem landen wollen. Und von den Browserherstellern da, von Mozilla, Google, Apple, Microsoft, Opera ist da drin. Und Cisco ist da auch drin als Browserhersteller, ich weiß jetzt nicht welchen Browser die so herstellen, aber die sind ja jedenfalls auch vertreten. Und die stellen die sogenannten Baseline-Requirements her, beziehungsweise geben die heraus. Und diese Baseline-Requirements sind Anforderungen an eine CA. Und wenn die diese Anforderungen nicht erfüllen, dann werden die auch nicht in den Trustsource aufgenommen. Und das war der Grund, wenn wir jetzt nochmal zurückgreifen auf CAcert, wo die sich bemüht haben auch aufgenommen zu werden, diese Anforderungen können sie halt nicht erfüllen. Und das liegt daran, weil das sind jetzt nicht so einfache Anforderungen, weil da geht es einmal um die Prozesse, um die Menschen die dort arbeiten und es geht um technische Anforderungen. Also bei den technischen Anforderungen gibt es halt einmal zum Beispiel von den physikalischen Anforderungen, dass es in einem gesicherten Rechenzentrum sein muss. Von einfachen Sachen wie, da gibt es einen Feuerlöscher, bis das sollte auf einer HSM, also einen Hardwaremodul, sollte der private Schlüssel vom Root Zertifikat gespeichert sein, in einem speziellen Raum, der vielleicht mit einem Gitter nochmal gesichert ist. Da geht es um die Prozesse, wie kommt man jetzt in diesen Raum rein? In den Raum sollten möglichst, sollte man nicht alleine reinkommen, sondern da sollten möglichst immer von sagen wir 5 Administratoren immer mindestens 2 dabei sein. Es geht um diese Prozesse, wie dieses Schlüsselmaterial rotiert wird, wenn das nötig ist. Es geht um das Personal, dass das unbedenklich ist. Da gibt es dann halt Anforderungen an Sachen, dass man sozusagen eine Hintergrundüberprüfung machen sollte oder machen muss. Und es gibt auch technische Anforderung, also wie soll das Zertifikat aufgebaut sein. Was darf da drinstehen? Was darf da nicht drinstehen? Zum Beispiel, dass ich nicht einfach ein Zertifikat ausstellen kann, womit ich andere Zertifikate signieren kann, sondern nur das ich Zertifikate ausstelle, mit denen ich TLS machen kann oder E-Mail. Aber nicht das ich eins in die Hände bekomme und dann einfach selbst Zertifikate ausstellen kann. Da gibt es halt ein sehr großes Dokument, was auch immer mal wieder aktualisiert wird und das ist halt nicht einfach zu erfüllen.

Simon Kölsch: Man muss halt auch klar sagen, wenn man das nicht erfüllen kann, dann hat man eigentlich keine Geschäftsgrundlage mehr. Wie komplex das ist, hat man ja auch bei Symantec gesehen. Da ist ja auch quasi das Zertifikat aus den Browsern gepatcht worden, vollkommen zurecht, aber da passiert inzwischen auch Mal, dass eine CA, wenn sie sich nicht daranhält, auch wirklich aus den Stores entfernt wird.

Christoph Iserlohn: Genau und gerade die Browserhersteller sind da ziemlich hinterher. Und normalerweise gibt es für jedes CA auch ein jährliches Audit von unabhängigen Stellen, dass auch diese Baseline Requirements eingehalten werden. Und so ein Audit zu erstellen ist halt auch nicht was man so nebenbei machen kann und was billig ist, sondern das kostet Geld. Und muss ja dann halt auch gemacht werden. Das ist ja nicht so, dass man einfach dann sagt: Hier ein Audit, macht das mal! Sondern man muss dann die entsprechenden Dokumentationen bereitstellen und nachweisen, dass man die Prozesse einhält, dass die Technik auf den Neusten Stand ist und so weiter und so fort. Das ist schon ein schwieriger Prozess.

Simon Kölsch: Okay. Also hier haben wir ein Forum dafür, die sich um die ganzen Auditierungsprozesse kümmern und sicherstellen, dass zumindest organisatorisch die Bedingungen dementsprechend gegeben sind. Was gibt es da denn noch für Maßnahmen, um da irgendwie mit Problemen umzugehen?

Christoph Iserlohn: Die zweite Maßnahme, die auf jeden Fall erwähnenswert ist, ist eine Initiative von Google. Die ist auch genau aus diesen DigiNotar Hack sozusagen mitentstanden. Da waren noch mehr Vorfälle, wo dann sozusagen missbräuchlich Zertifikate ausgestellt wurden und darauf hat Google dann die Certificate Transperancy Initiative gegründet. Und die besteht aus eigentlich 3 Elementen. Das wichtigste sind die certificate logs. Das ist ein log file sozusagen, also das ist nicht wie ein normales log file. Das ist ein log, da werden alle Zertifikate, die so eine CA ausstellt, hinterlegt. Aber dieses log ist halt append only, also ich kann nur etwas anhängen und die sind kryptographisch abgesichert, also signiert. Das Ganze basiert auf einem Merkle Tree.

Simon Kölsch: Keine Blockchain, was ist da los?

Christoph Iserlohn: Ja, es ist vergleichbar mit einer Blockchain, nur dass es nicht so viel Energie verbraucht und nicht so viel Hype hat. Aber auf jeden Fall wird damit sichergestellt, dass die halt sozusagen Manipulationssicher sind, solange man den privaten Schlüssel dafür hat. Also die kryptografische Überprüfung passiert wieder mit dem öffentlichen Schlüssel und derjenige, der das Log betreibt muss natürlich sehen, dass er seinen privaten Schlüssel entsprechen sichert. Deshalb, es gibt auch verschiedene Log-Betreiber, also Google macht eins, Cloudflare hat eins. Das sind so große Namen, aber es gibt auch noch andere CAs, die eins betreiben.

Simon Kölsch: Also das Protokollmäßig spezifiziert. Ich kann das aber dezentral aufbauen. Was wahrscheinlich bei der Last eh notwendig ist, oder?

Christoph Iserlohn: Ganz genau und die CAs können dann Zertifikate einreichen. Eigentlich kann es jeder machen, aber typischerweise sind es die CAs, die sagen: Ich habe das jetzt ausgestellt, trage das mal bitte in deinem Log ein. Und typischerweise gehen die auch an mehrere Logs dran und sagen: Hier, trag das mal ein Google und Cloudflare trag das auch mal ein. Und die bekommen dann einen signed cert timestamp zurück, was auch wieder ein signierter Zeitstempel ist, wann das eingetragen wurde, beziehungsweise wann das für die Eintragung aufgenommen wurde. Es gibt da eine zeitliche Verzögerung, wann das auf diesem Log erscheint und die darf auch nicht zu lange sein, aber das ist halt nicht unbedingt instatan, das kann mal eine Minute dauern und ich glaube das geht sogar bis zu einen ganzen Tag. Also das ist geregelt, dass das so bis zu einem Tag dauern kann, damit falls da mal auch ein Outage ist oder sonst ein Problem, damit diese Betreiber dieser Lots auch Zeit haben zu reagieren. Also so mit den Logs kann man…, das ist jetzt schön und gut, dass es die gibt und die werden jetzt von zwei anderen Elementen von diesen Certificate transperancy Projekt oder Initiative benutzt. Und da gibt es einmal den Monitor und den Auditor, das sind Rollen, die man hat. Der Monitor, der schaut nämlich auf die ganzen Logs und guckt da nach merkwürdigen Zertifikaten. Zum Beispiel guckt der dann: Oh, da ist jetzt ein Zertifikat, das ist eigentlich ein CA Zertifikat, also damit kann ich eigentlich andere Zertifikate signieren, das sollte ja eigentlich nicht unbedingt ausgegeben werden, wenn es an irgendeinen Endnutzer kommt. Oder die gucken nach Fishing-Versuchen. Also Facebook macht das zum Beispiel, die gucken da nach ob Zertifikate auf Domains wie auf Facebookk, mit zwei k, also irgend so ein Typo ist in der Domain oder facebook.com-example.com, also was eigentlich nur eine sub-Domain ist.

Simon Kölsch: Ja, mit Unicode gibt es ja auch Spielereien.

Christoph Iserlohn: Ja genau. Mit Unicode, wo dann die Zeichen ganz ähnlich aussehen, wie unsere normalen Zeichen, unsere ASCII-Zeichen, aber das a dann doch ein anderer Buchstabe ist, wo ich kenne, dass man kyrillische Buchstaben benutzt, die dann vom Font her genauso aussehen. Und die gucken das dann und schauen darauf, ob solche Zertifikate ausgestellt werden. Und wenn man Facebook-Entwickler ist und da Facebook-Apps macht auf deren Plattform, dann kann man sich sogar subscriben darauf auf solche Alerts, wenn mal sowas passiert ist. Dann haben die die so einen Monitor betreiben halt die Chance schnell darauf zu reagieren. Das macht nicht nur Facebook so, Google macht das so, also die großen Internetfirmen schauen dann halt darauf, was da so passiert und können dann entsprechend vielleicht einschreiten und die CA kontaktieren und sagen: Das muss zurückgenommen werden, wenn es auch ein Falsches ist. Also wenn zum Beispiel jemand für Google aus Versehen ein Zertifikat ausstellen würde und Google hat das nicht beantragt und hat auch keinen Vertrag mit denen, dann könnten die sagen: Das muss jetzt zurückgenommen werden oder das auch auf ihre internen Sperrlisten setzen. Also Google Chrome nutzt ja nicht nur die öffentlichen CRLs, sondern die haben ja auch eine interne Sperrliste zum Beispiel. Und es gibt den Auditor, dass sind jetzt so Software-Komponenten, die überprüfen einmal dieses Log, also die Krypto davon, dass das auch konsistent ist und da nicht manipuliert wird. Und die können auch prüfen, ob ein Zertifikat überhaupt in dem Log auftaucht. Das ist zum Beispiel der Fall, wenn wir jetzt sowas haben, wie bei DigiNotar und eine CA wird gehackt und die würden jetzt die Leute, die die gehackt haben, würden jetzt ein Zertifikat ausstellen für Google oder für Apple oder für Microsoft. Dann würden die das ja nicht unbedingt ins Log eintragen, weil das würde ja relativ früh auffallen. Und deshalb, wenn dann ein Auditor das so sieht, kommt das Zertifikat in die Finger und sieht: Das erscheint aber in keinen Log. Das ist auch sehr suspekt. Und der Google Chrome ist jetzt der erste Browser, der verlangt, dass so ein SCT, also diese signed cert timestamp, also der Nachweis, dass das in das Log eingetragen wurde, verlangt, dass die mit ausgeliefert werden. Sonst zeigt der eine Warnung an. So kann Google halt verhindern, dass für Google Zertifikate ausgestellt werden, die nicht in dem Log auftauchen und da sie das Log auch Monitoren, dass da Zertifikate auftauchen, die nicht von ihnen gewünscht sind.

Simon Kölsch: Ja, plus die haben ja sicher entsprechendes Reporting, was falsche Zertifikate dann angeht, oder?

Christoph Iserlohn: Reporting für wen?

Simon Kölsch: Naja, zumindest Google betreibt ja auch aktiv nochmal Monitoring, was das angeht. Die haben in der Vergangenheit immer sehr schnell mitbekommen, wenn da Zertifikate auftauchen, die auf ihre Domains ausgestellt sind, die eigentlich niemand ausgestellt hat.

Christoph Iserlohn: Genau, also die sind auch in der Rolle Monitor unterwegs. Die machen eigentlich alles, die betreiben Logs, die monitoren Logs, ihre eigenen aber auch die von Anderen und die machen auch die Auditor Rolle und überprüfen dann Zertifikate: Das kenne ich gar nicht, das taucht auch nirgendswo auf, da kann was irgendwie nicht stimmen. Also das machen die. Und das kann auch eigentlich jeder machen. Also so einen Log betreiben ist wahrscheinlich schwierig, weil da stellen Google und auch Andere Anforderungen dran, jedenfalls wenn die diesen Log vertrauen sollten. Also prinzipiell kann das erstmal jeder machen. Ich kann ja auch meine eigene CA betreiben und kann einfach Zertifikate da reinballen, aber das Google das sozusagen benutzen würde um zu sagen: Ich prüfe jetzt was dagegen. Dann muss es da eine gewisse Vertrauensstellung geben und dann die Anforderungen dran, wie das Log betrieben werden muss und das ist vielleicht nicht ganz so einfach diese Anforderungen zu erfüllen. Aber so als Monitor Rolle da zu sein und mir die Logs anzugucken, die sind alle öffentlich, das ist schon einfacher. Auditor ist noch die einfachste Rolle, wo ich dann einfach sagen kann: Aha, hier habe ich ein Zertifikat, ich gucke mal, ist das irgendwo in einen Log dann auch vorhanden?

Simon Kölsch: Okay. Hast du noch Themen, wo du noch ein bisschen drauf eingehen willst oder noch einen weiteren Punkt, den wir noch nicht abgedeckt haben?

Christoph Iserlohn: Also zwei technische Sachen könnten wir noch erwähnen. Einmal jetzt gerade in, wo ich gerade gesagt habe, dieses sign cert timestamps. Wie funktioniert das denn? Weil wenn Google Chrome die verlangt, also wo tauchen die denn auf? Da gibt es drei Möglichkeiten. Einmal gibt es das als TLS Extension, dann gibt es eine Cert Extension, da ist es direkt in den Cert kodiert oder als OCSP Extension, dann ist es halt in OCSP Responder, wo man die halt finden kann. Und im Moment werden typischerweise solche Cert-Extensions benutzt, wo das im Zertifikat steht. Weil da braucht man für seinen Server keine Änderung, also wenn ich TLS ändern will die Einstellung, dann muss ich halt an meinem Server rumkonfigurieren, bei OCSP muss ich bei den OCSP Server rumkonfigurieren und wenn einfach das im Cert drinsteht, dann brauche ich nichts ändern.

Simon Kölsch: Und dann teile ich den Client einfach mit, wo der das nochmal überprüfen kann.

Christoph Iserlohn: Ja, da steht dieser SCT dann nochmal drin. Da läuft das so ab, bevor das eingetragen wird gibt es so ein Pre-Cert, da ist der natürlich noch nicht drin. Dann kriegt man diesen Timestamp, der wird dann ins Zertifikat gepackt und dann kommt das da nochmal rein. Und dann steht das halt im Zertifikat drin. Da steht dann welches Log und zu welchen Zeitstempel das war und dann kann man da halt nachschauen. Ich muss ja auch gucken, wenn es verschiedene Log-Betreiber gibt, muss ich ja auch wissen, wo muss ich überhaupt gucken? Und das ist halt die einfachste Variante, weil Zertifikate kriege ich halt so oder so und da müssen sich die drum kümmern, die die Zertifikate ausstellen. Bei TLS und OCSP müsste ich halt selbst an meinem Server arbeiten, damit die damit ausgeliefert werden. Das ist halt noch gar nicht verbreitet. Und eine zweite technische Sache, die ich ganz interessant finde, ist, das ist jetzt aus dem Kontext von dem CA Browser Forum. Da ist es festgelegt, dass jetzt, also ist jetzt auch verpflichtend, dass eine CA DNS Certification Authority authorization, CAA unterstützen muss. Ist jetzt ein kleiner Zungenbrecher Begriff, aber die Idee ist recht einfach. Ein DNS-Eintrag zeigt dann nämlich an welche CA für meine Domain Zertifikate ausgeben können. Also das ist dann einfach ein Textfeld in DNS, da steht dann was weiß ich wieder example.org und dahintersteht: Darf nur von Let’s Encrypt oder von DigiCert oder von GoDaddy. Da kann ich dann entweder keinen Eintrag hinlegen, das heißt alle dürfen für meine Domain eins ausstellen oder wenn ich mehrere habe, dann dürfen halt die Menge, die ich da angegeben habe oder auch nur einen. Wenn so eine CA dann einen Antrag kriegt: Stell doch mal bitte für Example aus. Dann können die dahin gehen und in der DNS schauen, oder die müssen sogar schauen ob es da einen Eintrag gibt und wenn sie dann selbst nicht darinsteht, muss sie das halt verweigern. Also kann man halt vorbeugen, dass irgendwelche Leute ungerechtfertigt Anträge stellen für eine Domain, die ihnen vielleicht nicht gehört oder wo sie vielleicht nur zum Teil…. Die sie gehackt haben und wo sie den Seiteninhalt manipulieren können. Und dann so eine HTTP Challenge von Let’s Encrypt vielleicht bestehen könnten, weil sie unter die spezielle Adresse vielleicht die Challenge legen können. Aber in DNS steht: Von Let’s Encrypt will ich keine Zertifikate, weil ich zum Beispiel eine Bank bin und so eine standard validation brauche.

Simon Kölsch: Letztendlich hast du da halt einfach wieder eine öffentliche Information, die ein beliebiger Client auch überprüfen kann.

Christoph Iserlohn: Ganz genau. Macht halt deutlich mehr Transparenz in den ganzen Prozess.

Simon Kölsch: Das ist auch sicherlich etwas, was man Stück für Stück, relativ unproblematisch auf bestehende Systeme auch ausrollen kann. Von daher, wenn man da etwas betreut, macht es vielleicht Sinn da auch einen Blick draufzuwerfen.

Christoph Iserlohn: Absolut. Sollte man tun.

Simon Kölsch: Gut, dann bleibt uns eigentlich noch aufzuklären, was der CEO von Canonical mit CAs zu tun hat.

Christoph Iserlohn: Ja, der Mark Shuttleworth ist ja bekannter Weise auch der große Spender von Ubuntu, der uns das schöne Betriebssystem, also ein Linux-Distribution für Endanwender, geschenkt hat. Und auch sonst viel im Linux Bereich vorantreibt. Und das kostet ja alles Geld, dann kann man sich fragen: Wo kommt denn das ganze Geld her? Und der Mark Shuttleworth ist sehr reich geworden in so der ersten Dotcom Zeit war das glaube ich, weil er selber hatte Thawte und das war eine der ersten CAs, wenn nicht die erste, die außerhalb der USA Zertifikate verkauft hat. Und er hat sie dann verkauft an Verisign für 500 Millionen Dollar und dann hat er erstmal Urlaub gemacht, und zwar auf der ISS, war einer der ersten Weltraumtouristen und auch der erste Afrikaner, also er kommt aus Süd-Afrika, der im Weltraum war. Und hat dann einen ganz großen anderen Teil auch hier schön in Open Source und in Ubuntu gesteckt.

Simon Kölsch: Okay. Also soviel zu dem Thema, wie wichtig das ist, dass man Root Zertifikat hat was schonmal in Browsern drinnen ist.

Christoph Iserlohn: Ja, der hat eine gute Chance genutzt.

Simon Kölsch: Gut, dann wären wir jetzt eigentlich am Ende. Wir bedanken uns für die Aufmerksamkeit, wenn ihr solange durchgehalten habt und ansonsten nehmen wir natürlich gerne Feedback/Anregungen an Podcast auf INNOQ.com entgegen. Dann bis zum nächsten Mal. Tschüss Christoph!

Christoph Iserlohn: Ciao Simon!