 Wer kennt denn alles Observatory von Mozilla? Okay, drei, vier Hände, das ist gut. Dann seid ihr alle richtig hier. Die, die es schon kennt, für die wird es vielleicht ein bisschen langweiliger. Aber es ist ja auch so für die anderen, die es noch nicht kennen gedacht, der Vortrag ein bisschen, so ein bisschen 101 Session, sich da mal ein bisschen mit zu beschäftigen, was für Tools es gibt. Wir werden es auch so machen, ungefähr 45 Minuten Talk und hinterher kann man auch noch ein paar Fragen stellen. Das wird relativ knapp, weil sind dieses Jahr wieder zwei Header dazugekommen. Ich mach das jetzt schon, ich glaube es ist jetzt das dritte Mal und jedes Jahr sind ungefähr zwei Header mehr. Deswegen, dass mit der Security scheint nicht so einfach zu sein. Genau. Ja, wo stehen wir da? Hat's ja schon gesagt, ja, irgendwie ist das alles nicht so richtig schön, sicheren Quotschreiben kann eigentlich keiner so richtig. Ja, also das ist vielleicht nicht mehr ganz so schlimm, das ist schon deutlich besser geworden, aber das Problem hatten wir halt schon auch großflächig. Alle Anwendungen reparieren oder alle sauberen Coden wird mindestens schwierig oder skaliert zumindest nicht. Viele Leute haben so Bestandsanwendungen, die repariert auch keiner mehr vollständig. Das ist auch in der aktuellen Overs Top 10, die ja inzwischen dann doch mal final released wurde vor zwei, drei Monaten. Ist das auch immer noch drin? Also die Probleme, die gehen damit aber auch nicht alle weg, mit diesen zusätzlichen Headern, die man machen kann, wo ich dann später noch drauf zu sprechen komme. Aber man braucht irgendwas, was man vielleicht noch zusätzlich machen kann, um das Problem zumindest ein bisschen zu minimieren. Genau, also irgendwas, was man vielleicht auch außerhalb der Anwendung machen kann, das ist so ein bisschen das Thema heute. Also einmal wie grob, ein bisschen HTTPS, aber ich werde jetzt nicht auf die ganzen Algorithmen eingehen oder sowas heute. Wie gesagt, das ist eher so ein Basisvortrag. Das werde ich komplett weglassen, aber so ein paar Dinge, wo man bei Zertifikaten vielleicht drauf achten muss, wobei das mit Let's Encrypt ja auch viel einfacher geworden ist als in der Vergangenheit. Was verstehe ich jetzt hier unter Infrastruktur, mal so ein bisschen mehr der Protokoll, Stack und weniger die Anwendung selber. Also da werde ich heute auch nicht weiter drüber reden, sondern wirklich über den oberen Teil war ja auch diese Header beeinflussen, wie sich die User Agents verhalten, wenn man die mit schickt. Das schauen wir uns nachher auch noch im Beispiel an. So dass man, weil die Kammern zwar, die sind nützlich und die sollte man benutzen, aber man sollte schon wissen, was man da tut, sonst kann das irgendwann später weh tun. Und das ist immer so, das funktioniert, alles am Anfang ein paar Monate später tut es dann weh. Deswegen sollte man sich das, bevor man das einfach alles einschaltet, ein bisschen damit beschäftigen, das auch mal testen. Und genau, was sind jetzt eigentlich diese sogenannten HTTP Security Header? Das ist im Prinzip eine Protokollerweiterung von HTTP, also zusätzliche Header. Die kann ich, die schickt der Server in seine Antwort halt mit an den User Agents und dann wertet er die aus und macht irgendwas anders, als wenn man sie nicht mit schicken würde. Ja genau, also wie gesagt, das werden jedes Jahr irgendwie ein paar mehr, die man da einbauen kann. Um die Sache noch ein bisschen sicherer zu machen. Der große Vorteil ist, ich muss jetzt nicht wirklich in die Anwendung eingreifen. Für die meisten davon, das stimmt natürlich nicht ganz. Ab und zu muss man dann schon auch Modifikation in der Anwendung vornehmen. Auf jeden Fall hilft es, das Web ein Stück sicherer zu machen und es macht es dem Angreifer ein Stück schwieriger. Aber es ist garantiert kein Allheil mit dem. Ich muss jetzt keine sicheren Code mehr schreiben oder sowas. Das ist nur ein Zusatzbaustein. Genau, was hat man jetzt für ein Problem, wenn so ein Usagen, also wenn Chrome oder irgendwer anders, das halt nicht richtig implementiert hat, dann ist es halt auch gleich überall kaputt. Aber wenn die das reparieren, dann ist es wieder überall repariert. Also ich habe so ein Fast-Fail-Mode hier. Wenn jemand dort was entdeckt, dann kann man es schnell reparieren. Aber dann muss die Lot hat auch wieder die User-Agent entsprechend aktualisieren. In dem Mobile-Umfeld ist das natürlich wieder so eine Sache, wenn man das Android-Update aufspielt für den Web-View, der das dann vielleicht doch noch nicht kann, weil es irgendwie eine alte Version ist. Das ist also auch mal wichtig, sich vor Augen zu führen. Diese ganzen Header, die man da einbauen kann, die funktionieren natürlich auch nur, wenn ich ein aktuelles Frontend bin. Also eine aktuelle Version des User-Agents entweder als Browser oder in der Mobile-App, in dem darunter liegen, ein Framework habe. Das heißt, das Betriebssystem ist auf dem aktuellen Stand beziehungsweise die Komponenten, auf die die mobile Anwendung aufsetzen. Die von Android oder von anderen mobilen Plattforms, IOS usw. bereitgestellt werden. Man wird auch irgendwie abhängig davon, dass das dann da funktioniert. Und das Risiko ist halt, dass sich der Entwickler dann sagt, ach, ich habe ja die ganzen Header da eingebaut. Das ist schon alles cool so, muss auf den Rest nicht mehr achten. Deswegen war vorhin auch Sequel-Injection und so was. Das ist was, was ich im Anwendungscode hinbekommen muss oder auch fehlerfreien JavaScript ersetzt mir das alles nicht. Genau, also diese Infrastrukturmaßnahmen, die ich hier zwischen Server und User-Agent einführen kann, die helfen, Dinge besser zu machen, aber die ersetzen andere Sachen nicht. Man muss sich schon irgendwie damit beschäftigen, weil wenn jetzt so ein Administrator auch einfach so irgendwo im Web-Server so ein Header mitschickt und der Anwendungsentwickler weiß das nicht, kann das vielleicht auch witzige Seiteneffekte haben. Genau, das sind unten die zwei neuen. Ich klicke die mal kurz hier rein. Also das sind eine ganze Menge. Die zwei unteren, die sind, ja, das Kurs ist jetzt nicht so neu, aber auch mehr in den Fokus gerückt und mit den ganzen API-Geschichten. Ja, ein Mobile-Map im Regen meistens in der API und erlaube ich das dann allem oder nicht. Was relativ neu ist in Referra-Polices, da kann ich also jetzt steuern, was schickt das mehr so ein Privacy-Feature im Prinzip. Was schickt mein User-Agent, wenn er auf meiner Seite war, wenn ich zum nächsten Link gehe, dann halt mit wo er da vor war, schickt er überhaupt was mit oder schickt er nur die Domain mit oder bestimmte andere Details. Genau, dann sind hier so ein paar Äthel, ich gehe die mal ganz kurz durch und dann gehe ich mal auf dieses Observatory, was ich am Anfang genannt habe und dann kann man sich mal schauen oder da zeige ich mal ein paar Beispiele und gehe dann noch mal auf einzelne Aspekte, der Hader ein, was man da machen kann oder nicht oder warum man das macht oder worauf man da achten muss. Hier habe ich ein Durchgestrichen, den gibt es zwar noch, der funktioniert auch noch überall, der ist aber, also das war eine gute Idee. Was hat man da gemacht, steht ja da, man hat irgendwie Kies gepinnt, das kann man aber auch relativ leichtes brauchen oder es kann halt ziemlich furchtbar schiefgehen, deswegen ist das ein Hader, der ist inzwischen in der Kategorie optional wieder angesiedelt, weil man sich damit in Zweifel mehr Probleme anhandelt, als man löst. Und es kann theoretisch auch von Angreifern benutzt werden, da komme ich aber noch mal drauf. Also so ein Server schickt ja irgendwie Heder an den Kleinten und verändert dann sein Verhalten und wer im Raum hier der server in der Website betreibt, checkt jeden Tag, was für Heder der Server mitschickt. Da gibt es dann halt lustige Angriffswektoren und dann sollte man vielleicht die Heder öfter mal checken, die man mitschickt, sonst kriegt man irgendwann so einen unschönen Erpresser-Brief und hat ganz viel Arbeit. Erklär ich nachher noch mal im Detail. Das ist so ein, ja das obere ist halt also der allererste, das X-Content-Type-Options, das ist quasi noch aus der Zeit, als die Leute immer kaputte Webseiten gebaut haben. Und dann haben die User-Agent, das ist ja jetzt auch so ein bisschen wieder der Ansatz, man repariert es irgendwo an der anderen Stelle, versucht rauszufinden, was hat mir der Server denn jetzt eigentlich für ein Inhalt geschickt, weil der Heder, der Mime-Type vielleicht nicht korrekt war. Und inzwischen sagt man, na ja, aber wenn ich sage, das ist eine Textartei, dann will ich auch, dass du lieber User-Agent, das als Textartei interpretierst und nicht versuchst, ein Image zu rennen oder so, es war in den ersten paar Bytes irgendwas anderes drinsteht. Da gibt es auch einige Angriffe, die in der Vergangenheit dann darauf basieren, dass die User-Agent alle hergehen und versuchen rauszufinden, was tatsächlich angekommen ist. Der HSTS-Heder ist mit einer der wichtigsten im Sinne von Sicherung des Übertragungsweges, weil das macht das, was da stets drückt, Transport Security, das heißt, Enforced, also das forciert die Benutzung von HTTPS. Das ist auch ein sogenannte Tofu-Heder, warum heißt das Tofu? Weil das bezieht sich auf Trust on First Use, das heißt, wenn ich das erste Mal, das gilt auch für ein paar andere der Heder, wenn ich das erste Mal die Website besuche, dann kann mir der Server halt diese zusätzlichen Informationen mit schicken, wie ich die Seite in Zukunft benutzen soll, wenn ich wieder komme. Und dieser Heder sagt halt auch, wenn du das nächste Mal kommst, dann komm auf jeden Fall per HTTPS, auch wenn man gar keinen Protokoll angibt, sondern nur den Domain-Namen eingibt, dann wird dann der User-Agent in Zukunft immer per HTTPS zu der Seite gehen. Und das ist dann halt auch schon, wenn man also so einen Heder mitschickt, und dann geht das HTTPS nicht, HTTPS geht vielleicht noch, aber dann kommen die Leute, die schon mal da waren, nicht mehr auf die Seite. Weil die User-Agent, haben Sie gemerkt, da gehe ich nur noch per HTTPS hin. Deswegen muss man dann natürlich auch sicherstellen, dass das S funktioniert, weil sonst bin ich offline für den User, der wiederkommt. Also das macht es auf einer Seite sicherer, aber auf der anderen Seite hat man als Betreiber von der Webseite, muss man sich ein bisschen mehr darum kümmern, dass die Infrastruktur in Ordnung ist. Weil sonst kommen die Leute da nicht mehr hin. Ich zeige das dann auch gleich mal im Browser, wie sich das dann verändert, das Verhalten. Genau, dann gibt es X-Frame-Options, der ist auch ein bisschen outdated, den sollte man aber schon noch mitschicken, gerade für ältere User-Agent, die das per CSP noch nicht können. Das ist halt eine super sichere und funktionierende Variante, wenn man die eigene Seite nicht irgendwo anders geframed haben möchte. Das verhindert auch ein paar Angriffsszenarien wie Cross-Site-Resource-Fortuary, also wo die eigene Seite unsichtbar in dem Frame eingebettet wird und dann klickt man irgendein Online-Spiel, aber klickt eigentlich in seinem Online-Banking. Und hier, wenn man so ein header mitschickt, dann stellt halt der User-Agent sicher, dass das nicht geframed werden kann, weil alle anderen Varianten, sogenannte Framebuster, die auf JavaScript basieren, die kann halt der Angreifer immer ausschalten, weil der kontrolliert ja den iFrame, in dem er die Seite lädt. Und dann kann man auch JavaScript deaktivieren. Dann sieht die Seite vielleicht nicht so schön aus, aber die sind immer angreifbar. Und diese Header, solange der User-Agent das sauber implementiert hat, sind halt nicht angreifbar. Deswegen ist das, der ist billig, der kostet nichts, muss er nur mitschicken. Außer man hat wieder eine Web-Anwendung, wo Teile in anderen Anwendungen geframed werden sollen. Wenn ich dann den Header mitschicke, dann ist das Framing kaputt. Bei dem Header kann ich halt nur sagen, same origin, also auf der eigenen Domain. Oder ich kann eine, es für alle, erlauben. Das hat man dann im CSP-Header, zu dem komme ich noch, aufgeräumt, da kann ich beliebig viele Domains angeben, den ich quasi das Framing erlauben möchte. Genau, CSP, der ist superkomplex. Da muss man, ich zeige gleich so eine Seite, die hilft einem beim Setup. Es gibt da inzwischen auch Support für die Header in vielen Frameworks, weil gerade der CSP-Header ist nicht so ohne, weil das ist ja auch wieder eine eigene Policy, die ich da definiere. Also ich kann da komplexe Vorgaben machen für Ressourcen, die die Seite benutzt. Und das ist auch noch relativ neu. Das schicke ich jetzt nicht als HTT-Header mit, aber ich kann im CSP Sub-Resource Identity enforzen, sagen alles, was ich irgendwo herholen muss, diese Sub-Resource Identity haben, Sub-Resource Identity. Es ist quasi ein Hash auf eine Ressource, die ich nicht bei mir selber hoste. Wenn man jetzt seinen JavaScript-Framework der Wahl aus irgendeinem CDN lädt, das kann man ja machen, aber es ist halt so ein bisschen out of control, dass ich da eigentlich für JavaScript einbinde. Dann kann man Hash drüberlegen und den schickt man dann mit. Und dann kann der User-Agent sagen, okay, das ist immer noch dieselbe Datei, die der Entwickler oder die Anwendung haben wollte und überprüft das über den Hash. Das heißt, wenn das CDN gehackt wird oder das DNS gehackt wird und plötzlich die Ressource woanders herkommt, dann habe ich da kein Problem mehr. So, war jetzt ein bisschen sehr theoretisch, deswegen machen das jetzt mal ein bisschen praktisch. Genau, ich habe das jetzt mal mit Google kommen gemacht. Da steht jetzt ein D minus, nicht wundern. Weil, wie gesagt, man muss einmal gucken, was mache ich eigentlich auf der Seite, wofür benutze ich die, was für Risiken habe ich dort und gegen was will ich mich eigentlich schützen. Zum Vergleich, wenn man jetzt auf Mail beziehungsweise redirected das dann auf Accounts, also auf R-Rating. Hier sind auch noch mehr Ratings, da komme ich gleich noch zu. Manchmal hat man bei dem ANA, bei dem ANC, bei dem AND, was ist denn jetzt richtig. Damit es nicht so einfach wird, schäten das auch noch alle irgendwie anders. Erklär ich aber gleich noch. Das Schöne an dem Projekt von Mozilla hier ist, hier gibt es immer Hinweise für den Entwickler. Hier gibt es schöne Guidelines. Eine Erklärung, wir haben so ein Punktesystem dahinten dran. Hier sieht man auch noch mal, was für header hat man eigentlich mitgeschickt von der Seite. Ich kann auch gleich noch mal fragen, wer seine eigene Seite testen will, können wir auch noch mal drauf schauen. Aber wie gesagt, also das D ist jetzt nicht unbedingt gut oder schlecht, sondern es kommt darauf an, was ich damit mache und gegen was ich mich schützen möchte. Man muss nicht immer alles haben. Wie man hier sieht, haben die jetzt hier nicht so viel, es ist kein CSP-Header drin, die Cookies sind nicht alle mit dem Secure-Fleck gesichert. Als Secure-Fleck beim Cookie brauche ich nur, wenn da zum Beispiel eine Session-ID drin ist. Dann will ich das haben oder ein HTTP-Only-Fleck. Wenn da irgendwas drin ist, kommt darauf an, wie wertvoll das für die Anwendung ist. Das muss man halt dann selber entscheiden. Course-Settings sind da, die haben hier ein Pin drin. Also das ist natürlich bei Google jetzt nicht so verwunderlich. Die schützt die Infrastruktur schon sehr intensiv, weil da auch viele Angriffe gegenlaufen. Hier ist jetzt kein HS... Also hier ist ein HSTS-Header, aber hier gibt es Punktabzug, weil das generelle Übereinkommen ist, man soll das auf 6 Monate setzen, das entspricht dann der Zahl dahinten in Sekunden. Und jetzt gucken wir mal, Google hat das jetzt hier auf 6.000, also das ist die Anzahl Sekunden an einem Tag. Warum machen die das? Ja, falls doch mal was ist, was ich gerade gesagt habe, und die müssen die Google.com mal ohne HTTPS ausliefern, dann sind alle, die schon da waren, nur einen Tag ausgesperrt. Weil sonst sind die 6 Monate ausgesperrt. Wenn ich irgendein größeres Problem habe und brauche halt länger, um das zu beheben, deswegen haben sie das auf der Hauptdomain so gelöst. Wenn wir uns jetzt die Account anschauen, da ist das alles grün. Bei CSP ist auch drin, da gibt es nur einen Punktabzug wegen bestimmten Elementen, da komme ich nochmal drauf. Dann sieht man hier, wo ist es, wo ist es, hier, die Zahl ist jetzt größer als ein halbes Jahr, weil, weil die haben hier noch was. Das sehen wir gleich auf dem nächsten Tab, die ist auch preloaded. Und wenn man auf diese preload-Liste möchte, erkläre ich auch gleich, dann ist inzwischen die Vorgabe das auf ein Jahr zu setzen. Das heißt, hier ist es jetzt so, wenn es ein HTTPS-Problem auf der Account-Seite von Google gibt, die gibt aber keiner von Hand im Browser ein, die gehen alle auf Google.com. Deswegen muss ich sicherstellen, dass ich da immer Leute abhole. Hier ist es jetzt aber natürlich super security-kritisch, weil wenn irgendwer die Accounts da kaputt macht, das wäre nicht so witzig. Oder da was abziehen kann, deswegen ist hier jetzt genau das Gegenteil. Man hat das jetzt ja auf über ein Jahr. Das heißt, jeder, der einmal auf dieser Domain war, merkt sich der User-Agent für mindestens ein Jahr, da gehe ich nur noch per HTTPS hin. Ansonsten sieht man hier auch diesen X-Content-Type, no sniff, habe ich ja gerade erklärt. X-Frame-Options, Denialen, nicht mal selber frame, gar kein framing. Das ist auch die sicherste Variante, wenn das geht. Aber manchmal hat man ja selber irgendwie so Anwendung, die sich selber frame oder Teile davon, dann macht man the same origin. Hier beim XSS hat man, der default ist leider nur eine 1, ohne mod block. Was heißt das? Was macht das? Die Browser-Hersteller oder die User-Agent-Hersteller haben so angefangen, so ein bisschen voodoo zu machen und sagen, ah, das ist gutes JavaScript und das ist böses JavaScript. Ja, ich sage voodoo, weil das ist natürlich nicht so einfach zu analysieren. Und der Standard-Mode, wenn man den Header nicht mitschickt ist, ich filter alles raus, was komisch aussieht, aber ich stelle sicher, dass die Seite funktioniert. Ich sage dem User aber nicht Bescheid. Das heißt, der Render hat die Seite der User-Agent. Das heißt, ich sehe die Webseite, wird mir angezeigt. Auch wenn irgendwer da drin komisches JavaScript abläuft, dann filtert der User-Agent das verweck. Ich kriege es aber als User gar nicht mit. Und Mode-Block macht genau das. Das blockt das Rendering. Das heißt, wenn ich dann auf der Seite bin, dann ist es erst mal kaputt, weil es wird nicht gerendert. Sobald der Filter greift, hört der User-Agent auf die Seite zu rendern. Dann merke ich zumindest als End-User, da ist irgendwas, geht nicht. Und meldet mich dann beim Support oder was weiß ich, oder schreibt an, an dem das Block gehört. Hey, deine Seite geht nicht. Und dann kann man sich darum kümmern. Aber ich laufe nicht Gefahr, dass irgendwas passiert, was ich nicht will. Deswegen schickt man diesen Mode-Block mit, damit der User-Agent-Wenderfilter schon mal greift. Die sind natürlich super fehler-tolerant gebaut, weil, wenn man das jetzt mal hochrechnet, wie viele Leute bestimmte User-Agent benutzen, um sich dann überlegt, da wäre eine Forst-Positive-Rate von 1%. wäre wahrscheinlich nicht so witzig, weil dann Großteil der Webseiten nicht mehr funktioniert. Deswegen, das ist so ein netter Versuch, da was zu tun. Aber realistisch ist das halt auch nur ein weiterer Baustein und sollte sich da niemals drauf verlassen. Genau, wenn wir jetzt wieder oben hingehen. Also, wir haben jetzt ein A, weil viel kritischerer Aspekt. Und hier haben wir ein D-Minus, weil die da bestimmte Dinge einfach nicht machen. Die sagen, ja, okay, an der Stelle habe ich das Problem, aber nicht. Genau, dann schauen wir mal hier auf dem Observator. Hier gibt es noch mehr Tubs. Also einmal diesen Übergottner, der prüft auch noch mehr Sachen. Also, der checkt einmal diese Header, der checkt aber auch, was ich eben schon mal angedeutet habe, wie bestimmte Cookies verschickt werden. Bei Cookies kann man noch zusätzliche Flex mit schicken. Ein HTTP-Only-Fleck, der stellt dann sicher, dass ich z.B. per JavaScript nicht auf das Cookie zugreifen kann. Wenn ich ein Cookie habe, den ich nur zur Identifikation wie für eine Session hin und her schicke, dann muss ich dem JavaScript nicht auslesen. Wenn man das Fleck dran klebt, ist das dann sicher. Auch wenn jemand z.B. JavaScript in die Seite checken kann, kann er den Session Cookie nicht stehlen, weil das JavaScript nicht an den Cookie rankommt. Und das Secure-Fleck ist dafür da, dass das Cookie nur verschickt wird, wenn ich über eine sichere Verbindung, also HTTPS, mit dem Server-Räder. Und wenn ich per HTTP mit dem Server-Räder, dann schicke ich das Cookie nicht mit als User-Agent. Genau. Dann haben wir, wie gesagt, die Machenheit, das Keep-Hinning. Aber da sollte man die Finger von lassen, wenn man nicht wirklich weiß, was man dann macht und Sicherheitspläne hat, um damit zu arbeiten. Man muss beim Keep-Hinning auch immer mindestens zwei Hashes mit schicken von so einem öffentlichen Schlüssel. Also da wird nicht das Zertifikat gepinnt, sondern wirklich der Key vom Zertifikat. Der öffentliche Teil. Aber wenn jetzt mein privater Schlüssel verloren geht oder weil die Seite geheckt wurde und ich muss das tauschen, dann sind ja die Leute, die vorher schon da waren, die haben den Hasch auf den anderen Schlüssel. Wenn ich jetzt einfach das komplett tausche, dann kommen die nicht mehr auf die Seite, so ein bisschen wie der HTTPS-Häder, nur schwieriger zu fixen, weil jetzt auch noch das Zertifikat oder der Schlüssel vom Zertifikat, der öffentliche Schlüssel vom Zertifikat hatte, sich auch noch gemerkt hat, ich kann nicht einfach irgendein neues Zertifikat dahin legen, mit einem anderen Schlüssel ein paar unten drunter. Genau, hier ist auch, naja, die redirects, was ist das? Das ist auch so eine Maßnahme Trust and First Use, weil der normale User gibt ja in seinem Client einfach eine Domain ein, zum Beispiel Google.com oder Entropia.de oder sowas. Und dann gehen die per HTTPS dahin und dann ist es eine gute Idee, wenn man das sowieso per HTTPS ausliefert, das dann ein sogenannte redirect, also ich verweise auf die sichere Verbindung. Und das ist halt angreifbar. Und wenn ich noch mehrere redirects dazwischen habe, dann hat ein potenzieller Angreifer noch mehr Optionen dazwischen zu funken. Wenn man jetzt irgendwo in seinem Lieblingscafé oder was weiß ich, ist und da erstmal per HTTPS unterwegs, und das weiß ich. Also dieser Internet-Access Point, der ist hier nicht sicher. Und deswegen macht man das dann in Kombination mit dem HTTPS-Header, weil beim nächsten Zugriff ist mir das dann egal. Genau, was haben wir jetzt hier noch? Genau, wenn man Sachen nicht hat, gibt es halt Punktabzug und dann kommt so ein Rating raus und dann gibt es einmal noch die Bewertung des Protokolls. Das sieht man auch hier hinten. SSL-Apps ist so ein etablierter Standard, aber das muss man jetzt sich nicht alles merken. Da muss ich nur Observatory.mozilla.org merken. Die haben das da alles mit drin. Hier sind jetzt verschiedene Scanner, die nochmal die Qualität vom HTTPS-Setup prüfen. Das heißt, die Algorithmen, die man eingebaut hat und auch die Header, die direkt mit dem HTTPS zu tun haben. Jetzt sieht man hier aber schon, SSL-Apps hatten A und TLS, also dieser andere Scanner, hatten C. Die prüfen beide das gleiche, aber die haben ein bisschen einen anderen Fokus, einen anderen Schwerpunkt darauf, was die prüfen. Die Franzosen hier unten im Prinzip, die schauen ein bisschen mehr auf moderne Algorithmen. Also nimmt man wirklich das Allerneuste, was man kriegen kann und mit großen Bitlängen. Und das SSL-Apps ist ein bisschen praxisorientierter, also ist deswegen nicht schlechter. Aber ich weiß schon, wenn man hier ein A hat, das ist auf jeden Fall gut. Und wenn man hier ein C hat, ist das nicht unbedingt schlimm. Dann gibt es hier noch eine Seite, die heißt der Security-Headerspunkt.com. Die prüft noch mal explizit auf dieses Security-Headers. Ich habe das hier auch noch mal offen. Und die machen so ein, das überdeckt sich so ein bisschen, aber das ist quasi wie eine zweite Meinung, wo man auch noch mal einen Feedback bekommt und auch ganz viel Hintergrund wissen, welche sind hinter jedem Link, ist quasi noch mal ein Blog-Post, der den Header im Detail erklärt, weil das mache ich jetzt nicht. Aber da hat man wirklich Schöne, wenn man da drauf geht, kann man dann ganz viel lesen, um dann zu verstehen, was die einzelnen Möglichkeiten, die man da jetzt hat, wie die Referra-Policy zum Beispiel funktioniert und was dann am Ende die andere Domänen, die ich im Zweifel nach der ersten Domain-Anklicke vom User-Agent für zusätzliche Informationen bekommt und dann kann ich für mich entscheiden, will ich das als Server-Betreiber, als Anwendungsbetreiber und das Verhalten darüber steuern. Das sind auch immer ein bisschen längere Ausführungen. Auch im Mozilla Developer Network, die sind auch relativ ausführlich diese Beschreibung. Hier gibt es auch noch ein Google CSP Evaluator, gibt es ein Mozilla CSP Generator. Ich habe hier auch noch einen anderen, der heißt CSP is a Viewson. Guck ich gleich mal drauf. Das ist jetzt nur, um einen Header zu konfigurieren. Da sind jetzt 1, 2, 3, 4, 5, 6, 7, 8, 9 Tabs. Und dann kann ich immer irgendwelche Hicke machen und irgendwelche Felder ausfüllen. Dann kann ich auf Create klicken. Das macht glaube ich schon ein bisschen deutlich, wie komplex dieser Header ist und wie er funktioniert. Ich kann hier also ganz grob, kann ich darüber steuern. Im Default kann ich ein paar allgemeine Vorgaben machen, von wo die Anwendung Ressourcen laden kann. Und dann kann ich das für bestimmte Anwendungstypen, wie Script, Style, Image, Fonts, Daten, Medias, Framing, habe ich ja schon, mit dem X-Frame-Options. Aber hier kann ich jetzt eine beliebige Liste angeben, comma getrennt, von wo ich Medien erlaube oder bestimmte JavaScripts, CSS oder Bilder. Wenn ich CDNs einbinde, dann kann ich das halt darüber steuern, dass es aber nur genau das ist und alles andere nicht. Also ist wirklich so, da muss man sich ein bisschen einlesen und mit beschäftigen. Das ist hier also so mehr ein Teaser, um da drauf einzugehen. So, was passiert jetzt, wenn man so ein HSTS halt damit schickt? Ich habe jetzt hier mal eine Domain, die hat jetzt irgendwie ein HTTPS-Problem mit dem Zertifikat. Das matcht irgendwie nicht. Hier steht, der Name passt nicht. Na gut, das muss jetzt nicht angucken. Dann habe ich, aber üblicherweise sieht das so aus, da gibt es diesen Advanced-Button und dann klick ich hier auf Proceed. Der steht ja Proceed to, ist zwar unsicher, aber der User kann im Prinzip immer noch auf die Seite draufgehen. Und dann klick ich da und dann funktioniert es vielleicht. Ich muss vielleicht mal neu laden. Ah ja, genau, wenn es da drauf geht, dann komme ich irgendwie auf die Seite. Und jetzt ist es aber so. Erklär ich gleich noch, was das ist. Nettes Feature von Chrome sollte man als Entwickler zumindest kennen. Der End-User sollte es besser nicht kennen. Also hier kann man sich ein bisschen selber helfen, wenn man jetzt kein Hedder mitgeschickt hat. Ich habe jetzt mal den hier. Jetzt war ich hier auf, was war ich, auf Labs. Genau. So, da kann ich jetzt den Brause fragen, hat er irgendwelche Hedder bekommen von der Domain, hat er nicht. Und wenn ich jetzt hergehe und so ein HTS Hedder mitschecke, das Schöne ist auf dieser Chrome-Internet. Ihr seht, hier sind noch eine ganze Menge andere Sachen. Ich kann hier alle Events, Capture nicht, ich kann HTTP2 angucken, Bandbreite, DNS. Also es ist wirklich so ein sehr schönes Entwickler, so sollte man kennen. Unter anderem hat man hier diese Domain Security Policy Tab. Da kann man mal damit rumspielen. Und das ist nicht gefährlich. Also ich kann jetzt hier irgendeine Domain angeben sagen, da hätte mir so ein Hedder geschickt. Da kann man noch, da gibt es noch ein Flag, Includes Subdomains, muss man halt nicht aufpassen, wenn man seine Hauptdomain nimmt und noch interne Sachen damit hat und dann plötzlich alle interne Seiten nicht mehr gehen. Weil der User Agent hat gesagt bekommen, also wenn ich jetzt hier, wenn das jetzt irgendeine große Firma wäre und dann gibt es hier irgendwelche internen Sachen, die halt nur auf HTTP laufen und dann schicke ich auf der Hauptdomain so ein Hedder mit, dann wird das spaßig. Deswegen, man kann das schnell machen, man sollte immer so ein bisschen im Hinterkopf behalten, was man da tut. Oder was das für Konsequenzen haben könnte. Und dann wird das später. Solange das nur dynamisch ist, kriegt man das irgendwie immer wieder weggelöscht. Also ich zeige das mal, weil hier auf der Hauptdomain schicke ich den Hedder mit. Da passt auch das Zertifikat, das ist auch schön grün. Aber wenn man jetzt hier wieder fragt, hey, kennst du für die Domain irgendwelche Hedder? Dann sagt er, oh ja, hab ich. Dann sieht man jetzt hier diesen Unterschied, da steht einmal Static und Static heißt Static, hat in den Browser Code einkompiliert. Das kann man machen. Das kann man dann verfahren, wie man da draufkommt auf die Liste. Und dann steht man da im Browser Code. Dann kommt man auch nicht wieder raus so schnell. Das dauert 2-3 Monate, bis der nächste Chrome-Release kommt. Und solange gilt das. Und dann enforced er das. Jetzt habe ich das nur als Hedder mit geschickt, also dynamisch. Da steht jetzt drin, hey, wenn ich da draufkomme, dann muss ich das immer so machen. Auf der Seite ist das ja egal, weil die funktioniert ja. Und wenn ich jetzt auf eine andere gehe, auf eine andere Subdomain, auf eine andere Diktikat oder halt, es könnte auch irgendwas anderes mit dem HTTPS nicht stimmen, nicht funktioniert, dann geht es jetzt auch, weil da war ich vorhin schon drauf. Aber da ist noch, ich kann da beliebige Domains eingehen. Dann kommt hier wieder mein Hinweis. Und jetzt, oh, da ist gar kein Link mehr. Das ist aber unschön. Weil die Hauptdomain hat jetzt gesagt, hey, ich kann das. Und ich will, dass das sicher ist. Jetzt ist es aber auch sicher, das heißt, der Nutzer kann da auch nichts Unsicheres mehr machen. Jetzt gibt es diesen Button nicht mehr. Hey, ich bin groß, bin erwachsen, ich weiß, was ich tue. Lass mich da hin. Ich will da unbedingt weiterarbeiten. Jetzt blockt der Useragent, weil ich den gesagt habe, hey, ich will Security, jetzt kriege ich auch Security. Halt den User von der Seite komplett weg. Und da steht jetzt, ja, die kriegen das schon hin, weil die wissen ja, was sie tun. Sie haben so einen Header mitgeschickt. Die sind schon ein Schritt besser als der Rest. Und das ist halt, was man jetzt öfter begegnet ist, alle machen Letz Encrypt und haben ihre Automatisierung nicht im Griff. Und die Letz Encrypt-Zertifikate laufen drei Monate, beziehungsweise 90 Tage. Und nach 90 Tagen ist die Seite kaputt. Und jetzt ist sie ganz kaputt, weil ich ja jetzt einen Header mitgeschickt habe. Dann komme ich da nicht mehr drauf. Also, mein Nutzer kommt da nicht mehr drauf. Ich will sicherzustellen, dass man diese Zertifikate vor den 90 Tagen erneuert, weil sonst ist der Dienst offline. Im Prinzip ist das jetzt so ein Self DOS. Ich habe meine Seite vom Letz genommen, weil ich diesen Header mitgeschickt habe. Und wenn man jetzt hergeht und ich lösche den jetzt wieder, das Gute ist ja hier, ich kann jetzt hergehen und sagen, hey, lösche das doch mal wieder, es ist hier nur dynamisch. Also, da kann man ganz ungefähr mit rumspielen. So, jetzt habe ich das gelöscht. Wenn ich das jetzt wieder lade, dann sieht man jetzt, ah, ja, es ist zwar kaputt, aber die Leute, die in der Lage sind, auf Advanced zu klicken, also sieht das ja initial mal aus. Und man sieht ja hier auch Intended, ja, also das ist so ein bisschen Userführung an der Stelle, durch die User Agents, das machen alle ähnlich, Firefox, Chrome, Internet Explorer, sodass man sicheres Verhalten motiviert quasi, Back to Safety, hier gehe ich lieber nicht hin, aber ich habe halt hier immer noch diesen Donuts, was in der steht nochmal, bist du sicher, aber jetzt kann ich hier wieder hin, eben ging das nicht, ja, weil der Header dabei war, das ist halt so ein Beispiel, deswegen, das ist auf jeden Fall super, das ist gut, wenn man das macht, aber man muss dann hinten seine Infrastrukturprozesse in den Griff haben und dann, das ist wirklich wichtig und man muss diese Header verstehen, auch wenn sie sehr einfach aussehen, auch wie dieser X-Frame Header, den kann ich mal eben rausschicken und dann ruft irgendwie zwei Tage später hin und dann, hey, ist alles kaputt hier, weil die Seite nicht mehr geframed werden kann und das war aber der, ein wichtiger Use Case von der Anwendung und dann ist das alles offline, dann ist hier und Verfügbarkeit ist auch ein Sicherheitsfeature und ein Kriterium und hier mache ich die Verfügbarkeit kaputt, wenn ich es nicht richtig mache, dann bin ich super sicher, aber nicht erreichbar. Ja, das ist halt immer Security Costed, ja, und das ist das, und wie gesagt, das merkt man dann halt, vielleicht erst nach 90 Tagen, ja, ich habe Letzengrypt und alles cool in Chica STS'er damit und in drei Monaten ruft jemand panisch den Atmen an, warum die Leute alle bei ihm anrufen, dass sie nicht mehr auf die Seite kommen und dann fängt das Suchenersten an, ja, die Seite geht, die Anwendung läuft, das ist das Problem. Oh, hm, und wie kommt man jetzt wieder raus? Ja, letztens Grypt, Skript starten, zwei Minuten später geht es wieder, aber es ist vielleicht erstmal nicht so eine schöne Erfahrung für die Nutzer. Also machen, ja, aber drauf achten, was man dann macht. Genau, jetzt gibt es hier noch so ein paar lustige Expect Citi und dann gibt es noch Reports. Auf die Reports gehe ich noch kurz ein und was Expect Citis, aber nur ganz am Rande, das sind so Spezial-Zertifikatgeschichten in der Vergangenheit haben ja alle so ein bisschen gemerkt, war mit den CAs, da stellen die so eine zwischen CAs und dann kann da jeder für jede Domain irgendwelche anderen CAs ausstellen, das irgendwie uncool, auch für meine oder halt für Google oder so und deswegen hat man sich überlegt, ja, dann machen wir so irgendwie so öffentliche Monitore, wo alle CAs die Zertifikate ausstellen, die reinschreiben müssen. Das heißt, dann kann ich gucken, welche CAs für welche Domain Zertifikat ausgestellt haben. Ja, und dann kann ich das überprüfen, ob noch eine CAs für meine Domain auch ein Zertifikat ausstellt. Dann sagen wir, hey, was soll das? Und dann kriegen die Ärger, deswegen ist ja Verisign jetzt Geschichte und ein paar andere auch, weil die sind hier an die Spiele hingehalten haben und das wird dadurch aber sichtbar. Also, das ist nicht so einfach mit der Public Key Infrastructure. Da gibt es auch noch eine schöne Seite, das nur so als um auch zu zeigen, dass das komplex ist. Oh, ist gar kein HTTPS da. Und das von Google. Das haben die aber absichtlich gemacht. Und das auch noch für die PKI-Seite. Klingt ja erst mal schlimm. Also, sie gibt es auch als HTTPS-Version. Aber das ist Absicht. Ich gehe da jetzt nicht weiter, aber ich zeige nur noch, warum das so ist. Weil das tut auch nur weh, genau dann, wenn man es nicht braucht. Weil man hat ja hier so Zertification Revocation List. Das haben alle PKI's. Das hat auch Let's Encrypt. Die zeigt auf HTTPS. Warum ist das so? Wenn wir jetzt mal annehmen, dass diese URL, wo diese Revocation List liegt, die benutzt man auch nicht mehr so aktiv. Da gibt es jetzt wieder andere Methoden. Da sage ich auch noch ein, zwei kleine Worte zu. Aber das ist dann noch mal ein anderer Vortrag, übrigens ja mehr um die Header. Wenn man jetzt sagt, hey, ist das Zertifikat noch gültig, dann gibt es halt diese Liste, kann man nachgucken, steht das da drin. Wenn es da drin steht, dann ist es vielleicht nicht mehr gültig. Und dann ist das nicht okay, wenn ich zu dieser Ressource gehe. Wenn jetzt aber diese URL, auf der diese Liste liegt, auch ein ungültiges Zertifikat hätte, dann habe ich wieder so eine Schleife, die nicht funktioniert. Und dann ist es kaputt. Wenn ich wirklich sicher sein will, will ich halt diese Liste prüfen. Wobei man was macht man heute Tage anders. Weil es hat wieder ein paar Privacy Issues, weil wenn jeder dahin geht, um Lissab zu rufen, weiß ich ja, wo der gerade war, im Zweifel, oder dass er hat irgendwas anzürft. Und deswegen liegt das auf HTTP, weil diese Liste selber ist ja signiert, also sicher in Sicht. Das kann ich als Empfänger validieren, dass die von der richtigen CA kommt und dass das da drin steht, nicht verändert wurde. Und das ist ja öffentliche Information. Deswegen muss ich das ja nicht geheim transportieren, also nicht gegen Ausspielen schützen. Aber deswegen hat man das da auf HTTP. Ich habe auch so einen HTTPS-Header gehabt. Auf jeden Fall. Deswegen PKI-Betremmen und so ist kompliziert. Versucht man zu vermeiden, außer man weiß, was man macht. Genau. So viel dazu. Ja, das ist das Beispiel. Aber das ist okay. Und deswegen, heutzutage, macht man letzten Crypt. Aber wie gesagt, 90 Tage Timeline. Wenn man die Automatisierung nicht hat, dann muss man irgendwie andere Brotes sagen, wer von Hand das Ding aktualisiert und diesen Skript aufruft, damit er das Zertifikat erneuert. Okay, CT, genau. Certificate Transparency. Habe ich eben schon gesagt, das ist quasi ganz vereinfacht. Die PKIs müssen alle Zertifikate diese veröffentlichen in irgendein öffentliches Verzeichnis legen, beziehungsweise in mehrere. Was heißt das jetzt, wenn ich letzten Crypt für interne Infrastruktur benutze? Ich mache die Public. Kann man machen. Sollte man aber im Hinterkopf behalten und sich nicht wundern, wenn plötzlich alle Weltweiß, wie die Intensor war heißen. Das wird veröffentlicht. Also, ist eine gute Idee. Aber hat Zeiteneffekte. Sollte man kennen und entscheiden, ob das okay ist oder nicht für den Use Case, den man hat. Dann kann man auch für interne Systeme, let's encrypt, das kann man so ein bisschen rumroten und so, dann geht das schon, weil es hat ja keinen öffentlichen DNS-Eintrag dann, die Domain oder so, die ich damit schütze. Sollte man sich dann in einer радikanten Post-Code et cetera veröffentlichen? Das ist ja das Ver azid II. Weil die zertifikate veröffentlicht werden und alles, was in dem Zertifikat drinsteht, ist Public. Genau. SSL gibt es nicht mehr. Aber es heißt immer noch überall SSL, weil es die Basis, aber weiss ich, ich mache man TLS. Dans zwischen Version 1.3. Aber 1.3 kommt jetzt. Das ist jetzt verabschiedet der Standard. Warum hat das so lange gedauert? Die wollten das schon vor zwei Jahren machen. Weil es so andere Geräte gibt, die Sicherheit machen, indem sie HTTPS-Verbindungen aufbrechen, in Unternehmensnetzen, um da reingucken zu können, was da für JavaScript und so was hinhergeschickt wird, weil man nicht weiß, was man sich dafür Zeug einfängt. Und die haben das nicht standardkonform implementiert, die TLS-Protokolle. Das heißt, wenn jetzt ein System gekommen ist, dann sagen sie, hey, ich kann schon 1.3 und diese Security-Box, die ja eigentlich denn das HTTPS kaputt macht, hat sie gesagt, eh, 1.3 kenne ich nicht, ich gehe weg. Und Standardkonform wäre gewesen, der muss dann halt ein Downgrade machen und sagen, hey, ich kann nur 1.2, schick mir ein 1.2, lass uns über TLS 1.2 reden. Und deswegen hat sich das so ein bisschen verzögert, weil da alle noch ein paar Hausaufgaben machen mussten. Uns gab es noch ein paar andere Konflikte. Aber selbst die Algorithmen, da muss man jetzt auch schon wieder aufstehen und seine Hausaufgaben machen. Was da auch ganz gut ist, weil diese Security da gibt es auch ein Overs-Projekt. Wie ich hier immer noch mal einstreuen, es gibt auch eine Gruppe in Karlsruhe, da ist so eine Meetup-Gruppe, kann man gucken, kann man auch mal vorbeikommen, gibt es einmal im Monat einen kleinen Vortrag zu irgendeinem Thema, was man das mit Security zu tun hat, in der Regel mit Web-Anwendungen. Genau. Ja, hier ist dann nochmal die Übersicht, einfach im Slide Deck, dass man da einfach mal klicken kann. Also das kann man sich merken, ein bisschen mit Rumspielen, wie sagt, auf dem anderen Sinne noch mehr Links. Kann man schon, gibt es noch weitere Tools, die Ihnen dabei helfen, sich mit dem ganzen Head-Hand-Vertraut zu machen. Genau, das habe ich auch gezeigt, heißt jetzt kommen. Also die machen nochmal nur Security-Header, die machen nur HTTPS-Security, aber das sind so Standard-Tools, die sollte man kennen, als Entwickler, vor allem wenn man Web-Anwendung baut oder irgendwas mit APIs macht, da kann man das Zeug mal gegen testen und schauen, wo man steht. Das habe ich jetzt nicht weiter besprochen. Es gibt bei ein, zwei der Headern noch die Möglichkeit, sozusagen, wenn das in Client getriggert wird, einen Request an eine andere URL zu schicken, entweder auf derselben Domain oder auf einer anderen. Und das ist ein Dienst, der hilft einem dabei. Ist aber natürlich wieder eine externe Partei, muss man wissen, ob man das dahin schicken würde oder ob man es selber baut. Sind aber Leute aus der Security-Szene, aber trotzdem ist es ein unabhängiger Dienst. Ich kontrolliere das nicht. Muss man sich überlegen, ob man das machen will. Das ist aber eine gute Idee. Weil, was ist der riesen Vorteil davon? Ich merke vielleicht, wenn mein Server angegriffen wird, aber ich merke nicht, wenn der User-Agent angegriffen wird, in der Regel, habe ich darüber keine Informationen auf der Backend-Seite. Über diese Report-URIs, die man im HSTS und im CSP-Header mitschicken kann, ne, nicht im HSTS, nur im CSP-Header mitschicken kann, merke ich dann plötzlich, oh, da passieren komische Dinge auf der Client-Seite und kann dann da drauf reagieren. Das ist also ein Super-Monitoring-Feature, um auf mögliche Security-Vorfälle reagieren zu können, die ich sonst nicht sehen kann. Das heißt, ich mache mehr Dinge sichtbar für den Anwendungsbetreiber über diese Report-URIs, die man in einigen Headern hat. Deswegen ist es eine super Idee, die zu benutzen. Man hat die auch am Anfang, kann man den CSP-Header zum Beispiel auch in so ein Report-Undie-Modus schalten. Dann hat man auch im Chrome, in den Dev-Tool, zieht man dann, ah, was alles verletzt ist. Und dann weiß ich, okay, ich muss erst mal alles aufräumen, bevor ich das Ding live schalte, weil sonst die Anwendung dauernd geht. Und das ist halt auch eine gute Sache. Und hier ist nochmal Hinweis auf diese Net-Internet von Chrome. Das ist ein super Hilfsmittel, um das zu testen und halt so ein paar andere Sachen auch anzuschauen, mit dem man sich vielleicht manchmal rumärgert, wo man so als Entwickler noch mal Zusatzinformation bekommt, die vielleicht auch nicht in den Dev-Tools sichtbar sind. Da hat man hier noch mal einen ganz anderen Zuge auf die, wirklich auf die Internets vom User-Agent. Und man kann damit arbeiten, oder halt mal so ein CSP-Header oder ein HST-Header ausprobieren und gucken, was passiert. Genau, so, fertig. So, vielen Dank für deinen coolen Vortrag. Wir haben jetzt noch ein bisschen Zeit für Fragen. Richtig, wenn ich noch mal was zeigen soll, wenn es irgendwelche Verständnisfragen gibt, dann möchtest du mal ein bisschen mehr Zeit dafür aufgehoben. Soll ich noch mal eine andere Domäne ausprobieren? Können wir alles machen? Ja, nach vorne. Du hattest ja diese Kisten in den Filmarwänd, die für mehr Security sorgen sollen, indem sie TLS kaputt machen? Ja. Wie ist das mit dem Certificate-Pinning und den, also wenn ich diese Header mit schieße? Ja, also es ist so, ich hab das noch nicht wirklich selber ausprobiert. Aber es ist so, wie das funktioniert, ist es so, dass man noch eine zusätzliche CA in den Cert-Store z.B. vom Windows legt. Den benutzt ja auch der Chrome. Oder Firefox kann das inzwischen auch über den Fleck auf den OS Cert-Store zugreifen, nicht nur auf den eigenen. Und wenn der erkennt, dass das kein eingebautes ist, dann macht er das nicht. Das heißt, du merkst das nicht. Also das ist transparent an der Stelle. Auch von Chrome. Das heißt, wenn man so eine zusätzliche CA-Route, deswegen sollte man ab und zu auch seine OS Stores prüfen, was da so für CAs drin liegen. Deswegen ist das auch immer blöd, wenn irgendwelche Hersteller hergehen und da welche dazu liegen, weil die wirklich alles kündern. Und wenn dann der Private Key noch drin liegt, dann greifen die Sicherheitsmaßnahmen auch nicht mehr. Also wenn dann diese Kiste das aufbricht und dann neu verschlüsselt quasi mit einem selbst erstellten Zertifikat mit der eigenen Root CA, die der User Agent dann aber kennt und der weiß auch, dass sie lokal ist, weil sie nicht in seinem Cert-Store war, das heißt, nachinstalliert ist, dann fleckt er das nicht. Also, ja, das ist da... Naja, die Industrie muss halt funktionieren. Also da ist man dann auch... Ja, bei einigen anderen... Oder wo man denkt, die machen das immer schön, das stimmt nicht ganz. Das ist dann wirklich... Das kann voll transparent aufgebrochen werden und man merkt es nicht. Wenn man diese lokale CA im Trustor vom Betriebssystem hat, das Unterlinungsjahr genauso, dann... Ja, dann geht das. Deswegen muss man da wieder Zusatzmaßnahmen betreiben, um sich herzustellen, dass da nicht irgendwelche CA's auftauchen, die man da nicht haben will. Aber wenn das ein Angreifer, oder man installiert das mit seinem Tool, da hat das schon auf dem Laptop oder so, schafft die da hinzulegen, dann kann er komplett alle Verbindungen, da fleckt auch kein Chrome mehr, irgendwas. Zumindest war das mal mein Stand von Mamiya. Wie gesagt, das habe ich nicht wirklich durchgetestet. Könnte man mal machen, aber ich befürchte, das funktioniert immer noch, weil sonst viele große Unternehmen viele Probleme hätten mit vielen Mitarbeitern. Da arbeiten die dann schon alle zusammen. Okay, vielen Dank. Davor noch eine andere Frage? Also, ja, noch mal eine Rückfrage zur vorherigen Frage. Und zwar, ich glaube, es ging eigentlich darum, wenn in dem HTTP-Header ja, der Fingerprint von dem Zertifikat steht und die man in the middle attack, ja, ein Neues, auch weil die das Zertifikat ausstellt, dann stimmen die ja der Fingerprint. Ja, aber der ignoriert das dann, weil er weiß, dass das erlaubt ist in dem Fall, weil die RU-CA, die das gemacht hat, also das Zertifikat, was da ausgestellt wurde, ist von der RU-CA, die ich explizit dazugelegt habe. Und darüber wird es ausgehebelt. Also das heißt, in dem Moment, wo ich eine RU-CA drin habe, die nicht mit dem Browser ausgeliefert, also die nicht default ist, dann das kann man flägen, ja, und dann greift das wohl auch nicht mehr. Wie gesagt, das habe ich nicht validiert. Müsste man mal sauber durchtesten, aber ich glaube, das ist genau so eine, na ja, eine Backdoor im Prinzip, die, glaube ich, schon funktioniert, wenn bestimmte Voraussetzungen gegeben sind. Also, die geht nicht out of the box, aber aber wie gesagt, dieses Keep-Hinning, das macht sowieso mehr Kopfschmerzen, als es hilft. Also muss man wirklich gut sein in dem, was man tut, weil bei letzten Grippen muss ich ja dann auch, ich wechsle ja eigentlich auch immer die Schlüsselpaare, da muss ich ja auch immer schon das Schlüsselpaar, das nächste oder das übernächste auch schon haben, mir irgendwo hinlegen und dann nicht einfach ein neues generieren, sondern eins von den vorgenerierten Nehmen, wo der Hash schon beim Kleint bekannt ist. Was schon schwieriger, glaube ich, für den Standard-User. Ja, haben wir noch weitere Fragen. Ja, wenn keine Fragen mehr sind, dann danke ich auch, dass zuhören.