TLS

Simon Kölsch: Herzlich Willkommen zum INNOQ-Security-Podcast zur Folge TLS. Ich sitze hier mit Christoph, hi Christoph!

Christoph Iserlohn: Hallo Simon!

Simon Kölsch: Kannst du mich hören?

Christoph Iserlohn: Ich kann dich sehr gut hören.

Simon Kölsch: Wir wollen uns mit TLS beschäftigen. Du hast die letzten zwei Episoden einmal mit Lucas über Krypto geredet und über das Thema Zertifikate. Wenn ich das für mich so ein bisschen einsortieren soll, dann kann man aus den Folgen für die jetzige mitnehmen: Es gibt so etwas wie Schutzziele, die man erreichen möchte, zum Beispiel das verschlüsselte Übertragen von Informationen oder das Sicherstellen, mit wem man da eigentlich spricht oder kommuniziert. Das erreiche ich irgendwie mit einem Kryptosystem, wie auch immer das technisch dann umgesetzt ist. Und zum anderen brauche ich dafür irgendwie Schlüsselmaterial, das ich austauschen möchte. An Schlüssel hängen natürlich immer irgendwelche Metadaten dran: Für wen ist denn dieser Schlüssel? Wann wurde der ausgestellt? Und das hab ich mal so für mich mitgenommen, das ist eigentlich in einem Zertifikat gespeichert. Und in dieser Episode möchten wir darüber reden, wie wir dann wirklich mit einem technischen Protokoll, nämlich TLS, kommunizieren, um diese Schutzziele zum einen zu erreichen und zum anderen, wie wir mit dem Schlüsselmaterial dabei umgehen. Habe ich das so richtig in Erinnerung?

Christoph Iserlohn: Das hast du ganz richtig in Erinnerung. Ein Ziel, ein Schutzziel, das wir vielleicht auch noch erwähnen sollten, wäre die Integrität der Kommunikation. Die Verschlüsselung stellt die Vertraulichkeit her. Aber man kann ja auch die verschlüsselte Kommunikation manipulieren und man sollte das merken.

Simon Kölsch: Okay, dann lass uns doch da direkt mal einsteigen. TLS steht für Transport Layer Security. Das klingt ja schon mal vielversprechend. Was sind denn da eigentlich die Ziele von diesem Protokoll und was ist das denn eigentlich genau?

Christoph Iserlohn: Vielleicht greifen wir da mal zurück auf die Entstehungsgeschichte von TLS. Damals hieß es noch SSL. Darauf können wir gleich auch noch einmal eingehen, warum das jetzt TLS heißt und wie da die genaue Geschichte war. Aber so in den 90er Jahren, Mitte der 90er Jahre des letzten Jahrtausends, da hatte das Internet dann doch schon eine etwas größere Verbreitung gefunden, auch sozusagen im zivilen Umfeld, und Netscape war mit ihrem Navigator-Browser relativ groß dabei.

Simon Kölsch: Wir sind schon nach Mosaic, ja?

Christoph Iserlohn: Wir sind schon nach Mosaic, ja. So 1995 circa, 1994, 95 sind wir. Und dann wurde das auch kommerziell interessant. Also wollte man Transaktionen ausführen irgendwie im Netz, wo vielleicht Geld irgendwo getauscht wurde, Waren gegen Geld, oder Bankgeschäfte gemacht werden sollten. Und mit der unverschlüsselten Übertragung von solchen sensitiven Daten war das natürlich nicht getan. Und deshalb ist Netscape auf die Idee gekommen und sagte, sie machen SSL, den Socket Security Layer, um so etwas zu ermöglichen. Da haben sie dann halt diese drei Schutzziele gehabt. Einmal, dass sich die Leute authentisieren können, also wer sind sie eigentlich? Das haben sie dann gemacht, wie wir das ja auch in der letzten Folge mal besprochen haben mit Zertifikaten, um die Identität herauszufinden. Dann sollte das natürlich vertraulich sein. Alles muss verschlüsselt sein. Man sollte jetzt nicht unbedingt sehen, welche Geschäfte da gemacht werden und um welche Beträge es geht. Und sie sollten sicher sein vor Manipulationen, deshalb brauchen wir die Integrität. Und das wird typischerweise durch einen Message Authentication Code sichergestellt. Und so wird das TLS-Protokoll sichergestellt. Das heißt, wir haben jetzt die drei Schutzziele Authentisierung, Vertraulichkeit, Integrität und die macht das Protokoll TLS, stellt das somit sicher.

Simon Kölsch: Okay, du hast jetzt einen Message Authentication Code erwähnt. Kannst du das näher ausführen?

Christoph Iserlohn: Also wenn ich Daten verschlüssele, dann könnte die zwar jetzt niemand, der nicht die passenden Schlüssel hat, entschlüsseln, aber auf dem Transportweg könnte irgendein Angreifer die manipulieren. Entweder indem er Zugänge zu den Routern hat, die dazwischen stehen, zum Beispiel, oder auch direkt auf der Leitung durch Störsignale. Dann wird da zwar wahrscheinlich Datenmüll reinkommen, aber nichtsdestotrotz werden die verschlüsselten Daten irgendwie manipuliert. Und wenn ich das nicht merke, dann kann das schlimme Folgen haben. Wenn darin jetzt nur Müll steht, dann ist das wahrscheinlich nicht so schlimm. Aber man stelle sich mal vor, ich weiß über die Struktur dieser Daten Bescheid. Nehmen wir als Beispiel mal eine Banküberweisung. Die ist strukturell wahrscheinlich immer gleich: Irgendwo sind da reservierte Felder für den Namen und die Bankverbindung und für den Betrag. Und wenn ich jetzt weiß, an welcher Stelle der Betrag steht, der steht jetzt an Byte-Nummer 356 oder so etwas, da beginnt das. Und wenn ich da gezielt ab diesem Byte andere Daten reinschreibe, dann wird sich der Betrag verändern. Die Verschlüsselung merkt das aber erst mal nicht selber. Also derjenige, der es entschlüsselt, merkt das nicht unbedingt.

Simon Kölsch: Also mit genug Überweisungsdaten könnte ich quasi statistisch die Stellen sehen, die irgendwie zusammengehören.

Christoph Iserlohn: Ja, das könnte ich zum Beispiel ja auch selber ausprobieren, wenn ich dieselbe Bank benutze und mir das anschaue, wo da was steht. Dann könnte ich versuchen, das bei anderen zu manipulieren und dann käme da ein ganz anderer Betrag heraus oder vielleicht ein andere Empfänger, eine andere IBAN-Nummer.

Simon Kölsch: Okay, das heißt, ich müsste unter Umständen gar nicht herausfinden, wie die Daten im Klartext aussehen. Ich muss nur die Stelle finden, an die ich eigene Daten injizieren kann in den Datenstream. Das wollen wir verhindern?

Christoph Iserlohn: Ganz genau, das wollen wir verhindern. Wir wollen merken, wenn das manipuliert wird. Und dazu dient dann so ein MAC, Message Authentication Code. Das heißt, über die Daten, über die verschlüsselten Daten oder auch im Fall von TLS über die nicht verschlüsselten Daten – Da gibt es einen größeren Streit, was man machen soll. Also erst den MAC bilden, dann verschlüsseln oder erst verschlüsseln und dann den MAC bilden. Das ist umstritten, was da das Bessere ist. Auf jeden Fall ist es bei TLS so, dass erst der MAC gebildet wird und dann verschlüsselt wird. Die Daten, darüber bilde ich einen Hash. Also im Fall von HMAC-Verfahren, also einem Hash based Message Authentication Code, bilde ich einen Hash. Und da kommt noch ein geheimer Schlüssel mit hinein. Und dann kann derjenige, der das absendet, den ausrechnen und derjenige, der es empfängt, kann das auch ausrechnen. Wenn die Daten manipuliert würden, ist der Hash natürlich anders. Und dann ist aufgedeckt worden, dass die Daten irgendwie manipuliert wurden.

Simon Kölsch: Okay, das heißt, wir haben hier symmetrische Krypto. Das heißt, Empfänger und Sender kennen beide den Schlüssel und können deswegen mit dem gleichen Schlüssel feststellen, ob sich irgendetwas an der Nachricht verändert hat an der Stelle.

Christoph Iserlohn: Ganz genau. In dem Fall muss dieser Schlüssel natürlich vorher auch auf sicherem Weg ausgetauscht worden sein.

Simon Kölsch: Und bei TLS hat man sich dafür entschieden, dass ich nicht mal diesen Authentication Code lesen kann, weil quasi die komplette Session danach erst verschlüsselt wird.

Christoph Iserlohn: Ganz genau. Also der Plain Text bekommt den Authentication Code und danach wird es verschlüsselt. Und im Zweifelsfall gibt es danach auch noch einmal ein Padding bzw. es gibt ein Padding vor dem Verschlüsseln, weil wenn man so einen Block-Cipher hat, der muss halt immer eine bestimmte Größe haben, bei AES typischerweise 128 oder 256 Byte. Und der verschlüsselte Text ist nicht immer ganz genauso lang, ein Vielfaches von 128 oder 256. Da muss man dann noch ein bisschen Padding-Bytes am Ende einfügen.

Simon Kölsch: Okay. Das heißt, wenn wir uns so ein bisschen das Ökosystem, in dem sich das befindet, anschauen, dann ist das das Web. Das heißt, wir haben sehr viele Infrastrukturkomponenten, die Daten übertragen. Da gibt es Proxies, die irgendwo dazwischen stecken, irgendwo im Internet. Da gibt es vielleicht noch zur Applikation dazugehörig den Reverse Proxy, da sind irgendwelche Load-Balancer. Über all diese Infrastrukturkomponenten werden meine Daten übertragen. Teilweise sind die unter der Kontrolle von dem Server, von der Server-Seite. Teilweise ist es aber auch einfach öffentliche Infrastruktur, irgendwie ein offener WLAN-Hotspot, ich sitze im Zug und hab da irgendwie WLAN. Dann ist da irgendwie noch einmal ein Squid-Proxy dazwischen und all so Dinge. Und darüber wollen wir jetzt als Client zu einem Server eine sichere Verbindung herstellen.

Christoph Iserlohn: Diese Proxies, die du erwähnt hast, oder Mittelboxen könnte man die auch nennen, die sind für TLS natürlich ein gewisses Problem. Es kommt drauf an, um welche Art von Mittelbox es sich handelt. Wenn die auf IP-Ebene arbeitet, dann geht das wahrscheinlich noch. Aber es gibt ja eine ganze Reihe an Boxen, die arbeiten… Alson nehmen wir einmal an, so ein Squid ist ein HTTP-Proxy. Und dieser Proxy kann natürlich jetzt nichts mehr sehen von diesem HTTP-Protokoll. Also er kann nicht sehen, dass er dir irgendwie eine Seite ausliefern kann, die er schon im Cache hat. Denn die einzige Möglichkeit, wir er das sehen kann, ist, dass er die Verbindung aufbricht bzw. deine Verbindung nur bis dahin verschlüsselt ist. Und manchmal kann das in Ordnung sein. Manche Firmen machen das, wenn die zum Beispiel so ein CDN benutzen, dann geht die Verschlüsselung bis zu diesen Edge-Proxies. Und intern vom Edge-Proxy vielleicht bis zu deinem Backend-System wird noch eine weitere TLS-Verbindung aufgemacht. Aber eigentlich möchtest du eine Punkt-zu-Punkt-Verbindungen haben zu dem entsprechenden Backend oder zu dem entsprechenden Service, zu dem du die Verbindung aufbauen willst. Das schaltet eine Menge Sachen bei den HTTP-Proxies dann einfach aus bzw. macht das sinnlos, da einen HTTP-Proxy zwischen zu stellen.

Simon Kölsch: Das heißt, wir haben immer den Punkt, dass wir bei der Verschlüsselung beachten müssen, an welcher Stelle brechen wir denn die Verschlüsselung auf, können die Daten vielleicht, um sie zu routen, auslesen, um sie dann wieder im Zweifel noch einmal zu verschlüsseln. Das ist grundsätzlich irgendwie möglich, da ist es irgendwie flexibel genug. Aber du hattest jetzt Netscape erwähnt und das Thema SSL. Da war so ein bisschen das Umfeld, in dem das ein Endprotokoll entstanden ist, dann das Web, einfach um das zu ermöglichen. Ist das bis heute Use Case? Finde ich SSL/TLS nur an der Stelle, oder ist da der Einsatz viel breiter?

Christoph Iserlohn: Also wenn du jetzt mit Web das WWW meinst, wofür ja natürlich auch der Netscape-Navigator gemacht war, dann hat sich dieser Bereich natürlich erweitert. Also TLS ist ein allgemeines Protokoll, das auf TCP basiert, und das kann ich auch dafür nutzen, zum Beispiel, um die Verbindung zwischen Mail-Server oder beliebige TCP-Verbindungen zu verschlüsseln. Das ist heute nicht mehr darauf beschränkt und war es eigentlich auch nie. Es ist nur in dem Umfeld des Webs entstanden, aber ich kann das auch für beliebige andere Transporte nehmen. Wie gesagt, zwischen Web-Servern als typisches Beispiel, wo man es heute auch immer mehr macht. Aber es kann auch Beliebiges sein. Es können irgendwelche proprietären TCP-Verbindungen, Protokolle sein. Was weiß ich, im Embedded-Bereich irgendwelche Sensoren, die auf raw TCP ihre Daten liefern, das kann ich auch mit TLS verschlüsseln. Das ist jetzt nicht unbedingt ans Web gebunden, wobei wir das vielleicht einschränken müssen, vielleicht kommen wir darauf später noch einmal. Es gibt so ein paar Extensions, seit TLS 1.2, wo man sozusagen in die höhere Protokollebene mit eingreifen kann, indem man sagt, ich möchte danach bitte HTTP/2 sprechen. Das ist im Grunde erst einmal eine Optimierung, um sozusagen weitere Handshakes oder weitere Round-Trips zu vermeiden. Denn in der idealen OSI-Welt sind ja die ganzen Layer schön abgetrennt und wissen nichts voneinander. Da hast du erst mal die TLS-Round-Trips und -Handshakes und Sonstiges. Und dann kommt die Applikation darüber und muss auch noch einmal schauen, was wird denn jetzt hier gesprochen? Soll ich jetzt hier HTTP/1 sprechen oder soll ich hier HTTP/2 sprechen? Wenn man das schon vorher mitteilt innerhalb von TLS, dann kann man das optimieren.

Simon Kölsch: Genau, das ist grundsätzlich oft eine Ursache für Performance-Probleme. Jetzt gar nicht irgendwie bestimmte Bandbreite- oder Ladegeschwindigkeiten, sondern am Ende ist es die Latenz auf der Leitung. Und gerade wenn wir so etwas wie TCP als Protokoll nutzen, was in viele kleine Pakete fragmentiert, um über die Leitungen zu schicken und es da viele Handshakes gibt, dann habe ich an der Stelle eine hohe Latenz. Wenn wir zum Beispiel an so etwas wie Australien oder so denken und wir haben einen Server irgendwo in den USA stehen, da ist es gar nicht ungewöhnlich, dass ich eine Latenz von 200 bis 300 Millisekunden habe. Und wenn wir dann so einen Handshake zwischen Client und Server haben, schicken das Paket einmal in die eine Richtung, einmal in die andere Richtung und noch einmal eine Bestätigung zurück, dann ist man schon bei einer Sekunde und die wird man auch gar nicht so einfach los. Da kann man das auch nicht wegoptimieren, da sind einfach geografische Entfernungen dazwischen. Und um verschlüsselte Verbindungen mit einem Webserver auszuhandeln, passiert so etwas eben häufiger und da hat man der Stelle das Protokoll entsprechend auf Geschwindigkeit optimiert bzw. kann es dann dafür einsetzen. Okay.

Christoph Iserlohn: Ganz genau. Und gerade beim Web ist halt das Problem, dass das eine interaktive Anwendung ist und ich nicht diese zwei, drei, vier Sekunden warten möchte, bis meine Seite ausgeliefert wird. Während das bei anderen Protokollarten… Also wenn ich jetzt SMTP spreche, also eine Mail verschicke, dann ist mir das wahrscheinlich egal, ob im Hintergrund die Verbindung drei Sekunden länger braucht, um aufgebaut zu sein, und dann erst die Mail verschickt wird und irgendwo ankommt, weil es sowieso ein asynchrones Medium ist.

Simon Kölsch: Da hat sich ja durchaus auch das Web in den letzten 20 Jahren verändert, was Synchronität angeht mit Benutzern und Interaktionen.

Christoph Iserlohn: Ja.

Simon Kölsch: Okay, wir sind jetzt ein paar Mal gesprungen zwischen SSL und TLS und einer spezifischen TLS-Version. Wir waren so ein bisschen bei der Einordnung, dass Netscape da diesen Standard vorangetrieben hat, um ihn entsprechend in die Browser einzubauen. Da waren wir jetzt bei SSL, dem Secure Socket Layer, der, so wie du am Anfang erwähnt hast, halt auf TCP basiert. Da habe ich einen Socket, sprich, ich habe irgendwie die Möglichkeit, eine Verbindung, eine Punkt-zu-Punkt-Verbindung zwischen zwei Systemen herzustellen, einem Client und einem Server. Und ich habe nicht nur eine IP-Adresse, um den entsprechenden Teilnehmer in der Kommunikation zu identifizieren, sondern ich habe jetzt plötzlich auch noch so etwas wie Ports und spreche dann einfach mit dem Server auf einem bestimmten Port über diese Punkt-zu-Punkt-Verbindung. Das kann man dann ganz grob als Socket bezeichnen. Und diesen Socket-Layer, diese Punkt-zu-Punkt-Verbindung, wollte Netscape da mit SSL absichern. Wie ging das denn weiter?

Christoph Iserlohn: In der Historie war es so, dass das erste Protokoll, SSL Version 1, erst einmal gar nicht veröffentlicht wurde, lustigerweise. Denn da hat man schon Sicherheitsmängel und Design-Fehler so frühzeitig bemerkt, dass man gesagt hat, nein, wir machen direkt mal eine Version 2. Die kam dann 1995 in den Navigator. Die Entwicklung hat schon früher begonnen. Ich weiß nicht, ich glaube, ein Jahr früher, ganz genau weiß ich das nicht. Und du hattest gerade gesagt, dass sie das in die Browser bringen wollten. Eigentlich wollten sie das natürlich in den Navigator bringen. Damals waren ja so die Browser-Kriege zwischen Netscape und Microsoft mit ihrem IE und sie wollten sich da natürlich einen Vorsprung erarbeiten und hatten jetzt gar nicht unbedingt so viel Interesse, dass das woanders landet. Bzw. Microsoft hatte auch nicht viel Interesse, so etwas unbedingt zu übernehmen. Deshalb kamen die auch mit ihrem eigenen Protokoll heraus, dem PCT, Private Communication Technology. Das war zwar kompatibel mit SSL Version 2, hatte aber so ein paar Sicherheitsprobleme, die darin theoretisch waren, aber noch nicht praktisch aufgetreten.

Simon Kölsch: Da muss ich jetzt nachfragen: Lebt das noch?

Christoph Iserlohn: Nein, das hat sich nicht so durchgesetzt. Sozusagen außerhalb der Microsoft-Welt hat das keiner irgendwie implementiert.

Simon Kölsch: Das beruhigt mich.

Christoph Iserlohn: Microsoft war damals jetzt auch noch nicht so, dass sie ihre eigenen Technologien irgendwie als Open Source offengelegt oder sonst irgendwie bereitwillig weitergegeben haben. Da war es sozusagen knallhart: Wer setzt sich durch? Aber Microsoft hat es in dem Fall nicht getan. Von daher ging die SSL-Entwicklung weiter mit SSL 3. Das kam irgendwann Ende von 95 raus. Das hat dann auch die Sicherheitslücken gefixt, die das SSL 2-Design hatte. Und Netscape wollte dann doch versuchen, das irgendwie in eine breitere Öffentlichkeit zu bringen und nicht nur bei sich zu haben. Und sie haben dann die Entwicklung des Protokolls an die IETF, also die Internet Engineering Task Force, übergeben. Das sind die, die ganzen RFCs herausgeben.

Simon Kölsch: Die auch den ganzen Standardisierungsprozess begleiten.

Christoph Iserlohn: Genau, den Standardisierungsprozess begleiten und auch definiert haben, welche Schritte da nötig sind. Es gibt ja für einen RFC immer einen gewissen Status und dann gibt es Statusübergänge. Und die haben das dann übernommen. Und da kam auch die Umbenennung nach TLS. Also eigentlich ist TLS 1.0 fast genau SSL 3. Aber Gerüchten zufolge hat Microsoft das durchgesetzt in einer ersten Runde, wo die sich zusammengesetzt haben, dass man das, wenn man es dann abgibt, auch unbedingt umbenennen müsste. Da verlinken wir in den Shownotes mal von jemanden etwas, der hat einen Blogeintrag geschrieben, der hat daran früher gearbeitet und er sagt, in der Telefonkonferenz hätte Microsoft sozusagen mit darauf gepocht, dass man das umbenennt. Dann haben wir jetzt TLS 1.0, das ist so 96, dass das angefangen hat. Und was da erwähnenswert ist, ist jetzt nicht die Technik, weil es ja ungefähr SSL 3 ist, mit minimalen Unterschieden, sondern wie lange die Standardisierung gebraucht hat. Denn der Standard wurde erst im Januar 99 verabschiedet. Das heißt drei Jahre später, als es angefangen hat. Und das ist schon eine ziemlich lange Zeit dafür.

Simon Kölsch: Okay, dazu muss man sagen, dass so etwas natürlich in Standardisierungsgremien auch immer ein Politikum ist, dass das ganz stark geprägt ist davon, welche Mitbewerber sich denn da zusammenfinden und da den Standard aushandeln. Man kann da natürlich zuschauen und es gibt Working Group-Mailinglisten und alles, was da so dazugehört. Aber am Ende liegt es auch immer mit an den Leuten, die den Standard wirklich konkret schreiben, an den Autoren, wie die miteinander kommunizieren. Und dann kann so etwas auch eine Weile dauern. Also HHTP/2, das wir bekommen haben, hat ja auch ein paar Jährchen gebraucht, bis man sich da einig war.

Christoph Iserlohn: Vieles in der IETF braucht halt sehr lange, was manchmal vielleicht auch sehr gut ist, wenn so etwas länger abhängt und reift. Aber im Gegensatz zu vorher war das ellenlang. Vorher war das sozusagen ein Jahr, in dem dann drei verschiedene Protokolle und Versionen da sind. Und dann dauert es auf einmal drei Jahre, obwohl es technisch fast dasselbe ist wie das letzte SSL-Protokoll, das ist halt bemerkenswert. Aber wir haben ja vorher gesagt, Microsoft war dabei und Netscape war dabei und die waren sich da auch nicht unbedingt so grün. Da kann man sich vorstellen, dass da sehr viel politische Diskussionen auch mit eingeflossen sind. Aber wo wir jetzt bei Zeiträumen sind, das hat sich ziemlich lange gehalten, nämlich zehn Jahre. So lange hat es gedauert, bis TLS 1.1 da war. Das hat das so ein bisschen optimiert. Das hatte er auch einen Fix für eine Lücke, die noch gar nicht bekannt war. Für die BEAST-Lücke, die wurde erst fünf, sechs Jahre später entdeckt. Das war da aber sozusagen schon gefixt.

Simon Kölsch: Das war ja dann der schnellste Patch von Bekanntwerden der Lücke bis zur Auslieferung.

Christoph Iserlohn: Das war kein Zero-Day, das war schon im negativen Bereich. Aber das Nette dabei ist, dass auch als dann diese Lücke gefunden wurde, TLS 1.1 niemand irgendwie implementiert hatte. Es hat halt sehr lange gedauert, bis die Leute das zum einen implementiert hatten und zum anderen das überall auch deployt war. Weil TLS 1.1 erst einmal keinen so wahnsinnigen Nutzen brachte gegenüber 1.0. Es war jetzt nicht so viel schneller, optimierter, in anderen Aspekten besser, dann haben die Leute gedacht, okay, das brauchen wir jetzt vielleicht gar nicht so unbedingt.

Simon Kölsch: Ja, das ist ja grundsätzlich dann auch so ein bisschen ein Problem, was Deployment-Geschwindigkeiten angeht und Budgetierung von Projekten, das sind genau die Dinge, die man natürlich auf später verschiebt. Vor allem, wenn es einem schwerfällt, da erst einmal konkrete Vorteile zu finden. Plus: Es ist natürlich ein kritischer Teil von der Infrastruktur. Wenn wir das auf dem Webserver ausrollen und machen das kaputt, dann haben wir halt keine Clients mehr, die sich da zu verbinden können. Das fasst man natürlich nicht an, wenn man es nicht unbedingt anfassen muss.

Christoph Iserlohn: Darauf kommen wir, glaube ich, später noch einmal, vielleicht was so aktuell noch deployt ist und was in Zukunft kommt. Da sieht man auch so ein paar Zeitskalen, die sehr lang sind. Naja, auf jeden Fall: 1.1 ist jetzt auch nicht die letzte Version, sondern danach kamen noch zwei Versionen. Das ist die Version 1.2, die kam schon relativ früh nach 1.1, 2008, und war auch nicht so viel unterschiedlich zu 1.1, aber eine Besonderheit, die man herausheben sollte: Das war die erste Version, die Verschlüsselungsalgorithmen mit AEAD erlaubt. AEAD steht für Authenticated Encryption With Associated Data. Hört sich kompliziert an, ist aber relativ einfach. Die kombiniert die Verschlüsselung direkt mit einer Integritätssicherung. Das heißt, man braucht keinen MAC oder HMAC mehr. Was sehr praktisch ist, weil einige Angriffe – da kommen wir auch später noch zu, was so an Angriffen möglich ist – halt genau auf diesen HMAC oder die Integritätssicherung zielen. Und bei denen ist das nicht mehr möglich.

Simon Kölsch: Okay, das heißt, vorher habe ich Integritätssicherung quasi selbst mit einem Werkzeug gemacht und wenn ich den aktuelleren Standard benutze, ist das quasi in die Verschlüsselung eingebaut und ich muss mich nicht mehr darum kümmern. Das macht wahrscheinlich die Library mit und ich werde damit erst einmal nicht so sehr in Berührung kommen?

Christoph Iserlohn: Genau, so kann man das sagen. Wobei wir jetzt beachten müssen, bei TLS 1.2 war das die erste Version die Verschlüsselungsalgorithmen, die das unterstützen, erlaubt hat. Das waren aber noch bei weitem nicht alle. Das ist aber ein guter Übergang, um auf TLS Version 1.3 hinzuweisen, die 2018 veröffentlicht wurde. Daran wurde auch sehr lange gearbeitet, schon seit 2013, also auch wieder fünf Jahre. Da war es aber nicht so die politischen Einflussnahmen, sondern sehr viele technische Hürden, weil man mit TLS 1.3 sehr viele Altlasten über Bord werfen wollte. Und so mit diesen prototypische Implementierung hat man dann gemerkt, ja, aber viele Dinge im Internet, irgendwelche Proxies, Middle-Boxen, Server, kommen damit nicht zurecht, obwohl es eigentlich rückwärtskompatibel sein sollte. Und deshalb hat es sehr lange gedauert, da ein paar Wege zu finden, wie man das auch noch kompatibel macht. Und seit TLS 1.3, also jetzt seit zwei Jahren, sind nur noch die AEAD-Verschlüsselungsalgorithmen spezifiziert. Also man braucht das MAC-Verfahren nicht mehr.

Simon Kölsch: Okay, das heißt, grundsätzlich ist es ja nur das Protokoll, wie diese Verbindungen aufgebaut werden. Wir haben aber eben gehört, es gab knapp zehn Jahre kein Update auf den Standard. Dennoch sind die Kryptosysteme, die darunterliegen, und die Algorithmen teilweise konfigurierbar bzw. es gibt eine Untermenge davon, die ich in dem Protokoll dann verwenden kann. Das lässt sich erweitern oder reduzieren. Und an manchen Stellen passt man da das Protokoll an und nimmt deswegen vielleicht an den einen oder anderen Stellen, um ein konkretes Beispiel zu nennen, MD5 raus, weil man sagt, es ist gebrochen. Aber im großen Ganzen ist es quasi konfigurierbar, was man dann nimmt. Deswegen überlebt man da vielleicht auch mal zehn Jahre ohne Update vom Standard.

Christoph Iserlohn: Ganz genau. Man will das Protokoll sehr flexibel halten und erlaubt dann zum Beispiel bei den ganzen Verschlüsselungsalgorithmen, dass man da eine große Auswahl hat und die dann entsprechend anpassen kann. Auch für verschiedene Use Cases, die sind ja auch auf verschiedene Ziele optimiert, zum Beispiel für eine schnelle Softwareimplementierung oder eine leichte Hardwareimplementierung. Wenn ich die verschiedenen anbieten kann, dann können verschiedene Clients, sehr viele verschiedene Clients ganz gut mit mir sprechen und ein optimales Protokoll aushandeln, also eine optimale Konfiguration innerhalb des Protokolls. Das andere ist: Man ist ein bisschen zukunftssicherer. Also wenn mal ein Verschlüsselungsalgorithmus gebrochen wird, dann kann ich den heraus konfigurieren und muss nicht direkt auf eine neue Protokollversion wechseln. Von daher bietet sich das an. Ein Nachteil bei solchen Sachen ist natürlich, dass Protokolle, die sehr viel Flexibilität erlauben, auch relativ komplex sind und dadurch auch die Implementierung nicht so einfach ist und Implementierungsfehler im Fall von TLS auch direkt zu Sicherheitslücken führen können.

Simon Kölsch: Darauf kommen wir am Ende sowieso noch einmal zurück, was Libraries und Implementierungsdetails angeht. Wir sind jetzt bei TLS 1.3, das ist die aktuelle Version. Wie ist das denn verbreitet im Moment? Also TLS 1.3 ist die Version, die ich im Moment eigentlich konfigurieren könnte und einsetzen oder ist so etwas wie SSL 3 immer noch relevant und das muss ich im Zweifel unterstützen? Oder was wäre da so ein Teil, auf den ich mich eigentlich konzentrieren sollte?

Christoph Iserlohn: Also für SSL 2 gibt es auch ein RFC, dass das nicht mehr eingesetzt werden soll, für SSL 3 auch. Auch 1.0 und 1.1 sind eigentlich als veraltet gekennzeichnet, sind aber jetzt noch nicht so, dass sie überhaupt nicht mehr eingesetzt werden sollen. Aber normalerweise wird man sagen, einen Server sollte man so konfigurieren, oder überhaupt Clients und Server, die TSL nutzen, dass sie 1.2 und 1.3 benutzen.

Simon Kölsch: Okay.

Christoph Iserlohn: 1.2 muss man noch speziell konfigurieren, damit es wirklich hundertprozentig sicher ist nach aktuellem Stand. Darin sind noch Sachen, die aus Sicherheitssicht suboptimal sind, die müsste man dann halt abschalten. Bei TLS 1.3 hat man relativ viel aufgeräumt, auch an dem Verschlüsselungsalgorithmen und Schlüsseltauschverfahren. Das kann man eigentlich sozusagen out-of-the-box einsetzen. Das Problem ist, 1.3 ist noch sehr wenig verbreitet. 1.2 wird wohl so den Hauptteil aufmachen, aber es gibt auch noch jede Menge alte Clients, die 1.2 auch noch nicht sprechen, sondern nur 1.1, teilweise auch 1.0. Es kommt halt immer ein bisschen auf die Lebensdauer der Clients an, weil man so im embedded-Bereich irgendwo oder im Bereich der Industrie…

Simon Kölsch: Ich glaube, da muss man gar nicht so weit in den embedded-Bereich gehen. Es reichen ja die ganzen uralt Android-Handys, die so auf dem Markt sind und da sind ja teilweise auch Browser drauf, bei denen das ein bisschen schwieriger ist. Das heißt, okay, grundsätzlich muss man die Clients im Hinterkopf behalten, aber wenn man so etwas angeht oder damit irgendwie zu tun hat, wird man sich bei TLS 1.2, 1.3 bewegen, eigentlich?

Christoph Iserlohn: Das wäre meine Empfehlung.

Simon Kölsch: Okay, das heißt, wir haben jetzt so ein bisschen über die Versionierung von dem Protokoll gesprochen, wo wir uns gerade befinden, vielleicht mal zum etwas technischeren Teil: Wie funktioniert das denn eigentlich dann genau? Wie ist denn so ein Ablauf? Ich habe verstanden: Wir haben einen Client, der kann über TLS herausfinden, mit wem er denn spricht. Und auf der anderen Seite ist ein Server, der kann entscheiden, ob er mit diesem Clients sprechen will. Oder es ist ihm egal, weil er mit allen spricht. Wie ist denn da so der Ablauf vom Protokoll? Wir gehen da nicht total in die Tiefe, aber vielleicht so ein bisschen high Level. Welche Schritte gibt es da, welche Teile gibt es davon?

Christoph Iserlohn: Also um das einmal aufzuschlüsseln, würde ich anfangen, welche Teile gibt es denn in dem Protokoll? Da gibt es einmal die TLS-Records und auf diesen Records basierend gibt es – sie nennen das auch noch einmal Protokoll – das Handshake-Protokoll – das ist das Wichtigste. Darauf können wir vielleicht gleich einmal etwas detaillierter eingehen – das Alert-Protokoll, das ist, wenn irgendetwas schief läuft und eigentlich das Uninteressante sind Application-Data. Das sind dann halt die verschlüsselten Daten. Sobald wir da angekommen sind, brauchen wir uns eher um wenig zu kümmern. Diese Records, die ich gerade erwähnt habe, die könnte man vielleicht vergleichen mit IP-Paketen. Sie stellen sicher, dass diese ganzen Nachrichten, die da verschickt werden, auch zusammengefügt werden können.

Simon Kölsch: Das heißt, TLS ist erst einmal so ein sicherer Kanal, und dann gibt es noch einmal so Sub-Protokolle. Das heißt, in TLS werden verschiedene Dinge ausgehandelt, Daten übertragen, und dafür gibt es dann innerhalb von diesem TLS quasi mit den Records eine Art Routing oder mit Meta-Informationen, die ich darüber übertragen kann?

Christoph Iserlohn: Also Routing gar nicht so, sondern mehr: Die Nachrichten müssen da ja nicht unbedingt alle immer reinpassen in ein so einen Record. Die kümmern sich zum Beispiel um Fragmentierung, dass das aufgeteilt wird auf mehrere Records und dann wieder vernünftig zusammengefügt wird. Und die haben dann noch einen Typ, damit man weiß, okay, was für eine Art von Nachricht ist denn darin jetzt? Gehört das jetzt zum Handshake oder sind wir bei der Application-Data? Das passiert auf der Ebene. Die ist vielleicht auch gar nicht so interessant. Es ist nur interessant, eigentlich, dass das so ein bisschen Sachen abnimmt, die wir auf der TCP-Ebene auch schon mal haben. Interessant sind die Protokolle darin. Der Begriff, den finde ich eigentlich sehr ungünstig gewählt. Denn das TLS-Protokoll hat intern noch einmal ein Handshake- und ein Alert-Protokoll. Das hätte man vielleicht anders benennen können. Alert – fangen wir damit an – das ist relativ leicht abzuhaken, das ist: Irgendetwas geht schief und der Server oder der Client können das dann irgendwie melden und sagen, hier ist etwas schiefgegangen. Und meistens wird dann auch die Verbindung abgebrochen, weil das sonst sehr leicht ausgenutzt werden kann, um einen Angriff zu starten. Also wird immer gesagt, irgendetwas ist schiefgegangen, wir beenden die Verbindung.

Simon Kölsch: Daten nur halb verschlüsselt übertragen hilft uns hier nicht weiter. Da wollen wir dann vielleicht lieber gar keine Daten übertragen.

Christoph Iserlohn: Zum Beispiel. Oder ich komme mit deinen Zertifikaten nicht klar. Ich kann den Trust nicht herstellen, weil ich deinem Root-Zertifikat nicht vertraue, dann lohnt es sich auch nicht weiter zu reden. Dann kann man auch sagen, Verbindung bitte beenden. Am interessantesten ist das Handshake-Protokoll. Wir müssen ja irgendwie eine Verbindung erst einmal aufbauen, und das Wichtige ist da, wir müssen damit ja auch eine Verschlüsselung aufbauen. Die ist ja nicht automatisch verschlüsselt, sondern wir müssen uns als Client und Server irgendwie darauf einigen, welchen Schlüssel nehmen wir denn jetzt? Und da wir vorhin darüber gesprochen haben, dass das sehr flexibel ist, welchen Algorithmus benutzen wir denn jetzt dafür? Und so weiter und so fort. Und das macht halt das Handshake-Protokoll.

Simon Kölsch: Das heißt, damit lösen wird das Problem, dass Sender und Empfänger sich kennen, aber nicht vorher schon irgendwie direkt einen Schlüssel ausgetauscht haben, sondern man geht davon aus, dass das ein unsicherer Übertragungsweg ist. Und irgendwie müssen sich beide jetzt auf eine Verschlüsselung und Algorithmen einigen?

Christoph Iserlohn: Ganz genau. Man kann ja auch nicht davon ausgehen, dass die sich schon mal kennengelernt haben. Also in meinem Browser kann ich eine beliebige Adresse für eine Webseite oder für einen Server eintippen. Dafür kann ich ja nicht alle Schlüssel schon haben oder schon einmal da gewesen sein.

Simon Kölsch: Man könnte natürlich sagen, indirekt über so etwas wie Certificate-Authorities, die Zertifikate unterschreiben, gibt es da ein Vertrauensverhältnis. Aber das wäre dann inhaltlich Thema für die nächste Folge.

Christoph Iserlohn: Ganz genau. Das kann man noch einmal extra behandeln, das ist auch ein großes Thema. Aber Zertifikate werden in diesem Handshake auch untereinander ausgetauscht. Ich könnte ja mal kurz beschreiben, wie so ein TLS-Handshake funktioniert, was es da für Nachrichten gibt. Das wäre jetzt Version 1.2. Es fängt erst einmal an mit der sogenannten Client Hello-Message. Also der Client schickt eine Message: Client Hello. Darin ist dann, welche Protokollversion unterstütze ich denn und zwar TLS-Protokoll. Das heißt, ich weiß auch nicht, welche Protokollversionen der Server alle unterstützt. Also es kann auch sein, ich unterstütze jetzt 1.0, 1.1, 1.2 und der Server unterstüzt nur 1.1. Dann sage ich erst einmal, welche Version wird denn da unterstützt. Dann schicke ich einen Zufallswert mit. Den braucht man dann, damit beide Seiten einen Schlüssel erzeugen können. Also einmal für den Client und einmal für den Server, und da schicke ich das sogenannte Client Random mit. Dann schicke ich mit: Was für Verschlüsselungalgorithmen unterstütze ich denn alle. Also was kann ich denn. Dann gibt es noch die Liste davon, welche Komprimierungsmethoden man unterstützt. TLS hat auch eingebaut, dass es eine Komprimierung geben kann. Das gilt aber nur bis TLS 1.2. Damit gab es auch Sicherheitsprobleme. Und das ganze Design erlaubt auch nicht, dass man sozusagen sichere Komprimierungmethoden findet. Deshalb gibt es das bei 1.3 nicht mehr. Aber bei 1.2 ging das noch auch bei allen vorher. Und dann liefere ich noch eine Liste von Extensions mit. Da ist das Protokoll flexibel, da gibt es eine Reihe von Extensions und der Server muss auch nicht auf alles reagieren. Das macht es halt flexibler, wenn man nachträglich noch etwas am Protokoll einbauen will, was jetzt nicht die komplette neue Protokollversion erfordert. Darin ist dann zum Beispiel, welchen Servernamen möchte ich denn haben? Mit welcher Adresse verbinde ich mich? Das ist eine ganz wichtige Extension.

Simon Kölsch: Okay, das heißt, wenn ich überlege, wir reden die ganze Zeit von TCP-Layer, Client und Server. Da habe ich eine Kommunikation zwischen IP-Adressen und wenn wir aber eine verschlüsselte Website aufrufen mit HTTPS, dann kann es ja durchaus sein, dass auf der gleichen IP-Adresse mehrere virtuelle Server laufen, die auf unterschiedliche den DNS-Namen reagieren.

Christoph Iserlohn: Ganz genau. Und ich kenne erst einmal nur die IP-Adresse bzw. die IP-Adresse nützt halt nichts, um dem Server zu sagen, welches Zertifikat möchtest du denn jetzt haben. Also möchtest du das jetzt für den www.simon.kölsch oder den www.christoph.iserlohn. Weil wir uns jetzt einen Server teilen mit der gleichen IP. Und in dieser Extension steht dann, ich möchte jetzt aber mit dem simon.kölsch sprechen.

Simon Kölsch: Als ob ich noch eine Kölsch-Domain bekäme.

Christoph Iserlohn: Iserlohn ist auch ein schwieriger Name um eine Domain zu bekommen, von daher.

Simon Kölsch: Okay. Das heißt, hier an der Stelle übermitteln wir einfach noch ein paar zusätzliche Informationen beim Handshake. Besprechen dann die ganzen Details, welchen Algorithmus wir haben wollen, was da so dazugehört, eventuell noch eine Extension. Das heißt, wir sagen, ich möchte nur eine verschlüsselte Verbindung, ich möchte auch genau die Domain XY aufrufen. Ich nehme an, der Server antwortet mit ähnlichen Infos?

Christoph Iserlohn: Genau. Die erste Nachricht vom Server ist auch ein Server-Hello. Und der sagt dann darin: Okay, ich habe jetzt aus denen, die du mir vorgeschlagen, folgende Protokollversion gewählt und auch folgenden Algorithmus, um zu verschlüsseln, und auch wie wir komprimieren, wenn wir das noch tun. Gleichzeitig macht er dann auch noch sein Geheimnis, also Server Random schickt er auch noch mit. Das ist eigentlich die Server Hello-Message, schon fast fertig, der kann auch noch Extensions mitliefern, wenn er möchte. Er könnte z.B. sagen, bitte Client, schick mir doch auch mal dein Zertifikat. Normalerweise ist es ja so, das Zertifikat schickt mir der Server, der weist sich aus. Clients können anonym sein, also beliebige Clients, die anonym sind, können sich verbinden. In anderen Szenarien, wo es jetzt nicht im Web ist, sondern in einer geschlossenen Infrastruktur, könnte man auch ein Client-Zertifikat verlangen.

Simon Kölsch: Also im Enterprise-Umfeld findet man das häufig, dann auf Mitarbeiterausweisen, da ist dann eine Smartcard dabei und die Smartcard hat ein Zertifikat ausgestellt von einer eigenen CA für diesen Mitarbeiter. Und das kann ich auch benutzen, um mich dann gegenüber einem Server zu authentifizieren.

Christoph Iserlohn: Ganz genau. Ein weiteres Beispiel ist: Heutzutage hat man ja oft irgendwelche Microservice-Umfelder oder SCS. Und da sind dann halt ganz viele Services, die miteinander reden. Die authentifizieren sich dann auch gegenseitig, indem sich auch ein Client- und ein Server-Zertifikat schicken in ihren TLS-Verbindungen untereinander.

Simon Kölsch: Okay, das heißt, wenn ich eh Infrastruktur habe, um Zertifikate zu managen, ist es durchaus mal eine Überlegung, bevor ich das nächste selbstgebastelte Passwort-Token-Hash-wie-auch-immer-System baue, vielleicht einfach auf der Ebene schon TLS zu nutzen und Client-Zertifikate einzusetzen?

Christoph Iserlohn: Das kann man machen. Dabei gibt es zwei Dinge, die zu beachten sind. So ein TLS-Zertifikat zu installieren ist halt nichts für Leute, die technisch nicht so versiert sind. Und manchmal kann man das auch gar nicht, wenn man administrierte PCs hat, da einfach Zertifikate in den Stores, in den Key- und Zertifikatsstores der Browser zu installieren. Und das andere ist: So etwas muss man auch erst einmal managen können. Das ist jetzt nicht einfach. Ich meine, das andere, um irgendwelche Multifaktor-Authentifizierung-Sachen zu managen oder Passwort und so, das ist halt auch nicht einfach.

Simon Kölsch: Genau.

Christoph Iserlohn: Das muss man abwägen, ganz für den Use Case spezifisch.

Simon Kölsch: Deswegen, wenn ich so etwas wie eine PKI, Public Key Infrastructure, zur Verfügung habe oder einfach nutzen könnte, wäre das zumindest eine Überlegung wert?

Christoph Iserlohn: Absolut.

Simon Kölsch: Grundsätzlich Management von Geheimnissen, nennen wir es mal so, Schlüsseln, wie auch immer, muss ich in jedem Fall sicherstellen, egal welche Variante ich da am Ende nehme.

Christoph Iserlohn: Absolut. Gut. Der Server hat jetzt so ein Server Hello geschickt. Dann schickt er noch sein Certificate, das ist auch ein Nachrichtentyp und danach schickt er eine Key-Exchange-Message. Und das dient zum Schlüsselaustausch. Die Daten dabei sind noch einmal signiert mit dem Private Key des Zertifikats, damit der Client das auch noch einmal überprüfen kann. Denn noch läuft das ja alles unverschlüsselt ab. Und dann sagt der Server mit Server Hello, ich bin jetzt fertig. Dann schickt der Client auch einen kleinen Key-Exchange. Und dann haben sozusagen beide den Schlüssel in der Hand. Da gibt es mehrere Schlüsseltauschverfahren. Einmal könnte man das einfach mit RSA, also mit dem Key aus dem Zertifikat, verschlüsseln. Da ist ja schon ein Public Key dabei. Das hat aber Nachteile, weil das kein PFS, Perfect-Forward-Secrecy unterstützt. Was das ist, können wir gleich noch einmal klären. Oder man nimmt so ein Diffie-Hellmann-basiertes System. Die sind halt Perfect-Forward-Secrecy und dann hat man danach den gemeinsamen Schlüssel. Und dann kann man verschlüsselte Daten schicken. Was aber noch kommt, ist eine Finish-Nachricht. Und da wird noch einmal der ganze Handshake, die Nachrichten gehasht. Und genauso schickt der Server danach noch einmal eine Finish-Nachricht und er macht auch einen Hash darüber.

Simon Kölsch: Das ist zum Schutz wovor?

Christoph Iserlohn: Des Handshakes, um die Integrität des Handshakes abzusichern. Damit man sieht, da wurde nicht zwischendurch manipuliert. Denn der ist ja auch im Klartext, läuft der durch das Kabel oder durch die Radiowellen im WLAN. Und die kann man ja beliebig manipulieren. Aber wenn sie integritätsgesichert sind, dann merkt man das, wenn sie manipuliert sind, und dann würde man die Verbindung abbrechen. Und danach ist der Handshake vorbei und danach können die Applikations-Daten fließen, die dann alle mit dem ausgehandelten Schlüssel verschlüsselt sind und die sind dann relativ unspektakulär.

Simon Kölsch: Das heißt, wir haben eine Leitung, auf der eventuell ein Angreifer sitzen könnte, aber trotzdem handeln beide einen gemeinsamen Schlüssel für die bestehende Verbindung so aus, dass der Angreifer keine Möglichkeit hat, dann später den Klartext zu bekommen. Da sind wir nicht ganz auf der grünen Wiese, sondern wir haben einen kleinen Anfang, nämlich das Server-Zertifikat, dem wir irgendwie erst einmal Vertrauen entgegenbringen. Das können wir abgleichen mit einer langen Liste, mit der CA, die bei mir liegt. Das wäre das Thema, das wir das nächste Mal noch einmal ein bisschen tiefer gehend behandeln. Und damit kann man quasi diesen ganzen Prozess bootstrapen, um dann irgendwie diesen sicheren Kanal zu bekommen.

Christoph Iserlohn: Ganz genau.

Simon Kölsch: Okay, und dann würde man wahrscheinlich hauptsächlich Data Frames auf dem TLS-Layer sehen, weil dann, was auch immer für ein Protokoll darin noch einmal besprochen wird, das hin und her übertragen wird.

Christoph Iserlohn: Genau. TLS erlaubt es bis 1.2 auch noch einmal sozusagen ein Renogiation von dem ganzen Cipher Spec zu machen. Das heißt, ich kann innerhalb der Verbindung sagen, ich schicke noch einmal eine Nachricht und möchte jetzt noch einmal irgendwie den Schlüssel tauschen und vielleicht auch den Algorithmus und so. Da das aber auch einen Angriffsvektor geboten hat, wurde es bei TLS 1.3 entfernt. Da kann man das nicht mehr machen, da laufen nur noch verschlüsselte Applikationsdaten rüber. Bei 1.2 könnte man das noch einmal ändern. Hintergrund ist der, dass man, wenn man extrem landläufige Verbindungen hätte, man irgendwann sozusagen dabei wäre…

Simon Kölsch: Den Schlüssel rotieren möchte.

Christoph Iserlohn: Genau, man möchte den Schlüssel rotieren oder der Initialisierungsvektor soll geändert werden für die symmetrischen Schlüsselverfahren und solche Sachen. Das hat aber praktisch eigentlich keine Relevanz gehabt. Und wie gesagt, das hat nur mehr Angriffsfläche geboten, die leider auch ausgenutzt werden konnte und deshalb ist es bei TLS 1.3 verschwunden.

Simon Kölsch: Okay, wir haben es jetzt ein paarmal schon erwähnt. Erstmal klingt das ja ganz gut, was das Protokoll verspricht. Aber am Ende ist es wesentlich komplizierter mit dem Handshake, mit dem Aushandeln, was für Algorithmen ich einsetze. Und immer wieder gab es Angriffe oder Lücken, die im Protokoll auch bekannt geworden sind, die man dann versucht hat, mit einer neuen Protokollversion auch zu beheben. Was gibt es denn da? Gibt es da bestimmte, die wir exemplarisch vielleicht einmal durchgehen können? Was heißt dann eigentlich ein Angriff auf dieses System?

Christoph Iserlohn: Wir können das vielleicht mal zweiteilen. Einmal, welche Arten von Angriffen gibt es? Und dann vielleicht mal einen rauspicken und den konkret etwas näher diskutieren. Bei den Arten könnte man unterscheiden zwischen: Einmal gibt es gebrochene Krypto. Also z.B. der RC4-Cipher, der ist halt gebrochen. Und der ist erlaubt in älteren TLS-Versionen. Wenn man den dann aushandelt, dann nützt das halt relativ wenig, dass man TLS benutzt, den kann man dann abhören und knacken. Genauso wäre gebrochene Krypto, wenn man jetzt MD5 in Zertifikaten benutzt für die Signatur. Das ist ja jetzt auch gebrochen, dass man da Kollisionen erzeugen kann und dann gefälschte Zertifikate herstellt, was ja auch schon passiert ist. Von daher, das wäre also gebrochene Krypto, die man einsetzt. Das wäre ein Eingriff. Als Gegenmaßnahme wird sich da natürlich anbieten, auf eine Version zu wechseln, die die gebrochene Krypto nicht mehr drin hat. Und wenn das nicht geht, die herauszukonfigurieren, dass sie gar nicht erst benutzt wird.

Simon Kölsch: Okay. Aber selbst das dauert ja immer eine Weile, bis so Hash-Kollisionen zum Beispiel gefunden werden oder Ähnliches. Ein Schutz davor, dass, wenn jemand einfach verschlüsselte Daten aufzeichnet und die fünf Jahre lang irgendwo liegen lässt, um sie sich dann anzugucken, weil jetzt eben die Hälfte der Algorithmen gebrochen ist, gibt es da einen Mechanismus?

Christoph Iserlohn: Wenn die Krypto dann gebrochen wird? Wahrscheinlich nicht. Das kommt aber auch darauf an, wie die Krypto gebrochen wird, also welche Daten man noch zusätzlich braucht. Ich würde da gerne dann vielleicht noch einmal auf, was ich vorhin erwähnt habe, Perfect-Forward-Secrecy eingehen. Denn das ist ein ähnlicher Fall. Da ist es so: Irgendein Angreifer zeichnet fleißig Daten auf. Wie wir ja alle wissen seit einigen Jahren, es ist ja auch ziemlich bestätigt durch Edward Snowden. Es gibt ganz viele Organisationen, die haben meistens drei Buchstaben, die zeichnen ganz schön viele Daten auf. Gibt es auch in Deutschland, hat auch drei Buchstaben, die zeichnen halt Daten auf. Das können verschlüsselte Verbindungen sein, mit denen können sie vielleicht erst einmal nichts anfangen. Wenn sie dann aber nachträglich an den Key kommen, könnte man die halt aufbrechen. Und wenn der Schlüsselaustausch, also der Handshake, jetzt darauf basiert, dass ich den öffentlichen Schlüssel des Zertifikats benutze, um den Schlüssel zu verschlüsseln, mit dem ich dann die eigentlichen Applikationsdaten verschlüssele, dann brauche ich irgendwann nur den privaten Schlüssel von diesem Zertifikat in die Hände zu bekommen und dann kann ich alle Verbindungen, die damit geführt werden, aufbrechen.

Simon Kölsch: Nachträglich dann?

Christoph Iserlohn: Nachträglich. Dagegen hilft Perfect-Forward-Secrecy, indem ein Schlüsselaustausch gemacht wird, bei dem ein Angreifer zwar mithören kann, aber diesen Schlüssel nicht konstruieren kann. Das berühmteste Verfahren ist von Diffie-Hellmann. Das gibt es in verschiedenen Varianten. Das gibt es auch mit elliptischen Kurven, dann ist es EC-Diffie-Hellman, also ECDH, sonst gibt es DH. Und das ist in so einem Podcast jetzt vielleicht schwierig zu erklären. Aber es gibt eine gute Analogie, und da gibt es noch ein schönes Video, das wir verlinken, wie man das zeigen kann. Und zwar ist das so, wenn du dir vorstellst, du mischst jetzt irgendwie Farben, Ölfarbe oder Wasserfarbe. Dann kommt, wenn du zwei Farben mischst, irgendeine Farbe wieder raus. Das Mischen ist sehr einfach, aber du kannst danach nicht mehr rekonstruieren, welche beiden Farbtöne du denn genau genommen, um zu diesem Ergebnis zu kommen. Du kannst beide Farben nicht mehr auseinanderhalten. Also sagen wir, wir beide machen Schlüsselaustausch. Dann einigen wir uns jetzt auf eine Farbe. Die kann der Angreifer auch gerne mithören, welche Farbe das ist. Und jeder von uns nimmt sich eine geheime Farbe, die bleibt nur bei uns selber, die wird nicht über die Leitung geschickt. Jetzt mische ich meine Farbe mit der, auf die wir uns geeinigt haben, schicke dir das, schon mal gemischt. Und du mischst dazu deine geheime Farbe, dann hast du sozusagen den Schlüssel. Du schickst mir aber auch noch einmal die öffentliche Farbe, auf die wir uns geeinigt haben, mit deiner geheimen Farbe und schickst mir das. Und dann kann ich meine geheime Farbe dazu mischen. Und dann sollten wir beide die gleiche Farbe haben. Der Angreifer hat jetzt aber nur die öffentliche Farbe und zwar das Gemixten. Wenn man die gemixten Sachen aber noch einmal zusammenmixen würde, dann wäre der öffentliche Anteil sozusagen doppelt darin. Das würde nicht die gleiche Farbe ergeben, die wir beide haben. Und da er das nicht auseinanderziehen kann, die Farben…

Simon Kölsch: Okay, da ist es selbst mit dem gebrochenen Schlüssel schwierig das zurückzurechnen.

Christoph Iserlohn: Genau. Und diese Farbe können wir auch nach der Verbindung wegwerfen. Das heißt, es sind vergängliche Schlüssel. Die laufen auch nicht über das Protokoll mit rüber, sondern werden lokal erzeugt von uns beiden. Und die Information darüber, wie man die erzeugt, sind auch nicht über die Leitung gelaufen, sondern das Geheimnis, die geheime Farbe, die wir uns bei der jeweils ausgedacht haben, bleibt ja bei uns. Das heißt, das kann man nachträglich nicht mehr knacken. Also man kann diesen Schlüssel nachträglich nicht wiederherstellen.

Simon Kölsch: Dann haben wir an der Stelle schon mal irgendwie eine Lösung dafür, wenn jemand einfach nur die Verbindung mitschneidet als ein Angriffsszenario, um es dann irgendwann zu einem späteren Zeitpunkt wieder zu entschlüsseln. Was haben wir denn noch so für Szenarien?

Christoph Iserlohn: Bei der gebrochenen Krypto, da hatte ich ja genannt, was da möglich ist und wie man das abwehrt, indem man andere Versionen einsetzt oder anders konfiguriert. Dann gibt es noch andere Fehlerarten, zum Beispiel den Protokollfehler, also im Protokolldesign. Ein Beispiel dafür ist die sogenannte Beast-Attacke. Die hat damit zu tun, dass in SSL 3 und TLS 1 der Initialisierungvektor, den man bei einer symmetrischen Verschlüsselung immer braucht, in bestimmten Krypto-Verfahren, sogenannten CBC-Verfahren, vorhersagbar war. Und wenn ich den habe, kann ich dann halt auch eine Entschlüsselung machen. Das heißt, dass der Designfehler war, dass dieser Initialisierungvektor so abgeleitet wurde, dass ein Angreifer den vorhersagen kann, wenn er entsprechend viele Nachrichten abfangen kann. Weitere Attacken sind Downgrade-Angriffe. Das heißt, ein Man-in-the-middle versucht, den Handshake zu manipulieren. Dass zum Beispiel eine unsichere Protokollvariante gewählt wird. Beispiele dafür sind einmal FREAK, so heißt der Angriff, der auf einer fehlerhaften Implementierung basiert. Also das Protokoll hätte das gar nicht unbedingt hergegeben, aber die Implementierung hat das falsch gemacht oder Logjam, die eher im Protokoll zu suchen ist. Um so etwas zu verhindern, hat dann TLS 1.3 auch gesagt, ein Protokoll-Downgrade gibt es nicht mehr, sondern bei 1.3 bleiben wir bei 1.3. Eine weitere Kategorie ist das Padding-Oracle. Da gibt es die Beispiele POODLE und später Lucky Thirteen. Da kommt das zum Tragen, dass der Integritätsschutz gemacht wird und dann erst die Verschlüsselung kommt. Man kann nämlich, wenn so eine Integritätsüberprüfung, also die Überprüfung des MAC, fehlschlägt, gewisse Informationen über den Klartext finden, und zwar indem man misst, wie lange das dauert. Da kann ich das Padding nach und nach he rauskriegen, also immer ein Byte. Also in einer Nachricht ist am Ende ein Padding drin, und ich kann dann systematisch ausprobieren mit gefälschten, verschlüsselten Texten, ob das jetzt geklappt hat oder nicht. Und pro Byte bräuchten wir 256 Versuche, weil ein Byte ja 256 Werte annehmen kann, ist jetzt auch im Podcast etwas schwer zu verstehen.

Simon Kölsch: Ja.

Christoph Iserlohn: Das grundsätzliche Problem dabei ist, dass man sich bei TLS dafür entschieden hatte, diese MAC-Berechnung auf den Klartext zu machen und danach erst die Encryption. Was hilft, ist, dass man so ein AEAD-Cipher nimmt, der den Integritätsschutz schon mit drin hat und der nicht noch einmal separat ist. Die sind dagegen resistent. Was es nich gibt, das sind Kompressionsangriffe, das hatte ich, glaube ich, schon vorher…

Simon Kölsch: Genau, das hatten wir eingangs erwähnt.

Christoph Iserlohn: Das basiert darauf: Bei Kompression verschwinden ja redundante Daten. Also die verschwinden nicht, aber –

Simon Kölsch: – werden sehr klein.

Christoph Iserlohn: Die werden dann halt wegkomprimiert und damit kann man, wenn man gezielt Nachrichten hinschickt, zum Beispiel eine Session-Cookie erraten, weil sozusagen die Daten des Session-Cookies wegkomprimiert sind. Das ist auch für einen Podcast relativ kompliziert, wir verlinken aber für die ganzen Attacken, die man jetzt für die Hörer und Hörerinnen nicht so leicht erklären kann, noch einmal in den Shownotes. Da kann man das dann nachlesen und da sind auch schöne Bilder dabei, da kann man die viel leichter verstehen. Das sollte nicht das Problem sein. Und die letzte Kategorie sind die Implementierungsfehler. Da ist vielleicht Heartbleed einer der bekanntesten und dann gehen wir auf den mal ein bisschen mehr ein. Der ist vielleicht auch leichter zu erklären.

Simon Kölsch: Es gab T-Shirts und ne Domain!

Christoph Iserlohn: Es gab T-Shirts und ne Domain, ganz genau. Heartbleed war nämlich einer der ersten, wenn nicht sogar die erste Sicherheitslücke, die eine eigene Webseite bekommen hat und auch so einen tollen Namen bekommen hat und ein Logo. Danach hatten das fast alle möglichen Lücken, das hat damit angefangen.

Simon Kölsch: Ja, inzwischen ist das gefühlt Standard.

Christoph Iserlohn: Und worum geht es bei Heartbleed? Es war ein Fehler in der OpenSSL-Bibliothek. Und zwar war es so, dass es da ein Heartbeat-Protokoll gibt, deshalb auch der Name Heartbleed. Das Heartbeat macht immer so ein Ping-Pong, um zu sagen, ich lebe noch, die eine oder die andere Seite. Das ist gerade bei so zustandslosen Protokollen wichtig, bei UDP zum Beispiel, dass man weiß, okay, da ist noch etwas, auf der anderen Seite. Und in dem Fall konnte man mit der Nachricht, ich lebe noch, bestimmte Daten senden, die nicht überprüft wurden von der Server-Seite, also von der OpenSSL-Bibliothek, die dazu geführt haben, dass der Server nicht nur das normale POM zurückgeschickt hat auf einen Ping, sondern viel mehr Daten aus seinem Speicher. Denn die Länge des Pings, was einem zurückgeschickt werden sollte, wurde nicht überprüft. Also schicke ich hier als Ping ABC und sage, ABC ist aber vier Kilobyte lang. Dann schickt der Server das ABC plus die weiteren Bytes, bis ich auf vier Kilobyte komme, aus dem Speicher, was nach ABC folgt. Das heißt, ich konnte aus Entfernung den Speicher von OpenSSL auslesen. Was natürlich sehr problematisch ist, weil im Speicher von OpenSSl liegen halt zum Beispiel auch die –

Simon Kölsch: Da liegen meine Keys.

Christoph Iserlohn: Genau. Da liegt das ganze Schlüsselmaterial. Das hatte dann zur Folge, dass man weltweit ziemlich viele Zertifikate austauschen musste, weil sehr viele der Server OpenSSL benutzen, um TLS zu implementieren. Und da man das nicht weiß, ob jemand diese Lücke ausgenutzt hat, wusste man auch nicht mehr, ob sein Schlüssel noch sicher war, also musste man den als kompromittiert ansehen. Danach musste man ganz viele Zertifikate austauschen. Was noch weitere Folgen hatte, dass z.B. Embedded-Geräte, die wenig Speicher haben, mit ihren CRLs, den Certificate Revocation Lists, also da, worauf steht, welche Zertifikat denn alle gesperrt sind, nicht mehr klarkamen, weil die viel zu groß wurden, sie die mit ihrem geringen Speicher nicht mehr verarbeiten konnten.

Simon Kölsch: Genau da kommt noch dazu, irgendwelche nicht genehmigten Speicherzugriffe. Dann schießt das auch schnell mal die Applikation ab oder das ganze Gerät. Dann hat man direkt noch einen neuen Vektor, nämlich dass man Server “DDoSen” kann, alles nicht so erfreulich an der Stelle.

Christoph Iserlohn: Alles nicht so erfreulich, ja. Das Gute daran war, dass Heartbleed aufgedeckt hat, in welchem schlimmen Zustand OpenSSL war. Denn OpenSSL hatte nur sehr wenig Geld. Zum größten Teil Freiwillige, sozusagen einer, der daran Vollzeit arbeiten konnte, der sich aber durch Consulting über OpenSSL oder mit OpenSSL verdingt hat und damit dann mehr darauf geschaut hat, dass er Kundenwünsche erfüllen konnte. Und es gab halt noch viel mehr im Nachgang, was man entdeckt hat, wo die Implementierung wirklich gruselig war. Das hat das aufgedeckt und dafür gesorgt, dass die jetzt eine bessere Finanzierung haben und dass auch viele Leute erst mal darauf geschaut haben. Weil dieser Open Souce-Gedanke, schauen nur genügend Augen darauf, findet man auch jeden Fehler, ist in der Theorie ganz schön, aber die Augen müssen auch erst einmal darauf schauen. Das hat halt vorher keiner getan.

Simon Kölsch: Genau. Ich glaube, das kann man einfach als so ein Pauschalargument erst einmal streichen. Es ist natürlich begrüßenswert, dass ich überhaupt erst einmal die Audit-Möglichkeit bekomme, aber nur weil Quellcode irgendwo in dem Repo liegt – und da haben wir ja nicht nur das als Beispiel, da gibt es ja Unmengen davon. Wir erinnern uns an den Gag mit dem Auskommentieren von Zufallszahlengeneratoren in Debian-Packages und was es da alles gab. Das heißt nicht, dass das dann irgendwie direkt auch jemand sieht oder da auch irgendwie gereviewt wird. Und dazu kommt wahrscheinlich einfach noch der Faktor, dass es mit den Finanzierungsmodellen bei Open Source einfach schwierig ist, dass da viel in der Freizeit passiert und dass es dann auch einfach nicht möglich ist, so ein dichtes Review zu fahren oder die ganze Zeit Peer-Reviews zu machen, wenn da einfach nicht so viele Leute für die Library überhaupt entwickeln. Und gerade bei OpenSSL ist es wahrscheinlich eine sehr, sehr, sehr lange Liste an Projekten, Firmen, Produkten, die die Library nutzen. Wenn man aber sieht – ich erinnere mich da auch noch an so Spendenaktionen für das Projekt und für den Entwickler – da ist es nicht ganz so einfach. Und von Libraries, die sich gar nicht so breit im Einsatz befinden, darüber braucht man, glaube ich, gar nicht anfangen zu diskutieren.

Christoph Iserlohn: Was ich da erwähnenswert finde, ist ja, dass das für ungefähr 80 Prozent der Sicherheit im Internet gesorgt hat, von der Verbreitung von OpenSSL her, und dann der Zustand so schlecht war, dass das irgendwie keinem aufgefallen ist. Also wenn das stimmen sollte, dass darauf so viele schauen, dann hätte ich ja erwartet, dass gerade da, bei so einer super kritischen Infrastruktur, dass das da passiert. Dass nicht irgendwie immer das Hinz und Kunz-Open Source-Projekt irgendwie ein Audit bekommt, das ist klar. Dass es ausgerechnet da passiert, sozusagen vom Herzen der Sicherheit im Internet, das hat mich damals doch schon sehr verwundert.

Simon Kölsch: Ja, man kann ja dann versuchen, da irgendetwas rein zu “geheimnissen” oder so, muss aber dann mal ganz ehrlich sagen die ganzen staatlichen Akteure oder Dienste oder was auch immer da sich noch so im Internet manchmal noch herumtreibt, die nutzen das ja auch alle. Es ist nicht so, dass das irgendwie nur End-User oder so betroffen hat, sondern ich möchte gar nicht wissen, wie viele staatliche Stellen noch nicht gepatcht geupdatet sind. Für die ist das genauso problematisch.

Christoph Iserlohn: Absolut. Aber die gute Nachricht ist: Jetzt ist OpenSSL, jedenfalls technisch gesehen, in einem deutlich besseren Zustand. Es gibt da immer noch Probleme. Zum Beispiel ist die API – sagen wir mal so – suboptimal, aber es hat jetzt auch diverse Audits hinter sich, die finanziert wurden. Der Code wurde auch groß bereinigt, es ist schon deutlich besser geworden.

Simon Kölsch: Gibt es denn erwähnenswerte Alternativen? Also OpenSSL ist ja so ein bisschen schon fast de facto-Standard. Gibt es irgendetwas, was man da noch erwähnen sollte an Alternativprojekten oder würde man am Ende bei OpenSSL landen?

Christoph Iserlohn: Das kann man nicht ganz pauschal sagen. Es gibt Alternativen, sowohl Open Source als auch kommerziell. Die wahrscheinlich bekannteste Open Source-Alternative ist GnuTLS, aus dem GNU-Projekt hervorgegangen. Da haben wir halt das Problem, dass das unter einer GPL-Lizenz ist und dass das für viele kommerzielle Einheiten, die Software zwar benutzen, aber dann eher mit einer MIT- oder Apache-License und nicht mit einer Gnu-License. Was es noch gibt, das sind kommerzielle Sachen. Es gibt wolfSSL, die gibt es, glaube ich, unter GNU und einer kommerziellen Variante…

Simon Kölsch: Wir könnten Werbeplakate schalten, Eberhard würde wolfTLS nutzen.

Christoph Iserlohn: Vielleicht. Auf jeden Fall zielt das so ein bisschen mehr auf den Embedded-Bereich ab. Es gibt Mbed TLS, früher einmal unter dem Namen PolarSSL bekannt, die auch kommerziell arbeiten und auch auf den Embedded-Bereich zielen. Das heißt, das sind sehr kompakte Implementierungen. Dann gibt es noch NSS, die Network Security Services. Das ist das, was von Netscape damals ausgehend SSL zum ersten Mal implementiert hatte und jetzt aber immer noch in der Fortentwicklung in Mozilla zu finden ist. Wobei das eigentlich nur in Mozilla zu finden ist. Also nicht weiter in anderen Projekten, was wahrscheinlich daran liegt, dass man es da nicht gut herauslösen kann als eigenes Projekt oder als Library. Erwähnenswert ist auch noch Schannel. Das ist die Microsoft-Implementierung in Windows. Und auf jeden Fall sollte man noch sagen, dass es von OpenSSL im Rahmen dieser Heartbleed-Geschichte auch Forks gab. Einmal LibreSSL, das wird von den OpenBSD-Leuten entwickelt, die ja eher auf Sicherheit achtgeben und die da sehr viel rausgeschmissen haben und sehr viel aufgeräumt haben, und noch BoringSSL. Das ist die Variante, die Google nutzt, die wahrscheinlich sehr gut ist, weil die viel Manpower haben, die aber nicht unbedingt so den typischen Open Source-Charakter haben. Wenn man auf deren Seite kommt, steht schon da, das soll man eigentlich nicht nutzen. Also die werden es nicht für andere pflegen, sondern nur für ihre internen Zwecke, also für den Chrome. Und daher ist das auch ein bisschen schwierig.

Simon Kölsch: Okay, aber so grundsätzlich kann man festhalten: Wir haben da eigentlich ein relativ diverses Ökosystem, was die Libraries angeht, die man da einsetzen kann?

Christoph Iserlohn: Ja, das haben wir auf jeden Fall. Wobei natürlich die Sache die ist: Das OpenSSL hat jetzt mit Heartbleed seine Katharsis erlebt. Die anderen sind nicht so viel in Benutzung. Ich bin mir nicht sicher, wie weit da der Stand ist. Okay, bei Mozilla, bei NSS, den Network Security Services, wird es wahrscheinlich besser aussehen. Die haben andere Gründe, warum es nicht genutzt wird, aber bei den anderen, GnuTLS, wolfSSL, Mbed, da weiß man auch nicht, ob die ihre Katharsis noch vor sich haben oder ob die wirklich gut sind.

Simon Kölsch: Das wäre zumindest ein Kriterium bei der Auswahl, wie sieht es denn mit Audits aus, was wurde da auditiert. Gibt es da überhaupt etwas zu dem Thema und was nicht?

Christoph Iserlohn: Was man dazu vielleicht auch noch sagen sollte und was ein gewisses Problem darstellt: Das sind alles, die ich jetzt genannt habe, C- bzw. C++- Libraries. Und das stellt natürlich ein Problem dar, wenn ich jetzt in anderen Programmiersprachen unterwegs bin und mir kein C-Binding einhandeln möchte. Und viele Sprachen haben das halt. Also Python und Ruby setzen zum Beispiel auf OpenSSL, für ihre TLS-Implementierungen. Es gibt zwei Ausnahmen, die ich erwähnenswert finde, das ist einmal Java, das hat eigene Implementierung in rein Java, und es gibt in Go auch eine reine Go-Implementierung, was in Sachen Portabilität, wie leicht kann ich das kompilieren und bauen und so, halt doch gewisse Vorteile gibt.

Simon Kölsch: Okay, gut. Ich nehme mit, das ist nicht ganz so trivial zu konfigurieren und je nachdem, was ich denn implementieren möchte, gibt es da noch die eine oder andere Bärenfalle, in die man tappen kann. Aber davon abgesehen klingt das ja alles ganz gut. Handele ich mir denn irgendwelche Nachteile ein, wenn ich TLS vorher nicht benutzt habe und das dann einsetzen möchte? Es gibt da ja immer Diskussionen um die Performance von dem Protokoll. Immer dann, wenn wir Zufall brauchen und Dinge verschlüsselt übertragen, kann das zumindest einen Effekt haben. Wie ist denn da der Stand aktuell?

Christoph Iserlohn: Ich würde es jetzt gar nicht als Nachteile bezeichnen, weil ich ja eigentlich dafür bin, dass wir eigentlich prinzipiell alles verschlüsseln. Da es zu TLS wenig Alternativen gibt, jedenfalls auf der Ebene, wo es arbeitet, würde ich das nicht als Nachteil sehen, sondern vielleicht sagen, dass man das nennt: Dinge, die man beachten sollte, wenn man dann ausrollt. Aber Performance ist ein gutes Stichwort. Als TLS aufkam in den 90ern, da war es noch so, dass das für die damalige Geschwindigkeit halt schon ein Problem war, dass es da zum Beispiel spezielle Beschleuniger-Hardware gab auf Servern, die das benutzten. Auf dem Client ist das meistens weniger ein Problem, weil er eine Verbindung hat oder lass es vier bis fünf sein. Aber so ein Server muss vielleicht 10000 oder mehr Verbindungen gleichzeitig annehmen und da für die Verschlüsselung sorgen. Da war das schon ein Problem. Das sollte heutzutage aber nicht mehr der Fall sein. Jeder Standard-Intel-Prozessor und auch die ARM-Prozessoren, die so auf der Server-Seite eingesetzt werden, haben spezielle Befehle, um Kryptographie zu beschleunigen, gerade AES zum Beispiel. Und auch die modernen Cipher, zum Beispiel AES und auch der ChaCha2020, ein andere Cipher, der aktuell ist und benutzt wird, der auch AEAD ist, der ist zum Beispiel darauf ausgelegt, dass man ihn sehr gut in Software implementieren kann und momentan auch schnell. Das heißt, für normale Server-Systeme ist das kein Problem mehr. Wenn man in den Embedded-Bereich kommt, dann kommt es darauf an, wie tief man geht. Auch Mikrocontroller haben zum Teil heute schon solche Hardwarebeschleunigung für AES mit dabei. Aber wenn man so einen acht Bit-Mikrocontroller hat, der hat das dann halt nicht mehr. Und da gibt es trotzdem Implementierungen, auch z.B. für AES, die noch relativ performant sind. Wo es dann schwieriger wird, ist bei der asymmetrischen Kryptographie, weil man da ja noch viel größere Längen hat, also RSA bei 4096 Bit einem acht Bit-Controller zu berechnen, ist schon schwierig. Elliptische Kurven sind dann halt etwas weniger, die haben vielleicht 256 Bit, da geht das gerade eben noch so. Es ist halt die Frage, wo setze ich solche Systeme ein? Müssen die dann verschlüsselt sprechen? Also setze ich die irgendwo draußen als Sensoren ein, dann sollten sie es vielleicht. Oder setze ich die im geschlossenen System ein und die Verbindung nach außen ist dann nur TLS-verschlüsselt und innerhalb arbeite ich dann halt ohne Verschlüsselung, weil ich sage, diesem System kann ich vertrauen, das ist vielleicht physisch abgeschlossen.

Simon Kölsch: Wenn wir uns da aber im Web-Umfeld bewegen, kann man wahrscheinlich festhalten, es gibt keine Ausrede mehr, was die Performance angeht. Testen sollte man das natürlich in jedem Fall, auch einfach um die eigene Konfiguration noch einmal zu überprüfen, aber was grundsätzlich Hardware- und CPU-Auslastung und Performance angeht, ist das pauschal für sich genommen eigentlich keine Ausrede mehr, nicht TLS zu sprechen.

Christoph Iserlohn: Also in dem Bereich, wo du gerade sagtest, so im Web-Umfeld, da schwingt das Pendel ja auch so ein bisschen rum. Früher hatte man vorne vielleicht ein System, das hat TLS gesprochen und man war dann in seinem eigenen Rechenzentrum und zu den Backend-Servern wurde dann eine normale TCP-Verbindung aufgebaut. Das heißt dann TLS-Offloading, also nur ganz vorne spricht TLS und danach untereinander sprechen die Systeme unverschlüsselt. Heutzutage sind ja immer mehr Systeme in der Cloud deployt, wo ich dann vielleicht nicht mehr das Vertrauen habe, weil es nicht meher mein eigenes Rechenzentrum ist, weil darin noch andere sein können in den Rechenzentren, weil ich auch vielleicht die Administration da nicht mehr unter Kontrolle hat, sodass es in modernen Architekturen auch immer mehr dazu kommt, dass die Systeme untereinander wieder TLS sprechen und es kein Offloading mehr gibt.

Simon Kölsch: Das heißt, ich erreiche aber auch nicht sofort Ende-zu-Ende-Security, nur weil irgendwo TLS dran steht, oder? Eigentlich schließt sich das dann ja schon fast aus, wenn ich an beliebiger Stelle theoretisch terminieren könnte.

Christoph Iserlohn: Ja, das ist ein Problem, das ist eine Transport-Verschlüsselung und nicht eine Payload-Verschlüsselung. Ich kenne nicht unbedingt die ganzen Systeme, die dazwischen geschaltet sind. Ob das nun irgendwie ein Frontend-Server ist und mit wem der dann im Backend spricht, das weiß ich nicht. Ich kann immer nur die Identität überprüfen mit dem Kommunikationspartner, mit dem ich Punkt-zu-Punkt-Verbindungen aufgemacht habe, und wenn der weiter mit anderen Systemen spricht, wo aber trotzdem meine Daten irgendwie weitergeleitet werden, dann hab ich darüber wenig Kontrolle.

Simon Kölsch: Okay. Habe ich denn, was das Ganze angeht, noch weitere Nachteile oder Dinge, die ich beachten sollte außer Performance-Themen?

Christoph Iserlohn: Also ich würde es, wie gesagt, immer noch nicht Nachteil nennen, aber was natürlich schwieriger ist, ist für die Entwicklung das ganze Set-up. Also wenn ich das lokal machen möchte, dann muss ich vielleicht die Identifizierung, also die Authentifizierung, ausschalten, weil ich da mit Test-Zertifikaten arbeiten muss oder ich muss bei den Entwicklern entsprechende Test-Zertifikate installiert haben. Oder ich mache lokal oder im Test überhaupt keine Verschlüsselung. Dann teste ich aber ja eigentlich ein anderes System als das, was dann live ist. Also für die Entwickler wird es auch manchmal noch schwierig. Genauso ist es natürlich schwierig, wenn ich dann eine Verschlüsselung habe, wenn ich dann etwas debuggen möchte, dann muss ich das ja auch wieder entschlüsseln können. Sonst könnte ich einfach z.B. einen Proxy dazwischen schalten und da vielleicht irgendetwas dumpen, das geht dann auch nicht mehr so leicht. Dann muss ich schauen, wie ich damit zurechtkomme. Da gibt es Möglichkeiten, da etwas zu machen, aber wenn ich kein TLS hätte, bräuchte ich mich darum erst gar nicht mehr zu kümmern.

Simon Kölsch: Gut. Was immer wieder ein Thema wird: Wir haben auf TLS immer in Kombination mit TCP geguckt. Wie sieht es denn eigentlich in der Zukunft aus? Konkret als Hinweis auf QUIC und HTTP/2 und HTTP/3, bei denen wir dann plötzlich UDP als Übertragungs-Protokoll haben. Wie sieht es da denn mit TLS aus? Kann ich TLS als Protokoll als solches darüber noch verwenden oder muss ich das entsprechend modifizieren?

Christoph Iserlohn: Für UDP gibt es bereits etwas, DTLS nennt sich das, das ist Datagram-TLS. Da gab es die erste Spezifikation schon 2006 und aktuell ist Version 1.2 auch schon sieben oder acht Jahre alt. Das ist eigentlich TLS, wo man sozusagen das Problem, worum sich vorher TCP gekümmert hat, noch einmal berücksichtigt. Ansonsten entspricht es dem normalen TLS von Verschlüsselung, Schlüsseltausch und Ähnlichem, also dem Handshake-Protokoll. Das ist gleich, aber es kümmert sich auch gleichzeitig noch darum, wenn Nachrichten verloren gehen, dass man die dann noch einmal sendet und die noch einmal angefordert werden. Das ist aber relativ selten im Einsatz. Es gibt so ein paar Anwendungen, zum Beispiel im SIP-Bereich. Also bei Voice over IP ist typischerweise ein UDP-Protokoll und SIP baut eine Session auf und da gibt es Verwendung von DTLS. Aber sonst ist das noch nicht so verbreitet. Du erwähntest gerade QUIC, was ja sozusagen der Unterbau von HTTP/3 wird und da wird auch auf UDP gesetzt anstatt auf TCP. Und die haben sich dazu entschlossen: Wir machen eigentlich TLS 1.3, aber dieser ganze Record-Layer, in dem die ganzen Nachrichten sind von TLS, den ersetzen wir durch QUIC und sorgen dafür, dass Nachrichten in der richtigen Reihenfolge ankommen und dass, wenn eine verloren geht, die wiederholt gesendet wird und so weiter. Das ist relativ praktisch, indem man sagt, okay, wir haben so ziemlich die gleichen Security-Properties wie TLS 1.3. Das wird für die Implementierer natürlich aber dann doch noch einmal ein großer Aufwand werden, weil man einen größeren Teil des Protokolls einfach untendrunter ersetzen muss und gleichzeitig vermischt man aber auch das Protokoll. Das ist jetzt keine besonders gute Trennung, wenn man nach OSI vorgehen würde, sondern gefühlt sind es drei oder vier Layer zusammen. Du hast halt UDP, machst darüber aber dann etwas, das eigentlich TCP macht, machst einen Teil TLS, also die Verschlüsselung, und machst auch noch die Applikation mit HTTP/3 darauf und das ist alles ein Protokoll.

Simon Kölsch: Streng genommen ist das alles in dem Application-Layer gelandet.

Christoph Iserlohn: Ja, eigentlich schon. Ich weiß noch nicht, ob ich das gut oder schlecht finden soll.

Simon Kölsch: Ich habe mir da auch noch nicht so richtig ein Urteil gebildet, ehrlich gesagt. Das wurde ja heiß diskutiert. Ich kann das auch alles nachzuvollziehen. Auf der anderen Seite ist das OSI-Schichten-Modell auch ein bisschen älter. Ich weiß nicht, wie konkret sich das wirklich an so einer Stelle anwenden lässt und ob das ein Vorteil ist, es anzuwenden, oder nicht. Um das pragmatisch anzugehen an der Stelle: Letztendlich ist die Entscheidung ja schon getroffen. Und wenn man mal ehrlich ist, muss man sagen, es gibt ja sowieso ganz viele anderen Stellen, wo Protokolle sehr leakey sind durch die Schichten selbst hindurch. Wir haben das eben, glaube ich, kurz erwähnt, wenn man das streng sieht, könnte man auch sagen, diese Virtual Server-Extension, bei der ich den Host-Namen mit übermittele, also im Prinzip das, was im HTTP-Protokoll der Host-Header ist, das ist ja eigentlich auch schon Leak durch die Schichten hindurch, wo mir HTTP in TLS als Extension leakt. Darüber kann man sicherlich geteilter Meinung sein.

Christoph Iserlohn: Genauso bei dem ALPN, was wir vorhin gesagt haben, bei dem ich schon mal sage, ich will übrigens HTTP/2 sprechen, damit man irgendwelche Round-Trips vermeidet. Das hat mit TLS ja erst mal nichts zu tun. Das nächste Protokoll darüber ist ja reine Optimierung, das leakt dann halt aber trotzdem durch. Ich bin auch noch nicht sicher bei der Bewertung. OSI ist natürlich ein schönes theoretisches Modell, das sich in der Praxis wahrscheinlich auch nicht bewährt, weil es wahrscheinlich zu sehr abstrahiert und zu viele praktische Probleme bildet. TCP ist ja auch schon eher zwei OSI-Layer, drei und vier, irgendwie zusammen. Bei QUIC sind es halt sehr viele. Wo ich ein bisschen unsicher bin, wie ich das bewerten soll, ist die Sache, dass das sehr viel durch große Player wie Google, Facebook und Co für deren Use Cases sehr optimiert wird und das so eine Komplexität erreicht, dass auch fast nur noch große Player in der Lage sind, das vernünftig zu implementieren. Da ist so etwas schön Geschichtes, bei dem ich mich nur um eine Schicht kümmern muss, vielleicht auch ein bisschen leichter, wenn man das als Open Source machen will, unbezahltes Open Source. Aber eine endgültige Meinung habe ich mir auch noch gar nicht gebildet.

Simon Kölsch: Okay. Aber das heißt, wir behalten auch TLS noch eine Weile? Das wird sich dadurch nicht ändern?

Christoph Iserlohn: Erst einmal nicht.

Simon Kölsch: Gut. Wie sieht es denn aus mit Werkzeugen? Jeder, der das mal debuggt hat, wird daran wahrscheinlich nicht direkt so viel Freude gehabt haben. Das ist immer, wenn Verschlüsselung im Spiel ist, ja auch noch einmal so eine Sache. Was gibt es da denn Erwähnenswertes?

Christoph Iserlohn: Vielleicht sollten wir erst einmal unterscheiden: Es gibt Werkzeuge, um sozusagen zu testen, wie gut das denn konfiguriert ist und ob man sicher ist gegen die bekannten Attacken. Und dann gibt es auch Werkzeuge dazu, um echtes Low Level-Debugging zu machen, was denn da über die Leitungen geht. Wenn wir mit dem Ersten anfangen: Wie gut ist denn mein SSL oder mein TLS konfiguriert? Am einfachsten ist es da, wenn man ein Online-Tool nimmt. Da gibt es verschiedene, Wormly, SSL Server Security Test. Und was ich immer sehr gerne benutze ist SSL Labs von Qualys. Da gebe ich die Domain ein und dann überprüft der eine ganze Menge Dinge: Welche TLS-Versionen sind noch erlaubt? Welche Verschlüsselungsalgorithmen erlaube ich? Bin ich gegen die verschiedenen Attacken abgesichert? Und dann gibt der einem eine schöne Note, A, B, C, D, E glaube ich sind die Wertungen, listet das alles auf, wo die Schwächen sind, was nicht so gut ist, und gibt auch direkt Hinweise, wie man das abstellen kann. Das ist ganz komfortabel und es ist leicht zu bedienen auch für Leute, die sich nicht auskennen, z.B. einfach nur ihren kleinen Server auf ihre Homepage irgendwo hosten und wissen möchten, ist das jetzt vernünftig konfiguriert? Wenn ich jetzt eine Infrastruktur testen möchte, dann habe ich vielleicht gar keine öffentlich IP-Adresse oder will die vielleicht auch gar nicht unbedingt testen, bei einer internen Infrastruktur.

Simon Kölsch: Genau. Ich kann ja durchaus im Backend Bereiche haben, zu denen ich mit so einem Web-Tool überhaupt keinen Zugang finde.

Christoph Iserlohn: Da gibt es dann halt Kommandozeilen-Tools, SSL Map, testssl.sh, mit Nmap kann man mit diversen Plug-ins etwas machen. Mein Lieblings-Tool dafür ist SSLyze. Die machen das ziemlich ähnlich wie SSL Labs. Sie schauen, was sind erlaubte Protokollversionen, Verschlüsselungsalgorithmen, welche Schwachstellen sind nicht abgedichtet und so weiter und geben einem dann so ein Textreport heraus. Was halt ganz gut ist, weil man das gut automatisieren kann.

Simon Kölsch: Man kann das integrieren in seine Landschaft.

Christoph Iserlohn: Genau. Das kann man zum Beispiel beim Deployment mitlaufen lassen, danach als Test und dann merkt man, wenn man etwas kaputt konfiguriert hat. Das ist ganz praktisch. Die erfordern dann halt ein bisschen mehr Kenntnisse, weil man denen eine ganze Anzahl von Parametern mitgeben kann. Die muss man auch erst einmal installiert bekommen, was heutzutage eigentlich ganz gut funktioniert, weil es dafür auch Docker-Images gibt, die schon vorkonfiguriert sind. Aber es ist ja auch nicht so einfach, wenn man alte Lücken testen will. Denn die neuen Libraries haben die ja irgendwie auch gefixt oder rausgeschmissen, die alten Cipher, und die will man ja trotzdem noch testen. Also braucht man zum Teil spezielle OpenSSL-Versionen oder selbst kompilierte.

Simon Kölsch: Die die älteren Versionen noch supporten dann an der Stelle?

Christoph Iserlohn: Ganz genau. Also zum Testen möchte ich das haben, aber auf der Server-Seite möchte ich das natürlich gar nicht erst hineinkompiliert haben. Von daher war das Set-up nicht immer so ganz einfach, mit Docker hat sich das zum Glück ein bisschen gelegt. Das ist um herauszubekommen, habe ich denn da etwas Vernünftiges gemacht. Wenn es jetzt nicht so klappt und ich brauche so ein Low Level-Debugging, dann benutze ich ja normalerweise so Tools wie Wireshark oder tcpdump, um mir dann anzuschauen, was denn da über die Leitung gelaufen ist. Das ist natürlich problematisch, wenn die verschlüsselt sind, dann funktioniert das nicht mehr so gut.

Simon Kölsch: Da sehe ich dann noch einen Teil vom Handshake, das war es dann aber, oder?

Christoph Iserlohn: Genau. Die eigentlichen Applikationsdaten sind dann verschlüsselt. Das ist erst einmal schlecht. Wenn ich da vom Browser aus etwas mache und eine Webseite teste, indem ich da herumklicke, dann gibt es noch Möglichkeiten, sowohl der Firefox- als auch der Chrome-Browser unterstützen das, dass man eine Environment-Variable setzt, das SSLKEYlOGFILE. Und da wird für jede Session der Key, mit dem die Applikationsdaten verschlüsselt sind, gedumpt. In Wireshark gibt es auch eine Option, wo man so etwas einsetzen kann, genau so einen Key. Das heißt, ich kann die wieder entschlüsseln. Wenn ich jetzt irgendwie Server-zu-Server-Verbindungen debuggen möchte mit Wireshark, dann wird es schon schwieriger. Dann muss ich halt sehen, mit welchem Server ich arbeite und ob ich da die Möglichkeit habe, Keys zu dumpen. Die meisten Server haben das erst einmal nicht unbedingt, da gibt es nicht die Möglichkeit, so eine env zu setzen, da muss man dann schon schauen. Vielleicht muss man da sogar zusätzlichen Code reinbringen, indem man sich in den Handshake mit reinsetzt. Die Möglichkeit gibt es bei einigen SSL-Bibliotheken schon, dass es so Callbacks gibt. Aber das wird dann deutlich komplizierter.

Simon Kölsch: Okay, das ist aber an der Stelle dann ein bisschen einfacher, wenn wir einen Browser im Spiel haben, weil der Client einfach dumpen kann. Auf einem Server muss man im Zweifel Code schreiben oder wenn man Pech hat, ist die Library so tief, dass man an die Stelle nicht so ganz fürs Debuggen herankommt. Aber gut, das ist ja auch der Sinn der Sache, dass die Verbindung verschlüsselt ist. Was ist denn eine gute Quelle für Konfigurationen? Das Tooling, das wir eben angesprochen haben, sagt mir ja schon, dass ist ein veraltetes Protokoll oder eine veraltete TLS-Version, der online Scanner von Qualys teilt mir das auch mit. Wo finde ich denn gute Richtlinien? Also mir fällt da spontan so etwas wie das NIST ein, die ja Empfehlungen abgeben, wo finde denn heraus, was für eine Cipher-Root ich verwenden sollte?

Christoph Iserlohn: NIST ist schon eine ganz gute Quelle. Das BSI bietet auch auf seiner Seite an, welche Cipher man benutzen sollte und welche nicht und welche TLS-Version man benutzen soll oder nicht. Was mir immer ganz gut hilft, ist: Es gibt eine Webseite, das sind die Cryptographic Right Answers. Die gehen jetzt nicht nur um TLS, sondern allgemein um Kryptografie und sagen aber immer sozusagen den aktuellsten Stand, was ich benutzen sollte. Von daher, das finde ich sehr gut. Die geben auch oft eine Begründung mit und schreiben auch in einer Weise, dass man nicht total tief in Kryptografie drin stehen muss. Ganz praktisch ist noch eine Seite, die ich empfehlen würde, die wir auch in den Shownotes verlinken, das ist die Cipherlist. Das ist eine Seite, da sind für Copy and Paste fertige Konfigurationen für ganz viele Programme, für den Apache httpd, für den nginx, für Lighthttpd, für haproxy, aber auch für Postfix und Exim, also für nicht Web-Server, sondern E-Mail-Server oder für ein Skript für einen Proxy, die eine aktuell gute Konfiguration haben, die ich dann einfach da hineinpasten kann, die so nach dem neuesten Stand das Vernünftige ist. Das ist für Leute, die dann auch weniger damit zu tun haben oder sich nicht in der Tiefe damit beschäftigen wollen, ein sehr guter Anlaufpunkt.

Simon Kölsch: Okay, es ist wichtig, dass ich eine bewusste Entscheidung treffe und nicht irgendwie den Default übernehme, sondern mir zumindest darüber klar werde, auch wenn ich die Details nicht genau nachvollziehen kann, aber dass ich mir zumindest klar werde, das ist die aktuelle Empfehlung und entweder nutzen wir die oder wir weichen bewusst davon ab. Und in so einem Fall, in dem wir bewusst davon abweichen, sollte man das natürlich auch dokumentieren.

Christoph Iserlohn: So ist das. Du sprichst eine Sache an, den Default. Leider ist es so, dass der Default meistens dafür ist, dass es sofort funktioniert und möglichst kompatibel mit allem ist, was im Endeffekt bedeutet, dass es wahrscheinlich die mit unsicherste Konfiguration ist, die man haben kann. Die einzige Ausnahme, die mir so spontan einfällt, ist das OpenBSD-Projekt, die alles im Default-Modus absichern und man alles explizit einschalten muss, um genau das zu erreichen, dass ich mich bewusst damit beschäftige, warum mache ich das denn jetzt. Was ich eigentlich für das bessere Vorgehen halte. Aber das hat sich noch nicht so durchgesetzt. Und wenn das so wäre, dann würde es wahrscheinlich bei vielen Leuten auch sehr viel Frust erzeugen, weil vieles nicht mehr auf Anhieb geht.

Simon Kölsch: Das kostet halt alles. Ich kaufe mir damit ein Stück weit Inkompatibilität, unter Umständen mit alten Clients, wie wir vorhin gesprochen haben, mit alten Browser-Versionen ein. Da muss ich mir dann überlegen, was ich denn davon nutzen möchte.

Christoph Iserlohn: Das ist immer eine Abwägungssache.

Simon Kölsch: Gut. Vielleicht eine Kleinigkeit, die gerade erwähnenswert ist: Wir zeichnen gerade im Juni 2020 auf, das heißt, COVID ist ein Thema. Da gab es ein paar Verzögerungen bei den Roll-outs von den Versionen. Magst du dazu ein bisschen was erzählen?

Christoph Iserlohn: Ja, wir hatten ja mal am Anfang gesagt, dass jetzt so TLS 1.2 der überwiegende Standard ist und TLS 1.3 langsam kommt. Und die Browser-Hersteller möchten das natürlich auch ein bisschen forcieren und hatten sich eigentlich entschlossen, alles unter TLS 1.2, also im konkreten Fall TLS 1.1, weil TLS 1.0 schon längere Zeit entfernt ist, auch aus den Browsern zu entfernen, dass sie das nicht mehr unterstützen. Jetzt war es aber so, dass durch COVID-19 herausgekommen ist, dass eine ganze Reihe von Regierungs-Webseiten oder von öffentlichen Diensten in allen möglichen Ländern oder vom Gesundheitswesen wichtige Informationen darüber bereitgestellt haben, über Hygieneregeln und -maßnahmen und so weiter und so fort und diese oft auch nur bis maximal TLS 1.1 zugänglich sind. Und dann haben sich Mozilla und Google entschieden, das Rauschmeißen von 1.1 noch einmal zu verschieben. Weil sie gesagt haben, dass es jetzt wichtiger ist, dass die Leute an diese Informationen herankommen und wir denen jetzt nicht in der Krisensituation aufbürden können, ihr müsst jetzt aber alle aber mal geschwind auf TLS 1.2 euer Deployment umstellen, sondern das hat sich dann dadurch jetzt erst einmal auf unbestimmte Zeit verzögert. Es gibt schon Pläne, wann es weitergehen soll, aber man muss halt die Lage abwarten, wie sich das so entwickelt. Und deshalb haben wir jetzt in den Browsern auch noch einmal längere Kompatibilität mit TLS 1 1.

Simon Kölsch: Okay. So Infrastruktur-Update-Projekte sind auch nicht die Projekte, die man im Moment dann angeht, wofür man Budget zurückstellt. Auch wenn das wünschenswert wäre. Aber dann ist es verständlich, dass das in Browsern ein Stück weit später ausgerollt wird.

Christoph Iserlohn: Man muss auch sehen: Das gilt ja weltweit. Ich glaube, bei uns ist das gar nicht so der Fall, jetzt hier in Deutschland, sondern das betrifft auch gerade ärmere Länder, Entwicklungsländer, die auch überhaupt kein Geld haben, solche Infrastrukturen dann umzustellen. Von daher, ich finde das auch begrüßenswert.

Simon Kölsch: Dann gibt es noch eine Version, die wir nicht erwähnt haben, das ist Enterprise TLS. Enterprise TLS ist eine Version, die kann ich anschalten, und dann ist alles besser, weil Enterprise ist gut.

Christoph Iserlohn: Das hast du schön zusammengefasst, denn wir wissen, immer wenn Enterprise da als Präfix oder auch als Suffix dran ist, dann wird es besser. ETLS darf man auch gar nicht mehr sagen, jetzt ist ETS. Das ist nicht mehr Enterprise TLS, sondern Enterprise Transport Security, ETS. Das kam auf, als TLS 1.3 standardisiert wurde. Über die Unterschiede von TLS 1.2 und 1.3 sollten wir gleich noch einmal sprechen. Aber erst einmal eTLS: Da hat ein Banken-Lobbyverband, BITS heißt der, sich eingeschaltet in die Standardisierung, weil TLS 1.3 alle Schlüsseltauschverfahren, die kein Perfect-Forward-Secrecy unterstützen, rauswerfen wollte und das dann auch getan hat. Das wollten die nicht. Und zwar weil es da Maschinen gibt, die jeden Traffic mitbekommen, jeden Traffic mit aufzeichnen, also die verschlüsselten Verbindung. Und die kennen halt alle den Private Key aus dem Zertifikat und können das entschlüsseln. Das wird damit begründet, dass man sich vor Malware schützen muss oder wenn Data Loss ist, muss man das irgendwie merken oder DDoS wird auch ins Feld geführt und alles mögliche kommt da herein, was für mich alles Scheinargumente sind, weil man sich vor den Sachen anders schützen kann. Und es wäre auch besser, sich anders davor zu schützen.

Simon Kölsch: Das sind auch die klassischen Web-Proxies, die man in großen Unternehmen hat, die dann eigentlich bei den eigenen Leuten Man-in-the-middle betreiben um zu monitoren. Darüber kann man sich natürlich lange streiten, was da eine sinnvolle Maßnahme ist oder ob man damit nicht Security auch schwächt.

Christoph Iserlohn: Absolut. Meines Erachtens schwächt das das nur. Aber sie haben es immerhin so weit geschafft, dass das Europäische Institut für Telekommunikationsnormen, ETSI, das standardisiert hat. Dafür gibt es einen Standard. Weil sie das bei TLS 1.3 nicht unterbekommen haben, weil die gesagt haben, okay, das schwächt unsere Security hier, das machen wir nicht, da haben sie es woanders standardisieren lassen. Da kam es dann auch zu diesem Namensstreit, weil die IETF gesagt hat, aber dann soll das nicht TLS heißen. Dann heißt es halt jetzt im Standard ETS. Von daher. Ich weiß nicht, wer es einsetzt, ich kenne auch keine Implementation dazu, aber da wird es bestimmt etwas geben. Was vielleicht ganz lustig ist am Rande, Fun-Fact ist, dass ETS als CVE im TLS vorhanden ist. CVE ist die Nummerierung der Schwachstellen, die offiziell gemeldet sind. Common Vulnerability and Exposures ist die Abkürzung. Und da wird das als CVE geführt.

Simon Kölsch: Zu Recht, würde ich behaupten. Okay, das ist aber auch etwas, was man einfach im Hinterkopf behalten sollte, wenn es in dem Projekt Schutzziele gibt, die man erreichen möchte und es gibt gleichzeitig ein non-functional Requirement, ETS oder eTLS in irgendeiner Art und Weise zu benutzen, oder das ist in irgendeiner Art und Weise involviert. Da sollte man zumindest mal hellhörig werden, ob das der geeignete Weg und die geeignete Protokollversion ist.

Christoph Iserlohn: Da sollte man auf jeden Fall die Ohren spitzen.

Simon Kölsch: Gut. Von meiner Seite her wären wir eigentlich jetzt am Ende von den Punkten, die wir so besprechen wollen. Hast du denn noch etwas, was du erwähnen möchtest?

Christoph Iserlohn: Ja, wie ich gerade sagte, ich würde gerne noch so ein bisschen darauf eingehen auf den Unterschied zwischen TLS 1.2 und 1.3, weil wir da jetzt gerade im Übergang sind. Wir hatten ganz am Anfang gesagt, dass der Übergang von 1.0 auf 1.1 sehr lange gedauert hat. Und ich würde gerne mal herausstellen, was hat sich geändert und warum sollte man dann vielleicht auch wirklich schneller auf TLS 1.3 umschwenken?

Simon Kölsch: Gerne.

Christoph Iserlohn: Also was hat sich geändert? Was ich schon gesagt habe: Man hat bei den Algorithmen aufgeräumt. Also alles, was unsicher ist, also zum heutigen Stand unsicher ist, wurde rausgeschmissen. Das heißt, es bleiben eigentlich nur noch sehr wenige Algorithmen übrig, die benutzt werden können und sollten. Was auch ganz gut ist, weil es die Konfiguration einfacher macht. Dann gibt es nur noch AEAD für die symmetrische Kryptographie. Das heißt, wir haben keine Integritätsprüfung mehr, die extern ist über einen MAC oder einen Hash-MAC, was gut ist, weil es alle diese Padding-Oracle-Angriffe dadurch nichtig macht. Für den Schlüsselaustausch ist, wie gerade im eTLS-Kontext erwähnt, nur noch Perfect-Forward-Secrecy möglich. Das heißt, auch Angreifer, die lange Jahre die Verbindung aufzeichnen, haben nichts mehr davon, was ganz gut ist. Das ist einfach die Sicherheit. Und zur Sicherheit gehört noch, im Handshake wird jetzt auch alles, was nach dem Server Hello kommt, schon verschlüsselt mit so einem Pre Key.

Simon Kölsch: Das heißt, Metadaten oder Ähnliches?

Christoph Iserlohn: Ein Teil der Metadaten. Es ist noch nicht alles. Im Client Hello steht ja auch schon einiges drin, zum Beispiel der Server, mit dem ich kommunizieren will. Es ist noch nicht alles verschlüsselt, daran arbeitet man auch mit weiteren Extensions, aber es ist schon besser. Also alles nach Server Hello ist in dem Fall verschlüsselt. Man kann auch kein Downgrade mehr machen und keinen neuen Cipher aushandeln, das sind alles Sicherheitsaspekte. Also es ist schon deutlich sicherer als TLS 1.2. Und zwar im Moment auch in einer Standard-Konfiguration, weil es momentan keine bekannten Schwachstellen gibt.

Simon Kölsch: Die anderen Teile sind einfach aus dem Protokoll komplett entfernt, das heißt, ich muss mich auch nicht darum kümmern, Dinge weg zu konfigurieren, sondern fahre da wahrscheinlich besser mit, wenn ich einfach die 1.3-Version einsetze?

Christoph Iserlohn: Auf jeden Fall. Und du bekommst auch eine Verbesserung der Latenz. Denn im Allgemeinen braucht man einen Round-Trip weniger als bei TLS 1.2. Und wenn man eine Session wieder aufnimmt – das geht auch, das geht auch schon bei 1.2. Dazu gibt es solche Session-IDs oder Session-Tickets. Also diese zwei Verfahren dafür, mit denen man alte Session wieder aufnehmen kann. Da braucht man nicht mehr den ganzen Handshake, nicht mehr alles aushandeln, sondern kann auf die gespeicherten Parameter für den Schlüssel und so weiter wieder zurückgreifen. Wenn man das hat, dann braucht man überhaupt keinen Round-Trip. Dann kann man schon in der ersten Nachricht auch Payload mitsenden. Das macht es eigentlich deutlich, deutlich schneller. Es funktioniert einfach so, dass der Client, anstatt auszuhandeln, welchen Schlüssel nehme ich denn, also welches Schlüsselverfahren nehmen wir denn jetzt und welchen Cipher nehmen wir jetzt und den danach ausrechnet und dann austauscht, sozusagen spekulativ schon einmal sagt, der Server wird wahrscheinlich dieses Verfahren unterstützen und da berechne ich jetzt schon mal was und schicke den schon im Client Hello mit. Und der Server kann den dann auswählen oder sagen, nein, probier noch einmal, das unterstütze ich nicht. Und der kann sogar mehr als einen Schlüssel mitschicken. Wenn er sagt, es gibt ja zwei Verfahren, die du unterstützt, dann sende ich für beide einen und du darfst dir einen auswählen. Das heißt, der Schlüsselaustausch ist deutlich früher abgeschlossen und es können schneller echte Applikationsdaten verschlüsselt über die Leitungen gehen. Das Latenzproblem hat man da schon sehr gut in den Griff bekommen, an der Stelle. Und das Letzte, was vielleicht noch erwähnenswert ist: Man hat sich viel Mühe gegeben kompatibel zu sein. Weil sich jetzt der Handshake und so geändert hat, haben wir bei den ersten Implementierungen herausbekommen, das funktioniert alles noch nicht so gut, wir müssen das abwärtskompatibel machen. Und das heißt an einigen Stellen tarnt sich TLS 1.3 als 1.2. Und zwar macht es das so, dass es eigentlich sagt, wir haben jetzt eine Session wieder aufgenommen und jetzt kommen schon die verschlüsselten Daten. In den verschlüsselten Daten steht aber eigentlich drin, ich bin 1.3 und das sind meine echten Daten, also es wir sozusagen gewrappt. Und die ganzen Middle-Boxen und so haben kein Problem mehr, das dann einfach durchzuleiten.

Simon Kölsch: Weil für sie sieht es von außen einfach wie verschlüsseltes TLS 1.2 aus?

Christoph Iserlohn: Es sieht erst einmal aus wie TLS 1.2, genau. Nur die Endpunkte, die dann wirklich alle Daten sehen, die können dann entsprechend sehen, das ist eigentlich 1.3. Das hat den Vorteil, es ist deutlich kompatibler. Es hat den Nachteil, die Implementierungskomplexität geht natürlich wieder nach oben. Aber so viele alte Zöpfe konnte man dann wohl doch nicht abschneiden.

Simon Kölsch: Okay. Hast du noch weitere Punkte, die dir spontan einfallen?

Christoph Iserlohn: Ich glaube, das war jetzt schon eine ganze Menge. Wir sind jetzt mal wesentlich länger gewesen als sonst die normalen INNOQ-Podcasts. Aber bei Security möchten wir manchmal auch ein bisschen mehr besprechen und nicht nur die Oberfläche berühren und ein bisschen daran kratzen, sondern da muss man vielleicht auch manchmal ein bisschen mehr Wissen haben, um das zu verstehen. Und dann wollen wir mal hoffen, dass unsere Hörer und Hörerinnen das genauso sehen.

Simon Kölsch: Dass sie noch dabei sind. Genau, als Hinweis in eigener Sache einfach: Wir werden den Security-Podcast noch nutzen, um einfach ein bisschen mit dem Format zu experimentieren, mit der Länge. Das ist eine lange Diskussion, wie lang ist der ideale Podcast? Und da gibt es einfach sehr unterschiedliche Hörgewohnheiten. Es gibt Leute, die packen das sehr dicht in ihren Tagesablauf auf dem Weg zur Arbeit oder Ähnliches und haben dann genau eine halbe Stunde, möchten das in einer halben Stunde hören und unterbrechen ungerne eine Episode und hören die später weiter, auch wenn das natürlich technisch möglich ist, es gibt ja auch Kapitelmarken und so weiter. Und da werden wir einfach mal schauen, wo wir uns einpendeln. Hier haben wir einfach die Möglichkeit, Dinge ein bisschen in der Tiefe zu besprechen. Und wahrscheinlich ist das für das Format ganz angemessen. Nichtsdestotrotz: Wenn Ihr Vorschläge, Kommentare, Hinweise, Themen habt, die ihr gerne sehen möchtet oder Ähnliches, das nehmen wir auch gerne. Einfach eine Mail an [email protected]. Da freuen wir uns auch einfach über Feedback. Gut, dann bedanke ich mich für das Gespräch. Und dann hören wir uns zur nächsten Folge wieder, wahrscheinlich mit dem Thema Certificate Authorities, Stichwort “Let’s encrypt” und wie man denn eigentlich dieses initiale Vertrauen herstellt.

Christoph Iserlohn: Das machen wir.

Simon Kölsch: Alles klar. Ciao.

Christoph Iserlohn: Ciao.