TLS richtig konfigurieren

Lisa:

Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Security Podcast. Heute habe ich Christoph Iserlohn zu Gast. Hallo!

Christoph:

Hallo Lisa!

Lisa:

Wir wollen heute nochmal über ‚TLS richtig konfigurieren‘ sprechen. Christoph, das Thema ‚TLS‘ gab es doch schonmal im Security Podcast, oder?

Christoph:

Ja, das war direkt eine der ersten Folgen. Deshalb ist es vielleicht komisch, dass wir jetzt nochmal drüber sprechen wollen über TLS, aber der Schwerpunkt wird ein ganz anderer sein. Damals hatte ich mit dem Simon darüber gesprochen, wie denn TLS überhaupt funktioniert, wie das entstanden ist, was es so für Neuigkeiten jeweils in den einzelnen Versionen gab und was es auch für Probleme gab, welche Angriffsmöglichkeiten es gegeben hat oder auch gibt. Und für die Konfiguration haben wir damals einfach nur auf eine Webseite verwiesen, wo man sich so ein bisschen copy und pasten kann. Das werden wir heute am Ende auch nochmal machen, als Tipp wo man sich gute Konfigurationen holen kann. Diesmal aber noch mit einer besseren Quelle als damals. Aber heute wollen wir einfach drüber sprechen: Was muss ich denn beachten bei der Konfiguration? Also es geht mehr in die Praxis.

Lisa:

Sehr schön! Was kann man denn bei TLS eigentlich alles konfigurieren?

Christoph:

Ja, da gibt es eine ganze Menge, was ich bei TLS konfigurieren kann. Also das erste ist erstmal die Protokollversion natürlich, die kann ich konfigurieren. Dann kann ich die Cipher Suite konfigurieren. Das sind eigentlich eine ganz Menge einzelne Konfigurationen, das sind so längere Strings, die eine ganze Menge Informationen beinhalten, die auch sehr unterschiedlich sein können. Auf die Details gehen wir dann gleich nochmal ein. Dann kann ich da zusätzlich noch zu konfigurieren, dieses Cipher Suite wird nämlich einmal vom Client geschickt und vom Server. Und zwar nicht nur eine, sondern auch noch direkt mehrere Cipher Suites, damit man aushandeln kann: Welche benutzen wir denn jetzt? Weil es können ja ganz verschiedene Clients an ganz beliebige Server rangehen und die haben sich nicht alle vorher auf eine geeinigt. Und man muss sich dann einigen und wenn es mehrere Kandidaten gibt und die Reihenfolge vielleicht nicht ganz gleich ist, muss man sich auch irgendwie einigen. Dann muss man natürlich seine Zertifikate konfigurieren. Das ist jetzt nicht direkt die TLS-Konfiguration, aber ist trotzdem wichtig. TLS geht halt nicht ohne Zertifikat, dann muss man dann halt auch schon darauf achten, was man da macht. Man kann die elliptischen Kurven konfigurieren, die benutzt werden beim Key exchange. Manchmal kann man das auch nicht, werden wir gleich hören. Dann kann man darüber reden, ob man Kompressionen benutzen sollte oder nicht. Das kann man auch konfigurieren. Dann gibt es die Möglichkeit der sogenannten Session Resumption. Was das nochmal genau ist, gehen wir gleich nochmal drauf ein, aber da gibt es auch mehrere Möglichkeiten, wie man das machen kann. Oder man kann es auch gar nicht machen, es gibt für beide gute Gründe. Und zu guter Letzt ein Thema, das auch nicht wieder ganz TLS ist, aber wahrscheinlich doch im Web ganz viel vorkommt ist, ob ich denn überhaupt noch dann HTTP konfigurieren soll oder nur noch HTTPS? Oder ob ich da einen redirect mache oder was auch immer. Also ist gibt eine ganze Menge Möglichkeiten, die man da konfigurieren kann und dadurch auch eine ganze Menge Möglichkeiten, was man falsch machen kann. Und vielleicht… Wir lernen heute, was man vielleicht besser nicht macht und was man besser macht.

Lisa:

Das klingt nach ganz schön vielen Themen! Dann würde ich sagen wir fangen mal an und gehen die mal der Reihe nach durch. Und du gibst mal gute Hinweise, gute Tipps und sagst, was sich dahinter verbirgt. Du hast, glaube ich, als erstes die Protokollversion erwähnt. Welche Protokollversionen gibt es denn? Und welche würde man wählen wollen? Und warum wählt man die, die man wählen möchte?

Christoph:

Also wir haben TLS gesagt… Konfiguration von TLS in dieser Folge. Es gibt ja auch noch SSL, sozusagen der Vorgänger. Wobei es eigentlich nur der Name der Vorgänger ist, sondern TLS… nach SSL 3.0 kam halt TLS 1.0 als Nachfolgeprotokoll. Wer da über die geschichtlichen Details was wissen will, der sollte nochmal in unsere erste Folge hören, da haben wir das schön aufgedröselt, warum es auch diesen Namenswechsel gab von SSL auf TLS. Und… Also aktuell, die aktuellste Version ist die Version 1.3. Und wenn die Software, die man benutzt, also zum Beispiel der Webserver, der NGINX oder Apache die unterstützt, sollte man die natürlich konfigurieren. Weil die extrem sicher ist. Also es gibt da bis jetzt keine bekannten Angriffe gegen und man kann die auch relativ… also eigentlich fast ohne Konfiguration der Cipher Suite sicher betreiben. Weil… Der einfache Grund dabei ist, dass man bei der Version 1.3 alle unsicheren Cipher Suites einfach alle rausgeschmissen hat. Und das heißt, man muss sie jetzt nicht nochmal… müsste die nicht unbedingt nochmal extra konfigurieren. Aber da noch nicht längst alle TLS 1.3 sprechen, muss man auch auf jeden Fall TLS 1.2 konfigurieren dabei. Und da gibt es halt, das ist diese Protokollversion ist eigentlich schon ziemlich alt und da gibt es dann halt noch eine ganze Reihe von Cipher Suites, die nicht sicher sind und die muss man dann rauskonfigurieren, dass die nicht benutzt werden. Und TLS 1.1 sollte… Also TLS 1.1 und 1.0 sind abgekündigt, also die gelten als obsolet. Die sollte man eigentlich gar nicht mehr konfigurieren. Es gibt wie immer Ausnahmen, wo man das vielleicht auch doch benutzen sollte, beziehungsweise eher benutzen muss. Wenn man zum Beispiel Clients hat, die kein TLS 1.2 sprechen. Das hört sich jetzt komisch an, wieso kann man kein TLS 1.2 sprechen? Aber das ist halt öfter nochmal so, gerade im Umfeld wenn man mit irgendwelchen embedded Systemen arbeitet und die die Clients sind und die nicht so oft Softwareupdates erfahren oder die vielleicht auch so einen… wo es keine Implementierung für diesen TLS 1.2 Stack gibt und die dann immer noch im Betrieb sind. Also so ein embedded System, also Hardware, ist ja meistens deutlich länger im Betrieb. Das sind dann nicht so die Software-Lebenszyklen, sondern da spricht man dann vielleicht eher von Jahrzehnten zum Teil. Und die können das dann manchmal nicht und da muss man eventuell auch noch TLS 1.1 unterstützten. Wenn ich jetzt aber sage, ich habe jetzt… betreibe jetzt einmal wahrscheinlich den üblichsten Anwendungsfall, irgendeine Webanwendung dabei, wo der Client jetzt vielleicht der Browser ist, dann gibt es keinen Grund auf weniger als 1.2 zu setzen. Nur 1.3 sollte man auch nicht machen, weil selbst wenn es der Browser ist, heißt es nicht, dass alle Browser schon auch 1.3 unterstützen. Gerade wenn man ein älteres Android hat, was vielleicht auch keine Softwareupdates mehr bekommt, dann muss ich auf jeden Fall auch noch 1.2 unterstützen oder mir natürlich ein neues Android-Phone kaufen. Oder egal welche andere Hardware, wenn sie keine Updates mehr bekommt, ist es wahrscheinlich immer ein Sicherheitsrisiko. Aber das ist ein anderes Thema.

Lisa:

Du hast jetzt eben das Wort Cipher Suite schon häufiger gesagt. Sind das diese verrückt kryptischen Strings in der Serverkonfiguration, die irgendwie so tls_ecdhe_ und so weiter sind? Verbirgt sich das dahinter?

Christoph:

Ganz genau! Also das ist zwar eigentlich so ein Konfigurationsparameter, aber da verbergen sich mehrere Arten von Konfiguration dahinter. Also wir können den ja mal aufdröseln. Also am Anfang kommt meistens dieses ‚tls‘, muss aber nicht überall. Das kommt auch auf den Server an, manche brauchen dieses Präfix nicht. Es gibt auch so eine Registry dafür, da sind alle Konfigurationen aufgeführt. Ich glaube da sind irgendwie… Also das sind auf jeden Fall über hundert Stück, die es da gibt. Also muss man aufpassen, was man da alles nimmt und was nicht. Gut, der erste Parameter nach dem ‚tls‘ und der erste wirkliche Parameter dann ist das Verfahren zum Key-exchange, beziehungsweise agreement. Das könnte zum Beispiel dann Diffie-Hellman sein. Also… Oder sollte auf jeden Fall ein Diffie-Hellman basiertes Verfahren sein, damit man perfect forward secrecy erreicht. Und da gibt’s dann halt verschiedene. Es gibt dann halt ‚dh‘, das ist ein einfaches Diffie-Hellman mit statischen Parametern. Also die Parameter für dieses Diffie-Hellman Verfahren sind dann fest codiert. Es gibt ‚dhe‘, das ist Diffie-Hellman Ephemeral. Das heißt, da werden die Parameter für diesen Diffie-Hellman Schlüsselaustausch immer wieder neu ausgehandelt. Und es gibt beide Varianten nochmal mit einem ‚ec‘ davor, also ‚ecdh‘ und ‚ecdhe‘. Das ist dann Elliptic-curve Diffie-Hellman. Und… Also man sollte auf jeden Fall das dhe-Verfahren nehmen, damit man perfect forward secrecy erreicht und, wenn man kann, sollte man vielleicht auch auf Elliptic-curve, also auf elliptische Kurven setzen, weil die dann sozusagen dem aktuellen Stand der Technik entsprechen. Es gibt auch noch andere Verfahren, zum Beispiel kann man die auch natürlich einfach… also keinen, also den Schlüssel einfach verschlüsseln und dann rüberschicken mit dem RSA-Algorithmus zum Beispiel. Das würde dann aber keine perfect forward secrecy mehr haben. Und deshalb sollte man das nicht nehmen und immer irgendwie auf Diffie-Hellman bauen. Hier muss man dann ein bisschen aufpassen, dieser Schlüsselaustausch, den gibt es bei TLS 1.3 nicht mehr in diesen Strings drinnen. Da kann man den nicht mehr konfigurieren. Das sind alles Verfahren, die dann genutzt werden, die perfect forward secrecy unterstützen, aber die braucht man dann nicht mehr extra konfigurieren. Deshalb fällt dieser Parameter bei meiner 1.3er Konfiguration raus. Vielleicht sollten wir nochmal kurz erklären, was perfect forward secrecy ist. Das haben wir zwar auch schon nochmal in der TLS, in der ersten Folge zu TLS gemacht, aber das passt hier ganz gut, weil ich das jetzt auch schon, glaube ich, fünf Mal erwähnt habe. Also wir stellen uns vor, dass der Internetverkehr abgehört wird und dauerhaft gespeichert wird. Das machen Organisationen, die oft drei Buchstaben haben und sehr viel im Geheimen arbeiten. Und wenn die Daten mit TLS verschlüsselt sind, können die erstmal nichts damit anfangen. Aber wenn ich nachträglich an den Schlüssel drankomme, könnte ich das ja wieder entschlüsseln. Und dazu könnte man zum Beispiel versuchen, den Server zu knacken und den Schlüssel da zu entwenden. Und deshalb ist das nicht so gut, wenn der Schlüssel einmal schon sozusagen am Anfang über die Leitung geht und nur mit diesem symmetrischen… mit dem asymmetrischen Schlüssel des Servers, mit dem RSA-Schlüssel verschlüsselt wurde. Um das zu verhindern gibt es halt Verfahren wie Diffie-Hellman, da geht dieser Schlüssel nicht über die Leitung, sondern da einigen sich Client und Server auf einen Schlüssel, ohne dass sie komplett alle Daten austauschen müssen dafür. Es gibt da so ein schönes Video, wo das schön mit Farbmischungen erklärt wird, das werden wir nochmal verlinken. Aber das führt dazu, dass man, wenn die Drei-Buchstaben-Organisation den Server dann mal aufmacht und da an den Schlüssel drankommen würde, den asymmetrischen, trotzdem nicht die gespeicherte Kommunikation wieder nachträglich entschlüsseln kann. Weil nachdem so eine TLS-Verbindung dann aufgehört hat, also beendet wurde, dann können Server diesen Schlüssel, der für diese Verbindung benutzt wurde, einfach wegschmeißen. Genau, und das ist auf jeden Fall ein Sicherheitsmerkmal, was man eigentlich haben will und deshalb hat TLS 1.3 auch nur noch Verfahren, die perfect forward secrecy unterstützen und deshalb wird man das auch gar nicht mehr einzeln konfigurieren. So, der zweite Parameter in dem Beispiel jetzt, wir hatten ‚ecdhe‘ gesagt, oder hattest du gesagt und dann kommen zum Beispiel ‚rsa‘. Damit wird konfiguriert, wie denn der Schlüsselaustausch signiert wird. Also es ist ja ganz gut, wenn ich da einen geheimen Schlüssel bekomme, ich muss ja auch wissen, dass ich das von der richtigen Quelle bekomme. Also dass man so eine machine in the middle attack verhindert. Dann wird der mit dem Schlüssel des Servers halt nochmal signiert. Und dann kann ich halt RSA nehmen, das ist so das typischer Verfahren oder ich kann auch ein Verfahren nehmen, was auf elliptische Kurven basiert. Zum Beispiel dann ‚ecdsa‘ wird das heißen und damit wird dieser Schlüsselaustausch signiert. Also die beiden brauche ich auch immer zusammen. Also ich brauche das Verfahren ‚wie tausche ich den Schlüssel aus?‘ und das zweite ‚wie stelle ich die Authentication damit klar?‘, also wie bringe ich eine Signatur darauf an? Und deshalb fehlt dieser Parameter dann auch bei 1.3, weil das halt schon außerhalb dieser Cipher Suite, sondern direkt auf der Protokollebene geregelt ist. Diese beiden Parameter entfallen dann. So, danach kommt der Teil, der bestimmt, welcher Cipher denn benutzt wird. Also zum Beispiel ‚aes‘ oder ‚rc4‘ oder ‚des‘. Wobei von denen drei, die ich jetzt genannt hatte, nur AES sicher ist. Also der Cipher und ein Cipher alleine nützt nichts, weil die brauchen immer irgendeinen Cipher Mode. Da verweise ich vielleicht auch nochmal auf die Kryptographie-Folge, die wir schonmal hatten. Das heißt, ich muss auch irgendwie sagen, wie wird der denn sozusagen betrieben und dazu kommen dann die nächsten Teile des Strings. Das ist jetzt vielleicht mal, wir können sagen ‚aes‘ und dann kommen ‚256-gcm‘. 256 ist die Schlüssellänge und GCM ist der Modus, der Galois Chaining Mode? Nein. Mir ist es gerade entfallen. Galois-Counter Mode heißt das. Es gibt dann auch noch den CBC zum Beispiel Modus oder den ECB. ECB ist Electronic Code Book, der ist extrem unsicher, den sollte man nicht nehmen. Und da kann man sich dann schön einen konfigurieren, da den entsprechenden Cipher. AES ist jetzt so ein Block Cipher, man könnte einen Stream Cipher nehmen, chacha20-poly1305 ist zum Beispiel einer, der sicher ist und auch in TLS 1.3 noch erlaubt ist. Also als sicher definiert wurde und ja, der wird da definiert. Worauf man da achten sollte ist, dass man einen AEAD-Cipher nimmt, also einer, der die Authentifizierung und die Verschlüsselung in einem vornimmt. Über Details von AEAD verweise ich auch nochmal auf unsere Krypto-Folge. In TLS 1.3 sind zum Beispiel nur noch diese AEAD-Cipher erlaubt, in TLS 1.2 sind auch noch andere Verfahren erlaubt, die das nicht machen. Und deshalb gibt es noch einen letzten Parameter. Der ist ein bisschen verwirrend, weil der in 1.2 und 1.3 zwar die selben Werte annehmen kann, aber eine andere Funktion hat. Da steht dann meistens sowas wie ‚md5-sha-256‘,‘sha-384‘, also kryptographische Hashfunktionen. Und in 1.2 hat der die Funktion, dass man damit diese Message-Authentication macht, die man beim AEAD-Cipher gar nicht mehr braucht. Und in 1.3 ist der halt dafür da, dass TLS eine sogenannte pseudorandom function braucht und da nimmt man normalerweise auch solche kryptographischen Hashfunktionen und deshalb sind die zwar gleich, haben aber eine ganz andere Funktion, wozu die innerhalb des Protokolls genutzt werden. Aber da ist vielleicht wichtig, dass man natürlich eine kryptographische Hashfunktion nimmt, die noch als sicher eingestuft wird und nicht zum Beispiel MD5, das ja als gebrochen gilt. Sondern dann, wie gesagt, SHA-256 oder SHA-384 zum Beispiel. Und dann hat man da so einen schönen langen String und normalerweise benutzt man dann… konfiguriert man dann nicht nur einen dieser Strings, sondern direkt mehrere. Weil diese Cipher Suites halt.. Also weil man durchaus mehrere Cipher Suites konfiguriert, weil der Client vielleicht gar nicht alles kann. Also ältere Browser können zum Beispiel nicht mit ECDSA, also Signaturen auf Basis von elliptischen Kurven, umgehen. Dann bräuchte ich zum Beispiel auch ein RSA oder neuere… ältere können vielleicht noch nicht den AES-GCM Modus. Und dann muss ich halt mehrere dieser String konfigurieren, die ich nutzen kann. Warum muss ich denn jetzt mehrere konfigurieren? Warum sucht der nicht einfach von allem, was ich kann sozusagen einen aus? Das Problem ist halt, bei TLS 1.2 sind jede Menge erlaubt, die heute nicht mehr als sicher gelten. Ich muss also genau sagen ‚die und die benutze ich und andere nicht‘. Bei 1.3 brauche ich das im Moment eigentlich nicht mehr machen, weil da sind auch nur vier oder fünf insgesamt erlaubt und die gelten alle als noch sicher. Trotzdem empfehlen manche natürlich davon auch nur drei bestimmte zu nehmen, dann deckt man eigentlich alle Clients ab und hat sozusagen auch noch die Dinge, die sozusagen noch einen Ticken sicherer sind, beziehungsweise als sicherer gelten. Also von daher kriegt man dann so eine schöne Reihe von Strings heraus. Genau. Also das steckt hinter dieser Cipher Suite. Das ist ein Parameter, der ganz viele Sachen steuert in dem und wahrscheinlich auch so der wichtigste Parameter in der ganzen TLS Konfiguration ist. Und da sollte man halt am besten keinen Fehler machen!

Lisa:

Aber den kann man sich ja auch kopieren, den muss sich ja nicht jedes Mal neu ausdenken.

Christoph:

Genau, da sollte man, wenn man eine sichere Liste hat, kopieren. Wir werden am Ende der Sendung auch nochmal eine Empfehlung geben, wo man aktuell sozusagen die beste copy and paste Vorlage dafür kriegt. Aber man muss halt auch… Ja, aber man muss halt auch immer, also bevor wir copy/paste machen, wir hätten ja auch nur darauf verlinken können und sagen: ‚Guck mal, da gibt es so ein bisschen Erklärung dazu‘, muss man halt auch immer sehen: in welchem Kontext ist man. Also zum Beispiel bei AES-Ciphern, die werden viel in Hardware unterstützt, da kann ich sagen: ‚Okay, dann unterstütze ich das eher mal, weil dann habe ich weniger Last.‘ Also und solche. Also muss man sich schon ein bisschen Gedanken machen, was man eigentlich alles unterstützen will. Also nur weil ich etwas theoretisch kann, muss ich das nicht unterstützen, auch wenn es sicher wäre. Wenn es dann zum Beispiel deutlich mehr Prozessorlast kostet, weil das keine Hardware-Unterstützung hat, dann sollte ich den Cipher vielleicht nicht unbedingt konfigurieren. Und von daher: Nicht nur einfach copy/paste, ein bisschen auch den Kontext berücksichtigen und die Erklärung dazu, warum was reingenommen wird. Weil copy/paste ist natürlich sehr allgemein gehalten. Also so der generische Use Case und wenn man den besser spezifizieren kann, sollte man dann auch gucken. Vielleicht strei… Also normalerweise heißt es dann: ‚Ich streiche noch mehr von den Ciphern.‘, nicht: ‚Ich pack noch welche dazu.‘

Lisa:

Okay. Genau, du hast schon gesagt, der Server hat auf jeden Fall eine Liste irgendwie, was er unterstützt und wie er das Ganze unterstützt und ich als Client muss mich jetzt irgendwie mit dem Server darauf einigen über welchen… also mit welchem Cipher wir arbeiten wollen. Wie funktioniert das? Und kann man das auch irgendwie festlegen?

Christoph:

Ja, man kann das bei den meisten TLS Konfigurationen, das kommt natürlich ganz auf das Programm an, was man nutzt. Also ob ich jetzt einen NGINX habe oder einen Apache oder ein Postfix oder irgendeine Programmiersprache, was weiß ich, in Go einfach einen TLS Client oder Server aufmache, kann man das mehr oder minder konfigurieren. Es ging jetzt darum, auf was einigt man sich, wenn man ganz viele hat? Also normalerweise ist es so, dass im Handshake, also der Client eine Verbindung zu einem Server aufbaut, schickt der halt eine Liste mit: Das kann ich. Und normalerweise ist die sortiert nach Präferenz. Und der Server macht das genauso und bei den meisten Servern kann man sich dann… kann man konfigurieren, ob man jetzt die Priorität vom Client oder die vom Server. Also man hat kein Problem, wenn an Position eins sozusagen dasselbe steht, dann braucht man sich nicht einigen. Aber wenn das sehr unterschiedlich ist, wenn man zum Beispiel im Server irgendwie auf Platz sechs hat von acht Cipher Suites, die man anbietet und das ist auch auf dem Client der Platz eins, dann muss man halt sehen: Okay, nehme ich den jetzt oder nehme ich jetzt einen, der beim Server höher priorisiert ist und die der Client auch unterstützt? Aber auf einen niedrigeren Listenplatz sozusagen. Und das kann man meistens festlegen und da muss man schauen, in welchem Kontext man sich befindet. Ich habe vorhin schonmal erwähnt, dass zum Beispiel AES-Cipher sehr viel Hardware-Unterstützungen mitbringen. Also allen aktuellen Intel chips und ARM chips und meistens sogar bei den embedded Geräten, haben eine Hardwarebeschleunigung AES. Also wäre es vielleicht ganz cool, wenn man AES benutzt. Und wenn ich jetzt zum Beispiel einen edge Server betreibe, irgendwie im CDN, und der kriegt ganz viel Traffic mit, dann muss ich natürlich auch schauen, dass ich vielleicht da die Last minimiere. Dann würde ich immer sagen: ‚Nehmt doch bitte den Server-Cipher zuerst.‘ Also die Priorität des Servers. Wenn ich das nicht habe und ich habe vielleicht einen selten besuchten, dann könnte ich auch sagen, ich bin freundlich zu meinen Clients. Weil die schicken das, was die vielleicht am Besten können. Also vielleicht haben die keine AES-Unterstützung und schicken dann irgendwie chacha20 mit als Cipher, wo es so gut wie nirgendwo Hardwareunterstützung gibt. Aber der sehr gut… also sehr schnell in Software implementiert werden kann. Und dann könnte ich sagen, ich nutze dann vielleicht eher den Client. Also in welchem Kontext bewege ich mich? Aber eins muss man beachten, wenn ich eine Konfiguration habe für auch sehr alte Clients, wir hatten ja vorhin gesagt: TLS 1.1 sollte man nicht erlauben, aber vielleicht muss man das manchmal machen, weil der Client sehr alt ist. Wenn ich sowas erlaube, sollte ich auf jeden Fall sagen, ich bevorzuge die Server-Ciphers, weil da kriege ich das Maximum an Sicherheit raus. Ich biete zwar relativ viel an, er sucht mir dann aber immer den sichersten raus. Also ich bevorzuge dann das, was der Server für am sichersten hält. Also da muss ich so ein bisschen den Kontext beachten. So Pi mal Daumen würde ich immer sagen, ich würde immer eher die Server-Ciphers präferieren dabei und eine Ausnahme machen, wenn der Kontext das hergibt, das man auch mal sagt: ‚Okay, jetzt machen wir den Client-Cipher.‘ Die Meinung ist nicht unumstritten, in dem, was wir später verlinken werden, ist es nämlich zum Beispiel so, dass auch an vielen Stellen die Clients-Ciphers… Also dass empfohlen wird die Client-Ciphers zuerst zu nehmen. Aber da, wie gesagt, sollte man den Kontext berücksichtigen.

Lisa:

Wir haben ganz am Anfang schon einmal gehört, dass natürlich TLS nicht ohne Zertifikate funktioniert und wenn ich mich jetzt so um ein Zertifikat kümmere, ist ja mein erster Schritt, dass ich es irgendwo bestellen muss. Worauf muss ich achten, wenn ich mein Zertifikat bestelle?

Christoph:

Da muss man eigentlich zwei Sachen beachten. Oder die jetzt wichtig sind für die Sicherheit und Konfiguration. Das ist erstmal: Welchen Schlüsseltyp habe ich denn darin? Also habe ich da einen RSA-Schlüssel drin oder einen für elliptische Kurven? Das bezieht sich dann darauf, wie kann ich denn die Signaturen machen? Also wenn ich eine RSA-Signatur machen will, dann brauche ich auch einen RSA-Schlüssel dafür. Wenn ich ein ECDSA, also ein auf elliptischen Kurven basierendes Signaturverfahren benutzen will, dann brauche ich einen, wo ein Schlüssel für elliptische Kurven drinnen ist. Also das ist eine Entscheidung, die ist entweder oder. Also ich kann kein Zertifikat haben, wo ich unbedingt beide Schlüsselarten sozusagen beliebig drin habe. Normalerweise habe ich da einen drin. Das muss ich beachten. Da bin ich mit RSA wahrscheinlich auf der sicheren Seite, weil das wird mehr unterstützt und ist jetzt auch kein unsicheres Verfahren. Hat natürlich etwas höhere, also etwas mehr Ansprüche an die Datengröße, die da benutzt wird. Also die elliptischen Kurven Verfahren verbrauchen da etwas weniger Speicher. Von daher: Ich bin unentschieden, um da eine konkrete Empfehlung zu geben. Es ist beides gut. Mit RSA ist man ein bisschen mehr auf der sicheren Seite was Kompatibilität mit allen möglichen Clients angeht. Wenn ich ein geschlossenes System habe wieder, was weiß ich, Intranet und sonst was irgendwie und die Clients sind unter Kontrolle, würde ich eher zu elliptischen Kurven raten. Und das zweite ist die Gültigkeitsdauer des Zertifikats. Die sollte man natürlich extrem kurz machen dabei, damit man kein Problem kriegt falls mal das irgendwie kompromittiert wird, dann ist eine kurze Gültigkeitsdauer da halt vorteilhaft. Also Kompromittierung sollte sowieso nicht passieren, aber man sollte auf alles gefasst sein. Und das geht auch ganz gut. Wenn man sich Zertifikate automatisch erstellen lässt so über Let’s Encrypt, da können wir auch nochmal auf die alte Folge verweisen, dann ist das auch nicht so ein Aufwand und die haben auch nur sehr kurzlebige Zertifikate. Während das, wenn ich ein Zertifikat habe, was ich woanders bestellt habe, dafür kann es auch Gründe geben, zum Beispiel wenn ich auch so ein extra validiertes Zertifikat brauche, dann sind die meistens länger gültig. Ein Jahr, zwei Jahre. Und das liegt unter anderem daran, weil das halt oft manueller Aufwand ist, den man nicht oft wiederholen möchte. Wenn sich zum Beispiel jemand da mit einem Ausweis authentifizieren muss, also eine extended validation für das Zertifikat haben will und weil man da auch bezahlen muss. Das wird sonst relativ teuer, wenn die sehr schnell auslaufen. Ich würde grundsätzlich eher dazu raten A) zu automatisieren, das ist weniger fehleranfällig und B) natürlich dadurch auch automatisch zur kürzeren Lebenszeit von Zertifikaten. Wobei man das halt auch nicht immer im Griff hat. Also wenn ich das bestelle, heißt das oft, dass ich das gar nicht angeben kann, sondern das annehmen muss, was der Anbieter einfach sagt. Aber da muss ich halt schauen. Wie gesagt, ich würde eher Automatisierung und kurzen Zertifikatsgültigkeitsdauern tendieren dabei. Genau. Und ja, das muss man beachten, wenn man sich so ein Zertifikat holt und wie gesagt, ein bisschen Gedanken vorher machen, will ich RSA oder elliptic curve für die Signatur haben? Ja. Zum Thema ‚Zertifikate‘ gibt es eins natürlich noch. Dass man noch gewisse Dinge konfigurierbar… Nein, die konfigurierbar sind. Also wenn wir jetzt das Zertifikat haben und dem Server sagen: ‚Hier liegt dein Zertifikat.‘ Dann kann ich sagen, ich liefere dieses Zertifikat aus oder ich liefere die ganze Zertifikatskette aus. Also mein Zertifikat ist signiert von einem anderen Zertifikat. Das wird nicht das Root-Zertifikat sein, weil das wahrscheinlich offline gelagert wird und nicht immer dafür rausgeholt wird, sondern ein Intermediate-Zertifikat. Manchmal sind auch mehrere Intermediates dabei und dann hat man halt eine Kette von meinem Serverzertifikat bis zum Root-Zertifikat. Wenn ich jetzt nur mein Zertifikat ausliefere, dann kann es sein, dass manche Clients sagen: ‚Die Intermediates, die kenne ich gar nicht. Ich lehne das ab!‘ Oder… Also das ist der schlechteste Fall, dann können die gar keine Verbindung aufbauen. Oder es kann sein, dass die sich das Zertifikat erstmal irgendwo runterladen müssen. Also die kennen das nicht, aber im Zertifikat ist immer auch die Stelle angegeben, wo kann ich das denn finden? Und dann laden sie sich ein Intermediate runter, gucken das nach, müssen davon das nächste Intermediate runterladen und so weiter und selber die Kette herstellen. Dann kann das natürlich die Latenz beim Verbindungsaufbau entsprechend erhöhen. Deshalb ist es immer wichtig, dass man, wenn man das Zertifikat konfiguriert, in dem Server eigentlich die gesamte Kette konfiguriert. Also man kann die komplett im Server hinterlegen und die auch dann immer alle übertragen. Dann kann der Client die ganze Kette validieren, ob er der vertraut und dann nur noch gucken: Hat er denn auch das Root-Zertifikat und vertraut der dem? Also das sollte man eigentlich immer machen, auch wenn das bedeutet, dass mehr Daten übertragen werden als manchmal nötig sind. Also manche Clients kennen dann vielleicht auch die Intermediates oder die… Genau, die Intermediates dazu und müssten das nicht machen. Aber allein da schon, dass manche Clients dann einfach sagen: ‚Ich lehne das ab‘ oder ‚Die Verbindung ist unsicher‘, würde ich auf jeden Fall immer die gesamte Kette konfigurieren und das heißt dann praktisch, dass in meinem Zertifikat dann noch die anderen entsprechend alle dranhängen, weil meistens ist das dann doch eine Datei, wo die alle einfach hintereinander geschrieben sind. Das sollte man konfigurieren und der letzte Punkt, der wichtig wäre vielleicht für die Zertifikatskonfiguration, ist das… oder das mit Zertifikaten zu tun haben, ist das OCSP stapling. OCSP ist das online certificate status protocol. Das sagt halt: Ist das Zertifikat noch gültig oder wurde das vielleicht zurückgezogen? Es gibt zwei Möglichkeiten, wie man sowas prüft. Das eine sind solche Listen, CLAs… CA… Ne, CRLs. CRLs sind das, die certificate revocation lists. Da stehen alle Zertifikate drauf, die eine CA vielleicht mal zurückgezogen hat. Oder dieses Onlineverfahren, da kann ich einfach sagen: Ist dieses Zertifikat noch gültig? Wenn man dieses Onlineverfahren benutzt, also OCSP, dann gibt es dabei zwei Probleme. Das erste ist, dieser OCSP-Responder nennt man das, der Server, der sagt: ‚Ist das Zertifikat gültig oder nicht?‘, der könnte ja mal offline sein, also nicht verfügbar. Das Problem ist, was mache ich denn dann, wenn er mir nicht antwortet? Da kann ich jetzt entweder sagen, ist mir jetzt egal temporär oder ich lehne die Verbindung ab. Das ist ein Problem. Und das zweite Problem ist ein Privacy Problem, damit offenbare ich diesem Server ja, wo ich hinwill. Wenn ich sage: ‚Hier, dieses Serverzertifikat, ist das noch gültig?‘, dann weiß der auch, wo ich hin surfen wollte. Das sollte nicht sein. Deshalb hatten die Browser das zum größten Teil auch abgeschaltet und nutzen eigene Listen, aber man kann das noch nutzen, um dieses OCSP stapling zu betreiben. Das ist eine Erweiterung von TLS, da fragt der Server selbst: ‚Ist mein Zertifikat noch gültig?‘ an diesen OCSP Server. Der kriegt davon eine Antwort und die Antwort wird einfach mit in die TLS-Verbindung gesteckt. Also das wird damit mitgesendet. Und der Client kann dann schauen, das ist halt signiert von so einem OCSP-Responder, dem vertraue ich und die Antwort ist jetzt erst eine Minute alt oder zwei, dann sage ich: ‚Ist okay.‘ Dann kann ich das benutzen, ohne irgendeinem OCSP-Responder zu sagen: Wohin wollte ich surfen? Und ich muss mich auch nicht so sehr drum kümmern, wie verfügbar die sind. Also dann können die vielleicht auch noch interne OCSP-Responder haben, die gar nicht am Netz, also am öffentlichen Netz hängen und da sich ein (32:56) holen. Also die können nicht einfach mal mit so einem DoS Angriff abgeschossen werden und dann macht das das leichter. Und für die Clients, die das unterstützt, ist das natürlich hervorragend. Und das andere ist, die Latenz wird auch geringer. Also wenn ich erstmal eine Verbindung aufbaue und dann erstmal einen anderen Server anfragen muss: ‚Ist das Zertifikat noch gültig?‘, oder direkt diese Antwort mitbekomme: ‚Ja, das ist in den letzten zwei Minuten noch gültig gewesen.‘, ist das für die Latenzen auch besser. Und da muss man dann auch noch zwei Sachen unterscheiden bei diesem OCSP stapling. Es gibt das Einfache, da wird diese Antwort von diesem OCSP-Responder nur für mein eigenes Zertifikat mitgeschickt und es gibt Multi-stapling. Da schicke ich das für jedes Zertifikat, das in der Kette drinnen ist mit. Weil, wenn der Client dann sagen würde: ‚Okay, deinem Zertifikat, dem glaube ich, dass das nicht zurückgezogen ist. Wie ist das denn mit dem Intermediate?‘ und dann müsste der da auch nochmal prüfen. Und dann kann ich mit diesem, Multi-stapling nennt sich das, halt auch direkt für die ganze Kette das mitschicken. Wenn das verfügbar ist, dann sollte man das konfigurieren. Das Problem ist, dieses Multi-stapling wird noch relativ selten unterstützt von den meisten Webservern jedenfalls und auch von den TLS-Bibliotheken. Das andere ist, natürlich ist es schwerer so einen Server zu konfigurieren, dass man sagt, der muss jetzt auch mit so einem OCSP-Responder sprechen. Also da muss der halt selber wieder mit einem anderen sprechen, da muss man vielleicht wieder irgendwelche Firewalls aufbohren, um zu sagen, der darf nicht nur Verbindungen annehmen, sondern aktiv auch einen an so ein OCSP machen oder nicht. Von daher muss man schauen. Wenn man zum Beispiel nur das öffentliche Web hat, nur die Standardbrowser unterstützen will, Chrome, Firefox, Safari, dann braucht man das nicht unbedingt. Weil die haben, wie gesagt, OCSP eigentlich alle ausgeschaltet oder nur noch als letztes Fallback. Sondern die benutzen halt eigene Mechanismen dafür, sprich die kriegen immer von… bei den jeweiligen Updates immer eine ganz große Liste von Zertifikaten, die gerade zurückgezogen sind. Also da muss man ein bisschen schauen. Ich würde immer sagen: Wenn es die Möglichkeit gibt, dann schaltet das einfach an. Das kann eigentlich wenig schaden, sondern nutzt nur den Clients, die OCSP nutzen. Die haben echt einen Vorteil dadurch.

Lisa:

Ich hätte eine kurze Frage zu dem Multi-stapling: Basiert das dann… Also arbeitet das OCSP Multi-stapling mit der konfigurierten Zertifikatskette oder schaut das selber die Zertifikate durch und bildet sich selber die Kette dadurch?

Christoph:

Das kann man nicht pauschal sagen, das kommt auf deine Serversoftware an. Normalerweise… also theoretisch könnte die einfach die Kette durchgehen und diese OCSP-Responder, die stehen in den Zertifikaten drinnen. Da steht: ‚Hier kannst du nachschauen! Da ist mein OCSP-Responder.‘ Dann könnten die das. Manche brauchen aber auch statische Konfigurationen, von daher: Hängt von deiner Software ab. Im Moment ist das aber die Mehrheit so… Die Mehrheit in dem Überblick, den ich habe, was gar nicht die Mehrheit sein muss, aber was ich so kenne, das ist eher so, dass A) Multi-stapling entweder gar nicht unterstützt wird oder dann nur, dass man statisch konfigurieren muss und wenig komfortabel ist. Aber da habe ich Hoffnung, dass das sich in Zukunft auch mal verbessert.

Lisa:

Okay, dann machen wir mal einen kleinen Themensprung. Weil neben perfect forward secrecy hast du ein anderes Wort noch unglaublich oft gesagt, und zwar elliptische Kurven. Eben gerade auch, wobei das jetzt nicht ganz in dem Zusammenhang steht, aber kann man am Server konfigurieren, welche Kurve verwendet werden soll?

Christoph:

Jein. Es kommt wieder auf deine Software an. Leider ist es auch da so, dass es eher selten konfigurierbar ist, obwohl das ein wichtiger Parameter ist. Also nochmal einen Schritt zurück, diese elliptischen… also Kryptographie auf elliptischen Kurven braucht halt als Parameter so eine sogenannte elliptische Kurve und davon gibt es ganz viele, die mal definiert wurden sind und auch untersucht worden sind. Warum müssen die definiert und untersucht werden, kann man nicht eine beliebige nehmen? Ne, es sind halt nicht alle sicher. Also um sicher Kryptographie damit zu betreiben müssen die halt ganz bestimmte Eigenschaften mitbringen und deshalb gibt es so Standardkurven, die definiert sind. Und die sind vor allem wichtig bei dem Signaturverfahren. Da muss man halt… Nicht bei dem Signaturverfahren, sondern bei dem Schlüsselaustausch. Also ECDHE, dem elliptic curve Diffie-Hellman. Da müssen sich der Server und der Client ja auch irgendwie auf eine Kurve einigen, die sie jetzt benutzen wollen für diesen Schlüsselaustausch zum Beispiel. Und da gibt es drei Stück dabei, die recht unaussprechliche Namen haben. Ich nenne jetzt nur eine, das ist prime256v1. Und das wäre gut, wenn man die auch alle konfigurieren könnte, das kann man aber fast nie. Was nicht so schlimm ist, wenn man vielleicht OpenSSL als unterliegende Crypto-Libary hat, weil die halt Kurven unterstützt, die sicher sind. Es wäre aber schöner, wenn man das einfach auch selber machen könnte. Wenn zum Beispiel für so ein Ding mal rauskommt, dass es unsicher ist, dass man die dann rauskonfigurieren kann und nicht irgendwie auf einen OpenSSL Patch warten muss dafür. Sondern, dass man es direkt per Konfiguration machen kann. Also von daher, ja, man kann es manchmal konfigurieren, sozusagen im Mainstream mehr nicht, aber schön wäre es. Und später gibt es halt auch… Also die Informationsquelle, die wir empfehlen, empfiehlt auch immer ganz bestimmte Kurven dabei. Unteranderem die prime256v1, die ich gerade genannt hatte, die anderen nenne ich jetzt nicht. Das ist immer schwierig mit der Aussprache sowas. Das ist nicht ganz Audio/Podcast geeignet.

Lisa:

Wie auch schon die Cipher Suites.

Christoph:

Ja, da hat man auch so einige Zungenbrecher dabei und viele Abkürzungen und so weiter und so fort.

Lisa:

Dann gehen wir mal zu was, was man ganz gut aussprechen kann, über. Als Informatiker möchte man ja immer möglichst wenig, ja, möglichst wenig große Dinge übers Netz schicken. Kann man den Payload komprimieren in TLS? Und falls ja, sollte man das tun?

Christoph:

Ja, man kann das tun. Nein, man kann das nicht tun. Also man konnte das tun, das ist jetzt aber bei dem TLS 1.3, ist das rausgeflogen. Und das ist rausgeflogen, weil es halt Angriffe da drauf gab. Die haben wir in der alten TLS-Folge mal ein bisschen besprochen, was es so an Angriffen gibt. Da kann man vielleicht auch nochmal reinhören. Auf jeden Fall, das ist eigentlich ein no-go. Die meisten Server haben das auch als Default sowieso nicht angeschaltet, aber wenn man das komprimieren kann, wenn es dafür einen Parameter gibt, würde ich das einfach immer sicherheitshalber auf ‚aus‘ setzen. Weil, das ist halt unsicher, von daher muss man damit leben, dass da ein bisschen mehr ist. Andererseits haben wir ja auch die Protokolle, die auf TLS aufsetzen dann öfter mal auch wieder Kompressionen dabei oder auch nicht. Also HTTP hat auch nochmal eine eigene Kompression. Ob das dann unter TLS noch mehr bringt, ist halt die Frage. Das ist halt… Also da ist die Antwort: Nein, mach das nicht! Man kann es, mach es aber nicht. Und wie gesagt, es wird verschwinden, aber bis TLS 1.2 komplett verschwunden ist, werden wir wahrscheinlich auch nochmal 10 Jahre drauf warten müssen. Von daher kann man es auch noch konfigurieren.

Lisa:

Ich vergesse einfach ganz schnell, dass es das überhaupt gibt und falls das irgendwo eingeschaltet ist, schalte ich das ganz schnell aus. Genau, wo könnten wir noch sparen? Wir haben eben schon über diesen kleinen Server-Handshake am Anfang gesprochen, dass sie sich erstmal einigen müssen, was sie überhaupt für ein Cipher sprechen wollen. Könnte man sich das nicht eigentlich merken, damit man nicht bei jedem Aufruf irgendwie wieder neu aushandeln muss?

Christoph]:

Ja, das ist eine gute Idee und das gibt es auch. Und dafür gibt es zwei Verfahren. Einmal IDs und Tickets. Und das gesamte nennt sich im TLS-Sprech ‚session resumption‘. Das heißt, diese Parameter und der aktuelle Verschlüsselungs-Key für die symmetrische Verschlüsselung, also für den AES-Cipher zum Beispiel und sowas, und den Initialisierungsfaktor, die kann man dann abspeichern und sagen: ‚Beim nächsten Mal benutzen wir die halt wieder.‘ Und das erste Verfahren, was es gab, sind die IDs. Da kriegt der Client am Anfang so einer Session eine ID mit und der Server merkt sich halt genau die ganzen Parameter. Und wenn er nochmal kommt, kann er die ID… der Client die ID angeben und dann kann man sozusagen direkt weitermachen an der Stelle, weil schon alles ausgehandelt ist. Und das Problem dabei ist… Beziehungsweise ich erkläre erstmal das andere Verfahren. Das andere sind Tickets. Da kriegt der Client sozusagen so eine Art binären blob und da drin sind verschlüsselt drin diese ganzen Parameter. Und zwar verschlüsselt mit einem Schlüssel des Servers. Das ist etwas besser das Verfahren. Warum ist das besser? Naja, bei diesen IDs, wenn der Server sich das alles merken muss, dann braucht der halt irgendwie einen Cache. Und wenn man mehr als einen Server hat, dann braucht der noch so einen geteilten Cache. Und einen geteilten Cache mit irgendwelchen sicherheitsrelevanten Informationen, also dem ganzen Schlüsselmaterial für ganze tausende von Sessions, die man in der Vergangenheit hatte, die muss man erstmal auch gut schützen. Und besonders wichtig ist die zu schützen, weil die nämlich auch perfect forward secrecy aushebeln. Also wir benutzen perfect forward secrecy, damit wir sagen können: Der Schlüssel wandert nicht über die Leitung, also nachträgliches Entschlüsseln ist nicht mehr möglich. Und nach der Session, also nach der Verbindung, wenn die abgebaut ist, werfen wir diese Schlüssel weg. Wenn ich jetzt unter der ID natürlich das ganze Material behalte, dann ist es halt so, wenn in der Zeit dann der Server aufgemacht wird von böswilligen Hackern oder Drei-Buchstaben-Organisationen, dann kommt man halt an diese Schlüssel wieder dran und könnte dann den Traffic auch wieder entschlüsseln, wenn die dann… wenn man das aufgezeichnet hat. Man kann da ein bisschen gegenarbeiten, indem man einfach sagt, die IDs wirft man und die Daten, die dahinter stehen, nach einer Zeit einfach weg. Also man muss sie nicht ewig behalten, sie haben nur eine gewisse Gültigkeit, aber dann hat man halt einen Zeitraum, sagen wir, der Cache ist vier Stunden, die Gültigkeit, dann ist man in den vier Stunden halt nicht mehr mit perfect forward secrecy ausgestattet. Diese Tickets sind eine leichte Verbesserung dabei, weil die jetzt erstmal beim Client lagern, nicht mehr so unbedingt beim Server. Aber die ginge auch schonmal über die Leitung und das heißt, wenn der Server geknackt wird und der Schlüssel den aufgemacht, dann ist das Ticket drüber gegangen und wenn man es aufgezeichnet hat, kann man das entschlüsseln. Das heißt viel Besserung ist da nicht. Das was besser ist, man braucht halt nicht mehr so einen Riesen Cache oder so, weil der Client die Information einfach speichert. Und der Server braucht nur seinen Schlüssel, den er ja so oder so hat. Also das ist normalerweise nicht der Schlüssel… also der öffentliche… der public key, den er im Zertifikat hat, sondern er erzeugt daraus immer nochmal einen neuen Schlüssel, damit er den auch oft rotieren kann. Genau, wie bei den IDs, den Zeitraum der Angreifbarkeit möglichst klein zu halten. Dann kann man den halt rotieren. Problem dabei: Viele Server lassen diese Rotation nicht zu. Also das kann man nicht konfigurieren. Es gibt so ein paar Ausnahmen, der Caddy Server, der in Go geschrieben ist, der macht das zum Beispiel sehr vorbildlich oder war der erste, der es vorbildlich gemacht hat, wo man sagen kann: Ich kann einen genauen Zeitraum bestimmen, wo ich diesen key rotieren kann. Und den Zeitraum dann ein wenig verkürze. Das andere ist, was bei Tickets nicht so gut ist, das verhindert zum Beispiel, dass ich effektiv AES-Schlüssel mit 256-Bit Länge benutze. Weil dieses Ticket hat fest kodiert, dass es AES 128 kodiert ist. Und wenn ich das Ticket knacken kann, also den 128 Schlüssel, dann komme ich auch an den anderen Schlüssel dran und dann nützt die 256-Bits nicht. Ich meine das ist jetzt ein ziemlicher edge case dabei und 128-Bit AES knackt man auch erstmal so nicht. Sondern ich mache den Server auf und dann kriege ich diesen Hauptschlüssel erstmal wahrscheinlich. Das ist der wahrscheinlichste Angriff. Aber nichtsdestotrotz sollte man das vielleicht mal erwähnen. Was ganz gut… Also eigentlich sollte man dann, wenn wir perfect forward secrecy haben, session resumption, sowohl mit IDs und Tickets, ausschalten. Da ist jetzt immer eine Abwägung bei, Performance oder Sicherheit? Da kommt es drauf an, was betreibe ich denn? Also wenn ich so einen anonymen Briefkasten für Whistleblower betreibe, dann sollte ich vielleicht nicht so viel Wert auf die anfängliche Latenz legen und auf die Performance dabei, sondern dann sollte ich die Sicherheit machen. Oder wenn ich Services für Leute anbiete in Diktaturen oder sowas, also die, die es nutzen können, da sollte ich da vielleicht vorsichtig sein. Wenn ich jetzt ein Webangebot mache, was relativ harmlos ist in dieser Hinsicht und trotzdem natürlich Verschlüsselung haben sollte, dann kann ich natürlich sagen, ich nehme solche Tickets und sage, ich mache die Schlüsselrotation dann in einen relativ kurzen Zeitraum. Also einen Tag, acht Stunden. Da kann ich, wenn man mehrmals am Tag da auf diese Webseite geht, vielleicht ordentlich Performance gewinnen. Also was weiß ich. Webseiten wie Google, Twitter oder so, die jeder von uns mehrfach pro Tag ansurft. Da gibt es bei jedem bestimmt 10, 20 Stück vielleicht, oder ich weiß nicht wie viele, aber einige, die man jeden Tag mehrfach ansurft. Da gewinnt man dann schon Performance. Wenn man das nicht macht, nicht jeder ist Google vom Traffic. Und wenn man eine Webseite betreibt, die jetzt eher selten angesurft wird, dann brauche ich das vielleicht auch nicht einschalten. Weil ich dann sagen kann, ich mache nur für 5% der Leute, die mich wirklich mehrmals pro Tag ansurfen, irgendeinen Performancegewinn, dann nehme ich halt lieber die Sicherheit. Was gut ist, in TLS 1.3 gibt es eine Verbesserung von dem Ganzen. Da gibt es für die Tickets jetzt noch ein weiteres Verfahren. Also es gibt das alte Verfahren und ein Neues, da kommt in diesem Tickettausch noch so ein Diffie-Hellman like rein. Die technischen Details sind sehr kompliziert, die lasse ich jetzt mal raus. Das Gute, damit ist perfect forward secrecy gewahrt, weil für das Ticket halt auch nicht alle Daten über die Leitung gegangen sind. Sondern bestimmte Dinge ausgehandelt wurden auf dem Client und auf dem Server, ohne dass die Daten ausgetauscht wurden. Und das ist halt natürlich entsprechend gut. Ja, von daher, bei TLS 1.3 kann man es halt, das wieder einschalten. Man muss nur ein bisschen aufpassen, das muss natürlich auch der Client entsprechend unterstützen und das ist nicht unbedingt der Fall. Deshalb sollte man da immer noch den Kontext sehen, welche Art von Webseite betreibe ich denn überhaupt? Und nur weil es sicher geht, heißt das nicht, dass die Clients unbedingt das auch nutzen. Und ich wüsste auch nicht irgendeine Serversoftware oder überhaupt eine TLS-Software, wo man das jetzt ausschalten kann, dass die alten Verfahren nicht genutzt werden können. Also so, dass man nur noch das 1.3er Secure-Verfahren benutzt. Wenn das geht, kann ich jetzt gar nicht sagen, dann kann man das natürlich problemlos machen.

Lisa:

Okay. Genau, du hast ja eben schon gesagt, Webseiten, wir haben hier über TLS gesprochen. Reicht das jetzt eigentlich, wenn ich nur noch HTTPS konfiguriere oder muss ich auch noch irgendwie mich um HTTP kümmern auf meinem Server?

Christoph:

Ja, kann man natürlich wieder nicht pauschal sagen. Also eigentlich, HTTP sollte man nicht mehr benutzen. Jetzt war es so, dass früher, wenn man irgendwo was zum Beispiel in seinem Browser eingegeben hat, immer HTTP benutzt wurde, wenn man nicht extra HTTPS eingegeben hat. Das hat sich jetzt zum Teil geändert. Ich glaube der Chrome macht es schon standardmäßig, dass er dann auf HTTPS geht. Machen aber halt nicht alle Clients. Deshalb gibt es mehrere Möglichkeiten dafür. Was man typischerweise macht, man konfiguriert HTTP ja so, dass man direkt ein Redirect auf HTTPS hat. Also dass man alle Seiten, die man ansurft, direkt über HTTP erstmal einen Redirect kriegen. Macht es ein bisschen besser, aber allerdings kann natürlich über unverschlüsselte Verbindungen dieser Redirect auch irgendwo andershin zum Beispiel umgelenkt werden oder so, weil da ja noch nichts verschlüsselt ist. Also das ist mehr so der Hinweis an den Client: ‚Nimm doch eigentlich lieber HTTPS‘, aber eigentlich sicher ist das nicht unbedingt. Von daher… Ja, also kann man machen. Wenn man HTTP nicht komplett ausschalten will oder kann, dann kann man diesen Redirect machen. Was man auch machen kann, ist einen strict transport security header mitsenden. Das ist jetzt auf der HTTP-Ebene, da kann man sagen: ‚Wenn du das nächste Mal kommst, dann bitte mit HTTPS und das gilt jetzt für Zeitraum XY‘, den kann man da konfigurieren. Und das verstehen eigentlich alle Standardbrowser und das heißt, man hat beim ersten Mal so ein gewisses Risiko, dass die Verbindung manipuliert wäre, weil es über HTTP geht, kriegt danach aber den strict transport security header gesendet und dann sollte das eigentlich entsprechend funktionieren. Beziehungsweise, wenn man direkt beim ersten Mal über HTTPS geht, kann man danach nicht aus Versehen wieder über HTTP ankommen, das ist ganz gut. Man kann sich auch bei den Browsern so Listen, auf jeden Fall der Chrome hat das, ich weiß nicht, ob die anderen das auch haben, da kann man, sozusagen, sich bewerben… nicht bewerben, aber kann man sagen: ‚Ich möchte da gerne aufgenommen werden‘, da weiß der Chrome schon von Anfang an, ich gehe da sowieso nur mit HTTPS drauf und das ist relativ groß. Da sind natürlich die eigenen Google Dienste, aber auch viele andere. Wie gesagt, da kann man auch sagen: ‚Ich möchte da auch gerne drauf!‘ Ich weiß nicht, wie lange das dauert bis man da drauf landet, aber dann kann das gar nicht mehr passieren. Aber diesen Header zu setzten ist ja auch kein Problem. In so einem Webserver, dass ein Header ergänzt wird, ist ja eigentlich Standard und das sollte man auf jeden Fall machen. Es gibt auch noch externe Plug-ins für die Browser, HTTPS Everywhere zum Beispiel, mit dem das auch… also der den Browser sozusagen sagt: ‚Du gehst immer über HTTPS‘. Sagen wir so, der Standardnutzer/-nutzerin, die haben dieses Plug-in wahrscheinlich nicht installiert. Deshalb ist es immer gut, diesen Header auch noch zu setzten. Ich hoffe, dass in Zukunft die Browser standardmäßig auf HTTPS gehen und man HTTP eingeben muss explizit, wenn man das machen will. Dann hat man dieses Problem weniger. Ich glaube, wenn das mal so weit ist, dann trauen sich auch mehr Webseiten einfach komplett HTTP einfach komplett abzuschalten. Also jetzt ist es manchmal noch so, die Angst, dass jemand der HTTP eingibt und sagt dann: ‚Wurde nicht gefunden‘, dass die dann nicht auf die Idee kommen HTTPS zu machen. Also und dass man dann eventuell vielleicht Kunden verliert oder so. Das ist glaube ich auch ein Grund, warum man das jetzt eigentlich noch nicht abschaltet.

Lisa:

Okay. Du hast jetzt schon unglaublich viele Konfigurationsmöglichkeiten beschrieben, gibt es denn darüber hinaus noch weitere Konfigurationsmöglichkeiten, die man sich vielleicht mal zu Gemüte führen sollte, wenn man Server konfiguriert?

Christoph:

Ja, also die wichtigsten haben wir glaube ich jetzt alle besprochen, die man sich anschauen sollte und die man, wenn es geht, explizit konfigurieren sollte. Es gibt noch was, was man immer oder was oft noch konfigurierbar ist. Das ist einmal, ob man Client-Zertifikate haben möchte und denen vertraut. Das ist ein use case, der gilt jetzt nicht für die Browser oder eher selten. Da geht das zwar auch, aber das ist relativ kompliziert für, ich sage jetzt wieder den ‚normalen‘ User/Userin in Anführungsstrichen, weil man dann erstmal so ein Client-Zertifikat in seinem Browser installieren muss. Und das mehr was ist für Leute, die sich vielleicht da besser auskennen. Es kann aber sein, zum Beispiel in so einer gemanagten Firmenumgebung, dass so ein… also wenn man so einen gemanagten Computer hat, wo die Software… wo man das nicht selber aufspielt, dass so ein Zertifikat da schon installiert wurde von den Admins und die kann man dann zur Authentifizierung nutzen. Dann braucht man vielleicht auch keine Passwörter mehr. Dann kann man schon direkt sehen, mit dem Zertifikat ist User XY gerade angekommen und macht einiges leichter. Dazu müssen die Server natürlich so konfiguriert werden, dass sie A) zum Beispiel immer ein Zertifikat verlangen und B) welchen Zertifikaten vertrauen sie denn? Oder meistens gibt man da nicht einfach alle Zertifikate an, weil das ist irgendwann unmanagebar, wenn man dann nachher, was weiß ich, irgendwie 2000 Zertifikate da konfigurieren müsste, sondern man gibt dann an, welcher CA vertraue ich denn? Wenn die von dieser CA signiert sind die Client-Zertifikate, dann kann ich denen auch vertrauen. So macht man das normalerweise. Wie gesagt, ist jetzt so für… sozusagen, wenn ich im normalen ‚www‘ bin, eigentlich kein use case, aber in firmeninternen Netzen schon durchaus mal gebräuchlich. Und das können auch die meisten Server, dass man diese Client-Zertifikate konfiguriert. Ja und noch was, was man machen kann, was jetzt auch eher unüblich ist, ist… also im ‚www‘-Umfeld unüblich ist, ist halt die Pre-shared Keys. Wir haben viel über Schlüsselaustausch und Schlüsselaustausch mit elliptischen Kurven und perfect forward secrecy, haben wir viel drüber geredet heute. Man kann natürlich auch sagen, die Schlüssel, die verteilen wir einfach schon vorher. Also ich kann sagen, es gibt einen Key und den kenne ich im Voraus, also er ist Pre-shared. Und da hat man dann vorne in diesem String nämlich das, auf einmal statt DHE, also Diffie-Hellman, hat man dann PSK, Pre-shared Key drin und dann bräuchte ich das nicht. Das ist so ein use case, wenn ich zum Beispiel irgendwie Hardware habe, die ich jetzt irgendwie an meinem Schreibtisch ein Kabel reinmache und dann eine Provisionierung vornehme, also eine Konfiguration. Also eine Software aufspiele und die konfiguriere, dann kann ich zum Beispiel sagen, für hier dieses spezielle Netz, wo in der Industrieanlage fünf Geräte miteinander sprechen, den gebe ich allen schon dem Key mit. Das hilft ein bisschen natürlich auch bei der Latenz, also wenn die Keys bekannt sind und der Schlüsselaustausch, der gerade viel Zeit kostet bei der TLS-Verbindung, das ist ja das Latenz-Problem, der Schlüsselaustausch. Wenn ich das nicht habe, ist natürlich auch ein Vorteil, ist aber eher so ein Rand-use case für den Bereich, wo wir uns so bewegen halt im Web. Aber kann man meistens auch noch machen. Von daher wenn man es mal gehört hat, weiß man jetzt wozu das gut ist.

Lisa:

Du hast jetzt… Genau, abschließend hätte ich noch eine Frage. Und zwar hast du mehrfach erwähnt, dass es eine Seite gibt, die wir auch verlinken wollen mit diesen Cipher Suites, wo die beschrieben sind. Ich würde gerne einmal schonmal wissen welche Seite das ist, wo es diese guten Konfigurationshinweise gibt?

Christoph:

Genau, das ist von Mozilla, Observatory heißt das. Also Observatory ist so ein… ist die Seite, damit kann man die Konfigurationen auch testen und die geben dann einem Tipps dazu. Und dazu gehört dann auch noch der SSL Configuration Generator. Da kann ich anklicken, ganz viel Software, was weiß ich. Ich kann den AWS Elastic Load Balancer, den Apache, den NGINX, den Postfix, die PostgreSQL, den HAProxy, MySQL anklicken und dann sage ich: Was will ich denn haben? Es gibt drei Konfigurationen, die die anbieten. Das sind ‚modern‘, das ist sozusagen bleeding edge, da ist nur TLS 1.3 drin. Dann gibt es Intermediate, das ist so das, was ich auch empfohlen hab, wo auch noch 1.2 konfiguriert ist und relativ viel Kompatibilität drin ist. Und dann gibt die noch für backwards compatibility, wo dann relativ viel unterstützt wird. Unter anderem noch TLS 1.1, sogar noch 1.0 noch. Damit die extrem vielen Clients, die vielleicht nicht mehr updaten können, auch noch kompatibel sind. Die sind dann da aufgeführt, beziehungsweise wird einem eine Konfiguration generiert, wo das dann so entsprechend alles drinsteht, die man dann fast copy und paste benutzen kann. Also wo das Zertifikat lokal liegt, muss man wahrscheinlich dann doch nochmal oder wie das heißt, ein bisschen was ändern. Aber dann hat man schonmal eine Vorlage für die meisten Serverprodukte oder für relativ viele. Und dazu gibt es noch eine dritte Sache, das ist die Security/Server Side TLS Wiki Seite von Mozilla. Also die drei Sachen gehören so zusammen und verweisen auch aufeinander. Da steht dann das nochmal drin, welche Parameter denn genutzt werden. Also welche Cipher Suites empfohlen werden und so ein paar Hinweise, warum man das machen sollte. Da stehen aber immer so edge cases drin, wie: Windows 7 mit Internet Explorer 11, der kann elliptic curve Diffie-Hellman nur, wenn man ein so und so Zertifikat hat, nicht mit RSA und keine Ahnung. Also recht spezielle Fälle dabei. Ist ganz interessant, um das mal zu schauen, kriegt man sogar als JSON-Format, wenn man es automatisiert und irgendwie woanders weiterverarbeiten will. Und also diese… alles von Mozilla, alles unter dem großen Schirm ‚Observatory‘ findet man das dann. Und wie gesagt, Observatory ist so ein Tool, damit kann man das auch testen. Da kann man seine Adresse eingeben, seine Webadresse und der sagt einem dann relativ viel dazu. Und das Gute ist, in der alten Folge hatten wir nochmal andere Tools empfohlen, auch so Webseiten womit man das testen kann und mit dem Mozilla-Teil kann man die auch noch… also da kann man noch so externe Einbindungen, kann man sagen, die sollen das auch nochmal testen und die Ergebnisse kriege ich dann direkt auch noch auf derselben Seite. Und die haben auch noch einen HTTP-Check, ob man so die security header und sowas richtig setzt. Also das könne wir mal in einer anderen Folge besprechen, security headers, glaube ich auch eine ganze… Stoff für eine ganze Folge. Also das ist alles in one place und das gibt es auch als CLI-Tool, also ich kann das auch scripten und also lokal ausführen und scripten. Das heißt, ich kann das auch noch in meine Build Pipeline einbauen und ja. Das wäre die aktuelle Empfehlung, die überholt so ein bisschen die Empfehlung aus der älteren Folge. Da haben wir auch gute Tools und Seiten empfohlen, aber die sind jetzt noch eigentlich vom aktuellen Stand hier bei Mozilla ein bisschen besser.

Lisa:

Sehr cool! Verlinken wir auf jeden Fall in den Shownotes. Ja Christoph, vielen, vielen Dank für die ganzen Informationen. Ich habe sehr, sehr viel mitgenommen auf jeden Fall. Falls ich einen Server konfigurieren muss, mache ich das jetzt sehr gerne, weil ich verstehe, was hinter diesen Strings steht. Ich danke dir, dass du heute hier warst und so viel erzählt hast! Dann danke ich allen Zuhörerinnen und Zuhörern, dass sie zugehört haben! Und hoffe, dass ihr genauso viel gelernt habt und mitgenommen habt, wie ich das habe! Und ich wünsche euch noch einen schönen Tag und bis zum nächsten Mal!

Christoph:

Ciao!