 Moin, ich bin Pascal. Ich wollte euch heute was über TLS erzählen. Wahrscheinlich habt ihr die Slides alle schon gelesen, trotzdem nochmal der Vollständigkeit halber. Das hier geht nur um TLS. Die Kryptoprimitiven, die erklärt werden, die solltet ihr unter keinen Umständen benutzen für E-Mail Verschlüsselung oder Festplattenverschlüsselung oder sonst irgendwas. Sonst werdet ihr euch in den Fuß schießen damit. Gut, dann zu den Grundlagen für diesen Talk einmal. Da haben wir eine kleine Legende. Das werdet ihr später sehen. Unten diese ampelfarbigen Dinger, also kaputter Scheiß, gammeliger Scheiß und scheint noch nicht ganz kaputt zu sein. Das werdet ihr später im Talk öfter begegnen. Ja, es sollte selbst erklären sein. Gut, kommen wir zu den Grundlagen. Also wir haben das Problem, wir wollen zwischen dem kleinen und dem Server eine Verschlüsselverbindung herstellen. Die sollen irgendwie miteinander reden können. Wahrscheinlich hat jeder hier schon mal von AES gehört, also schmeißen wir erst mal AES drauf. AES ist eine Blockschifre, ist eine symmetrische Schifre. Deswegen halbwegs schnell. Hat aber das Problem, du benutzt den gleichen Key zum Verschlüsselung und zum Entschlüsseln. Und diesen Key müsste man jetzt irgendwie zwischen diesem Server und diesem Klein aushandeln oder übertragen. Und das geht halt eher schwierig, weil die haben ja sonst noch nichts außer AES. Außerdem haben wir das Problem, wenn man mit AES die Daten, die übertragen werden, verschlüsselt, dann werden diese Daten im Regelfall größer sein als die Blockgröße von AES. Das heißt, man muss mehrere Blöcke verschlüsseln. Und was man da nicht tun sollte, ist, das gleiche Passwort bzw. den gleichen Key für jeden Block zu benutzen. Sonst passiert das, was ihr da auf der rechten Seite seht. So oben ist der Klartext. Unten drunter ist, was passiert, wenn ihr bei AES überall denselben Key benutzt für jeden Block. Und unten ist, wie man es richtig macht. Da kommen wir auch später noch dazu. Den kaputten Modus nennt man ECB Electronic Codebook. So, dann etwas generischer zu semerischer Verschlüsselung. Also wie ich schon gesagt, selber Key für gleiche Kommunikationspartner ist relativ schnell, geeignet für große Datenmengen, wenn man den richtigen Betriebsmodus benutzt. Man unterscheidet dann auch, es gibt neben den Blockschiffrinnen, gibt es noch Stromschiffrinnen. Für Stromschiffrinnen braucht ihr keinen Betriebsmodus erst mal. Und Stromschiffrinnen liefern quasi einfach ein beliebig langen Schlüsselstrom, mit dem dann im zweiten Schritt die Nutztaten verschlüsselt werden, denen sie quasi einfach mit einer Exo-Verbindung verknüpft werden mit dem Schlüsselstrom. Und nachher zum Entschlüsseln wird einfach nochmal der verschlüsselte Text, also der Cyphertext, mit demselben Schlüsselstrom nochmal mit exo verknüpft, dann fällt hinten wieder der Klartext raus. So, jetzt haben wir immer noch das Problem, wir haben nur symmetrische Verschlüsselung und da kann man diesen Schlüssel ja nicht irgendwie übers Internet verschicken. Das Internet ist böse und sonst kann jeder mitführen und das ändern und das will man ja nicht. Also brauchen wir ein Key-Exchange-Verfahren. Da gibt es jetzt verschiedene zur Auswahl. ASA, da kommen wir später zu, das ist jetzt hier nicht erklärt. Ansonsten ist das verbreiteste Diffie-Helmen und Diffie-Helmen, da gibt es noch verschiedene Abstufungen davon, das gibt es mit statischen Keys, mit dynamischen Keys, mit elliptischen Kurven ohne elliptische Kurven. Hier drüben, hier seht ihr einmal, so die, das ist ganz einfach mit Farben erklärt. Es gibt auch sich YouTube-Videos, die das schön erklären. Im Wesentlichen einigen sich ganz am Anfang die beiden Kommunikationspartner, also Server und Client, bzw. CC Alice und Bob, auf eine gemeinsame Farbe beziehungsweise eine zufällige Zahl. Dann werden sie sich danach, jeweils eine eigene, also wird jede Seite sich eine eigene zufällige Zahl ausdenken, die sie aber für sich wählt, die sie erst mal nicht rüber schickt. Was sie aber tut, sie verknüpft diesen eigenen Private-Gin, dann wird das mal verknüpft, das oben mit dieser gelben Farbe, die beide gemeinsam haben. Und dann kommt auf beiden Seiten unterschiedliche Mischungen raus, wo aber jeweils immer ganz oben das gelb und das rot beziehungsweise gelb und dieses Turkeys da drin ist. Die können sie jetzt übers unsicher Internet übertragen, weil wir davon ausgehen, dass man diese Farben zwar sehr einfach mischen, aber nicht mehr entmischen kann. So, und jetzt, wenn ihr gut aufgepasst habt, seht ihr, dass jetzt hier dieses Turkeys von Bob von Alice gewandert ist in dieser Mischung drin. Und das Rot von Alice ist rüber zu Bob gewandert. Aber halt beides mal immer mit diesem gelb gemischt. So, und wenn die jetzt beide nochmal ihre eigene Farbe jeweils dazu mischen, dann kommt nachher auf beiden Seiten die selbe Farbe raus, also der selbe Key. Und trotzdem kann jemand, der das mitgelesen hat, diesen Key nicht selber nachmischen, weil er diese geheimen Farben oder diese geheimen Zahlen nicht hat, diesen Private Key halt nicht hat. So, das führt uns zu einem etwas weiteren Feld. Diese Schlüsselaustauschverfahren, die sind eine Teildisziplin von asymetrischer Kryptografie. Eine andere Anwendung davon, da kommen wir später noch zu. Im Wesentlichen ist das das wichtigste Merkmal von asymetrischer Kryptografie, dass ihr nicht einen Schlüssel habt, sondern dass ihr immer zwei Schlüssel habt, beziehungsweise ein Schlüsselpaar und zwar für jeden Kommunikationspartner. Wir haben also jetzt ein asymetrisches Verfahren. Das kann man vollenermaßen benutzen. Das, was man an bestimmten Personen schicken will, von dieser Person muss man dann diesen Public Key, also wie ihr das vorhin in dieser Grafik gesehen habt, diese rot, beziehungsweise türkis und diese gelbe Farbe. Und der Kleint hat auch nochmal den Public Key und den Private Key. Beziehungsweise der Kleint bei TLS nachher, muss ihr das nicht haben, aber das führt jetzt zu weit. Wir haben also jetzt ein asymetrisches Verfahren. Da muss man dann diesen Public Key haben. Das verschlüsselt man mit dem Public Key von dieser Person. Und nur diese Person kann das dann mit dem eigenen Private Key, der zu dem Public Key gehört, wieder entschlüsseln. Da haben wir natürlich immer noch das Problem, wir müssen diese Public Keys über das Internet übertragen. Und das, was wir jetzt vorhin hatten, das ist zwar ganz gut, um irgendwie einen zufälligen Schlüssel auszuwählen, aber dieser zufällige Schlüssel ist halt im Regelfall nicht so ein Public Key, der irgendwie brauchbar wäre. Wir müssen noch etwas anderes ausdenken. Außerdem haben wir das Problem, dass asymetrische Kryptografie sowohl dieser Schlüsselaustausch wie auch generell asymetrische Kryptografie Verfahren in der Regel sehr langsam sind. Und in der Regel funktionieren die auch nur mit Datenmengen, die kürzer sind als die Nutzdaten, die verschlüsselt werden sollen. Das heißt, da müssen wir auch nochmal uns noch etwas Besseres ausdenken. Was man aber machen kann mit dieser asymetrischen Kryptografie, man kann das auch benutzen, nicht nur zum Verschlüsseln, sondern auch zum Signieren. Und im Wesentlichen ist das Prinzip ganz einfach. Man dreht einfach diese asymetrische Kryptografie quasi um. Das heißt, man verschlüsselt es quasi mit seinem eigenen Private Key und dann kann jemand anders nachprüfen, ob es von einem selber signiert wurde, indem er das mit dem Private Key verschlüsselte, mit dem öffentlichen Schlüssel, von dem er wieder entschlüsselt. Und wenn der andere sich sicher ist, dass ein bestimmter öffentlicher Schlüssel mit jemand anderem, dann kann er so quasi nachvollziehen, ob du eine Nachricht unterschrieben hast oder nicht. Jetzt haben wir aber immer noch das Problem, dass diese Nachricht nicht länger sein darf, als der Private Key mit dem es verschlüsselt bzw. signiert wird. Also müssten wir irgendwie was finden, wo wir längere Nachrichten mit signieren können. Und dafür gibt es kryptografische Hesches. Das hat wahrscheinlich hier schon mal von Char1 oder MD5 oder Char256 oder so gehört. Letztlich sind das Verfahren, wo ihr ein input beliebiger Länge reinpacken könnt. Und nachher fällt immer ein Output raus, der immer exakt dieselbe Länge hat für dasselbe Verfahren. Also bei MD5 zum Beispiel 128 Bit oder bei Char256 sind es 256 Bit. Und eine sehr schöne Eigenschaft ist, die sich auch schon ein bisschen aus dieser Beschreibung ergibt. Man kann zwar sehr einfach und sehr schnell diesen Hesch rechnen von einem bestimmten Input, aber man kann halt im Idealfall gar nicht zurückrechnen mit einem Output zu dem Input. Also man kann einen Brutforce-Angriff natürlich probieren, aber es gibt keine Möglichkeit von einem Hesch schneller als mit Brutforce zurückzurechnen auf diesen Klartext. Und was wir jetzt natürlich machen können ist, wir nehmen diesen Hesch. Der Hesch hat im Optimalfall maximal dieselbe Länge wie der Private Key, den wir mit uns sind. Und jetzt können wir einfach diesen Hesch signieren. Und wenn wir den Hesch signieren, haben wir quasi so eine Art Fingerabdruck oder so eine Prüfsummer, wie man es auch immer nennen will, die wir eigentlich signieren wollen. Und damit haben wir jetzt quasi schon digitale Signaturen. In der Praxis ist es noch ein bisschen komplizierter. Da wird noch etwas namens Padding benutzt. Das habe ich jetzt hier weggelassen, weil der Talk sonst zu lang wird. So, jetzt haben wir digitale Signaturen. Wir könnten jetzt mit diesen digitalen Signaturen zum Beispiel Public Key signieren. Jetzt haben wir aber noch das Problem, wir können die zwar signieren, aber dann muss die Gegenseite natürlich immer noch wissen, wer da jetzt was signiert hat und wie man trauen kann und wie nicht. Bei TLS löst man das dadurch, dass man sowas wie Notar hat. Das nennt man bei TLS ein Certificate Authority. Diese Certificate Authority hat quasi als Geschäftsmodell, dass ihr Public Key zusammen mit ein paar Informationen, welche Certificate Authority es ist und wie lange dieser Schlüssel gültig ist in allen möglichen Betriebssystemen und Browsern und Telefonen und was der Geier, was noch alles quasi eingebaut ist und mitgeliefert wird. Wenn jetzt der Public Key von derselben Certificate Authority auf vielen verschiedenen Rechnern verteilt ist, dann können alle diese Rechner quasi Certificate benutzen, die von dieser Certificate Authority beglaubigt ist oder unterschrieben ist und können sich über diesen Umweg dann quasi gegenseitig miteinander erst mal Certificate rumschicken und sicher sein, dass das Certificate, was sie von der Gegenseite geschickt kriegen, auch wirklich der Gegenseite gehört. Weil in dem Certificate nicht nur der Public Key steht, sondern da steht noch drin, wem das gehört bzw. wenn das im Server gehört, was für eine Domain der Server hat und wie lange dieser Schlüssel gültig ist. Jetzt spielen wir ein bisschen Kryptolego. Was wir bis jetzt haben, wir haben symmetrische Kryptografie, wir haben Schlüsselaustausch, wir haben digitale Signaturen. Schmeißen wir das alles mal zusammen. Wir haben eine Verbindung auf zum Server, wie man dazu im Web oder auch sonst, wo TLS üblicherweise benutzt wird, kennt. Der Client, der handelt mit dem Server ein gemeinsames Geheimnis aus. Das ist wie vorhin diese Farben, was dann unten dieses Brauen rausgekommen ist. Das wäre quasi ein gemeinsames Geheimnis. Bei TLS ist es ein bisschen komplizierter in der Praxis, aber wir nennen es jetzt mal vor einfach Master Secret kommt da raus, dieses Geheimnis. Aus diesem Master Secret kann man dann zum Beispiel einen Schlüssel ableiten, den man für AIS-Verschlüsselung oder für eine andere symmetrische Verschlüsselung benutzen kann. Und dann kann man schon, hat man quasi schon ein Verschlüsseling-Kanal mit der Gegenseite, über den man relativ schnell seine Daten halt schicken kann. Jetzt haben wir aber noch ein Problem. Wir merken nicht, wenn irgendjemand an dieser Übertragung rummanipuliert. Also was passiert zum Beispiel, wenn irgendwo ein Paket verloren geht wenn irgendjemand absichtlich an diesem Verschlüsselten da und zwar, was passiert, wenn da irgendjemand absichtlich da rumfuscht. Das werden wir dann irgendwie merken können. Dafür brauchen wir einen weiteren Baustein, das nennt man Message Authentication Code, kurz MAC. Der funktioniert vollendermaßen. Wir benutzen quasi diese Hashes, also das ist eine Möglichkeit. Es gibt zig verschiedene Varianten, wie man so ein MAC aufbauen kann. Eine der häufigsten ist, dass man das auf so ein Hash basiert. Und letztlich ist es ein bisschen vereinfacht gesagt, man hascht quasi die Daten, die man absichern will und hascht zusätzlich noch einen geheimen Schlüssel, den der Angreifer nicht kennen kann. Und am Ende können beide Seiten, die die Daten austauschen, einfach diesen Hash nochmal berechnen und ihren Schlüssel, auf den sie sich geeignet haben, beim Hash noch mit reinschmeißen. Und wenn danach derselbe Hash, also der selbe MAC, dann können sie dann drüber sicherstellen, dass diese Übertragung nicht manipuliert wurde, dass die halbwegs sicher ist. Anmerkungen am Rande. Bei neuen TLS-Versionen gibt es noch zusätzliche Krypto-Verfahren für die symmetrische Krypto, die die Funktion von dem Hash gleich miterledigen. Das ist dann ein bisschen schneller und effizienter und es hat auch noch ein paar andere Vorteile, auf die ich jetzt jeden Tag nicht eingehen werde. Also, jetzt haben wir also schon quasi alles, was wir brauchen für so eine TLS-Verbindung. Jetzt könnte man natürlich sagen, können wir diesen Key-Exchanger optimieren. Weil der Server, der hat ja schon ein Zertifikat. Das Zertifikat hat ein Public Key. Man könnte doch einfach hingehen und sagen, der Kleint, der denkt sich irgendein Schlüssel aus, irgendein Master Secret, verschlüsselt den mit dem Public Key des Servers und schickt diesen verschlüsselten IS-Schlüssel zum Beispiel an den Server. Und der Server kann ja nur der Server dann das entschlüsseln, weil nur der Server den Private Key zu diesem Public Key hat. Das gibt es auch tatsächlich, dieses Verfahren. Wenn ihr das benutzt, dann habt ihr keine Forward Secrecy. Was nämlich dann passieren kann, ist, wenn der Server gehackt wird und das Zertifikat was der Server hat, bzw. der Private Key zu dem Zertifikat, wenn der kompromittiert wird, dann kann man rückwirkend TLS-Verbindungen entschlüsseln. Das heißt, wenn Angräufe zum Beispiel die NSA oder sonst irgendein Geheimdienst auf Vorrat verschlüsselte Verbindungen mitgeschnitten hat, dann kann man die nachträglich entschlüsseln, wenn man an diesen Private Key kommt. Und das ist ein Problem, was man am Anfang mit diesem Key-Exchange-Verfahren nicht hat. Weil da werden diese temporären Daten oder diese zufälligen Schlüssel, die da mit Einfließenden in die Berechnung, die werden einfach weggeschmissen nach jedem Key-Exchange, die werden nicht gespeichert. Im Optimalfall, wenn man es richtig macht. So, jetzt können die Leute, die Vorkenntnis in Krypto-Horten langsam wieder aufwachen. Jetzt kommen wir zu den eigentlichen Bausteinen, was man so in TLS zu ausfällt. Also erst mal TLS selber. Von dem Protokoll gibt es sich verschiedene Versionen. Das ist das, was man in TLS ausfällt. Das ist das, was man in TLS ausfällt. Von dem Protokoll gibt es sich verschiedene Versionen. Wie ihr schon seht, eigentlich will man nur die zwei Letzten gebrauchen. Also SSL 1.0, das wurde eigentlich nie wirklich veröffentlicht. Ich bin nicht ganz sicher, aber ich glaube, das war so kaputt. Der Mensch, der sich das ausgedacht hat, der hat das irgendwie mal vorgestellt auf irgendeiner Konferenz. Und da saß ich jemandem im Publikum, der sich auch mit so kam, ein bisschen auskannte. Und der hatte irgendwie während dem Talk noch da mal kurz ausgeschränkt, von, oh, Scheiße, doch. Da war SSL 1.0, glaube ich, schon gegessen. SSL 2.0 hat es ein bisschen weiter geschafft. Das kennen Leute, die im Elthrill Internet Explorer in den Konfigurationen rumgedoktert haben, vielleicht noch. Das ist aber auch komplett kaputt. Das ist auch nicht zu retten. SSL 3.0, das war so das erste, was ein bisschen länger gehalten hat, was am Anfang nicht komplett kaputt aussah. Das hat dann auch ein bisschen gedauert. Das ist aber jetzt vor, mehr so in fünf Jahren oder so. Das ist vor ein paar Jahren jetzt auch soweit auseinandergefallen, dass man es gar nicht mehr benutzen sollte oder darf. Dann gibt es TLS 1.0 und 1.2. Das sind kleine Verbesserungen gegenüber SSL 3.0. Das hat aber immer noch erhebliche Nachteile. Zum Beispiel kann man bei TLS 1.0 und 1.1 keine zeitgemäßen Algorithmen für den MAC bzw. für die SESH Algorithmen benutzen. Da kann man nur sehr alte Sachen, D5 und SESH 1.0 basieren benutzen. Und das ist halt ihr gammelig und unsicher. Deswegen will man eigentlich TLS 1.0.2 oder TLS 1.0.3 am besten direkt. Problem ist, TLS 1.0.3 wird bis jetzt erst von der allerneuesten OpenSSL-Version unterstützt. Und wenn ihr irgendwo so eine stabile Distro auf euren Servern laufen habt, dann hat die wahrscheinlich noch kein aktuelles OpenSSL drin. Leute, die Rattled oder Centers benutzen, die können sich freuen. Und wenn die Rattled nach draußen kommen, das wird dann endlich auch OpenSSL 1.1.1 drin haben. Bei Ubuntu gab es mal Gerichte, dass sie eventuell irgendwann das nachreichend für Ubuntu 1804, das scheint aber bis jetzt auch nicht wirklich zu passieren. Das heißt, bei Ubuntu müsst ihr im Zoffersfall auch noch ein Jahr warten, bis da eine brauchbare OpenSSL-Version kommt. Aber bis dahin könnt ihr TLS 1.0.2 benutzen und wenn man das richtig konfiguriert, dann ist es auch durchaus brauchbar. So, dann kommen wir zu den Cipher Suits. Cipher Suits ist quasi einfach die Kombination immer von diesen Kryptobaustein, die ich am Anfang erklärt habe, also symmetrische Krypto, das Verfahren mit dem Zertifikate signiert werden bzw. das Verfahren auf dem Zertifikat selber basiert und dem MAC Verfahren. Quasi diese Kombination aus den Allen, das nennt man Cipher Suits, man kann die nicht beliebig mischen. Es gibt dann eine Liste von Sachen, die erlaubt sind. Die könnt ihr bei der IANA unterladen, also so eine Schwesterorganisation in der ITF, die hat so eine Registry, wo ihr Bildschirm seitenweise so Cipher Suits nachlesen könnt. Dann Moment, muss ich mein eigenes Slide nochmal lesen. Auch ja, dann bei den Cipher Suits ... doch, ja. Der erste Teilbaustein quasi von der Cipher Suits ist das Verfahren mit dem das Zertifikat erstellt wird bzw. der Schlüsseltyp auf dem das Zertifikat basiert. Am allerverbreitetsten sind RSA-Zertifikate, also da habt ihr einfach ein RSA-Schlüsselpaar. Es gibt aber auch Zertifikate, die auf eliptischen Kurven basieren, das nennt man dann ECDSA-Zertifikate, also Elliptic Curve Digital Signature Algorithm. Es gibt auch, wenn schon mal jemand mit Gnoupige oder so rumgespielt hat, es gibt auch noch eine Version von DSA ohne eliptische Kurven. Die ist mathematisch relativ ähnlich, hat aber in der Praxis das Problem, dass es kaum Implementierungen gibt, die eine akzeptable Schlüssellänge benutzen können. Also die hat nur eine Schlüssellänge von maximal 1.024 Bit, was für normales DSA furchtbar unsicher ist und was man nicht benutzen will. Bei RSA zum Beispiel, muss man heutzutage mindestens eine Schlüssellänge von 2.048 Bit benutzen. Auch das wird wohl nicht mehr anzulangen halten. Also nehmt lieber ein bisschen mehr 4.096 Bit bewährt in der Praxis. Bei ECDSA haben wir den Vorteil, weil das auf eliptischen Kurven basiert, kann man damit sehr viel kleineren Schlüssellängen arbeiten, um trotzdem dasselbe Sicherheitsniveau zu erreichen. Also unterm Strich kann man quasi sagen, bei ECDSA nimmt man einfach die doppelte ungefähr die doppelte Schlüssellänge von dem, was man für die symmetrische Krypto nimmt. Das heißt, wenn ihr AES128 nehmt, dann nehmt ihr eine Kurve, die 256 Bit lang ist. Für AES256 haben wir das Problem, es gibt zwar eine Kurve, die sogar ein bisschen länger ist als 512 Bit. Diese Kurve ist aber nicht zugelassen, um sie für Zertifikate zu benutzen. Also ihr könnt zwar selber Zertifikate euch ausstellen damit. Diese Kurve heißt P521, nicht P512. Damit könnt ihr euch eigene Zertifikate ausstellen, aber ihr werdet damit keinen Zertifikat kriegen, zum Beispiel von letzten Krypto oder von irgendeiner Zertifika Authority, der so ein üblicher Rechner vertraut. Da habt ihr quasi nur die Waren zwischen diesem P256 und einer Kurve namens P384. Die korrespondiert eigentlich Rechnerich eher zu 192 Bit, aber bei TLS hat sich irgendwie keiner die Mühe gemacht. TLS mit AES192 Bit zu spezifizieren, da gibt es nur 256 Bit oder 128 Bit in der Praxis heutzutage noch. Ein weiteres Problem ist noch, dass diese beiden Kurven, sowohl P256 als auch P384, die sind ein bisschen umstritten, weil die kommen eigentlich mal von der NSA und da gibt es Gerüchte, ob die NSA da eine Hintertür drin hat oder nicht. Ich persönlich glaube ihr nicht, aber da kann man sich lange drüber streiten. Es ist aber unabhängig davon, ob die NSA eine Hintertür drin hat oder nicht, haben diese Kurven auch ein paar mathematische Probleme, die die Implementierung relativ schwierig machen. Es ist sehr einfach, sich, wenn man diese Kurven implementiert, in den Fuß zu schießen und da Fehler zu machen. Ein relativ prominentes Beispiel, wo das mal passiert ist, ist vor ein paar Jahren, als die PlayStation 3 gejailraid wurde, die haben auch eine von diesen Kurven, ich weiß mehr welche, aber eine von diesen Kurven auch benutzt. Man muss bei diesen Kurven, wenn man damit irgendwas signiert, muss man für jede Signatur immer Zufallsdaten in die Begründung. Und diese Zufallsdaten, die müssen für jede Signatur anders sein, auch wenn man die selben Sachen signiert, quasi für jede Signatur immer neue Zufallsdaten. Das hat Sony irgendwie verkackt, die an Zufallszahlgenerator, glaube ich, der nicht ganz so zufällig war. Und dann ist am Ende, wenn das passiert, dann kann man am Ende ein Verfahren benutzen, wo man ein bisschen Rechnerei dann den Privacy zu dem Publiki rauskriegt und dann kann man die Signatur auch in der Begründung machen. Aber wenn man das richtig implementiert hat, wenn man an ständigen Zufallsdatengenerator benutzt, dann ist man vor diesem Problem gefallet. In Zukunft wird es hoffentlich noch Nachfolge geben, namens ED-DSA. Der ist von einem Kryptologen namens Daniel J. Bernstein, der hat sich die ausgedacht. ED-DSA ist erstmal nur ein genetischer Nachteil, die die beiden NSA-Kurven haben nicht mehr. Allerdings, bis jetzt sind diese neuen Kurven leider noch nicht zugelassen für Zertifikate, das heißt, ihr kriegt im Moment noch keine Zertifikate, die damit signiert sind und könnt auch selber, ja, ihr könnt euch selber mit ein bisschen Bustly welche ausstellen, dann habt ihr immer noch das Problem, dass im Moment kein Browser-Unterstützung für diesen Schlüsseltyp implementiert hat. So, dann kommen wir zum Schlüssel- Nachteil. Wir hatten vorhin schon gesagt, RSA ist scheiße. Dann Diffy-Helmen und Diffy-Helmen mit elliptischen Kurven ist auch dann scheiße, wenn man es nicht mit zufälligen Schlüssel benutzt, sondern wenn man quasi statische Schlüssel benutzt. Das Verfahren haben früher irgendwelche Leute benutzt, warum weiß man nicht, weil es bietet keinerlei Vorteile, es macht nur zusätzlich einen Aufwand. Also wenn man das mit statischen Schlüssel benutzt. Was ein bisschen besser ist, ist Diffy-Helmen mit ephemeral keys nennt man dort, also mit zufälligen Schlüssel, die man nach ihm Schlüssel auch schweckschmeißt. Allerdings hat das das Problem, dass es halt relativ langsam ist. Es braucht relativ viel CPU-Zeit und man kann sich auch da ein bisschen in den Fuß schießen, weil man sollte, wenn man das benutzt, eine sogenannte, das ist ein bisschen schwierig zu erklären, eine sogenannte Diffy-Helmen-Gruppe also quasi, das nennt man einen Zahlenkörper, also so ein mathematisches Konstrukt, auf dem quasi die ganzen Berechnungen für die Verschlüsselung und Entschlüsselung stattfinden. Es gibt da ein paar sehr alte standardisierte Gruppen, die bei Apache und ich glaube auch EngineX und bei allen möglichen Softwareprodukten eingebaut sind. Die sind aber alle ja wackelig und nicht so besonders toll. Man kann sich das auch selber generieren, so ein Ding und quasi selber eine Gruppe da mitschicken. Auch da kann es theoretisch passieren, dass da Schwachstellen drin sind, die man so einfach nicht findet, weil man da relativ lange drauf rumrechnen müsste und es dauert, wenn schon mal jemand von Azure selber gemacht hat, schon alleine so eine Gruppe zu erzeugen oder halt, wenn die eine anständige Länge hat, Ewigkeiten. Es gibt allerdings seit, ich glaube, 203 Jahren gibt es von der IETF eine Spezifikation, wo einige Gruppen gesagt haben, die besser geprüft sind und die man, denke ich, benutzen kann, ohne dass man sich groß Sorgen machen muss. Das sind die sogenannten FF-DHI-Gruppen hier für Finite Field, Diffie Helman, ephemeral. Wie gesagt, Diffie Helman auch mit ephemeral Keys ist aber immer noch relativ langsam. Also was man eigentlich haben will, ist Diffie Helman mit ephemeral Keys auf elliptischen Kurven. Das ist dieses ECDHI. Das wird auch von allen heutzutage relevanten OpenSSL-Versionen und so weiter unterstützt. Also eigentlich könnte 99% der Clients, die man so abdecken will, damit erreichen und das letzte Prozent hat dann halt Pech gehabt und soll endlich mal seine scheiß Büchsen updaten. So. Liptische Kurven stellt sich natürlich auch die Frage, da kann man auch wieder verschiedene Kurven auswählen. Da kann man auch wieder oben diese NSA-Kurven nehmen. An der Stelle auch diese P521-Kurve, die man für Zertifikate nicht benutzen darf. Und da kann man mittlerweile auch diese neueren Kurven benutzen. Diese EDDSA-Kurven. Beziehungsweise es ist nicht wirklich EDDSA. Eigentlich ist es mathematisch dieselbe Kurve in der anderen Darreichungsform, in der anderen Darstellung, weil das bei der Implementierung einige Sachen einfacher macht und einige Probleme verhindert. Letztlich ist aber hier dieses X 448 und was ich vorhin erwähnt hatte dieses EDD, 448, das ist letztlich gleiche Kurve wie gesagt, nur in der anderen Darreichungsform und dasselbe gilt auch für dieses X 25519. In der Praxis ist es so, dass dieses X 25519 mittlerweile von allen aktuellen Browsern implementiert wird. Also Firefox, Chrome, Internet Explorer glaube ich auch, die können das alle. X 448, das wird bis jetzt noch nicht so verbreitet. Das wird von OpenSSL wenn die OpenSSL 1.1.1 habt und ich glaube auch 1.1.0 wird es unterstützt. Bei anderen Libraries NSS müsste es auch können, wenn man von Firefox benutzt wird bei anderen Libraries da bin ich mir nicht ganz so sicher. Im Zweifelsfall ist es immer am besten, ihr könnt, wenn ihr halbwegs aktuellen Web Server habt, dann könnt ihr eine Liste mit Kurven spezifizieren und da könnt ihr auch quasi eine Reihenfolge vorgeben in der diese Kurven abgearbeitet werden sollen oder ausprobiert werden sollen und da würde ich raten, dieses X 25519 oder auch dieses X 448 ganz vorne hinzustellen und dann dahinter erst diese zusätzlichen Kurven reinzuschreiben. Ein Problem ist noch, es gibt Leiner relativ viele Handys mit Android 8.0 und Android 8.0 ist scheiße, weil das hat ein Bug der dazu führt, dass nur diese P256 Kurve unterstützt. Wenn ihr damit irgendeine andere Kurve um die Ecke kommt, dann fällt das Ding auseinander und funktioniert nicht mehr richtig. Beziehungsweise kriegt einfach ein ich glaube ein Zertifikat und ich sage gerade nicht ganz sicher, ob es für die Schlüsselaushandlung war oder für Zertifikate, auf jeden Fall an einer von den beiden Stellen unterstützt Android 8.0 diese anderen Kurven alle nicht und da muss man ein bisschen aufpassen sonst kriegt man da jedenfalls auf den Android-Geräten ein Zertifikatsfehler oder ein Fehler beim TLS Verbindungsaufbau. So, dann kommen wir endlich mal zu symmetrischen Verschlüsselung ganz oben ist der ganz alte Scheiß den will man alles nicht haben. Der einzige Use Case, wo man das oben vielleicht noch benutzen würde das ist, wenn man sehr, sehr, sehr, sehr alte Hardware hat. Also sowas wie ein 15 Jahre alten Print-Server oder irgendwelche Kisten, wo noch Windows XP drauf läuft weil die können nichts Besseres. Ansonsten ein bisschen neuer, aber immer noch uralt ist AIS-MCBC-Modus das ist das, was man so ab ich glaube ab TLS 1.0 fast überall oder TLS 1.1 glaube ich sogar vorgeschrieben überall benutzt hat. AIS-MCBC ist ein Modus der ist er hat ein paar Probleme der ist nicht katastrophal kaputt aber er ist kaputt genug, dass man eigentlich was Besseres benutzen will. Außerdem hat er den Nachteil, dass er relativ langsam ist, weil man kann das nicht parallelisieren. Es gibt da andere Modi die wesentlich schneller und effizienter sind und auch ein bisschen bessere Sicherheit bieten. Da wäre insbesondere halt diese AIS-GCM zu nennen. Das ist AIS in einem Betriebsmodus der ist quasi erlaubt auch diesen Mac den ich vorhin erklärt hatte wegzurationalisieren. Also da macht quasi die Verschlüsselung kümmert sich auch gleich drum, dass niemand bei der Übertragung an den Verschlüsselndaten rumfuscht und irgendwas manipulieren kann. Außerdem hat AIS-GCM den Vorteil, dass es parallelisierbar ist und dadurch halt extrem schnell sein kann. Also ich hab mal Benchmarks gefahren selbst auf so ein Laptop wie hier mit nur einem Thread auf nur einer CPU die CPU hier hat jetzt AIS-NI also Hardwarebeschleunigung für AIS da kann das Ding ich weiß nicht mehr was es war, ich glaub 30 Gigabit pro Sekund oder so durchprügeln auf einem Thread wohl gemerkt und das Ding hat 6 Threads, also da kann man Spaß mit haben. Eines der Probleme bei AIS ist AIS wird ein gutes Stück langsamer wenn es Moinshifter implementiert ist wenn es keine Hardwarebeschleunigung gibt. Das hat man zum Beispiel auf L-Trinnen oder billigeren Smartphones wenn ein Router zu Hause stehen hat irgendwie eine Fritzbox oder irgendwas wo ihr WT drauflaufen habt oder so die haben sehr oft keine Hardwarebeschleunigung für AIS oder nur sehr langsame Hardwarebeschleunigung für solche Fälle empfehle ich Chacha 20 mit Poly 1305 als Mac Chacha 20 das ist eine Stromschiffer also der arbeitet nicht mit Blöcken sondern liefert halt so einen Schlüsselstrom das ist eine Schlüsselung die auch von diesem Daniel J. Bernstein sich ausgedacht wurde also letztlich sind wir mittlerweile so weit dass wenn man es drauf anliegt könnte man TLS komplett nur noch mit Kryptobausteinen von Daniel J. Bernstein bauen und es wäre wahrscheinlich auch relativ sicher und würde relativ gut und schnell funktionieren Chacha 20 das funktioniert sogar auch auf ganz kleinen und ganz ganz langsam Embedded Geräten wirklich schnell also da könnt ihr irgendwie 20 Euro TP-Link WLAN-Router nehmen der irgendwie 150 MBit kann und irgendwie eine gammelige 600 Mhz MIPS CPU oder so drin hat und selbst der wird damit zumindest noch 100 MBit pro Sekunde an Cypher Text problemlos durchschieben können wenn ihr auf dem Ding AIS benutzt dann werdet ihr bei AIS wahrscheinlich so, ich weiß nicht ein Zehntel der Leistung ungefähr rauskriegen oder ein 20. der Leistung wie Chacha 20 wer wenn ihr kein AIS-NI zur Verfügung habt dann wer Chacha 20 vorzuziehen allerdings sollte man in der Praxis berücksichtigen für wen man optimieren will will man für den eigenen Server optimieren weil man sieht, dass da die CPU zu viel zu tun hat und die CPU ein bisschen entlasten will was bei TLS in der Praxis aber eigentlich so gut wie nie vorkommt oder will man so optimieren dass die Endnutzer nachher auf ihren Geräten möglichst eine schnelle Verbindung haben Verschlüsselung und der ganze Kryptogramm das ist alles CPU-Zeit das kostet alles Strom, das heißt geht alles auf den Akku und was man da zum Beispiel machen könnte ist wenn man eine normale Seite eine Mobilseite hat für Smartphones und Tablets und so ein Scheiß dann kann man für diese Mobilseite diese Chacha 20 nehmen und für die Hauptseite das AIS-GCM, wo der ganze Traffic drauf schlägt und dann einfach Android, Clients oder IOS-Clients oder was es da sonst noch alles an mobilen Geräten gibt, kann man dann einfach weiterleiten auf die mobile Seite, wenn man die erkennt und dann sind quasi alle optimal versorgt was es bis jetzt da noch nicht gibt das ist, zumindest Opensfußbereich hab ich das noch nicht gesehen das ist eine Möglichkeit, dass das OpenSSL zum Beispiel auf dem Server selber entscheidet ob es so abhängt davon was für eine Liste an unterstützenden Verschlüsselungen der Kleine die ihm schickt, ob es IES oder Chacha 20 vorziehen soll es gibt entweder die Möglichkeit, dass der Server komplett bestimmt was benutzt wird oder dass der Server einfach dem client die freie Auswahl lässt, in der Praxis benutzt man meistens die Variante, dass der Server alles vorgibt wenn man das aber benutzt, dann muss man sich als Dich in einem von beiden entscheiden so, dann zu den Macs Macs werdet ihr im Optimalfall wahrscheinlich gar nicht brauchen also wenn ihr Authenticated Encryption benutzt dann werden Macs quasi gar nicht mehr gebraucht beziehungsweise dieses Poly 19 05 natürlich bei Chacha 20 aber für IES-GCM braucht ihr dann eigentlich keinen weiteren Mac es steht zwar in den Namen der Ciphersuit, es steht dann immer noch hinten den Mac, hinten dran, aber meines Wissens wird der glaube ich gar nicht mehr oder fast gar nicht mehr benutzt naja auf jeden Fall was Macs angeht MD5 will man natürlich auf gar keinen Fall haben SHA1 ist heute noch halbwegs verbreitet sollte man aber auch schauen, dass man davon wegkommt, also es ist nicht ganz so schlimm wie wenn ihr jetzt Zertifikate habt, die mit SHA1 signiert sind, aber im Zweifelsfall will man lieber SHA296 oder SHA384 haben oder halt gleich Chacha 20 mit Poly 1305 so, dann nächstes Problem was passiert eigentlich, wenn das Zertikat kompromittiert ist, wir hatten das Problem ja vorhin schon mal kurz angesprochen da gibt es eigentlich keine wirklich schöne Lösung dafür bis jetzt z.B. es gibt schöne Lösungen, die aber nicht verbreitet sind oder nicht überall implementiert sind was man ganz am Anfang gemacht hat da haben die einzelnen Certificate Authorities Listen publiziert, auf denen einfach die ganzen Zertifikate, die kompromittiert waren oder sonst viel gesperrt werden sollten draufstanden, diese Listen die wurden von der CA signiert Problem ist seit es jetzt seit ein paar Jahren immer mehr HTTPS Seiten gibt gibt es, sind diese Listen auch immer größer geworden und wenn so eine Liste halt irgendwie 10 Megabyte oder 50 Megabyte oder was auch immer hat und euer Browser müsste eigentlich jedes Mal wenn er irgendeine Seite abruft diese Liste neu runterladen oder zumindest jedes Mal wenn er gestartet wird oder am anderen Tag dann könnte das vielleicht für eine CA noch funktionieren aber euer Browser vertraut in der Regel einigen 100 CA und wenn ihr für jede von diesen einigen 100 CA nur 10 Megabyte runterladen müsstet dann macht ihr ansonsten nichts anderes mehr den ganzen Tag deswegen skaliert das nicht deswegen benutzt man das in der Praxis nicht mehr dann gab es eine kleine Verbesserung des Verfahrens da hat sich jemand gedacht ja wir können noch den Browser sagen dass der Browser einfach ein Server von der CA direkt fragt ob das jeweilige Zertifikat noch gültig ist das hat man auch im Zeit lang gemacht allerdings hat sich dann rausgestellt es hat zum einen das Problem diese Server bei den CA sind nicht immer reichbar und das hat sich dann sicherlich mal ausgefallen und dann gibt es halt so Möglichkeiten entweder der Browser erzwingt dass er eine Antwort kriegen muss und dass da drinstehen muss das Zertifikat gültig ist das bedeutet wenn bei der CA der OCSP Server ausfällt dann funktionieren alle Webseiten nicht mehr die Zertifikate von dieser CA benutzen das ist also scheiße also hat man OCSP nicht mehr erzwungen und wenn es nicht erzwungen wird dann ist es komplett sinnlos weil dann kann ein Angreifer irgendwo der kann einfach diese OCSP von der CA unterdrücken und quasi so tun als wäre gerade der OCSP Server der CA nicht erreichbar und dann bringt OCSP ja nichts mehr dann war außerdem gibt es bei OCSP noch ein Problem die CA könnte also ihr sagt der CA ja quasi von welchem Zertifikat ihr wissen wollt ob das noch gültig ist oder nicht dadurch kann die CA natürlich sehr schön sehen wer auf welchen Seiten rum surft und Leute trecken das will man natürlich auch nicht haben um dieses Problem zu lösen hat man OCSP Stapling eingeführt dabei kümmert sich quasi der Server um OCSP der Server redet alle alle paar Stunden zum Beispiel mit der CA und vorsicht an eine neue Bestätigung von der CA dass ein Zertifikat noch gültig ist und auch alles ok ist und schickt diese Bestätigung immer unaufgefordert direkt mit dem Zertifikat mit raus zum Browser und dann kann der Browser das so prüfen das wäre eigentlich ein sehr schönes Verfahren das Problem ist es wird auch ein Browser normalerweise nicht erzwungen beziehungsweise bei Chrome haben sie bei Google Chrome haben sie sogar entschieden dass OCSP ihrer Meinung nach so komplett kaputt ist, dass sie gar nichts mehr davon implementieren wie der normales OCSP noch Stapling noch sonst irgendwas bei Firefox waren sie ein bisschen cleverer da haben sie OCSP Stapling zu implementieren aber es stand halt mäßig nicht erzwungen und dann ist jemand um die Ecke gekommen hat gesagt ja im Moment wird OCSP Stapling noch nicht erzwungen aber wir haben ja jetzt das Problem nicht mehr dass die Seiten nicht erreichbar sind wenn die CA Server nicht erreichbar sind weil der Server der kann sich seine Bestätigung ja Cajun also der eigene Server der das Zertifikat benutzt der kann sich ja diese Bestätigung von der CA einfach Cajun und kann die auch ausliefern wenn der CA Server nicht mehr erreichbar ist und dann könnten wir doch eigentlich ins Zertifikat direkt reinschreiben dass das Zertifikat nur gültig ist noch gültigen OCSP Bestätigung das nennt man dann Mast Staple das ist in der Praxis so weit ich weiß aber leider bis jetzt nur von Firefox implementiert und ich habe bis jetzt auch bei Google Kanaler Anstrengungen vernommen dass die im Vieh vorhin das mal zu implementieren das heißt im Moment ist es so mit diesem ganzen OCSP Kram könnt ihr Zertifikate zwar zurückrufen aber eigentlich nur für Firefox Chrome ist es eigentlich und ich glaube Windows mal ob die über OCSP zurückrufen sind oder nicht weil das alles so überhaupt nicht funktioniert gibt es eigentlich nur 2 Lösungen die eine seht ihr hier kurze Zertifikatslaufzeiten das ist einer der Hauptgründe warum ihr bei letzten Crypto noch Zertifikate mit 90 Tagen kriegt und nichts was länger dauert die andere Lösung ist die wird aber nur sehr selten aus dem Schrank geholt da haben quasi die einzelnen Browserhersteller in ihre Browser noch andere Methoden eingebaut also die haben quasi noch eigene Journalisten die der Browser von Browserhersteller runterlädt und regelmäßig aktualisiert und über diesen Mechanismus können die Browserhersteller wer bedarf auch sehr schnell Zertifikate sperren ohne dass sie über OCSP zum Beispiel zurückrufen werden müssen das wird aber in der Praxis glaube ich nur benutzt wenn ein Zertifikat von der CA kompromitiert ist weil man damit halt richtig viel Scheiße bauen könnte ein kompromitierten CA Zertifikat könnte man sich selber beliebige Zertifikate ausstellen und ansonsten wird das in der Praxis fast nicht benutzt vielleicht wird es benutzt werden keine Ahnung wenn irgendjemand das Zertifikat von Facebook oder Github oder so kompromitiert aber so für normale Wald- und Wiesenseiten wird es nicht benutzt weil es da auch nicht skalieren würde so dann haben wir noch ein paar kleinere Randphänomene, eins der Randphänomene sind User, User sind faul und User sind in der Regel auch zu faulen HTTPS in die Adresszelle zu zippen schöne Lösung wäre natürlich wenn der Browser einverstandert für HTTPS anstatt HTTP annehmen würde wenn man kein Protokoll angibt in der Praxis tun sie das aber nicht deswegen gibt es in der Praxis ein Mechanismus namens HTTPS das steht für HTTP Strict Transport Security damit könnt ihr quasi als Server den Browser sagen dass er für die nächsten X-Tage oder Monate oder Jahre mit dem Server, mit dem er gerade redet bzw. mit der Domain, mit der er gerade redet nur noch über HTTPS kommunizieren darf und wenn der User dann versucht unverschlusse HTTPS Verbindung aufzubauen dann wird der Browser die automatisch upgrade ohne den User zu fragen Bonus, der User kann auch wenn das Zertifikat zum Beispiel abgelaufen ist oder er irgendwie ein ungültiges Zertifikat da gezeigt kriegt vom Server, was ein anderer Feier machen könnte dann kann der User das nicht einfach wegkriegen, sondern der kommt einfach nicht mehr auf den Server bis da wieder ein gültiges Zertifikat kommt das ist zum Beispiel für Online Banking ein Feature was man da eigentlich haben will wenn die Banken nicht so inkompetent wären um das auszuruhen dann gibt es noch ein zusätzliches Feature ihr könnt HTTPS auch in eine Liste die HardCoded in den ganzen Bowsern mitgeliefert wird könnt ihr eure eigene Domain eintragen lassen allerdings weil das auch nur begrenzt skaliert hat man gesagt das macht man nur, wenn jemand sich committed, dass er nicht nur eine Domain sondern eine Domain inklusive aller Subdomains mit HTTPS ausliefert das heißt wenn ihr das nur für irgendwie einzelne Subdomain von eurer Domain machen wollt dann werdet ihr der HTTPS Preload nicht machen können da werdet ihr nicht in diese Liste reinkommen aber wenn ihr das für eure komplette Domain machen wollt dann ist das kein Problem in der Praxis in Guitars so dann nächstes Problem Mixed Content das wird eigentlich von dem HTTPS vorhin schon so ein bisschen erschlagen es gibt aber Fälle wo man dieses HTTPS nicht benutzen will oder kann aus irgendwelchen Gründen dann hat man das Problem, man hat vielleicht irgendeine alte Internetseite der noch Kram über HTTPS eingebunden ist und man will vielleicht nicht, das was weiß ich dass die Pornoseite über HTTPS geladen wird, aber die Videos oder die Bilder die man auf der Pornoseite schaut über HTTPS kommen weil dann bringt die Verschließung nicht viel da kann der Server dem Browser quasi sagen dass ja alle ungeschützten pan intended HTTPS Request automatisch zu HTTPS Upgraden soll anderes Problem ist noch Session Cookies die können komprimitiert werden wenn man nicht darauf achtet die können über HTTPS und über HTTPS verschickt werden und wenn der Angreifer es dann irgendwie schafft den Browser dazu zu bringen ein HTTPS Request mit seinem Session Cookie rauszuschicken, dann hat man halt das Session Cookie kompromitiert als Angreifer deswegen kann der Server für ein Cookie auch sagen dass das Cookie nur über HTTPS übertragen werden soll was man natürlich dann auch tun sollte so dann noch häufige Kritik wenn ich jetzt CAs vertraue dann kann die CA ja auch Schabernack treiben und irgendwelche anderen Zertifikate ausstellen, die ich nicht vertraue und damit könnte man dann theoretisch Leute abhören dagegen gibt's zwei Kräuter das eine Kräuter ist schon etwas welk, weil das wird glaube ich auch nur von Firefox unterstützt und bei Chrome ist es rausgeflogen von der Weile da kann der, das ist dies HPKP also HTTP Public Key Pinning da kann man quasi den Browser sagen, dass er für diese Domain nur noch Zertifikaten von einer bestimmten CA oder nur noch eine bestimmte Zertifikat vertrauen darf da haben sich aber Leute in der Praxis so oft in den Fuß mitgeschossen, weil sie sich von ihrem eigenen Server quasi ausgesperrt haben dass Google beschlossen hat das bei Chrome rauszuschmeißen und vermutlich wird es irgendwann auch bei Firefox rausfliegen ansonsten gibt's gegen diesen Missbrauch ein sehr viel effizienteres Mittel das ist Certificate Transparency das ist nämlich so, dass mittlerweile kommerzielle CAs gezwungen sind Zertifikate, die sie ausstellen in so öffentlichen Logs einzutragen das heißt jedes Zertifikat was irgendwie ausgestellt wird von Let's Encrypt oder von DigitZert oder sonst irgendeiner CA heutzutage das steht immer in öffentlich einsehbaren Logs drin diese Logs sind so gebaut, dass sie nicht manipulierbar sind und man kann einfach sich diese Logs anschauen und diese Logs monitoren ob Zertifikate für die eigene Domain ausgestellt werden da gibt's auch Dienstleister oder Online-Dienst über die man das machen kann und auch wegautomatisieren kann und es wurden auch schon CAs erwischt die unberechtigt Zertifikate ausgestellt haben die werden seit ein paar Jahren quasi nur noch über Certificate Transparency erwischt und wenn das mal passiert, dann kann es durchaus dann, dass die CA dann danach einfach weg vorm Fenster ist dann fliegt ihr aus dem Browsern-Row solid ihre Chefs Grundlage und könnt's zumachen so wie das zum Beispiel kürzlich mit WoSign und StartSSL passiert war ja, dann zweit letztes Slide was hier hier war jetzt relativ spezifisch für Web Server und HTTPS in der Praxis wird TLS natürlich auch noch für vielen anderen Graben benutzt, was sie generell immer machen wollen ist Compression abschalten Compression es gibt einmal, es gab früher Compression auf Niveau von TLS das ist mittlerweile, ich bin nicht ganz sicher ob es schon verboten ist, es wird auf jeden Fall glaube ich nirgendwo mehr benutzt und es gibt Compression auf HTTP Ebene das Problem daran ist, es gibt Angriffe wo ein Angreifer zum Beispiel den JavaScript in eurer Webseite hat und er kann über diese JavaScript über eure verschlüsselte Seite Anfragen schicken von denen der Angreifer den Clatext kennt und dann kann der Angreifer einfach Clatext schicken und schauen ob sich die Größe von dem Verschlüsseln Kram ändert und wenn die Größe dann kleiner wird als er es erwartet dann kann er daraus den Rückschuss ziehen was er schickt hat von denen er den Clatext kennt dieselben Daten sind die irgendwo anders in dem verschlüsselten Clatext den er noch nicht gesehen hat zu vorkommen und darüber kann er mit ein bisschen schwarzer Magie und Mathe und Rund probieren am Ende zum Beispiel Session Cookies erraten deswegen Compression immer abschalten dann gibt es so was die HTS mittlerweile auch endlich für Mail Server, das wird allerdings bis jetzt nur für ExSim unterstützt dann müsst ihr auf dem Mail Server zusätzlich noch ein Web Server laufen haben dass ein Dateien runtergeladen werde es wird jetzt hier ein bisschen zu weit führen aber es gibt mittlerweile technische Verfahren wo ihr erzwingen könnt dass ein Mail Server immer über TLS angesprochen wird Mail Server ist übrigens einer der wenigen Ausnahmen wo ihr auch gammelige Krypto unterstützen wollt weil im Zweifelsfall ist es immer noch besser wenn ihr gammelige Krypto unterstützt als wenn ihr gar keine Krypto unterstützt und die Sachen komplett unverschüsselt reinkommen Mail Server sind allerdings der einzige Use Case soweit ich weiß wo das so ist dass wir lieber anstehende Krypto erzwingen und im Zweifelsfall müssen die User dann halt Updates installieren dann gibt es geringlich nur Leute die sich fragen ob man nicht das ganze CA-Geröffel durch Dane ersetzen könnte Dane ist ein Verfahren wo im DNS geschützt durch DNS-Sech Zertifikate eingetragen werden beziehungsweise Publikis von Fingerprints von Publikis von Zertifikaten damit könnte man theoretisch CA's umgehen, das Problem ist man einfach nur das Vertrauensproblem von den CA's die im Moment halbwegs gut kontrolliert werden zu den Betreibern von den Top-Level-Domains die halt so gut wie gar nicht kontrolliert werden und ihr könnt euch hier selber überlegen wenn ihr Schiss habt von der Regierung abgehört zu werden ob ihr dann großes Vertrauen habt dem Betreiber von der Top-Level-Domain die diese Regierung gehört oder diesem Land gehört zu Vertrauen weil die könnten dann auch einfach für eure Domain beliebige eigene beliebige eigene Publikis in Dane eintragen und wenn Dane implementieren würdet dann würdet ihr quasi dann dem komprimitierten Key der zum Abhören benutzt wird von der Regierung vertrauen also deswegen Dane ist auch so wenn man die Regierung nicht vertraut dann ist es nicht brauchbar, wenn man die Regierung vertraut dann ist es durchaus brauchbar und kann eine Zusatzmaßnahme sein aber ist in der Praxis auch nur für Mail Server und Jobberserver relevant gut da gibt es noch Fragen alle eingeschlafen da hinten ist eine gibt es dann ja klar welche kannst du das in der zweiten Zeile erklären welche Art von redirect ist da gemeint und warum ist das unsicher es ist deswegen unsicher ein redirect der muss ja quasi jedes mal erfolgen wenn der browser drauf geht also du kannst zwar einen permanent redirect raus schicken der browser den speichert wenn der user dann irgendwann seinen redirect ist diese redirect wieder weg das heißt jedes mal wenn der browser diesen redirect nicht gecaged oder wenn du ein temporary redirect machst dann schickst du ja erstmal über unverschuldetes HTTP die Aufforderung an den browser auf die HTTP-S Seite zu gehen und ein Angreifer der in der Situation ist wo er deine Verbindung abhören und manipulieren kann der kann natürlich auch einfach ein HTTP-Traffic manipulieren solange er nicht mit TLS geschützt ist und da drüber kann er halt auch verhindern dass du dann von der HTTP-S Seite auf die HTTP-S Seite umleitest ja außerdem was er natürlich noch machen könnte ist dass er sich selber quasi als Web Server ausgibt und selber die Seite verschlüsselt runterlehnt aber sie halt unverschlüsselt an den enduser weiterleitet also von daher will man da lieber HTS benutzen was das Problem dann ein für alle mal löst sonst noch fragen was du verstanden habt oder ob ihr allein geschlafen seid es klingt, dass ihr dich allein geschlafen ok ich glaube dann hätten wir es so weit