 Das nächste Gespräch ist von Philippo Valsorda und Nick Sullivan, der TLS-1.3-Geräte ist von Philippo Valsorda und Nick Sullivan, der TLS-1.3-Geräte ist. Wir sind hier um über TLS-1.3 zu reden. TLS ist auf 1.3 auf jeden Fall die letzte Version von TLS, was das für Transporter Air Security steht. Ihr kennt alle den grünen. Nun, TLS ist ein transparentes Sicherheitsprotokoll, das beliebigen Applikationsverkehr transparent turnen kann. Es ist von Webbrowsern, von Mail-Sorvern wird es verwendet, um miteinander zu kommunizieren, über sicheres SMTP. Es wird von Tornoids benutzt, um miteinander zu kommunizieren. Es ist über 20 Jahre, hat es sich weiterentwickelt, aber im Zentrum geht es um ein Client in einem Server, die durch ein Netzwerk sicher kommunizieren möchten. Um sicher durch dieses Netzwerk kommunizieren zu können, müssen Sie sich auf Schlüsselmaterial einigen. Das Sie nutzen werden, um den Rest des Traffic zu verschlüsseln. Nun, wie Sie sich auf dieses Schlüsselmaterial einigen, das ist Teil des Handshakes der Handschüttelfase. Die meisten nutzen Public Key, asymmetrische Verschlüsselungsverfahren, um Daten vom Client zum Server zu vermitteln. So sieht dieser Handshake in TLS 1.2 aus. Der Client sendet erst ein Client Hello an den Server, in dem festgelegt wird, welche Parameter der Client unterstützt. Der Server sieht diese Parameter und antwortet mit seinem Server Hello, in dem steht, ja, sicher, wir verwenden diese Cypher Suite, die du gesagt hast, die du verwenden kannst. Und hier ist mein Key Share, den du für unsere Verhandlungen verwenden kannst. Und hier ist auch ein Zertifikat, das signiert wurde von einer Zertifikats Ausstellungsstelle. Und das Zertifikat bestätigt, dass ich cloudflat.com bin. Und hier ist ein Zertifikat, das bestätigt, dass die CA diese Zertifikat verwenden möchte. Der Client erhält diese Daten und verwendet dann sein eigen Key Share, den er komplettiert mit dem Key Share, für das Deferrenprotokoll. Er sendet dann die Finishing Message zurück an den Server und beendet damit ein Handshake. Der Server erhält diese Nachricht, antwortet mit seinem eigen Finish Message und sendet diesen Client. Nun sind wir in der Phase, wo wir endlich Applikationsdaten versenden können. Zusammengefasst, wir sind vom Client zum Server zum Client, vom Client zum Server, vom Client zum Client. Das ist ja ein 2-Round-Trips zwischen kleinen Server, bevor wir Applikationsdaten hin und her senden können, bevor wir das erste Byte-Applikationsdaten versenden können. Das auf mobilen Netzwerken und in verschiedenen Teilen der Welt kann das zu hunderten von Millisekunden Verzögerung führen. Und das muss jedes Mal passieren, wenn wir eine neue Verbindung aufbauen. Jedes Mal müssen der kleinen Server 2-mal Nachrichten hin und her senden, um sich auf einen Key zu erneigen, bevor sie überhaupt eine sichere Verbindung erzielen können. Und TLS 1.0 und 1.1 waren nicht so unterschiedlich von 1.2. Mögt ihr euch wundern, wieso haben wir einen kompletten neuen Turk für TLS 1.3? Das ist eine neue Iteration des Elben Konzepts. Keine große Differenz. Das stimmt nicht. TLS 1.3 ist eine große Änderung gegenüber den Alpen. Insbesondere im Handshake. Das größte Resultat ist, dass ein ganzer Roundtrip von diesen beiden kommt. Hier ist ein TLS 1.3 Handshake. Wie entfernt TLS 1.3 ein dieser beiden Roundtrips? Das macht es, indem es vorher sieht, welches Key, welchen Schlüssel Einigung das Album ist, der Server verändern wird. Und der Kleint sendet seinen Key Share schon im ersten Roundtrip. Im ersten Flug haben wir das Kleint Hello und die unterstützten Parameter und den Key Share, den der Kleint denkt, dass der Server verstehen wird. Der Server erhält diese Nachricht und wenn alles richtig funktioniert, dann sagt er ja, sicher, der Key Share gefällt mir. Hier ist mein eigener für den selben Algorithmus. Hier sind die anderen Parameter, die wir verwenden werden. Der Server vermischt die beiden Key shares bereits, weil er schon beide hat, den vom Kleint und den Eigen jetzt generierten, sendet das Zertifikat und die Signatur zurück und fertig. Es kann sofort die Finish-Nachricht versenden, ohne etwas anderes zu tun. Der Kleint erhält diese Finish-Nachricht, kann ebenfalls seinen Key zusammenstellen, sendet seine eigene Finish-Nachricht und ist sofort bereit, seine Applikationslehrer-Daten jetzt zu versenden. Zum Beispiel, sein HTP Request. Jetzt haben wir uns vom Kleint zum Server, vom Server zum Kleint bewegt und sind bereits jetzt fertig, um Daten auf der Applikationsschicht zu versenden. Wir wollten also eine HTPS-Verbindung aufbauen und der Browser muss nicht viermal die Latente zwischen Kleint und Server, viermal den Ping zwischen Kleint und Server abwarten, sondern nur zweimal. Und das erspart uns hunderte von Millisekunden bei jeder frischen Verbindung. Und jetzt ist das, was passiert, wenn die Vermutung richtig ist, und wie der Server mag, was der Kleint gesendet hat. Wenn der Server damit sich nicht einverstanden ist und den Key shares nicht unterstützt, dann antwortet es höflich, mit einem anderen Algorithmus zu benutzen, den er Kleint kann. Das ist ein Hello-Retry-Eneut-Versuch. Es ist ein Cookie, das heißt, es ist ohne State, und es geht zurück zu dem TLS 1.2-Handshake. Und das nicht so schwer zu implementieren, wenn der Kleint mit einem neuen Kleint hello antwortet. Und das sieht genauso aus wie ein neuer. Hier habe ich ein bisschen für euch gebürgen. TLS 1.2 ist nicht immer drei Roundtrips. Die meisten Verbindungen, die wir sehen, sind, zum Beispiel, Vermutung. Das bedeutet, der Kleint hat mit der Webseite schon vorher verbunden, sich verbunden. Und wir können diese Vermutung benutzen, um den Handshake zu beschleunigen. Das bedeutet, dass der Kleint einiges davon behalten kann, darüber, welches Schlüsselmaterial benutzt wird, um eine neueste Verbindung, auch nur einen Roundtrip zu haben, auch in Version 1.2. Hier haben wir die normale TLS 1.2-Roundtrip-Verbindung. Und hier sendet es ein neues Session-Ticket. Ein Session-Ticket ist nichts weiter als ein verschlüsselten Block von Schlüsselmaterial, den der Kleint einfach behält. Das Session-Ticket ist verschlüsselt und signiert, dass nur der Server weiß und ist komplett klar für den Kleint. Und der Kleint wird das behalten, genauerweise mit dem Schlüsselmaterial der Verbindung. Das heißt, das nächste Mal, wenn diese Verbindung wieder aufgebaut werden soll, mit dieser selben Webseite, sendet es das Kleint Hello und der Session-Ticket. Wenn der Server den Session-Ticket unterstützt, wird es entschlüsseln, den inneren Schlüsselmaterial benutzen. Und innerhalb von einem Roundtrip gibt es einen ausgetauschtes Schlüsselmaterial mit dem Kleint, weil der Kleint mit dem Schlüsselmaterial vom letzten Mal behalten hat und der Server es einfach nur von dem Session-Ticket wieder entschlüsselt hat. Jetzt hat der Server den Schlüssel und sendet einfach die Finish-Nachricht. Und der Kleint sagt, es sind auch seine Finish-Message und dann den Request. Das passiert schon. Das ist TLS 1.2. Überall den allermeisten modernen TLS-Verbindungen. TLS 1.3 wieder aufrufen, wieder neun Stellung, ist nicht so anders. Es hat immer noch das Session-Ticket. Wir haben den Inhalt ein bisschen geändert. Das nennt sich jetzt PSK, aber das bedeutet auch nur vorher ausgeteilt ein Schlüssel. Weil das genau das ist, was es ist. Das Schlüsselmaterial, das vorher schon bestätigt wurde. Und es funktioniert genauso. Der Server erhält das Session-Ticket, entschlüsselt es und geht zurück zur letzten Nachricht. Ein kleines Problem mit der Wiederaufnahme ist, dass wenn ein Angreifer diesen Session-Ticket-Schlüssel herausbekommt, den Schlüssel, den Server benutzt und den Session-Ticket zu verschlüsseln, dann kann ein Angreifer passiv oder vielleicht sogar in einem zukünftigen Zeitpunkt bei einem Mitschrieb der Verbindung das Entschlüssel und den PSK benutzen, um den Rest der ganzen Verbindungen zu entschlüsseln. Das ist keine gute Sache. Das bedeutet, dass jemand passive, nachteiligere Verschlüsselung nur mithilfe dieses Schlüssel machen kann. Normalerweise wird dies dadurch gemacht, dass Session-Ticket-Kies nicht langlebig sind. Aber es wäre toll, wenn wir trotzdem nicht vertrauen würden. Das sind eine Reihe von guten Papers, die sagen, dass nicht alle Implementationen das richtig machen. Auf der anderen Seite erlaubt uns, TLS 1.3-Diffy-Helmen mit wieder auf Leben zu benutzen. In TLS 1.2 gab es keine Art und Weise, solche Session-Kie zu verstecken. In TLS 1.3 kann man ein Kies-Share mit senden. Und der Server wird auch ein Kies-Share benutzen. Und dann kann Diffy-Helmen ausgeführt werden. Diffy-Helmen ist das, was benutzt wurde, um Forward-Security zu benutzen. Zum Beispiel, wenn der private Schüssel vom Tertifikat veröffentlicht wird. Es wird hier auch benutzt, um Forward-Security bei wiederaufgenommenen Verbindungen zu erschützen. Und jetzt sieht es aus wie ein ganz normaler 1.3-Schlüssel. Warum brauchen wir den Pre-Share-Kie? Hier ist ein Unterschied. Es ist überhaupt kein Zertifikat dabei. Weil es nicht notwendig ist, ein Zertifikat zu benutzen. Weil die Server und der Client in der Vergangenheit geredet haben. Und der Client weiß, dass er das Zertifikat des Servers bereits überprüft hat. Und wenn der Server das Session-Ticket entrüssen kann, dann bedeutet das, dass es alles in Ordnung ist. Die beiden Shares werden zusammengeschmissen und mit dem voll ausgeteilten Schlüssel benutzt, um den Rest der Verbindungen zu verschlüsseln. Da gibt es noch ein weiteres Feature, das bei TLS 1.3-Wiederauflebung benutzt wird. Und das ist die Situation, dass es uns ermöglicht, keine Roundtips für jeden Handshake zu brauchen. Alle Handshakes in 1.3 sind maximal ein Roundtrip. TLS 1.2-Wiederaufrufen müssen mindestens eins sein. TLS 3.0 können null Roundtrips sein. Wie funktioniert das? Na ja, wenn wir darüber nachdenken, wenn wir anfangen, haben wir diesen vorgeteilten Schlüssel. Der Client kann einfach diesen Schlüssel benutzen, um das, die frühen Daten, die es senden kann, dieses Get zum Server zu senden. Der Client öffnet eine Verbindung zu dem Server, der schon eine Verbindung in der Vergangenheit hat und sendet ihm ein Client-Hello, den Session-Ticket, den Key Share für die vier Helmen und dann die frühen Daten. Das ist dieser Masse an Application-Data, die verschosselt ist mit dem PSK. Der Server erhält das, entschützt den Session-Ticket, findet den PSK, benutzt den PSK, um die frühere Daten zu entschützeln, mixes die 2K-Share und führt das fort. Also was ist da passiert? Wir sind also in der Lage, die Sitzungsarten zu komplett entfernen, d.h. wir haben den Performance-Overhead von Thierrys komplett entfernt. Nun, 0RTT-Handshakes haben zwei Nachteile, zwei Probleme, die theoretisch unmöglich sind zu entfernen. Ein Problem, das wir mit PSK-ECDHE eingeführt haben mit SessionResumption 1.3, ist nicht möglich mit 0RTT-Data. Wenn wir Diffie-Helmen können wir erst machen, wenn wir das grüne Kästchen auf dieser Folie erreichen. Denken wir wieder an den Angreifer. Der Angreifer hat das Session-Ticket geklaut. Er kann das Klein-Hello angucken, kann das Session-Ticket entschlüsseln, den PSK auslesen, damit die frühen Daten auslesen und kann da sogar von einer aufgezeichneten Session machen, wenn er später an diesen Schlüssel kommt. D.h. diese frühen Daten sind nicht sicher gegenüber dem PSK. Damit wird es unmöglich vor der Server-Answer, bevor wir Diffie-Helmen ausgeführt haben, Daten vorwärts secure zu übermitteln. Zusammengefasst, hier bewegt sich relativ viel. TS1.2 hat forward-secrecy eingeführt, gegenüber den ZVK-Schlüsseln, vor einer langen Zeit, mit den elliptischen Kurven-DI-Modi. So können wir immer sicher sein gegen das offenlegen eines privaten Schlüsseln eines ZVKs. TS1.3 hat das auch immer, jedes Mal. Es gibt keine Modi, die nicht forward-secure sind. Aber wenn wir daran denken, was mit dem Session-Ticket-Key passieren könnte, da bietet TS1.2 niemals Sicherheit. Bei TS1.2, wenn jemand den Session-Key mitgelesen hat, kann er in der Zukunft immer Session-Key-Daten auslesen. In der Zukunft mit TS1.3 ist dies immer noch möglich, aber nur mit den frühen Daten. Der Rest der Daten ist nach ACDI geschützt. Ich hatte gesagt, es gibt zwei gefährliche Punkte. Der Zweite ist, dass Zero-RTT-Daten wieder abgespielt werden können in einer Replay-Attacke. Das Szenario ist folgendes. Wir haben Daten, Early Data, die beispielsweise ein Request der einige Cookies enthält. Diese http-Request führt zum Beispiel eine Transaktion aus, bewegt Geld von einem Grund auf ein anderes oder instruiert dem Server eine Aktion auszuführen. Diese Aktion kann mehrmals ausgeführt werden. Ein Attacke, ein Angreifer, kann so ein Server anweisen, dies mehrmals zu tun. Ein Angreifer kann diese Transaktion aber nicht verändern, nicht modifizieren und auch nicht auslesen, weil sie mit TS geschützt ist. Aber er kann die Nachricht aufzeichnen und sie wieder und wieder dem Server zustellen. Wenn wir einen einzelnen Server haben, dann ist es einfach zu verhindern. Wir signieren, wir merken uns einfach, die Transaktion, die ausgeführt wurde und führen sie nicht ein zweites Mal aus. Wenn wir aber verschiedene Server in Rechenzentren um die Welt haben, dann sind diese Server möglicherweise nicht alle immer zu jeder Zeit miteinander synchron. Das heißt, der Angreifer könnte auf Server A die Nachricht zustellen, der Server entschlüsselt die Session, kommt an die Early Data und führt die Transaktion aus. Das möchten wir nicht. Eine Gegenmaßnahme, die TS anbietet, ist, dass eine Lebensdauer angegeben werden kann in diese Sekunden. Hier wird angegeben, vor wie langer Zeit ich das Session ticket nicht als Kleint erhalten habe. Der Server prüft dann, ob diese Nachricht mit dem Timing, das der Server hat, übereinstimmt. Wenn z.B. der Angreifer die Nachricht hat, wenn z.B. seit der Angreifer die Nachricht 10 Sekunden später abspielt, erkennt der Server, dass diese Daten nicht zusammen passen und kann das Paket ablehnen. Wenn ein Angreifer schnell genug ist und innert einige Millisekunden reagiert, kann er die Nachricht weiterhin versenden. Dann kann er die Daten ablehnen oder er kann auch einfach mal reinschauen und die Server-Halo-Nachricht sagt, hey, das ist eine gute Nachricht oder das macht keinen Sinn. Und der Kleint findet frühe Daten bis der Server Hallo sagt. Also der Server ist blind und sagt, man muss entscheiden, akzeptiere ich 0 RTT-Daten oder lasche ich die einfach. Und wenn es etwas bekommt und es einfach nicht gültig ist, wenn z.B. hier eine RTT-Post ist, dann sagt er, hey, das kann ich nicht, weil ich nicht weiß, dass es kein Replay ist. Also muss der Server ein bisschen Konfirmation oder eine Benachrichtigung haben. Wenn der Server einfach die Finish-Nachricht wartet und dann darauf wartet, dass der Kleinen die Finish-Nachricht sendet, wenn der Kleint geantwortet hat, bedeutet das auch, dass die frühen Daten nicht erneut gesendet werden, weil der Finish-Nachricht den ganzen Handshake zu Ende führt. Wenn zusammen mit der Zufall die Daten, die der Server gesendet hat, das, was ein Server tun kann, er kann den frühen Daten akzeptieren und wenn es etwas ist, was nicht wirklich wichtig ist und nicht irgendwas ist, das gefährlich ist, wenn es wieder ein Problem dafür wird, dann wartet er einfach auf die Konfirmation. Aber da muss es zwischenspeichern. Und da ist ein Anreifer-Risk, wo ein Anreifer potenziell ein RTT-Post sendet, einfach nur, um die Nachricht in den Arbeitsspeicher zu füllen. Hier könnten wir ein bisschen helfen, wenn wir auf der Session-Ticket schreiben würden, was es die maximal Menge von frühen Daten, die der Kleinen senden kann. Wenn wir hier jemanden sehen, der mehr sendet, dann ist es offensichtlich ein Angreifer. Wir ignorieren das einfach, verlöschen die vorhandenen Daten und schließen die Verbindung. Wie dem auch sei, was auch immer wir gegen machen, wir arbeiten, wenn wir keinen globalen State von Internet-Server haben, müssen wir die Applikation sagen, dass diese Daten eventuell replayt sind. TLS 1.3 Spezifikation sagen ausdrücklich, dass Protokolle nicht 0 RTT benutzen, ohne dass die... ohne auf die Nachrichten Inhalte zu achten. Die ganze Stack von TLS muss das unterstützen. Und der Server muss dann die entsprechenden APIs aufrufen, um entweder die Daten zu löschen oder zu warten, bis sie definiert richtig sind. So. Das wird euch ein bisschen ändern, abhängig von den Protokollen. Aber wie ist das mit dem Lieblingsbeispiel? Wie ist das mit RTTP? RTTP sollte eigentlich einfach sein. RTTP-Spec, wenn man ihn dies sagt, wenn Get-Requests sind wichtig und sie dürfen nichts auf dem Server ändern. Also Ergebnis, wir lassen einfach Get-Requests in aller Art und Weise, weil selbst wenn sie erneut gesendet werden, ändert sich nichts. Super. Nein. Es gibt einige Server auf dem Internet, die irgendwie so etwas haben wie Sendmanmonage to PGP, diese Menge. Und das ein Get-Request. Und wenn ein Angreifer diese Nachricht mitschreibt, weil es frühe Starten ist und sie gegen einen anderen Server in den Pool erneut sendet, dann könnte das Geld doppelt überwiesen werden. Und das ist nicht akzeptierbar. Anwendungen. Also das können wir jetzt hier machen. Wir definieren, dass es nicht so gut ist. Wenn man die App zum Weiß, kann man sehr spezifische Regelnungen machen. Google weist zum Beispiel, arbeitet schon lange mit zero RTT seit drei Jahren. Und das bedeutet, dass sie sehr genau wissen, weil ich ihrer Nachricht, welcher Server so eine Endpoint hat. Aber wenn man Cloudflare ist und vor vielen Applikationen steht, dann kann man solche großen Vermutungen nicht machen. Und stattdessen muss man auf irgendein Mittelbasis hoffen. Zum Beispiel könnte man sagen, wir akzeptieren nur Get zu dem Brut. Also Get-Stash. Das ist wahrscheinlich das Beste, weil die meisten Verbindungen so anfangen. Und ganz unwahrscheinlich, dass dort wirklich Probleme auftreten. Wir arbeiten immer noch daran, wie genau dies zur Anwendung gemacht werden kann, wenn sie irgendeine Applikation kennen, die Probleme mit so etwas einfachem haben, senden sie uns bitte an die E-Mail. Aber wenn ihr eine Applikation habt, die so gefährdet ist, dann ist es eine schlechte Nachricht. Browsers werden heutzutage ohne TLS 1.3 HTTPS-Requests erneut absenden, wenn ein Netzwerk-Feder existiert. Und sie werden in leise wiederholen. Und es wäre nicht deutlich schlimmer als der aktuelle Status. Ich sehe, dass jetzt alle so ein bisschen ungeduldig werden in ihren Stühlen. Da, Kryptografen sind wieder dabei. Sie haben ein Sicherheitsprotokoll, das wir brauchen komplexer, als wir brauchen, um ihre Jobsicherheit für die nächsten 15 Jahre zu behalten. Richtig? Nein. Ich kann sicher sagen, dass ein der großen Bestandteile sogar größer als die Roundtrips, in meiner Meinung nach, ist, dass alles mit der Sicherheit gegen Komplexität abgewertet wird. Während 0 ist HTT durchgekommen, sind die meisten Sachen nicht durchgekommen. Funktioniert mein Mikrofon? Danke, Willi Pung. In TLS 1.3, also eine Weitredestination von TLS, sind wir zurückgegangen und haben geguckt, welche Leute wie TLS einsetzen und haben sich überlegt, was für TLS 1 Features es gibt und wie diese eingesetzt wird und wie die Komplexität dieser Features und dieser primitiven Gegenüber, der in Nutzen ist und eines der ersten, was wir ausgeschlossen haben, ist TLS 1.2 Static RSA Mode. Statt Diffy-Helmen zu verwenden, um ein Key auszuhandeln, wird stattdessen in dieser Version einfach der RSA Key des Zertifikats um ein Master Key für die Session zu erstellen. Und der Server verwendet einen Zertifikats-Key. Ein offensichtlicher Aspekt dieses Handshakes ist, dass wenn der Zertifikats-Schlüssel dieses Zertifikats veröffentlicht wird, auch Jahre später werden jemand die Daten aufgezeichnet hat. Früher Verbinderung kann der das ganze Gespräch mitlesen. Diese Funktion wurde vor rund 2 Jahren sehr, sehr früh in der Prozesse umgelegt. Von TLS 1.3 entfernt zu unserer großen Überraschung und zur Überraschung aller Leute, die die TLS 1.3 Mailing ist mehr geliesene haben, wurde kürzlich gegen das Ende der Verabschiedungsphase dieses E-Mail auf der Liste versendet von Andrew Kennedy, der bei Bits arbeitet. Was heißt das, er bei Banken arbeitet? Er schreibt, dass Entfernen des RSA-Key-Exchanges in TLS wird große Probleme verursachen für Banken, weil fast alle von den TLS-Intern verwenden und große sicherheitskritische Investments in Out-of-Band-TLS-Entschlüsselung haben. Out-of-Band-TLS-Entschlüsselung. Das klingt kritisch für jemanden. Eine der positiven Punkte war die Antwort von Kenny Patterson zu dieser Mail. Er schrieb, betreffend deine Anfrage, nein, wir versuchen ein sichereres Internet zu bauen. Danke. Nach diesem Austausch kam die Banken-Leute um aufzuzeigen, wie schwer es für sie war, ihr eigenes System zu debanken. Das hier ist ein sehr einfach Diagramm von ihren Switches und Routern und allem drum und dran. Das spricht alles TLS miteinander. Nach dieser Diskussion kam wir zu einem Kompromiss und statt das Protokoll zu schwächen. Hat Ihnen Matt Green beigebracht, TLS-Definement richtig einzusetzen, um ihnen aufzuzeigen, wie man den Statisch einsetzen kann, um aufzuzeigen, dass die Security-Community auch genau mit Banken zusammenarbeiten kann, ohne die Sicherheit von TLS zu gefährden. Aber auf jeden Fall, wir haben das Feature nicht wieder hinzugefügt und möchte nur darauf hinlegen, was hier steht nicht. Wir haben ein Statisches RSA getötet, und was haben wir sonst noch entfernt? Wenn ich zurückblicke auf die Kompromisse, die wir gemacht haben, es gab einige Primitiven, die in TLS 1.2 vertreten waren, die nicht mehr aktuell sind. RC4 zum Beispiel, ein Stromschiffer, Triple Des kommt weg, MD5 und SHA1 kommen weg, ASCBC. Es gibt sogar Konstruktionen, die entfernt wurden, ASCBC. RSA PKCS 1.5 war bekannt seit 1998, was das Problem vor sagt. Wir haben auch Kompression entfernt, Renegotiation, das ersetzt wurde durch einen sehr leichten Key-Update-Mechanismus. Bei TLS 1.3 haben keine dieser Verfahren die Hürde genommen. Und viele dieser Schwachstellen, die ihr seht, sind nicht mehr vertreten. Das ist ein guter Ausblick. Die Philosophie für TLS 1.3 ist vielerorts ver-einfachen und robuster machen. Es gibt einige kleine Fälle, in denen wir das machen könnten. Einige der Autoren, diese Papers sind viel leicht im Publikum. Es gibt eine Art, wie man Blockverschlüsselungsverfahren einsetzen kann, die durch ein simples Verfahren ersetzt wurden. TLS 1.2 hatte diese sehr komische Siphernegotiation durch eine Finish-Message geschützt. Aber der Algorithmus für diese Bestätigung erst in der Siphernegotiation ausgehandelt wurde. Also ein zweiter Schritt wurde ausgehandelt, was im ersten Schritt gemacht werden sollte, was zu Angriffen wie Freakow oder Logjam führte. Und mit der Sicherheit, dass es mit der Sicherheit downgraded werden konnte. Da was davor herrührt, dass die gewisse Nachrichten im Handshake nicht signiert waren. Alles von der Signatur aufbaut, ist digital signiert. Was haben wir sonst noch verändert? Was gab es sonst noch? Was hat sich verändert von der es 1.2, 2.3? Wir haben weniger, aber bessere Entscheidungsmöglichkeiten. Es gibt keine Abitrieren Kurven, keine Abitrieren DH-Gruppen. Und diese Kürzung der listemöglichen Parameter, die ermöglicht 1RTT in den meisten Fällen zu funktionieren, wie Philippo erwähnt hat, die Einschränkung der Verschlüsselungsmechanismen auf dem Server. Und das ist der Fall, dass die Einschränkung der Verschlüsselungsmechanismen auf dem Server so lange, die nur sicher sind, ist in einem höheren Anteil der Fälle möglich, beim ersten Roundtrip zu kommunizieren. Also die Konfiguration ist nicht mehr ein kompliziertes Take-away-Menu, sondern ein festes Drei-Gang-Menu. Man kann sich das Ganze in Wireshark angucken. Alles ist viel einfacher. Und die Kurven, und von da aus geht es weiter. TLS 1.3 hat auch noch weitere Probleme repariert. Einige Designprobleme von TLS 1.2 wurden entfernt. Wir haben darüber geredet, wie Forward Secrecy mit Wiederaufnahme in Version 1.2 und 1.3 funktioniert. Aber TLS 1.2 hat noch weitere Probleme. TLS 1.2 hat innerhalb der Session die wirklichen Geheimnisse der alten Verbindungsschlüssel. Also die Verbindung der regionalen Verbindung verschlüsselt die mit dem Session-Ticket-Key und sendet die zu dem Klein, um sie zurückzusenden fürs nächste Mal. Wir haben darüber geredet, wie das ein Risiko ist, dass ein Anreifer diese Session-Ticket-Schlüssel erhält und diese Session-Tickets entschlüsselt die Forward Secrecy zerstört und insbesondere bei Wiederaufgenommenen Verbindung. In TLS 1.2 ist es noch schlimmer. Wenn Sie den Session-Ticket entschlüsseln können, dann können Sie zurückkommen und den ersten Teil der Verbindung, die nicht wiederaufgenommen wurde, entschlüsseln. Und das ist komplett unnulltäglich. Wir hatten eine Hash-Funktion. Wir haben ein Wegfunktionen, wo man ein Input reintut und wir kriegen irgendwas zurück, wo man das alte nicht herausrechnen kann. Das ist was 1.3 macht. 1.3 entwickelt neue Schlüssel für die nächste Verbindung und speichert sie im Session-Ticket für den nächsten PSK. Selbst wenn Sie ein 1.3-Session-Ticket entschlüsseln, können Sie dann die nachfolgende Verbindung angreifen und vielleicht sogar nur die frühen Daten oder nur einen früheren Teil der Verbindung. Aber Sie können garantiert nicht die vorhergehenden, nicht wiederaufgenommenen Verbindung entschlüsseln. So, das wäre schon schlimm genug. Aber 1.2 macht noch eine weitere Entscheidung, die ich echt nicht verstehe. Diese ganze Idee von Master Sicherheit benutzen, weil das nur eine Erweiterung ins 1.2 war und nicht mehr in 1.3 ist. Aber 1.2 sendet den neuen Session-Ticket-Nachricht am Anfang des regionalen Handshakes und verschlüsselt. Also, verschlüsselt mit den Session-Keys, aber nicht mit der aktuellen Session-Keys. Das bedeutet, jeder Server, der das nur unterstützt, hat nicht nur am Anfang von jeder Verbindung, sogar wenn wiederaufnahmen nie passiert. Ein Session-Ticket erstellt, das nichts weiter ist als die grundlegenden Schüssel dieser Verbindung zusammen mit den Session-Ticket-Keys. Und wenn sie ein großer passiver Angreifer ist, der eventuell große Überwachungsangriffe sind und alle Verbindungen passiv entschlüsseln möchtest und eventuell irgendwie die Möglichkeit bestellen, das Session-Ticket-Keys zu haben, ist das am Anfang jeder TLS 1.2 Verbindung, der die Session-Keys versendet werden, verschlüsselt mit den Session-Ticket-Keys. 1.3 löst das, und diese Angriffe sind komplett nicht mehr möglich. Das Einzige, was sie passiv entschlüsseln können oder nachher nachträglich entschlüsseln können, sind frühe Daten und keine vorherigen Funktionen und dann geht auch nichts, was nach einem Null-Roundtrip-Time kommt. Also es ist eigentlich sicherer. Und woher wissen wir, dass es sicher ist? Diese Sicherheitsparameter und die Sicherheitsanforderungen von TLS wurden definiert. Anders als frühere Version von TLS haben die Leute aus der akademischen Gruppe waren vorher am Anfang gefolgt wird. Also die State Machine wurde analysiert und das hat uns viel geholfen dabei, das Protokoll zu verbessern. Wer arbeitet an TLS 1.3? Naja, es ist eine Organisation, die nennt sich EETEF, Internet Engineering Task Force. Die Mests treffen dreimal am Tag, dreimal im Jahr und diskutieren darüber und haben eine E-Mailing-Liste. Und ursprünglich, was ich davon wusste, war von September 2013, war eine Wunschliste für TLS 1.3. Und seitdem haben sie eine ersten Vorschlag gemacht, dass frühe Versionen als RFC bekannt sind und bevor etwas in RFC wird, ist es ein Internetdraft. Also wir haben das Internetdraft Null und da wird verbessert, bis dann irgendwann akzeptiert oder abgelehnt wird als RFC, also Request verkommend. Das Erste war im April. Und die aktuelle Draft 18, die fast fertig ist, also es ist die letzten Call, und es wurde im letzten 1. Oktober veröffentlicht und in dieser Zeit hat sehr viele unterschiedliche Angreife gegen TLS gesehen. Also der dreifache Handshake, Poodle, Freak, Logjam, Drown, das gab vorhin einen Vortrag darüber, Lucky Microsecond, Sloth, die ganzen anderen Akronüme, die sie vielleicht mitgekommen haben in den letzten Jahren, ist während der Entwicklung passiert und TLS 1.3 ist ein lebendiges Dokument über diese vorherigen Angriffe. TLS 1.3 ist hoffentlich kleiner, es ist doch nicht, zum Beispiel, dass TLS 1.3 ist, wenn man vieles davon weggelöscht, ist es deutlich genauer, obwohl TLS 0RTT Wiederaufnahme da drin sind. Also was verbessert ist. Ja, wie funktioniert das? Wie kann man mitmachen? Ja, GitHub und die Mailing-Liste. Wenn Sie jetzt eine Pull-Request senden wollen, dann schauen Sie hiermit und wahrscheinlich wollen Sie auch eine Nachricht auf der Mailing-Liste senden, um zu sagen, was Sie ändern wollen, was Sie ändern willst. Und wenn ihr mitmachen wollt, jetzt ist es ein bisschen spät, es ist auf dem letzten Ausruf, aber die Mailing-Liste ist noch da und ich habe dort mitgearbeitet und zum Beispiel Philippo, die haben mit an der ursprünglichen Version gearbeitet und ihr könnt das GitHub-Antwort schauen und zu sehen, wie viel Arbeit da reingestellt wurde. Die Draft ist in den Jahren deutlich geändert worden, so wie zum Beispiel über die Jahre oder Monate. Draft 9 hatte zum Beispiel diesen sehr komplexen Baumstruktur, wie Key-Schedules funktionieren soll. Hier sieht man HTK und diese ganzen unterschiedlichen Schlüssel, die im TLS-Sundshake verwendet werden können. Und das war ein Teil von dem Quick-Protokoll, das Philippo früher benannt hat, oder genauso wie in der OP-TLS. Es hatte sehr viel different Modi, sehr wie Statischen Diffy-Helmen und diesen Baum, was wir hatten, Key-Schedule. Und mit der Zeit wurde das deutlich reduziert zu dem, was wir heutzutage haben im TLS 1.3. Das ist ein sehr einfacher Schlüssel-Ableitungsalgorithmus und das hat sehr, sehr, sehr viel Arbeit gekostet um von etwas so groß und zu etwas deutlich kleineren zu kommen. Aber es ist passiert. Andere Sachen, die seitdem passiert sind in 1.3, sind deutlich weniger wichtig kryptografisch. Und ein Teil davon ist ein Benennung. Vielleicht haben Sie mitbekommen, TLS 1.3 ist nicht der einzige Name für dieses Protokoll. Philippo hat auch gesagt, 1.0, 1.1, 1.2 waren sehr kleine Iterationen und sogar gegenüber SSL V3. Aber TLS 1.3 ist eine ziemlich große Änderung. Das sind viele Optionen, wie man es nennen könnte. Also kurze Fragen. Welche meint, dass es 1.3 genannt werden soll? Okay. Ziemlich gute Nummer. Wie wäre es mit TLS 2? Okay, das sieht ein bisschen mehr aus. Denkt daran, dass SSL V2 ein Ding ist und ein grausames Ding. Wir wollen damit nicht abverwechseln werden. Wie wäre es mit TLS 4? Aha, aber noch einige. Wie wäre es mit TLS 2017? TLS 1.7, irgendjemand? Wie wäre das mit TLS Valenium? TLS Vista. Vielen Applaus. Viel Option. Zu Erinnerung, der Rest der Welt nennt das nicht wirklich TLS, das hier ist Google Trends. SSL gegen TLS. SSL ist, was der Großteil der Welt diesem Protokoll sagt, mit der höchsten Version 3.0. Das ist auch der Grund, wieso viele Leute denken, TLS 4 könnte ein guter Name für das Protokoll sein. Leute sind verwirrt, weil 3.0 höher ist als 1.2 usw. Auf jeden Fall, das hier war nicht die einzige Umfrage. Es gab einige andere informale Pulse, zum Beispiel Bacon, Speck war ein sehr gutes Resultat von der Umfrage von Ryan Hurst. Version sind etwas sehr klares mit TLS. Zum Beispiel die Version von TLS, die wir jetzt kennen, wenn man die im Protokoll anguckt, die passen eigentlich nicht. SSL 3 ist 3.0, TLS 1.0 ist TLS 3.0, TLS 1.2 ist SSL 3.3 und bis RUFT 16 war TLS 1.3 Version 3.4, wenn man die Netzwerkpakete anschaut, also ein Minerbump. Nach einigen Untersuchungen im Internet ist es aufgefallen, dass viele Server, wenn man den kleinen Tello mit Version 3.0 4 sendet, die Verbindung einfach unterbrechen. Das ist ziemlich schlecht. Das führt dazu, dass Browser nicht in der Lage sind, ein siches Downgrade zu machen. Was der Server eigentlich tun sollte, wenn er etwas höheres als 3.3 sieht, mit 3.3 zu antworten und sagen, ich verstehe nur das. Die Einigung ist jetzt, dass wir mit 3.3 weiterfahren und mit 3.4 als eine Erweiterung ausgehandelt werden. Aber so haben wir wieder mal die Vorteile gegen die Komplexität abgewogen und hier führt der Nutzen, dass die Serververbindung nicht abreißt, ist ein höherer Gewinn, als das wir hätten. Wir versuchen auch jedes Teil der Verhandlung, werden wir etwas Auffälligkeiten reintun, XAXA, damit es immer wieder etwas komisches sehen. Das soll ein sehr, sehr nützliches Ding werden, um die Kompatibilität zu steigern. Wir haben nur noch wenig Zeit, aber wir haben uns auch die Hände schmutzig gemacht und etwas, das CITF wirklich gerne hat, ist, Code auszuführen, wenn Stand-up-Sendung mit 3.3 in der Lage ist. Wir haben uns auch die Hände schmutzig gemacht und es ist cool auszuführen, wenn Standards entwickeln werden. Also haben wir im IETF 95 Hackathon ausprobiert und haben es geschafft, dass Firefox eine TLS 1.3-Seite bei Cloudflare laden kann an diesem Hackathon. Wir nutzen NSS, die Security Library in Firefox und mint eine neue Version von TLS 1.3 von Scratch in Go geschrieben. Das Resultat war, es funktioniert, aber das war nur ein Proof of Concept, ein Ausprobieren. Etwas mehr Produktionsbereites, weil wir haben geprüft, welche Library wir am Produktionsbereitesten halten. Überraschenderweise war das OpenSSL. Wir haben ein Bild von TLS 1.3 von OpenSSL gemacht und das Resultat, wir nennen es TLS Stress, ist ein Drop-in-Replacement für Crypto-TLS, kommt mit der wunderbaren Warnung, dass man das nicht einsetzen soll. Das hatte man überall und jetzt geht es um Security, es geht um Stabilität. Security haben wir geouteten lassen. Stabilität könnte frage sein. Ihr könnt beim Upstreaming-Prozess mitarbeiten. Die Google hat uns ein Branch geöffnet. Es wird sicher nicht in den nächsten Go-Releases reinkommen, aber wir arbeiten gerade, dass es Upstream eingearbeitet werden kann. Auf jeden Fall, wenn ihr Go benutzt, wird es schwer. Das erste Mal, wie wir Tres verwendet haben, war die Draft-Version 13. Um Browser zu unterstützen von dieser Version an, mussten wir verschiedene Draft-Versionen zur selben Zeit in dieser Library unterstützen. Mit komischen Änderungen. Wir mussten Dinge unterstützen, weil wir keine gewisse Dinge verändert haben. Wir haben eine Testmatrix, die alle unsere Commits gegen verschiedene Versionen der Klein-Libraries laufen ließ, um sicherzustellen, dass wir immer mit dem Browser kompatibel blieben. Die Kleinen sind jetzt mittlerweile deutlich stabiler. Vielleicht nutzt ihr es schon, ohne es zu westen. TLS 1.3 hat bei etwa 50% eingeschaltet. Das ist ein Experiment für Google-Sites. Und das hier ist, wie unsere Grafen aussehen, als wir zum ersten Mal gestartet sind. Mit Firefoxen Nightly und schließlich bei Chrome Canary. Heutzutage sind wir bei rund 700 Requests pro Sekunde stabil. Und auf unserer Seite haben wir es für Millionen von Seiten auf Cloudflare eingeschaltet. Und wie gesagt, die Spec ist ein lebendes Dokument. Ihr könnt es auf GitHub einsehen. Die Tress-Implementation ist zwar da, hat aber eine abstreckende Warnung. Und das aufgeführte Blog hier wird wahrscheinlich Quelle sein, wo wir weiter veröffentlichen. Vielen, vielen Dank für eure Aufmerksamkeit. Und wenn ihr Fragen habt, dann stellt euch einen Mikros an. Wir haben noch viel Zeit für Fragen. Die erste Frage ins Internet. Die erste Frage ist, welche Daten an die Applikation geben wird, den Applikationen-Entwicklern belasten werden. Das ist eine gute Entscheidung. Die erste Frage ist, ob die Applikation, welche Daten an die Applikation geben wird, und dass das eine gute Entscheidung ist. Das ist wirklich ein Problem. Es ist nicht zerstört bei normalerweise, sondern wenn man T-des funktionieren kriegt, dann kriegt man keine zero RTT, weil man dort mit der Anwendung zusammenarbeiten muss. Das heißt, wie solange eine Anwendung nicht weiß, wie das funktioniert, kann sie damit nicht arbeiten. Sie hat die gesamten Funktionen und auch die ganzen Roundtrip-Handshakes trotzdem. Auch wenn es nicht damit umgehen kann. Mit den frühen Tests des Protokolls habt ihr irgendwelche harten Zahlen gesammelt, wie die Performanceverbesserung aussieht? Ein Roundtrip. Das ist die Frage, was so ein Roundtrip ist. Ich kann keine Zahlen sagen, weil wenn Sie z.B. in San Francisco leben, dann sind sie in einer Pfeilbarfaser 6 Millisekunden. Aber wenn Sie vielleicht in irgendeine Frage, wo die einzige, die beste Verbindung ist, die Sie bekommen können, dann ist es eine deutlich bessere, deutlich stärkere Verbesserung. Vielleicht bis zu 200 Millisekunden. Aber wir haben das nicht offiziell gesammelt, diese Zahlen. Eine Anmerkung, die ich machen wollte, ist eine andere Verbesserung in Teles 1.3. Es wurde Verschlüsselung zu Kleinstzertifikaten hinzugefügt. Die Kleinstzertifikate werden verschlüsselt übermittelt. Was wichtig ist, wenn sich ein Kleint bewegt und von breiter Überwachung überwacht wird. Und eine andere Frage. Das ist eine Frage, die ich in der Frage habe, ist, ob die festen Diffie-Helmen-Gruppen nicht ein Problem mit Logjam waren. Hilft Teles 1.3 gegen solche Angriffe? Aber mit dem Proposal von den Banken? Nein, nein, nein. Die vordefinierten im Standard. Ja, in Logjam, da war eine Entscheidung, dass eine Diffie-Helmen-Gruppe von vielen Leuten in der Frage war. Das ist eine Frage, und in Logjam, da war eine Entscheidung, dass eine Diffie-Helmen-Gruppe von vielen, vielen Servandern von Standardmäßig unterstützt wird. Das waren 10, 24. Und in S1.3 würde eine vorher berechnete Schlüsselgruppe, die über 2000 bits ist, die kleinste, und sogar mit allen vorbegerechneten in der Welt, ist es noch nicht möglich, die ausreichend vorzuberechnen, die S1-Gruppen zu veranzen, wenn sie fest ist, dann wissen sie, dass man da nichts gegenmessen kann, das nicht genau so stark ist. Danke. Vielen Dank für deinen Tag, Torg. Im abstract habt ihr erwähnt, dass ein anderes Feature, das entfernt wurde, SNI-Runny-Servaname-Indication für den Zero-RTT-Ausdauern. Ja, wir haben diesen Vortrag schon mal gehalten und die Frage war auch schon mal da. Also haben wir das schon mal vorbereitet. SNI, also diese Servername Identification, dass man einen Zertifikat erkommt, abhängig von dem Zertifikat. Ja, Dr. Klein sagt, hey, ich hätte gerne diese Webseite. Zum Beispiel hat Klaufer sehr viele Webseiten hinter unserer Maschine. Das heißt, sie müssen uns hacken. Hallo, ich möchte eigentlich zum Beispiel zu Google.com reden. Und das ist natürlich in Privatsphäre ein Problem. Das heißt, wenn jemand nur auf diese Beiz, die übertragen werden kann, dann weiß er, auf welche Webseite man sich verbindet. Das wichtige Ding ist, dass es genau dasselbe Problem ist, wie Forward Secrecy für die frühen Daten sind. Also, wenn Sie SNI im Kleintalow senden, dann haben Sie noch keinen Schüssel ausgetauscht. Das heißt, man weiß nicht, welche Daten verwendet werden, wie es erschüsselt werden soll. Aber wenn man das SNI nicht am Anfang sendet, weiß deshalb nicht, welche Zertifikat zu antworten ist. Also, kann auch keinen Schüssel ausgetauscht werden. Das heißt, man müsste zwei Roundtrips machen. Und das machen wir in TSN.3 nicht mehr. Also, so funktioniert das nicht mehr mit einem One-Roundtrip-Handshakes. Aber das sind Ideen, wie man im HTP2-Spec hat, und wir arbeiten daran. Und das könnte möglich sein, eine Verbindung mit einer Domain zu erstellen, dann eine neue Verbindung mit einer anderen Verbindung. Und damit kann man SNI implementieren. Das heißt, jemand denkt, man braucht viel Verbindung. Aber dann hat auch eine andere Webseite über dieselbe Verbindung geladen. Die nächste Frage vom Mikrofon 7. Fünf. Ihr habt erwähnt, dass es eine formale Verifikation gab, welche Software wurde für die formale Verifikation verwendet. Ja, da waren einige Softwareimplementationen, die benutzt wurden. Und Protokolle, die benutzt wurden. Wir können zurückgehen hier. Tamron ist ein Software, die von Oxford unterstützt wurde. MIT, TLS. Es ist in F scharf, wenn ich mich richtig erinnere. Und NQ, SB, TLS ist in OCaml. Also, viele verschiedene Sprachen, die hier entwickelt sind. Und ich glaube, NQ, SB, R sind hier. Hi, thanks. Hi, danke für die informative Präsentation. Die Geschichte von SSL und TLS ist voller Möglichkeit, was irgendwie falsch gehen konnte, die uns wirklich auf den falschen Fuß serviced haben. Meine Frage ist, da wir wissen, dass es viele kleinere Organisationen gibt, die wahrscheinlich zero RTT falsch kriegen werden. Euer Bauchgefühl. Wie groß ist die Chance, dass uns das auf dem falschen Fuß serviced? Ja, wie ich gesagt habe, bin ich sehr skeptisch im Bereich RTTP, weil Browser jetzt schon gewisse Sachen replayen und erneut senden. Und wir haben Paper und Blackposts gesehen. Aber aktuell hat noch keiner wirklich versucht, dass das einen signifikanten Teil des Internets zu Problemen führt. Und ich weiß nicht, wie ich ihn antworten kann, wie komplex oder wie große Schwierigkeiten wir das haben. Aber auf der anderen Seite ist, wie viele wollen sagen, dass sie nicht TLS machen sollen, weil es zero RTT ist. Und TLS 1.3 ist schnell, also geht raus und verschlüsselt alles. Also das sind die beiden Probleme, die man ausbalancieren möchte. Und wieder eine eigene Meinung, die sehr wenig wert ist, dass eine Entscheidung, die bei der gesamten Community gemacht wurde auf der Mailingliste und ich kann Ihnen sagen, dass jeder da sehr konservativ mit gedacht hat und sogar der Name eventuell zu Problemen führen könnte. Also ich kann die Zukunft nicht zuhersagen, aber ich hoffe, dass wir die beste Entscheidung getroffen haben, dass wir den meisten Teil des Netzwerks internet so sicher wie möglich gemacht haben. Nächste Frage kommt aus dem Internet. Haben wir noch eine? Ja, haben wir. Was sind die großen Implementationen, die in Kompatibilitäten gefunden wurden, da die Spezifikation sich nun dem Ende zuneigt? Okay, während der Erstellung der Vor-Version, eine geht der, wo die Versionen intolerant waren, die Firewalls und ein paar sehr große Seiten, wie zum Beispiel PayPal, hatte damit Probleme. Aber während des Prozesses hatten wir Incompatibilitäten für alle möglichen Benutzer, zum Beispiel auch einen der zweiten Entwickler, hatte Probleme mit den Zahlen und während der Entstehung hatten wir manchmal keine Kompatibilität, aber es war viel Zusammenarbeit mit den kleinen Implementationen, mit den Server Implementationen von unserer Seite und ich bin sehr glücklich, dass wir sagen können, dass die 1.3 Implementationen sehr viel Interoperationstesting benutzt haben. Oder durchgeführt wurde. Die nächste Frage vom Mikrofon Nummer 1. Ich habe zwei kurze Fragen zur Session Resumption. Wenn man gewisse Daten, also eine Session auf dem Server speichert, ist das nicht ein super Cookie und das Privacy Gründen gefährlich? Und die zweite, wie sieht es mit Tennis Load Balancer aus, wenn man eine Riesenmenge an Servern hat, an die die Request gehen können? Wie schaut es da aus? Freie Session Tickets. Tennis 1.3 denkt über die Privatsphäre ein Problem mit Session Tickets und sie ermöglicht den Server mehrere Session Tickets zu senden. Das heißt, der Server weiß immer noch, welcher Klein diese Session Ticket sendet, wenn es das weiß. Aber jeder, der auf die Verbindung drauf schaut, weil sie verschüsselt versendet werden, können dort viele da sein, kann keiner die Verbindung zurückaufbauen kann. Der Server und der Klein müssen irgendeinen Bekannten einen Wissen austauschen. Der Server muss wissen, wer es war. Aber 1.3 Session Tickets können nicht mehr von einer dritten Partie und Übersucht nacherfolgt werden. Load Balancing, wir haben eine sehr interessante Paper dazu. Aber der Hintergrund ist, dass man im Endeffekt verstehen möchte, ist, wie Klein zwischen den Servern aussuchen und eine Balance dabei dazwischen finden, wie man die Schüsse am effektivsten austauscht, wie der Session Ticket effizient austauschen kann, wo dann auch Probleme sind. Nicht, dass er alles senden möchte, weil es zu einfach ist, eventuell auf einen draufzukommen. Ob man die jetzt so global macht oder ist eine Anfrage von dem Verwender. Die letzte Frage von dem Mikro Nummer 3. Ich hatte eine Frage betreffend, das... Wenn ich richtig verstanden habe, dann habt ihr zufällige Versionsnummern auf der kleinen Seite initiiert, um die Servers so zu trainieren, dass sie besser der Spezifikation genügen werden. Was ist das Resultat eurer Real-World-Tests? Wie viele Servers sind tatsächlich kaputt und funktioniert nicht? Man erwartet keine, weil sie alle 1.3 schon implementieren. Das heißt, alle Kleinen, die sie sehen, müssten eigentlich schon Grease machen. Aber auf der anderen Seite, als Google Grease enable hat, hat es, ich weiß nicht, welche spezifischen Serverimplementationen, aber eine in den größeren Serverimplementationen war, sofort erkannt, als nicht funktioniert. Ich glaube, es war Haskell. Ich weiß nicht mehr, ich kann Haskell nicht lesen. Ich weiß nicht, was ich falsch gemacht habe, aber ich habe die Verbindung einfach abgebrochen. Außerdem wurde Grease auch benutzt in Cypher Negotiation. Immer überall, wo eine Negotiation, also eine Verhandlung in TLS 1.3 ist, dann wird das verwendet. Ein kleiner Subset ging natürlich dadurch kaputt. Vielen Dank für den Talk. Liebe Zuhörer, das beendet die Übertragung von TLS 1.3, The Great, The Good and The Bad.