Fragen? Antworten! Siehe auch: Alternativlos
Man sollte Web-Developer einfach mal zwingen, in der Bahn zu entwickeln. Damit sich diese ganzen schlechten Angewohnheiten gar nicht erst einschleichen.
Übrigens: In letzter Zeit beobachtet man immer mehr Captchas in Webseiten, die sie ÜBERHAUPT NICHT BRAUCHEN. Insbesondere verachte ich Cloudflare da von vollem Herzen, die auch noch in anderer Leute Webseiten Captchas einbauen, weil ihre Marketingkokser Brand Awareness optimieren wollten. Absolut zum Kotzen.
"Please unblock challenges.cloudflare.com."
No. I don't think I will. Go fuck yourself.
Sie sind Kunde bei einem Rechenzentrum, das auf dem Papier super gegen alles abgesichert ist. Die hatten redundante Stromversorgung, genug Dieselgeneratoren und Diesel, um das ganze RZ ohne Teilrunterfahrung weiterbetreiben zu können, und Batterien zum Überbrücken des Anspringens der Diesel. Außerdem Techniker vor Ort, falls was passiert.
Dann gab es einen Stromausfall auf einer der Stromleitungen. Die Generatoren sprangen an und übernahmen. Dann gab es auf einer zweiten Leitung einen Kurzschluss, und der triggerte physische Sicherungen, die auch die Generatoren abschalteten.
Dann stellt sich raus, dass die Batterien, die 10 Minuten überbrücken können sollten, nach 4 Minuten alle waren.
Dann stellt sich raus, dass das Schließsystem nicht an den Notfall-Akkus hing und nicht operabel war. Die Reparateure kamen also nicht an die zu reparierenden Gerätschaften ran.
Oh und das Personal vor Ort? Das waren lauter Security-Leute und ein Techniker, und der arbeitete da auch erst seit einer Woche.
So ähnlich ist das auch bei Cloudflare. Da gehen die Leute eigentlich hin, damit Ausfälle gar nicht erst vorkommen, und wenn doch, dann sind sie schnell wieder behoben.
Wenn ich das selber baue, denken sich manche Firmen, dann sind die Dienste nicht so schnell wieder oben wie bei einem internationalen Cloudanbieter von Rang und Namen!
Stellt sich raus: Nope. Die pfuschen genau so wie alle anderen Pfuscher und wenn da was ausfällt, bleibt das gerne auch 24h kaputt. Oder mehr. Mal sehen.
Geht in die Cloud, haben sie gesagt! Wegen der Zuverlässigkeit, haben sie gesagt.
Wenn ja: Habt ihr alle Lack gesoffen? Sind bei den ganzen Firmen gar keine Erwachsenen mehr im Raum oder was ist da los?
Wenn ihr eure Credentials oder anderen Geheimnisse einem Third-Party-Dienst gebt, sind es nicht mehr eure Geheimnisse. Das ist ja nun echt keine Raketenchirurgie!
Mann Mann Mann
Und auch die Ausreden immer. "Aber wir haben doch eh schon alles an Cloudflare und Amazon weggegeben, das macht den Kohl auch nicht mehr fett."
Wo bleibt eigentlich die Revolution?
Trotzdem haben einmal alle üblichen Verdächtigen, deren Geschäftsmodell auf Kompetenzsimulation basiert, HTTP/2 ausgerollt, weil, äh, wir sind ja hier Technologieführer!1!!
Jetzt gibt es mal wieder einen HTTP/2-Angriff. Der betrifft niemanden von euch. Der betrifft die oben erwähnten Deppen üblichen Verdächtigen. Ich kann ruhig schlafen. Ihr wahrscheinlich auch. Betroffen sind Google, Cloudflare und Amazon. Sonst niemand. Ihr könnt alle beruhigt eure Vorurteile bestätigt sehen und weiter schlafen.
Ich radikalisiere mich ja langsam zum Fernseher. Ich warne vor etwas, keiner hört auf mich, und dann sehe ich mir aus der Ferne an, wie die Welt niederbrennt. Zum Wohl!
Update: Außerdem ist HTTP/2 eine Google-Erfindung. Google versucht hier also einen Heldenmythos zu etablieren, in dem sie uns vor dem Monster retten, das sie selbst geschaffen haben. Ohne den Teil zu erwähnen, dass sie das Monster geschaffen haben. Zum Kotzen, diese Tech Bros immer.
Microsoft pullt diese Nummer seit Jahrzehnten. Und kommen bis heute damit durch. Hier, kauf doch Defender oben drauf! Und zahl Extra für Cloud-Logs. Und kauf noch unser SIEM. Alles, damit du dich vor den Sicherheitslücken in unserer Software "schützen" kannst.
Die […] Sperre bei den Providern galt eigentlich dem Musikportal CannaPower. Da jedoch nicht die Domains, sondern die IP-Adressen gesperrt wurden, zog die Sperraktion auch Unbeteiligte in Mitleidenschaft. Die Provider sind gesetzlich dazu verpflichtet, die Sperren umzusetzen.Schlau!
Für mich persönlich ist jetzt bei Matthew Green der Zeitpunkt gekommen, die Reißleine zu ziehen. Der ist einfach zu häufig negativ aufgefallen. Erst mit Agitprop gegen GnuPG, dann mit Agitprop für Cryptocurrencies, und jetzt halt mit Agitprop gegen Dan Bernsteins Post-Quantum-Transparenzvorstoß. Ich betrachte den ab jetzt als NSA-U-Boot und schiebe ihn in meinem Threat Model auf die Angreiferseite.
Da kann er es sich neben Eric Rescorla bequem machen.
Diesen Go-Crypto-Typen, den er da zitiert, hatte ich noch nicht auf dem Radar, aber was der da schreibt ist geradezu grotesk schlecht. Da hat sich das Go-Team entweder einen naiven Anfänger oder einen Idioten eingetreten. Ich würde deren Crypto erstmal lieber nicht trauen nach diesen Aussagen.
Das war schon immer das Bedrohungsmodel in der Kryptographie, dass du davon ausgehst, dass dein Feind eine rechenschaftsfreie Regierungs- oder Militärbehörde mit unendlich viel Budget ist. Selbstverständlich musst du dann gucken, ob die nicht Kryptographen bestochen haben könnte. Nicht zuletzt weil die NSA ja tatsächlich RSA Inc bestochen hat, damit sie ihren Backdoor-DualEC-RNG weltweit verteilt haben. Das ist ja kein Fiebertraum, dass die NSA Kryptographen bestechen könnte!
Das ist seit echt vielen Jahren ganz normales Standardvorgehen, dass man z.B. bei komischen Konstanten in Krypto-Verfahren fragt, wo die herkommen, und ob die vielleicht irgendwas kryptografisch schwächer machen oder mit einer Hintertür versehen.
Seit vor 50 Jahren die S-Boxen von DES unerklärlich von der NSA kamen, ist das Teil des Bedrohungsmodells. Das Konzept hat sogar einen Namen: Nothing-up-my-sleeve Number.
Hier so zu tun als verbreite djb Verschwörungstheorien oder als beleidige er hier Kollegen, das ist so dermaßen jenseits von gut und böse, dass ich mit sehr viel Aufwand überhaupt die Annahme im Raum stehen lassen kann, dass das ein Versehen von dem Go-Typen war. Böse Absicht ist so viel wahrscheinlicher.
Update: Ein Leser schreibt, auch der Go-Typ ist schon durch GnuPG-Bashing aufgefallen. Ich habe mich auch schon abfällig über die Codequalität von GnuPG geäußert und das Dateiformat ist furchtbar, aber GnuPG war das Tool, mit dem Snowden sein Leben vor dem Zugriff der US-Behörden geschützt hat. Mit GnuPG. Nicht mit "age", nicht mit Google-Crypto, nicht mit Cloudflare-Crypto, nicht mit Microsoft-Krypto. Mit GnuPG. Wer also GnuPG generell die Existenzberechtigung absprechen will, und dann auch noch sein Gehalt von Google und Cloudflare nimmt, die um US-Regierungsaufträge konkurrieren, der ist mir direkt suspekt.
This outage was caused by a change that was part of a long-running project to increase resilience in our busiest locations.Operation erfolgreich, Patient tot! :-)
Ergebnis: web3 ist auch down.
Wir erinnern uns: web3 will man, weil das dezentral und daher unkaputtbar ist!1!!
$ host www.zensus2022.de www.zensus2022.de is a nickname for www.zensus2022.de.cdn.cloudflare.net www.zensus2022.de.cdn.cloudflare.net is a nickname for c7ba73fe210a4279bce9682f61b09d5c.pacloudflare.com c7ba73fe210a4279bce9682f61b09d5c.pacloudflare.com has address 141.101.90.2Nein, das heißt nicht, dass das in den USA liegt. Tut es auch zumindest von hier aus gerade nicht. Sowas könnt ihr schnell selber auf Plausibilität prüfen, indem ihr die Site pingt, und dann guckt, wie viel Latenz die Antwort hatte.
Ich krieg hier gerade eine Latenz von ~10 ms und komme (kann man mit traceroute/mtr/tracert sehen) beim BCIX raus, also in Berlin.
Eine Webseite, die tatsächlich in den USA gehostet wird, hat aus Europa eher so eine Latenz über 100 ms.
Update: Nein, das heißt auch nicht, dass die Site nicht doch in den USA liegt. Aber an dem DNS kannst du das halt erstmal nicht erkennen, und an der Position des Caching-Servers auch nicht.
Selbst wenn man das erkennen könnte, wäre das immer noch nur eine Momentaufnahme und morgen könnte das woanders liegen.
Jahrelang haben sie nur an Lizenzkosten für ihre schlechte Software verdient, an Supportverträgen für Großunternehmen, an eigentlich das Kartellamt betreffende Upselling-Reindrückaktionen für Infrastruktur wie Sharepoint und Exchange, jetzt noch an Cloud-Gebühren, die so grotesk sind, dass Cloudflare das Geschäftsmodell hat, ein Cacheing davor anzubieten, um die Kosten geringer zu halten.
Von den paar Brosamen lebt Microsoft im Moment.
Doch damit ist jetzt Schluss.
Jetzt verdient Microsoft auch noch an "Experten", die sie euch in die Firma schicken.
Die kümmern sich da um Probleme, die durch den Einsatz von Microsoft-Produkten überhaupt erst entstanden sind.
Ja nee nee, Moment. Ihr zahlt für die Experten. Das ist kein Kundendienst.
Ich finde ja immer geil, wie Microsoft einfach behaupten kann, sie hätten Experten, und die Leute glauben das dann auch noch. Wenn Microsoft Experten hätte, wieso müssen sie dann immer noch jeden Monate Dutzende von Patches raushauen? Wieso verkacken sie immer noch so viele von den Patches?
Wieso haben wir inzwischen Patch-Testen beim Kunden mit "Preview"-Patches?
Das wird echt eine interessante Frage für Historiker, wie diese Firma jemals so viel Einfluss gewinnen konnte.
Aber hey. Akkurat eingeschätzt, die Kunden. Wer so blöde ist, Windows, Exchange, Active Directory und Office einzusetzen, und dann so blöde war, sich von Microsoft einen Defender andrehen zu lassen, der Probleme fixt, die man ohne Microsoft nicht hatte, und der dann auch noch so bekloppt ist, in die Microsoft-Cloud zu ziehen ... der dann externe Hilfe bezahlt, um die Ransomware wieder loszuwerden ... NA KLAR ist der dann auch so blöde und zahlt auch nochmal für "Experten" von Microsoft.
Idioten von ihrem Geld trennen ist das zweitälteste Geschäftsmodell der Welt.
Aber stellt sich raus: Da ist noch Luft nach unten. Man kann Single Sign On an die Cloud outsourcen. Dann kann die Firma in der Cloud für jeden deiner Dienste und jeden deiner User inklusive Admins gültige Login-Credentials ausstellen.
What could possibly go wrong?
Es gibt eigentlich nur zwei Möglichkeiten, dachte ich mir, als ich das hörte. Entweder das wird von einem Geheimdienst betrieben, oder alle Geheimdienste haben sich da reingehackt. Das ist ja als wenn du mit einem Bullseye auf dem Rücken rumrennst. So einem krassen Potential zur Berechtigungserlangung kann kein Geheimdienst widerstehen.
Ich sehe sowas bei Kunden eher selten, aber ich habe es schon gesehen. Cyberark z.B. ist mir schon begegnet. Ein israelischer Anbieter. Ich maß dem nie groß Bedeutung zu, bis ich mal an deren Hq in Israel vorbeikam. Hier ist ein Foto von dem Gebäude. Wisst ihr, wer da noch sitzt? Cellebrite. Ja, die mit den Smartphone-Exploits. Da verstand ich, dass wir es hier mit Full Spectrum Identity Services zu tun haben.
Ich erwähne das nicht, um mich über die Leute lustig zu machen, die ihre Login-Software an irgendeinen Cloud-Anbieter outsourcen. Nein. Die haben genug zu leiden.
Ich erwähne das, weil Lapsus (russische Ransomware-Gang) offenbar seit Monaten bei Okta drinnen sitzt. Okta bietet Single-Sign-On-Cloud-Outsourcing an.
Auf er einen Seite ist das natürlich apokalyptisch. Auf der anderen Seite ändert es nichts. Denn die Aufgabe von Login ist, dass sich niemand aus der Cloud einfach bei dir einloggen kann. Wenn du dein Login in die Cloud schiebst, hast du per Definition dein schlimmstes Bedrohungsszenario immanentisiert.
Und jetzt haben wir den Salat. Beziehungsweise den Emmerich-Film. Und ich bin der Jeff Goldblum-Charakter, der die ganze Zeit gewarnt hat.
Mein persönliches Karriere-Highlight in dem Kontext war ja, als ein Kunde von mir wollte, dass ich so einem Provider einen Voice-Print gebe. Ich sollte da anrufen und lauter Phoneme auf Band sprechen. Und dann, so die Erklärung, wenn ich mal mein Passwort resetten muss, dann kann der Computer erkennen, dass ich es bin. Ich habe dankend abgelehnt. Das ist ja eine Sache, ob der Kunde mein Passwort einem ausländischen Geheimdienst in der Cloud gibt, aber meine biometrischen Daten behalte ich lieber für mich, vielen Dank. Der Kunde konnte das gar nicht verstehen. Wir anderen Mitarbeiter bei dem Kunden machen das auch alle und noch nie gab es Ärger!
Vielleicht aus aktuellem Anlass bei der Gelegenheit an meine anderen Kunden: Keine Sorge. Selbstverständlich kriegt jeder Kunde sein eigenes zufällig generiertes Passwort mit ausreichend Entropie. Wenn ein Kunde mein Passwort in die Cloud schiebt, kriegt die Cloud keinen Zugriff auf meine Accounts bei anderen Kunden.
Irgendjemand muss ja hier ein paar Standards haben. :-)
Update: BTW: Glaubt mal gar nicht, ihr condescending Unix neckbeards, dass ihr nicht betroffen seid von dieser Art Irrsinn. Ein Kumpel schildert mir gerade, wie ihn der neue Ubuntu-Installer nach seinem Github-Usernamen fragte, damit er da SSH-Keys runterladen kann. Und über diesen Clownflare-Klassiker von 2019 lachen wir heute noch.
Update: Bei Microsoft scheint Lapsus auch eingedrungen zu sein.
Update: Möglicherweise via Okta? Der Okta-Krater sieht jedenfalls vergleichsweise groß aus.
Update: Hat hier jemand seinen Quellcode bei Gitlab liegen?
Nicht?
In sozialen Netzen finden die ja nicht mehr statt, Fernsehen von denen wurde auch verboten, die Webseite geht seit Anfang des Monats nicht mehr.
Auch bei Google findet man keinen RT-Content mehr. Hier ist der zugehörige Eintrag aus der Lumen-Datenbank. Wenn ihr da mal ein bisschen das Kleingedruckte durchlest, findet ihr diesen Absatz hier:
As regards the posts made by individuals that reproduce the content of RT and Sputnik, those posts shall not be published and, if published, must be deleted.Also nicht nur RT. Auch Privatleute, die RT-Content wiedergeben.Das ist übrigens nicht nur Deutschland. Ein Kumpel aus Belgien hat gerade mal probiert und bei dem kommt eine Stoppschild-Seite. Er hat daraufhin mal Tor probiert, und auch per Tor kam er nicht dran.
Das ist nicht verwunderlich, denn die meisten Tor Exit Nodes stehen in ... Deutschland. Ja, Deutschland, weil das immer alle für den Hort der Freiheit hielten. Wo sonst würde man seine Exit Nodes aufstellen, wenn nicht in einem Land, wo verfassungsmäßig garantiert keine Zensur stattfindet?
Seid ihr eigentlich auch so froh, dass ihr bei den Guten seid?
Update: Wo ist eigentlich die Gesellschaft für Freiheitsrechte, wenn man sie braucht?
Update: Das ist übrigens technisch eine DNS-Sperre. Wer seinen eigenen DNS-Server betreibt, ist nicht betroffen. Im Moment scheinen auch die öffentlichen DNS-Server von Google, Cloudflare und IBM noch nicht zu zensieren.
Update: Mehrere Leser schreiben mir, dass sie von der Zensur noch nichts bemerkt haben, bei ihnen ginge es. Ich kann hier gerade live testen, dass Vodafone und O2 das zensieren. Ein Kumpel mit Telekom-DSL kann es noch auflösen. Das wäre ja bemerkenswert, wenn ausgerechnet die Telekom die Zensurorder nicht umgesetzt hätte.
Ansonsten kann es auch sein, dass ihr in eurem WLAN-Router 8.8.8.8, 1.1.1.1 oder 9.9.9.9 eingetragen habt. Oder, was auch mal interessant zu wissen wäre, vielleicht benutzt ihr Firefox und die haben ihr DoH-Antizensur-"Experiment" auch für Deutschland freigeschaltet und resolven dann über 1.1.1.1.
Außerdem scheint es einen Unterschied zu geben, ob man nach rt.com fragt oder nach de.rt.com. de.rt.com ist auch bei der Telekom blockiert, meint mein Kumpel.
Update: Die Gesellschaft für Freiheitsrechte äußert sich. Sie finden, der Kreml solle seine Klagen mal selber finanzieren.
Ich weiß nicht, wie ihr das seht, aber ich fand nicht, dass es hier um die Rechte von RT geht. Ich fand, dass es hier um meine Rechte geht. Das mag euch jetzt überraschen, aber ich hätte meine Rechte viel lieber von der GFF verteidigt als vom Kreml.
Update: Die rechtliche Grundlage für die Vorzensur ist anscheinend diese EU-Verordnung. Ich hätte ja gerne mal eine zweite Expertenmeinung eingeholt dazu, ob die überhaupt die Befugnis für so eine Zensuranordnung haben. Schade, dass die GFF dafür offenbar nicht zur Verfügung steht. Ich bin ehrlich gesagt ziemlich enttäuscht von Ulfs Argumentation hier. Ist ein Haftbefehl eines Landes, das extraterritoriale Folterknäste betreibt, auch nicht so schlimm, solange Fefe weiß, wo die ecuadorianische Botschaft ist?! Das kann ja wohl nicht ernsthaft das Bewertungskriterium sein.
Die Antwort könnte die Bevölkerung verunsichern.
Mindestens zwei Stunden muss eine Windows-Maschine durchgängig online sein, um neue Updates herunterzuladen. Bis zur vollständigen Installation benötigen die Maschinen dann sogar sechs Stunden ununterbrochene Online-Zeit. So lautet das Ergebnis einer Microsoft-Untersuchung, warum mancher Windows-Rechner verlässlich automatisch die monatlichen Sicherheits- respektive die halbjährlichen Feature-Updates erhält, während andere jedoch einen manuellen Stupser zum Installieren brauchen und ohne Nachpflege gefährlich veralten.Die Leute sind einfach nicht lang genug online, um der verkackten, lahmarschigen, überlasteten Azure-Infrastruktur erfolgreich Updates zu entlocken. Ein paar Dutzend Versuche braucht der Autoupdater dafür halt!1!! Oder wie soll man das verstehen?
Au Mann Ey.
Hey, Leute, wenn ihr nicht in der Lage seid, eure Updates zeitnah downloadbar zu machen, dann redet doch mal mit einer Firma, die sich mit sowas auskennt. Akamai oder Google oder so. Cloudflare! *schenkelklopf*
Es gibt ein paar hervorhebenswerte Aspekte daran.
Nun, stellt sich raus: Cloudflare cached bis 15GB. Kann man einstellen, muss man aber nicht. Hat er nicht. Seine Hash-Datenbank zum Download hat kürzlich die 15GB-Grenze gerissen.
Also hat Cloudflare die nicht mehr gecached. Also schlugen die Kosten auf Azure durch und er bekam eine Rechnung über 5000 AU$ von denen. Als er das diagnostiziert und gefixt hatte, kam die zweite Hälfte der Rechnung, nochmal 6000 AU$.
Bonus: Er findet Cloud immer noch voll geil und will auch nicht von Azure weggehen.
Es gibt online zwei Hinweise, was man tun kann. Erstens: http3 abschalten (in about:config network.http.http3.enabled auf false) und zweitens: In about:preferences#privacy bei Firefox Data Collection and Use alles abschalten.
In meinem Firefox ist http3 nicht deaktiviert, aber ich habe natürlich aller Data Collection widersprochen.
Aus meiner Sicht würde ich also nicht das Ausschalten von http3 empfehlen, denn das ist bei mir an und ich habe kein Problem, sondern die Datenkrakenabschaltung.
Dann kursiert noch die Idee, dass das was mit DNS over HTTP zu tun hat. Das habe ich nicht angeschaltet, weil ich Cloudflare nicht traue. Ich musste es aber, soweit ich mich erinnern kann, auch noch nicht ausschalten, weil Firefox das in Deutschland noch nicht hinter meinem Rücken anzuschalten versucht hat.
Update: Sieht als als sei Telemetrie bloß der Trigger gewesen. Leute berichten, auch Firefox 91 habe schon den Bug. Mir ist er immer noch nicht begegnet.
Aus aktuellem Anlass sei auch nochmal auf meine Ausführungen zu HTTP/2 von 2015 und aus 2019 verwiesen. Ich habe HTTP/2 nie implementiert, weder client- noch serverseitig. Das ist gar nicht mit akzeptabler Softwarekomplexität implementierbar, wenn man irgendeinen der (eh nur theoretischen) Vorteile haben will. HTTP/3 bestätigt mich da inhaltlich, denn es ist ein Wegschmeißen von HTTP/2 und ein Neumachen auf Basis von QUIC. Hier ist die Spec von QUIC. Könnt ihr euch ja selbst überlegen, ob ihr das von der Komplexität her für akzeptabel haltet.
Oh, warte, sagte ich wegschmeißen und neumachen? nicht wirklich:
HTTP/3 is an Internet Draft adopted by the QUIC working group. The original proposal was named "HTTP/2 Semantics Using The QUIC Transport Protocol",[8] and later named "Hypertext Transfer Protocol (HTTP) over QUIC".[9]
Denn bei Kommittee-Standards ist das wie bei Hoardern. Da wird nie irgendwas weggeschmissen, egal wie schlimm es stinkt.
Update: Nochmal langsam zum mitmeißeln: Komplexität ist der Feind.
Man kann auch eine Menge andere Dinge erkennen. Zum Beispiel: Wenn die Partei dich zur Briefwahl nötigen will, ist genau wie wenn dich eine Computerspielefirma zum "Pre-Purchase" nötigen will. Die wollen gerne, dass du jetzt, wo es außer heißer Luft und billigen Versprechen nichts gibt, die Entscheidung triffst, damit du nicht mehr abspringen kannst, wenn sich vor der Wahl noch rausstellt, dass das alles Lügen waren und die Partei dich nach Strich und Faden verarscht hat.
Soweit ich weiß, ist die per Briefwahl abgegebene Stimme auch tatsächlich bindend und nicht korrigierbar. Korrigiert mich, wenn ich da falsch liege. Aber selbst wenn das nicht so wäre: Wer sich einmal festlegt, ändert seine Position nur sehr unwahrscheinlich. Ein abgegebener Wahlzettel fühlt sich an wie ein Versprechen. Versprechen brechen ist sozial geächtet. Niemand will unzuverlässig sein.
Lasst euch also bitte nicht zur Briefwahl nötigen. Es gibt gute Gründe für eine Briefwahl. Aber "weil die CDU mich drängte" ist keiner davon.
Aber eigentlich ging es ja um Digitalisierung. Der offensichtliche Prüfstein ist: Setzen die Cookies und lügen dir im Terrorbanner noch ins Gesicht, sie täten das für dich und um deine "Erfahrung zu optimieren"? Binden die externe Ressourcen ein? Am besten noch ausländische?
Gucken wir doch mal.
Oh und: Sie setzen einen Cookie. Ohne um Erlaubnis gefragt zu haben.
Inhaltlich ist das natürlich auch grotesk. Die schreiben da ernsthaft:
„Respekt – das ist meine Idee für unsere Gesellschaft. Dafür kämpfe ich mit Leib und Seele, mit Herz und Verstand.“Von dem Olaf Scholz, der Folter für mutmaßliche Kleindrogendealer eingeführt hat. Der lügt uns jetzt was von Respekt ins Gesicht. Unglaublich.
Oh und darunter? "JETZT BRIEFWAHL BEANTRAGEN". Danke. Keine weiteren Fragen.
Die CDU bindet Ressourcen von zwei COM-Domains ein. Einmal von Cloudflare, das ist bei mir in nächster Nähe in Berlin gehostet, und einmal von einem dänischen Anbieter, der bei Amazon US-WEST hostet. Ja, richtig gelesen! Die haben einen externen Anbieter für ihr Cookieterrorbanner, setzen direkt 4 Cookies, bevor man da zustimmen konnte, und dann liegt das Cookieterrorbanner auch noch in den USA. Schlimmer verkacken kann man das gar nicht an der Stelle.
Aber was ist ihr erster inhaltlicher Punkt nach dem Aufmacher-GIF? "JETZT BRIEFWAHL BEANTRAGEN!". Danke. Keine weiteren Fragen.
Was ich bei den Grünen noch auffällig finde:
Hilf uns, den erfolgreichsten Bundestagswahlkampf aller Zeiten vorzubereiten! Wir wollen möglichst viele Erstwählerinnen in der ganzen Republik auf die Wahl aufmerksam machen.Wir sind hier nur an Frauen interessiert. Männer können ruhig CDU wählen gehen.
Wie so häufig stellt sich raus, dass die Linkspartei als einzige nicht Totalversager sind.
Ich versteh echt nicht, wieso die bei den Umfragen nur bei 7% liegen gerade. Ich meine, die Leute sind von Baerbock und Laschet so abgetörnt, dass sie den Scholz in Erwägung ziehen! Aber nicht die Linken!?
Ich frag das ja gelegentlich Leute, wieso die Linken eigentlich nicht mehr Stimmen kriegen. Da kommt dann häufig: Aber die ganzen SED-Kader!1!!
Das ist ein Mem aus den 90er Jahren. Das stimmte damals nicht und stimmt heute erst recht nicht. Wenn euch alte Stasi-Kader sorgen, müsst ihr mehr Angst vor der CDU haben als vor den Linken!
Dann kommt noch häufig: Aber die Klimakatastrophe! Da muss man doch die Grünen wählen! Ach? Ist das so?
Die Linkspartei hat sicher auch ihre Probleme, gar keine Frage. Aber was da so gegen sie vorgebracht wird, das sind keine davon.
Wie verstrahlt die Situation ist, kann man auch gut daran sehen, dass die Leute der SPD, die ihnen Hartz IV gebracht hat, sie zu ewiger Armut und staatlicher Gängelei verurteilt hat, und aus Kohlekumpelstimmfanggründen lieber Kohlekraftwerke betreibt als was gegen die Klimakatastrophe zu tun, dass man DENEN mehr Sozialkompetenz zutraut als den Linken.
Lest euch mal deren Programm durch. Guckt euch mal deren Gesetzesvorschläge an! Wat!?
Der Fairness halber hier noch eine Gegenposition: Mein Kumpel Erdgeist ist frisch nachgeschulter Wahlhelfer, und der findet, dass es dieses Mal mit Covid und den hochkomplexen Wahlzetteln in der Tat kein gültiger Kritikpunkt ist, wenn Parteien ihre Wähler zum Briefwählen nötigen wollen. Er sagt auch, dass man sich nach der Briefwahl nochmal umentscheiden kann. Man muss dann zum Wahlamt laufen und denen die Situation erklären und die invalidieren dann den Wahlzettel und geben dir einen neuen. Würde mich wundern, wenn das irgendjemand wahrnimmt, ehrlich gesagt, denn Briefwahl machste ja gerade, um dir den einen Behördengang zum Wahllokal zu sparen. Wenn du zum Umentscheiden zum Wahlamt musst, dann machste ja unterm Strich sogar Verlust im Vergleich zur Präsenzwahl.
Update: Mir schriebt jemand, dass es die Wahlkampfkostenerstatung ab 1% gibt. Das wusste ich nicht, ich dachte die gibt es ab 5%.
Update: Der Vergleich betraf nur die Homepages. Wenn man da Links folgt, sieht das möglicherweise anders aus und da kommen dann auch bei den Linken Youtube-Videos mit Zustimmungsterrorbanner. Seufz.
Der Cloudflare-Timeout gestern? Das war mein Aprilscherz.
Aber das Niveau an Paranoia unter meinen Lesern empfinde ich in diesen schweren Zeiten als sehr positiv. :-)
Und keine Sorge. Ich habe keinen von euch tatsächlich zu Cloudflare geschickt, auch nicht für Ressourcen auf der Timeout-Seite.
Unbefugte haben nach einem Medienbericht 150.000 Überwachungskameras einer US-Firma unter anderem in Krankenhäusern, Gefängnissen, Schulen und Polizeirevieren angezapftSie sagen wohl, sie hätten das Passwort im Internet gefunden.
Da fände ich ja weniger interessant, wo sie das gefunden haben, sondern wieso es "das Passwort" gibt und damit kommt man dann überall rein.
Betroffen sind Unternehmen wie der Elektroauto-Hersteller Tesla und die IT-Sicherheitsfirma Cloudflare.Der Hersteller ist wohl dieses Startup hier. Hätten sie mal ihre Kohle in tatsächliche Security investiert statt in Hochglanz-Webseiten. Deren Slogan ist jedenfalls nicht gut gealtert:
By approaching safety with a software-first approach, we’re making security as seamless and modern as the organizations we protect.Software-first approach, ja? Im Hintergrund hört man ein heiseres Wyle E Coyote Lachen.
Inhaltlich sieht das sehr spannend aus, und die Beispiele klingen hervorragend für die Bandbreite. Ich würde trotzdem noch nicht die Sektkorken knallen lassen.
Das ist das Wesen von Machine Learning, dass die Beispiele toll sind. Andere Beispiele sind dann weniger toll.
Ich habe mich ja schon über die früheren Versuche von Cloudflare öffentlich geärgert, und aus meiner Sicht ist alles, was irgendwo in der Infrastruktur ein Cloudflare beinhaltet, direkt abzulehnen.
Aber ich hab mir das RFC mal angeguckt. Stellt sich raus: Die machen da Onion Routing. Also so ein bisschen. Eine Zwiebel mit nur einer Schicht. Ist wie Tor, nur schlechter.
Nehmen wir mal an, ich will was im DNS nach gucken. Dann hole ich mir aus dem DNS (das RFC liegt bisher nur als Draft vor, und es sagt: ich soll dem nur trauen, wenn es per DNSSEC kam!1!!) den public key von dem Cloudflare-Service. Dann gehe ich zu einem der drei Proxy-Server, der für Europa steht bei Surfnet (in den Niederlanden). Dem drücke ich eine Anfrage in die Hand, über https, aber die Anfrage ist auch nochmal verschlüsselt mit dem pubkey von Cloudflare. Surfnet geht damit zu Cloudflare und Cloudflare hat dazu den private key und kann das entschlüsseln.
Die Idee ist, dass Cloudflare dann nur die IP von Surfnet sieht, nicht von mir.
Cloudflare verschlüsselt dann die Antwort an meinen pubkey, den ich in dem Paket mitgeschickt habe.
Da können wir direkt aufhören, über das Protokoll zu reden. Da steht dann zwar nicht meine IP dran, aber mein pubkey. Das ist genau so eindeutig. Was für Spezialexperten denken sich denn bitte solche Protokolle aus!?
Nun würde man denken, dass im RFC steht: du musst pro Anfrage nen anderen Key nehmen. Steht da aber nicht.
Jetzt stellt sich auch die Frage, wieso da überhaupt ein public key drinsteht. Wir haben ja das Protokoll so entworfen, dass nur Cloudflare die Anfrage entschlüsseln kann. Da hätte ich also auch einfach direkt einen zufälligen AES-Key reintun können und mit dem kommt dann die Antwort verschlüsselt. Der Proxy sieht dann die verschlüsselte Antwort aber sah den Key vorher nicht. Public Key Krypto ist langsam und teuer!
Ich fühle mal wieder alle meine Vorurteile vollumfänglich bestätigt.
Seufz.
Mit so einem gemeinsamen Key kann man übrigens auch "signieren". Machst du ein SHA-256 von den Nutzdaten plus dem Key, den du aber nicht in der Antwort wieder mit rausschickst. Fertig. Sparst du dir auch noch die Signier-Pubkey-Operation.
Jedenfalls, warum ich das blogge... der Einsender hat auch ein Zitat aus dem Kleingedruckten geschickt, das ich hier mal wiedergeben will:
60% to DJTP for deposit in DJTP’s 2020 General Election Account for the retirement of general election debt (up to a maximum of $2,800/$5,000) or, if such debt has been retired or any portion of the contribution would exceed the limit to the 2020 General Election Account, for deposit in DJTP’s Recount Account (up to a maximum of $2,800/$5,000); 40% to the RNC’s Operating account (up to a maximum of $35,500/$15,000); and any additional funds to the RNC for deposit in the RNC’s Legal Proceedings account or Headquarters account (up to a maximum of $213,000/$90,000).Ein Conman bis zum letzten Atemzug. Die Kohle der Spende für das Bekämpfen von "Wahlbetrug" geht mitnichten in die "Bekämpfung" von "Wahlbetrug" sondern damit zahlt Onkel Donald erstmal seine Schulden ab.Wobei man das ja auch positiv sehen kann. Sonst lässt Donald die Gläubiger einfach im Regen stehen. Hier mal ne Shell Company pleite gehen lassen, da mal ne Privatinsolvenz, ich glaube das ist das erste Mal, dass der überhaupt irgendwas zurückzahlen will. Oder vielleicht tut er ja auch nur so, um den Gläubigern glaubwürdig simulieren zu können, er habe alles versucht.
Aber das reicht ihnen nicht. Das sind auch die mit dem öffentlichen DNS-Server, der sieht, auf welche anderen Seiten ihr so geht.
Aber das reicht ihnen nicht. Das sind auch die mit dem Pilotprojekt für "verschlüsseltes DNS" mit Mozilla, damit sonst keiner sieht, was sie sehen können.
Und jetzt stellt sich raus: Auch das reicht ihnen noch nicht. Jetzt wollen sie auch noch, dass ihr ihren Cloud-Webbrowser benutzt. Damit sie auch noch sehen können, wo ihr die Maus hinbewegt aber nicht draufklickt, und wie lange ihr auf welcher Seite bleibt.
Gut, man könnte sagen, so häufig wie die ihre eigene Infrastruktur abschießen, da muss man keine großen Sorgen haben, dass nicht auch ihre Datenbanken mit den Datenkrankendaten periodisch gelöscht werden. Aber darauf würde ich mich ja eher nicht verlassen wollen. Browser in der Cloud ist jedenfalls die denkbar dämlichste Idee, die ich in den letzten Jahren gehört habe. Ja, NOCH dämlicher als "wir leiten alle Mozilla-DNS-Anfragen über Cloudflare".
Es ist natürlich auch ein massives Sicherheitsproblem, weil dann alle eure Logindaten für Webseiten bei denen in der Cloud landen und dort abgreifbar sind, für Cloudflare und sonstige Angreifer.
Wo wir gerade bei Datenkraken waren: Stellt sich raus, dass Google Chrome Google-Webseiten gerne mal von Privatsphäreneinstellungen ausnimmt. Uns hat der Benutzer bestimmt nicht gemeint, als er gesagt hat, er will alle Cookies löschen!1!!
Update: Hier kommt gerade noch ein Leserbrief dazu rein, der einen anderen wichtigen Aspekt beleuchtet:
dieser Satz hier (Zitat)
As a result, the only thing every sent to a user's device is a package of draw commands to render the webpage and this also means that the company's new service will be compatible with any HTML5 compliant browser including Chrome, Safari, Edge and Firefox.hat für mich noch eine ganz andere Implikation. Wenn ich den Ansatz richtig verstehe, bekommt der *echte* Browser auf dem so kastrierten Gerät nur noch einen Satz svg.Draw-Kommandos statt der eigentlichen Webseite. Das bedeutet, dass auch alle Meta-Informationen über die Objekte der Seite wegfallen und alles nur noch über Koordinaten, wo der User klickt, laufen muss. Wie sie mit Tastatureingaben umgehen sagt der Artikel nicht. Auf jeden Fall zerschießt ein derartiger Ansatz einmal komplett und rückstandsfrei den Access-Tree einer Seite - nein *aller* Seiten. Das ist der Ort, wo assistive Software heutzutage 95% ihrer Informationen hernehmen um beispielsweise Webseiten vorlesen zu können, Vergrößerung anzubieten oder Navigation in Seitenstrukturen möglich zu machen.
Das ist ein Arbeitsplatz-Zerstörungsprojekt für jegliche Menschen mit einer Behinderung, die ihren PC anders als mit Point and click bedienen wollen oder müssen!
Stell dir nur mal den ersten Arbeitstag für so einen Menschen in seinem neuen Unternehmen vor.
Im Bewerbungsgespräch noch so: "Mit assistiver Technik kann ich, ggf. mit Anpassung, heute ziemlich jede Software schnell und produktiv bedienen."
Vor Ort so: "Dann richten Sie sich mal ein. Gern geben wir Ihnen etwas mehr Zeit dafür. Wir nutzen übrigens Cloudflare for Teams mit Browser Isolation."
Neue Angestellte: "Oh ..." *panischer Blick* "Kriegen wir das irgendwie anders hin?" (Erklärungsversuch)
Vorgesetzte und Personalerin: "..." *tauschen Blicke*
Was machen die noch gleich beruflich?
Oh ja richtig, Router konfigurieren, um die Ausfallsicherheit zu erhöhen!1!!
Mein Blog ist übrigens ganz unausfallsicher auf einem Rechner bei einem normale Hoster gehostet. Und wisst ihr, was passiert, wenn ihr das von weit weg lesen wollt? China oder Amerika oder so? Es geht einfach. Ganz ohne verteiltes Caching. Flutscht.
Allerdings sind die Symptombeschreibungen aus den USA und Europa subtil unterschiedlich. Vielleicht handelt es sich daher um zwei Ausfälle, die nur zufällig gleichzeitig stattfanden.
Weiß da zufällig jemand genaueres?
Update: Auf einer Pressekonferenz zur Corona-App hat der Telekom-Vorstand angesagt, die 5G-Umstellung sei Schuld gewesen. Das klingt erstmal wie die schlechteste Ausrede aller Zeiten, aber mir hat auch jemand erzählt, wie sie das intern ihren Mitarbeitern erklärt haben. Da klingt die Geschichte so: Die haben versehentlich eine für 5G benötigte Konfiguration frühzeitig freigeschaltet, woraufhin ihnen irgendein Schlangenöl die Infrastruktur runterfuhr, um den "Angriff" abzuwehren, und das hat halt auch die Mobilfunkkunden abgewehrt.
Meldung 1: Tech von NSA-Mitarbeitern soll eure Browser absichern, sagt McAfee. Warte mal, McAfee? Die, die gerade mal wieder mit heruntergelassenen Hosen erwischt wurden? Die, auf die sich das Kammergericht Berlin verlassen hatte, um dann festzustellen, dass sie verlassen waren? Ja, genau die!
Meldung 2: Die Telekom macht jetzt auch Security! Ergebnis:
Bei einem Softwareupdate der beiden betroffenen Routertypen habe man versucht, die Geräte gegen eine neue Angriffsart abzusichern. "Durch diese Implementierung werden ungewöhnlich kleine Netzwerk-Pakete, die häufig bei bestimmten Angriffen verwendet werden, vom Router ignoriert", heißt es in dem Statement.What the FUCK? Kleine Pakete? Soll das ein Scherz sein? Wisst ihr, welche Pakete klein sind? DNS! Signalisierung von TCP! Ping!
Erst nachträglich habe sich herausgestellt, dass diese Art von Datenpaketen nicht nur von Angreifern, sondern auch von den Onleihe-Servern sowie einigen älteren IoT-Geräten verwendet würden.Ja, äh, NO SHIT, SHERLOCK!
Meldung 3: IOTA wurde final zerstört, haben das eh schon verspielte Vertrauen endgültig verspielt (oh und Bonus: Cloudflare war involviert!). Und in der Mitte des Artikels? "Lesen Sie auch: IOTA - die nächste Generation der Blockchain?"
Srsly? Hey, Heise, fällt euch das nicht selber auf, wie lächerlich ihr euch da macht?
Na immerhin kriege ich die "bestmögliche Nutzererfahrung" auf eurer Seite, wenn ich sinnlosen Cookies zustimme. Und ihr verratet meine Metadaten direkt an ausländische Datenabschnorchler wie Cloudflare. Danke, BMWI! Das ist alles, was ich mir von eurer Digitalkompetenz erhofft hatte!
Dazu kommt, dass viele Entwickler selber dick Internet haben, und es daher nie nötig fanden, ihre externen Modul-Downloads zu cachen oder anderweitig dafür zu sorgen, dass da nicht zu viele Fetches auf einmal aufschlagen und die Infrastruktur plattmachen.
Das ist für viele Open-Source-Projekte ein Problem, die ihren Scheiß selber hosten, und ist einer der Gründe für den Erfolg von github und co. Dann trägt die Kosten der Plattformbetreiber.
Ich spreche das an, weil npm jetzt Rate Limiting eingeführt hat. Das Ergebnis ist genau das, was ihr jetzt vermutet: Den ganzen "viele Dependencies sind ein Zeichen für ausgereiften Code"-Deppen platzen jetzt ihre Buildprozesse wegen mysteriöser "du machst zuviele Zugriffe"-Fehlermeldungen.
Wer also auf einen guten Moment für einen spontanen Ausbruch an Schadenfreude gewartet hat: Hier ist er! :-)
Update: Wir haben ein Bekennerschreiben von ... Cloudflare! MWAHAHAHA
Durch die Flachzangen willst du doch deine Bankdaten durchrouten!!1!
Auch in 2020 werden es Satiriker schwer haben mit der Realität mitzuhalten. Heute klingelte bei tausenden Kanadiern die Telefone:"This is a Province of Ontario emergency bulletin which applies to people within ten (10) kilometres of the Pickering Nuclear Generating Station. An
incident was reported at the Pickering Nuclear Generating Station. There has been NO abnormal release of radioactivity from the station and emergency staff are responding to the situation. People near the Pickering Nuclear Generating Station DO NOT need to take any protective actions at this time. Remain tuned to local media for further information and instructions."
Und die Punchline? Hier ist deren Atom-Infoseite."Ontario’s nuclear reactors are built with multiple safe guards."Wartet, das war noch nicht die Punchline. Die Seite zeigt nichts an, wenn Cloudflare nicht verfügbar ist.
Ja, DAS Cloudflare.
Das hat ein offensichtliches Problem: Cloudflare kann jetzt den entschlüsselten Traffic sehen, inklusive eure Kontostände und Überweisungen, wenn ihr euch da einloggt und Überweisungen tätigt.
Cloudflare hat in den letzten Jahren vor allem durch Inkompetenz und Ausfälle auf sich aufmerksam gemacht, und darauf, dass sie so verzweifelt "Kunden" brauchten, dass sie ihre Dienste verschenkt haben, um ihren Investoren mehr "Conversions" zeigen zu können. Gewinn haben die glaube ich noch nicht gemacht, das ist wie Uber eine Verbrennungsmaschine für Investorenkohle. In Expertenkreisen werden die gerne als Clownflare verspottet.
Außerdem ist das eine US-Firma. Und es ist bekannt, dass die US-Regierung sehr an Kontoinformationen ausländischer Bürger interessiert sind. Mit solchen illegal erlangten Daten haben sie gegen die Schweiz ein Exempel statuiert, wenn ihr euch erinnert.
Das ist alles ein perfekter Sturm. Wieso sitze ich also seit mehreren Tagen auf der Meldung?
Weil die Lage nicht so einfach ist. Meine Anforderungen an meine Bank sind völlig klar. Ich möchte, dass die höhere Security-Anforderungen haben, dass die ihren Scheiß nicht in der Cloud haben sondern selber hosten, dass das ein ordentliches Rechenzentrum mit ordentlichen Betreibern ist, und mit physischer Security, und dass meine Kontodaten da sicher liegen.
Das Problem bei dem Bild ist, dass Banken keine Hosting-Experten sind. Die können auch nicht mit Geld umgehen, daher werfen Banken üblicherweise mit hanebüchenen Geldsäcken auf das Problem, was aber meiner Beobachtung nach nicht dazu führt, dass die die beste Leistung kriegen, sondern dass sie die krassesten Blender und Abzocker als Dienstleister kriegen.
Dazu kommt, dass das Umfeld ein Morast aus Compliance-Scheiß und einer inkompetenten, freidrehenden Regulierungsbehörde ist, die (aus meiner Warte gesehen) an einem Stück völlig hilflos sinnlose Maßnahmen verhängt. Dazu kommt, dass es je nach Bank und Zusammenschluss (z.B. die Landesbanken oder die Sparkassen) nochmal separate Regularien gibt. Da blickt niemand mehr durch. Am Ende hat man da einen riesigen Apparat, der sich so Passierschein-A38-mäßig selbst mit Alzheimer-Prävention in Form von sinnloser Beschäftigung im Kreis beschäftigt.
Die Situation ist daher regelmäßig so, dass der Scheiß in der Cloud sogar besser implementiert und kompetenter administriert wird.
Wer also wie ich Wert darauf legt, dass seine Bank den Scheiß nicht in die Cloud geschoben hat, der wird wahrscheinlich nicht eine superkompetente Bank kriegen, die ihren Kram im Griff hat, sondern einen Moloch aus Abhängigkeiten, der eigentlich schon vor fünf Jahren in die Cloud gesollt hätte, aber sie haben es nicht geschafft.
Ich verallgemeine hier natürlich schamlos.
Aber eine Frage könnt ihr euch ja mal direkt stellen: Wieso hat die Regulierungsbehörde der DKB nach der Cloudflare-Nummer nicht direkt die Lizenz entzogen? Das kann doch nur heißen, dass sie entweder nichts taugt, weil sie zu lahmarschig ist, oder sie taugt nichts, weil sowas nicht verhindert. Das heißt aber im Umkehrschluss, dass deren Regulierung sicher auch nicht dazu geführt haben wird, dass bei den anderen Banken die Rechenzentren ordentlich betrieben werden.
Denkt mal drüber nach.
Ich weiß aus gut informierter Quelle, dass die Bafin (die Regulierungsbehörde) keine grundsätzlichen Einwände gegen Cloud-Migrationen hat. Also nicht nur Cloudflare vorschalten sondern richtig komplett in die Cloud ziehen. Wozu haben wir eigentlich eine Regulierungsbehörde, wenn die das nicht verhindert?
Anders herum gefragt: Was ist eigentlich der fundamentale Unterschied zwischen Cloud und "eigenem RZ"? Das ist im Allgemeinen nämlich kein eigenes RZ sondern das betreibt irgendein Zulieferer. Ist das nicht dasselbe in grün?
Ja aber Fefe, die sitzen doch in Deutschland und unterliegen unseren strengen Gesetzen und Regulierungen!!1! Ja das haben wir ja gerade live gesehen, wie hilfreich unsere strengen Gesetze und Regulierungen sind. Keine weiteren Fragen.
Ich habe mich über die Jahre mit vielen Kunden über die Cloud unterhalten, und da die hanebüchsten Geschichten gehört. Die Ausrede ist immer dieselbe. Schlimmer als was wir jetzt haben kann das auch nicht sein. Ein Kunde formulierte das mal so: Amazon antwortet wenigstens auf unsere Trouble Tickets.
Insofern, kurz gesagt: Das Gedankenmodell, das euch dazu bringt, die Cloudflare-Nummer negativ zu bewerten, fußt auf völlig falschen Annahmen über die Industrie. Ihr habt zwar völlig recht, dass das Scheiße ist, aber ihr habt ja gar keine Vorstellung davon, wie Scheiße der Normalzustand in der Branche ist. Dabei ist gerade erst live und in Farbe die PSD2-Apokalypse an euch vorbeigescrollt. Aber irgendwie nimmt das niemand als Anlass, mal sein Gedankenmodell zur Bankeninfrastruktur zu überdenken.
Cloudflare, wir erinnern uns, sind bekannt für so Glanzleistungen wie:
Ich persönlich würde Cloudflare nicht auch nur in die Nähe meiner Produktion lassen, selbst wenn sie mich dafür bezahlen würden.
Aber gucken wir doch mal, was der Vorschlag ist. Hier ist der erste Satz:
If your organization uses SSH public keys, it’s entirely possible you have already mislaid one.Da kannste direkt zu lesen aufhören. Der heißt ja nicht zufällig public, der key. Der ist public. Den zu verlegen ist genau so wenig ein Sicherheitsproblem wie das Telefonbuch zu verlegen. Schon die Prämisse ist absurd.
There is a file sitting in a backup or on a former employee’s computer which grants the holder access to your infrastructure.Äh, ... nein. Den public key zu haben gibt einem Angreifer genau gar nichts. Der private key dazu ist der, der einem Zugriff gibt. Und der liegt ja gerade nicht auf irgendwelchen Kisten rum sondern auf dem Arbeitsplatzrechner des Inhabers, oder, wenn der so futuristisch drauf ist, auf einer Smartcard von dem.If you share SSH keys between employees it’s likely only a few keys are enough to give an attacker access to your entire system.Wow. Ich hielt ja nicht viel von deren Krypto-Expertise, aber wenn die bei Cloudflare mehreren Mitarbeitern Zugriff auf denselben SSH-Schlüssel geben, dann ist das kein Fall für Auslachen mehr, das ist ein Fall für den Abdecker.Aber was schlagen sie denn vor?
Replacing a private network with Cloudflare AccessNEEEEIIIIIINNNNNN!!!!!!Wer kommt denn auf solche Ideen? Wer zieht denn bitte eine Firma, die für ihre Ausfälle bekannt ist, in die Authentisierung seiner Dienste rein? Damit nächstes Mal auch deine Firma komplett stillsteht?! So blöde kann doch keiner sein, würde man hoffen!
Jedenfalls keiner meine Leser.
Würde man hoffen.
Aber lest euch mal den Incident Report zu ihrem letzten Ausfall durch. Der, der von der Regex ausgelöst wurde. Achtet mal darauf, dass sie sich auf ihren eigenen Systemen nicht mehr einloggen konnten. Das wird bei euch dann auch so sein. (Danke, Lukas)
Cloudflare hat auch nicht so genau hingeguckt, ist ihnen jetzt aufgefallen. Rechtzeitig aufgefallen, hoffen sie, um vor dem Richter mildernde Umstände geltend zu machen.
Richter? Ja, denn wir reden hier von Terroristen und Ländern mit Wirtschaftssanktionen.
Aber selbst damit machen sie noch Achtstellig Verlust pro Quartal. Hey, da will man doch Aktionär werden! Of course we lose money but we will make it up in volume!
Daraufhin gab es Widerspruch bei Golem und jetzt rudert auch Heise zurück. Dabei spielt das doch mal sowas von überhaupt gar keine Rolle, wie irgendwelche Malware-Samples nach Hause telefonieren. Wenn eie Malware nach Hause telefoniert, ist das Kind schon im Brunnen und ist schon blau angelaufen.
Das Problem bei DNS-over-HTTPS ist auch nicht, dass man damit verschlüsselt kommunizieren kann, sondern dass ... ich hatte das hier schonmal ausgeführt ... die Komplexität mehrere Größenordnungen höher ist, ohne dass es tatsächlich einen echten Privacy-Mehrwert bringt. Außer in einem Szenario. Bei einem WLAN, das man sich mit Fremden teilt.
Mein Hauptproblem mit DNS-over-HTTPS war aber, dass das den gesamten Traffic über Cloudflare lenken wollte. Nun halte ich Cloudflare für einen Haufen inkompetente Clowns, aber selbst wenn sie wüssten, was sie täten, was wie gesagt jedenfalls aus meiner Warte nicht der Fall zu sein scheint, selbst dann wäre es eine schlechte Idee, allen DNS-Traffic aller Mozilla-Kunden über Cloudflare zu tunneln. Das macht dann nämlich das Abgreifen der DNS-Daten noch einfacher für die Geheimdienste. Die müssen nur bei Cloudflare den Schnorchel ansetzen. Gerade für US-Geheimdienste, in deren Jurisdiktion Cloudflare liegt, wäre dafür nicht mal Hacking-Aufwand vonnöten.
Also, nochmal zum Mitmeißeln. DOH ist schlecht, weil es so furchtbar komplex ist, nicht weil Malware darüber reden könnte. DOH zu Cloudflare ist schlecht, weil Cloudflare alle Nase lang irgendwelche katastrophalen Ausfälle hat, und weil zentralisiertes DNS-Routing für die Dienste das Abschnorcheln zu einfach macht. Und hört endlich auf, Malware zu analysieren, was sie nach der Infektion macht. Nach der Infektion ist es zu spät. Findet lieber raus, wie die Malware auf das System kommen kann, und macht das zu.
Nun, … gut dass ich dagegen war.
Erstens kamen Mozilla-Mitarbeiter/Helfer und schrieben mir (ich paraphrasiere) "Ihr Anruf ist uns sehr wichtig. Wir nehmen alle Beschwerden ernst." und einer kam mit so PR-Technobabble ala "we leveraged synergies to improve benefits". Das empfinde ich symptomatisch für das Problem, in dem wir uns befinden. Mozilla hat vergessen, wer ihre Software einsetzt, und warum. Dass sie überhaupt angefangen haben, mir irgendwelche Anmelde-Scheiße wie Pocket und Sync penetrant reindrücken zu wollen, zeigt das mehr als deutlich.
Zweitens kamen so Digital-Prepper mit "also ich benutze ja deshalb (obskurer Firefox-Fork von vor 8 Jahren). Der kann zwar kein Javascript, und dumpt bei 40% der Webseiten core, aber dafür kann ich dem noch vertrauen!1!! Ruf mal bitte dazu auf, dass Entwickler dem Projekt helfen sollen!!1!".
Drittens kamen so "der Fefe hat keine Ahnung, was für ein Idiot"-Meldungen. Die kommen häufig nicht ZU mir sondern ÜBER mich auf Twitter, wenn sich die Leute gegenseitig im Kreis ihre eigene Großartigkeit und die Idiotie aller anderen bestätigen. Dass Leute immer noch für sowas Zeit haben...
Einer fragte mich, ob es vielleicht in China ein Browser-Projekt gäbe. Weil den Browsern aus dem Westen kann man ja nicht mehr trauen.
Ich finde es schockierend, wie die Browserhersteller aus dem Westen ihre eigene Userbasis solange mit Füßen getreten haben, bis ihnen niemand mehr traut, und Leute nur noch aus Lockin-Gründen bei ihrem Browser bleiben. Weil es zu nervig wäre, die Bookmarks und Extensions woanders hin zu migrieren.
Ich hatte mal gehofft, dass Open Source und Free Software dagegen immun sein könnte.
Damit das nicht ganz untechnisch ist hier: Mozillas eigentliches Problem war, dass sie Profil-Korruption hatten, wenn alte und neue Versionen von Firefox am selben Profil herumgearbeitet haben. Das ist ein bekanntes und zigfach gelöstes Problem. X.509-Zertifikate, TLS, SMB, HTTP, wo man hinguckt, überall gibt es Protokolle, die nachträglich erweitert wurden. Klar ist das nicht immer schön. Aber Code so zu machen, dass alte Versionen neue Felder, die sie nicht kennen, ignorieren und im Profil beibehalten beim Speichern, das ist echt keine Raketentechnologie. Hier hat Mozilla technisch auf ganzer Linie verkackt. Und ihre Lösung war nicht, das zu reparieren, sondern mir lieber mein Profil wegzunehmen in der neuen Version (Bookmarks, Extensions, Ublock-Regeln, alles) und mir Sync reinzudrücken zu versuchen. Das ist nicht zu verteidigen. Seit Jahren hat der Browser immer und immer wieder solche versifften Ecken, aber Firefox investiert ihre Millionen lieber woanders. Bei Pocket und Sync.
Oh apropos Sync. Sync gab es ja mal in kryptografisch ordentlich. So dass man a) dem Server nicht trauen musste und b) einen eigenen Server betreiben konnte. Angeblich kann man heute immer noch einen eigenen Server betreiben. Das wurde mir auch ein paar Mal empfohlen. Ich will aber keine weiteren Services betreiben müssen. Jeder Service ist ein Risiko. Schonmal doppelt, wenn das irgendein stinkender Python-Rotz von Mozilla ist. Was die immer alle mit ihrem Python haben! Das war ja schon bei Letsencrypt fast ein Todesurteil, dieser stinkende Python-Rotz, den sie allen Benutzern überhelfen wollten.
Besonders geil finde ich immer, wenn Mozilla dann erzählt, für sowas gäbe es halt keine Entwickler gerade. Ihr habt ein Millionenbudget! Ihr könnt Leute dafür bezahlten, Dinge zu tun, die sie freiwillig nicht tun würden! Stattdessen fließt die Kohle dann zu Hipster-Scheiße wie Pocket und Sync. Zum Mäusemelken.
Oh, das UI um meinen eigenen Server zu benennen, habe ich auch nicht gesehen. Firefox zeigt mir hier jedenfalls nur eine Login-Maske, bei deren Benutzung ich ihrer "Datenschutzerklärung" zugestimmt haben muss. Ja nee, klar. Erzählen mir was von Privatsphäre und wollen dann meinen DNS-Bewegungsdaten bei Cloudflare hochladen und mich über Sync-Login tracken können. Wird nicht passieren, Mozilla.
Ihr lautester Angriff bisher war dieses Projekt mit Mozilla, dass Firefox seine DNS-Anfragen über ein neues Protokoll (über HTTPS!!1!) an Cloudflare durchtunnelt, damit sie schön alle Bewegungsdaten des Internets bei sich in der Datenbank haben. Daten sind das Erdöl des 21. Jahrhunderts!
Dann erinnere ich mich da noch an "hört mal alle auf, ANY-Anfragen zu beantworten, weil wir können das auch nicht". Ganz großes Kino.
Warum hole ich das alles aus der Mottenkiste? Weil es bei Cloudflare vor ein paar Wochen einen lustigen DNS-Ausfall gab.
WENN es jemanden gibt, dem ich in Sachen DNS weniger zuhören würde als Axel Voss, dann ist es Cloudflare.
A major international bank accidentally published a private package of their own to the public npm Registry, took *3 years* to notice, and then sent DMCA takedown notices to Amazon and Cloudflare for hosting "stolen code".Einmal mit Profis arbeiten!
Aber so wird die US-Regierung das nicht sehen, ist anzunehmen. Könnte uns ja eigentlich völlig egal sein, aaaaaaber Cloudflare waren auch die, denen Mozilla den DNS-Traffic ihrer User schenken wollte. Und da wird es dann doch interessant für Verschwörungstheoretiker.
Das Ausformulieren überlasse ich mal Bert Hubert, der PowerDNS gegründet hat. Das ist kein direkter Konkurrent von Cloudflare. Der hatte sich auch schon ausführlich über Mozilla-DNS-via-Cloudflare geäußert. Spoiler: Er ist kein Fan.
Update: Falls jemand Bert Hubert nicht kennt: Das ist ein verdienter Ingenieur, der neben DNS z.B. auch für die einzige brauchbare Einführung in iproute2, die ipsec-tools und Traffic Shaping bekannt ist. Der weiß, wovon er redet. Wenn sein Wort gegen das von Cloudflare steht, würde ich immer erstmal ihm glauben.
Heute ist so eine Gelegenheit, und zwar bei den herausragenden Bullshitsprenklern von Cloudflare, die schon seit Jahren immer wieder durch die Dichte ihrer Nebelbänke beeindrucken konnten. Hier ist die Phrase:
It allows you to write serverless code which runs in the fabric of the Internet itselfWow. Ernsthaft. Wenn euch das nicht beeindruckt, dann weiß ich auch nicht.
seitdem hier in Bayern der Polizeistaat im Vormarsch ist (seit Jahren schon), benutze ich fast ausschließlich ssh-tunnel mit socks v5 am Ende. Mache da auch DNS drüber. Du ahnst ja gar nicht wie viele Internetseiten Angst vor rootserver IP ranges haben. Du würdest an der schieren Menge von Captchas, die ich täglich zu Gesicht bekomme, regelrecht verzweifeln. Ganz zu schweigen von Seiten, die diese IP ranges komplett gesperrt haben. Den Cloudflare Verein würde ich am liebsten abfackeln. Das hat mitlerweile echt krankhafte Ausmaße angenommen.Und noch einer:
ich möchte noch darauf hinweisen dass Cloudfare (und auch andere CDNs) dem geneigten User ein Captcha präsentieren, sobald man mit Tor unterwegs ist.Cloudflare hat sich durch ihr Gebaren eine große Gemeinde an Anti-Fans eingetreten, die sie verachten, wo immer sie sich reintentakeln.
Update: Wobei hey, vielleicht machen wir das falsch. Vielleicht sollten wir das als Entertainment sehen. Free casual gaming! Alzheimer-Prävention!!
DNS hat zwei große Probleme. Erstens dass jeder auf dem Weg die Anfragen und Antworten sehen kann. Und zweitens dass man falsche Antworten auf anderer Leute Anfragen schicken kann.
Das erste Problem ist zwar doof, aber nicht verheerend. Das liegt daran, dass man für die DNS-Auflösung normalerweise den DNS-Server des Internet-Providers nimmt, und der kann eh sehen, mit welchen IP-Adressen du redest. Der gewinnt also nicht so viel, und mit dem hast du ein Vertragsverhältnis und das ist eine deutsche Firma und die unterliegt dem deutschen Datenschutz. Nicht ideal aber auch kein Beinbruch. Und wem das nicht reicht, der kann sich einen eigenen DNS-Resolver irgendwo hinstellen und selbst betreiben. Dann muss man aber ein VPN zu dem benutzen, sonst kann der ISP immer noch alles sehen.
Ja aber Fefe, der BND könnte doch Kabel Deutschland hacken und die DNS-Daten abschnorcheln! Ja, könnte er, aber er müsste dann alle ISPs hacken, um an alle DNS-Daten ranzukommen. Wenn ihr 1.1.1.1 oder 8.8.8.8 verwendet, dann muss die NSA nur diesen einen Anbieter hacken und hat alle DNS-Daten von allen Leuten auf der Welt. Macht das also nicht!
Das zweite Problem, dass jemand falsche Antworten unterschieben kann, wird vollständig von TLS gelöst.
Warum spreche ich das an? Weil Heise gerade Propaganda fährt, DNS sei so unsicher, und man möge doch JSON über HTTPS zum Auflösen von Namen nehmen. Dazu kann ich nur sagen: NEEEEIIIINNNNN! Der Feind von Sicherheit ist Komplexität. Einen DNS-Resover kann man in ein paar hundert Zeilen Code schreiben. Ich weiß das, weil ich es getan habe. Ein JSON-über-HTTPS-Client sind 5-6stellig viele Zeilen Code.
Und das noch größere Problem: Firefox hat das gerade in ihren Browser eingebaut. Und zwar so, dass die Anfragen über Cloudflare gehen. NEEEIIIINNNN!!!! Damit ist Cloudflare ganz oben auf der Liste der für die NSA interessanten Firmen, und da könnt ihr mal einen drauf lassen, dass die die DNS-Daten da abgreifen werden. Zur Not nicht per Hack sondern per National Security Letter.
Was also tun? Nun, Option 1: Das wegkonfigurieren bei Firefox. about:config, nach trr suchen, network.trr.mode auf 5 setzen.
Option 2: Eigenen DNS-over-HTTPS-Server betreiben. Kann man machen. Hier ist eine solche Software in Rust. Das Kosten-Nutzen-Verhältnis stimmt aber aus meiner Sicht nicht.
Hier ist ein aktueller Blogpost dazu.
Ich finde es höchst bedauerlich, wie Firefox mit solchen Geschichten weiter Krieg gegen ihre User führt. An die Werbe-Add-Ons und die extern gehostete Addons-Seite mit Google Analytics erinnert ihr euch ja sicher noch alle. Und an die tolle Idee, Werbung auf der New-Tab-Seite einzublenden? Mann Mann Mann, Firefox. Was denkt ihr euch bloß!
Update: Das betrifft im Moment nicht die Stable-Version. Offizieller Doku.
Update: Nachdem Golem und Heise hierauf linken, ist es vielleicht an der Zeit, Gegenforderungen aufzustellen. Meine Forderung ist ganz einfach: Weniger Komplexität. Komplexität ist der Feind. Die Anzahl der Bugs steigt mit der Codegröße. Die Leute stöpseln heute nur noch Komponenten aus Libraries zusammen. Das ist Schönwetter-Programmieren! Ein Programm, das nur beherrschbar ist, wenn es zufällig gerade gut funktioniert, ist wertlos. Wir brauchen Programme, die überschaubar wenig Dinge tun, und dafür vollständig beherrschbar sind. Am besten nicht nur vom Programmierer, sondern auch vom Benutzer. Die Geschwindigkeit, mit der wir uns mit unbeherrschten und unbeherrschbaren Technologien umzingeln, ist aus meiner Sicht ein Vorbote der Apokalypse.
Asimov beschreibt in seiner Foundation Serie eine Zukunft, in der die Menschheit selbst-reparierende Atomkraftwerke gebaut hat. Und als die fertig waren, starben die Leute aus, die die noch reparieren konnten, weil man sie nicht mehr brauchte. Nach vielen Jahren war die Selbstreparatur dann am Ende und es gab niemanden mehr, der die warten konnte.
So ungefähr machen wir das auch gerade. Nur dass wir den Schritt mit dem Selbstreparieren überspringen. Wir bauen direkt Dinge, die niemand mehr reparieren kann. Schlimm genug, wenn die Hardware heute so ist, aber das heißt doch nicht, dass die Software auch so sein muss?!
Mich macht besonders fertig, dass wir jetzt mit "KI" soweit sind, dass wir unwartbare Software absichtlich herbeiführen. Wie in einem Scifi-Film, wo die Aliens erst Hirnfresser-Parasiten schicken, damit die Zielrasse sich selbst kaputtmacht, und man für die Machtübernahme nicht mehr so viel Ressourcen aufwenden muss.
Zudem arbeiten wir künftig mit Cloudflare zusammen, um eine Web Application Firewall (WAF) auf unserer Webseite und im Kundenmenü einzusetzen. Diese dient als Filter zwischen unseren Servern und potenziell bösartigem Datenverkehr aus dem Internet. Sie schützt vor betrügerischen Aktivitäten wie SQL-Injections und Cross-Site-Scripting und wird in den nächsten Tagen aktiv.Ich bin kein Kunde von denen und kann daher nicht beurteilen, dass das wirklich so von Domainfactory geschrieben wurde.
Aber erstens: Das ist wie "wir haben einen Virenscanner installiert und sind jetzt sicher". Bullshit.
Zweitens: Der Traffic zwischen dem Kunden und der Firma geht jetzt über eine Drittfirma mit Sitz im Ausland. Das fände ich als Kunde unakzeptabel. Ich finde es auch unakzeptabel, wenn Firmen ihre Mail über Drittserver von Anbietern im Ausland machen. Möglicherweise vertrete ich da eine Mindermeinung.
Drittens: Wenn jemand seine Sicherheitsprobleme nicht durch "wir machen die Software sicherer" sondern durch "wir schalten Schlangenöl davor" löst, dann liegt die Vermutung nahe, dass die Kompetenz fehlte, das Kernproblem zu lösen. Meiner Meinung nach ist das eine Bankrotterklärung. Wieso habt ihr die Software dann überhaupt eingesetzt, wenn ihr die nicht absichern könnt?!
Nun ist der Betrieb sicherer Systeme für einen Hostinganbieter Teil der Kernkompetenz. Wenn die also an der Stelle schon eine solche Bankrotterklärung verkünden, würde das mein Vertrauen in den Rest ihrer Kernkompetenzen deutlich schmälern.
Zu Cloudflare im Speziellen: Ich bin bisher nicht beeindruckt von denen. Die fallen vor allem durch Marketing-Getöse auf. Und durch Fehlermeldungen und Captchas vor irgendwelchen Webseiten, die sie angeblich "beschützen". Und diese "Fehlermeldungen" sind vor allem Cloudflare-Eigenwerbung. Ich hatte glaube ich sogar schon mal eine Cloudflare-Fehlermeldung als Aprilscherz. :)
Update: Über ein Dutzend Leser haben bestätigt, auch eine Mail mit diesem Textblock von Domainfactory gekriegt zu haben. Einer schrieb, er habe anlässlich der Sicherheitslücke letztens eine fristlose Kündigung ausgesprochen und sei damit (für ihn überraschend) anstandslos durchgekommen.
Ich habe ja vor inzwischen vielen Jahren eine Abstraktionsschicht über diverse Netzwerk-Event-APIs der verschiedenen Plattformen geschrieben, und darauf meinen Webserver gatling aufgebaut. Seit dem hat sich im Internet einiges verschoben. Web ohne TLS spricht niemand mehr, also habe ich TLS nachgerüstet. Für Web mit TLS ist aber das Skalierungsproblem ein ganz anderes. Da geht es nicht mehr darum, dass jemand viele Verbindungen aufbaut und dein Server damit nicht klarkommt, sondern es geht darum, dass jemand viele TLS-Handshakes lostritt und dein Server die ganze Zeit mit 100% CPU läuft.
Seit dem hat sich auch eine andere Sache verändert: CPUs mit nur einem Core gibt es nicht mehr. Es liegt also auf der Hand, dass ich mal das Modell von gatling und der Abstraktionsschicht ändern sollte, damit es sich auf mehrere Cores verteilen lässt. Das ist leider kein Selbstläufer, weil die unterliegenden APIs teilweise nervige Probleme haben. So gibt es einmal die fundamentale Frage, ob man edge triggered oder level triggered arbeiten soll. Level Triggering ist, was poll macht. Wenn du nach Deskriptor 3 fragst, und 3 ist lesbar, und du tust nichts mit ihm sondern rufst wieder poll auf und fragst nach Deskriptor 3, dann sagt dir poll wieder, dass er lesbar ist. epoll und kqueue arbeiten genau so, lassen sich aber umschalten. Edge Triggering heißt, dass das API dir nur einmal Bescheid sagt, dass ein Deskriptor lesbar ist. So funktioniert der Vorläufer von epoll, SIGIO, den meine Abstraktion unterstützt. Das verkompliziert aber das Programmiermodell massiv, weil ich jetzt darüber Buch führen muss, welche Deskriptoren lesbar sind und welche nicht. Dafür hat es aber den großen Vorteil, dass multithreading sozusagen von alleine geht.
Nehmen wir mal an, du hast vier Threads, und alle rufen epoll auf. Deskriptor 3 wird lesbar. Dann kommen alle Threads zurück und melden das. Das ist natürlich Unsinn, weil nur einer zum Zuge kommt und die anderen sinnlos Strom verbraucht haben.
Daher macht man das entweder so, dass nur ein Thread epoll aufruft und eine Datenstruktur befüllt, die dann von Worker Threads abgearbeitet wird. Oder man macht es so, dass jeder Thread einen eigenen Pool aus disjunkten Verbindungen verwaltet und die jeweils mit einem eigenen epoll bearbeitet. Die bessere Skalierbarkeit hat auf jeden Fall Variante 2, aber dann sollte man keine Threads sondern Prozesse nehmen.
gatling hat Fälle, z.B. CGI oder Proxy-Modus, bei denen mehr als ein Deskriptor zu einer Verbindung gehört. Das naive aufteilen der Deskriptoren auf Pools funktioniert also nicht, denn zusammengehörende Verbindungen müssen auch im selben Pool sein. Oder man baut ein API, um nachträglich Deskriptoren hin- und herzuschieben. Das wäre auch die bessere Lastverteilung gut, aber zieht einen Rattenschwanz an Komplexität nach sich. Ist daher aus meiner Sicht gerade erstmal unattraktiv.
Ich habe mich daher entschieden, lieber jeweils nur einen Thread zu haben, der epoll macht (oder halt kqueue, whatever), und der befüllt eine Datenstruktur, und aus der bedienen sich dann die Worker-Threads. Die Threads handeln das on the fly untereinander aus, wer gerade für Event-Abholen zuständig ist, und wer auf die Datenstruktur wartet. Damit das API nach außen einfach bleibt.
Das sieht ganz gut aus und scheint auch schön zu flutschen und vor allem ist das API viel einfacher als was ich vorher hatte. Aber ich kam ins Grübeln. Wenn ich hier schon einen neuen Webserver mache, dann soll der aber auch nicht nur TLS machen, sondern TLS mit Privilege Separation. Wenn jemandem ein Angriff auf den Webserver gelingt, möchte ich gerne möglichst minimieren, was er damit anstellen kann. In erster Näherung stelle ich mir vor, dass der Private Key von dem Server in einem separaten Prozess liegt (und ich per seccomp-filter o.ä. verhindere, dass man da ptrace o.ä. machen kann). Aber je mehr ich darüber nachdenke, desto weniger gangbar sieht das aus. Das erste Problem ist, und dafür kann TLS jetzt nichts, wenn ich den Handshake-Teil in einen Prozess tue und nur die Session Keys in den anderen Teil rüberreiche, dann hat ein Angreifer immer noch alle Session Keys im Zugriff. Das ist immer noch ziemlich schlimm. Gut, dank Forward Secrecy ist es kein Super-GAU, aber gut wäre es nicht.
Ein möglicher Ausweg wäre, dass man das gesamte TLS auslagert, und sozusagen durch einen TLS-Proxy-Prozess kommuniziert. Das riecht erstmal nach einem prohibitiv teuren Performance-Nachteil. Und gewonnen hätte man damit auch nicht viel, denn ein Angreifer könnte trotzdem allen Verkehr aller anderen Leute sehen und ihnen Müll senden, um sie anzugreifen, er könnte bloß nicht den schon gelaufenen Teil der Verbindung entschlüsseln. Ich glaube, das wäre die Kosten nicht wert.
Aber was, wenn man das TLS in den Kernel schieben kann. Linux hat seit kurzem ein API für Kernel-TLS. Da gibt man dem Kernel per setsockopt den Schlüssel und dann kann man auf dem Socket ganz normal Daten rausschreiben. Das klingt sehr attraktiv, denn den setsockopt könnte der TLS-Handshake-Prozess machen und dann den Socket rüberreichen zu dem Web-Prozess. Nachteil: Der Kernel-Support ist rudimentär und kann nur Daten rausschreiben. Kann nicht lesen, und kann keine Kontrollnachrichten schicken. Das muss man über ein krudes Spezial-API machen. Das müsste man dann zurück an den TLS-Handshake-Prozess delegieren. Gut, wäre denkbar. Schlimmer noch: Lesen kann der Kernel-TLS auch nicht. Das ist schon eher hinderlich.
OK, nehmen wir an, ich habe meinen Webserver aufgeteilt. Ein Prozess macht HTTP, einer macht TLS-Handshake. TLS hat aus Performance-Gründen ein Feature namens Session Resumption. Der Server behält die Krypto-Parameter für Verbindungen eine Weile vorrätig, und gibt dem Client ein Cookie. Wenn derselbe Client wieder kommt, kann er einfach den Cookie vorzeigen, und der Server findet dann die Krypto-Parameter und benutzt die weiter. Spart eine Menge teure Public-Key-Krypto und ist super für die Performance. Aber auf der anderen Seite heißt das eben, dass ein Angriff auf den Server auch diese ganzen gespeicherten Krypto-Kontexte im Speicher finden kann, und mit ihnen mitgesniffte Daten anderer Leute entschlüsseln kann. Das ist mal richtig doll Scheiße. Die Frage ist, ob sich Privilege Separation überhaupt lohnt, wenn man dieses Problem mit sich rumschleppt?
Und da denke ich mir gerade: Hey, was, wenn man die Tickets (so heißen die Cookies bei TLS) und die Krypto-Kontexte in einen dritten separaten Prozess packt. Grundsätzlich könnte das sogar sowas wie ein Redis auf einem anderen Server sein, dann könnten alle Frontends in einem Loadbalancer untereinander Session Resumption machen. Cloudflare hat vor ner Weile mal einen Hack in die Richtung angekündigt. Die Sicherheit von den Tokens basiert darauf, dass sie lang und zufällig und damit nicht vorhersagbar oder ratbar sind. Da müsste man gucken, wie man verhindert, dass ein Angreifer den Redis-Traffic mitsnifft, sonst hat man nichts gewonnen.
Naja und fundamental gibt es natürlich auch noch das Problem, dass die ganzen TLS-Libraries da draußen gar nicht vorsehen, dass man in ihren Interna herumpfuscht, und sowas macht wie nach einem Handshake die Krypto-Keys extrahieren und in einen anderen Prozess schieben, oder auf der anderen Seite einen bestehenden Krypto-Kontext entgegennehmen, aber ohne Public-Key-Teil des Kontexts, und dann damit symmetrisch Krypto zu machen.
Die nächste Frage ist natürlich auch, was eigentlich mehr CPU frisst, die Handshakes oder der symmetrische Teil. Das wird vermutlich von der Traffic-Load auf dem Server abhängen, ob der Videostreaming macht oder sowas wie mein Blog, was aus lauter kleinen kurzen Verbindungs-Bursts besteht.
Was ich sagen will: Ist alles nicht so einfach, und es ist auch nicht klar, ob sich der ganze Aufwand am Ende lohnen würde. Sollte aber glaube ich trotzdem mal jemand machen.
Update: Und es stellt sich natürlich die Frage, wen man hier eigentlich vor wem beschützen möchte. Muss man nicht eher befürchten, dass jemand den TLS-Stack hackt, als dass jemand den Webserver hackt?
Update: Vielleicht muss man sich aus Sicherheitsgesichtspunkten einfach generell von der Idee verabschieden, in einem Serverprozess mehrere Verbindungen zu multiplexen. Vielleicht sollte ich mal ein Extremkonzept implementieren, um zu gucken, wie schlimm das performt. Einfach damit man mal einen Datenpunkt hat. So pro Verbindung einen httpd-Prozess und einen TLS-Privilege-Separation-Prozess. Aber nicht abforken sondern schön fork+exec, damit die alle eigenes ASLR kriegen. Rein intuitiv kann das nicht gut performen, aber auf der anderen Seite gehen Rechnerarchitekturen ja gerade hin zu 256-Core-ARM-Servern. So würde man die ganzen Cores immerhin sinnvoll nutzen.
New hotness: 1.1.1.1
Von der Performance her nehmen die sich nicht viel, beide antworten viel schneller als übliche DNS-Resolver von Internet-Providern.
Aber lasst euch mal nicht von dem "privacy-first"-Blablah täuschen. Das ist eine Behauptung, ein Versprechen. Google verspricht Ähnliches für 8.8.8.8.
Der DNS-Server kann alles sehen, was ihr an Anfragen ins Netz stellt, und sieht damit, was man seit Snowden bei Telefonen "die Metadaten" nennt. Wer seine DNS-Daten ohne Not in fremde Hand gibt, gibt damit seine Privatsphäre weitgehend auf.
Ich rate also entschieden davon ab, irgendeinen (gar zu einer ausländischen Organisation gehörende) DNS-Server zu verwenden — schon gar nicht aus Five-Eyes-Staaten.
OK, was sind die Alternativen? Den ISP-DNS benutzen. Das hat den Nachteil, dass die oft langsam sind, gerne mal ausfallen, und dass man möglicherweise auch nicht will, dass die Daten beim ISP anfallen. Letzteres kann man nur mit einem VPN verhindern (wobei dann der VPN-Endpunkt alle Daten sieht und zuordnen kann; auch nicht besser!) oder einem Anonymisierungsdienst wie Tor verhindern.
Ich persönlich betreibe einen eigenen Resolver in meinem Netz.
Man muss sich aber im Klaren sein, dass auch am Anfang einer TLS-Verbindung noch der Name der Site im Klartext dransteht, d.h. auch ohne DNS kann jemand, der den Traffic sieht, sehen, mit welchem Host du zu reden versuchst, selbst wenn hinter der IP ganz viele Sites hängen. Besserung war glaube ich für TLS 1.3 geplant, hier ist ein aktueller Draft dazu, aber scheint es nicht in den Standard geschafft zu haben…? Und das hat auch andere Probleme, wenn man das zumacht. Im Moment kann man einen Load Balancer bauen, der den TLS durchreicht, und der das richtige Backend am SNI erkennt (wo der gewünschte Servername steht), und dann wird der TLS im Backend terminiert. Das ist viel besser als wenn man den TLS im Load-Balancer terminiert und dann zum Backend unverschlüsselt kommuniziert. Ein Angreifer, der den Load Balancer übernimmt, kann dann alle Anfragen sehen.
Wenn man das beibehalten will, muss man sich ziemlich verbiegen. Ihr könnt ja selber man kurz in den Draft gucken.
Also, kurz gefasst: Seine DNS-Anfragen über irgendeine amerikanische Cloud-Klitsche routen, ist eine sehr schlechte Idee für eure Privatsphäre. Aber es selber zu machen hilft leider auch nicht so viel, wie man hoffen würde.
Ich finde bei sowas immer, dass man NSA und co ja nicht noch freiwillig entgegenkommen muss. Oh und richtig geil wäre das erst, wenn DNS verschlüsselt wäre. Es gibt da was mit TLS für DNS, aber das ist hochkomplex, eine riesige Angriffsoberfläche und erhöht die Netzwerklatenz deutlich. Cloudflare bietet das an. Aber das würde halt nur den Weg von euch zu Cloudflare schützen. Bei Cloudflare könnte die NSA immer noch alles abgreifen.
Update: Leser berichten, dass einzelne ISPs gar keinen DNS-Resolver mehr betreiben sondern ihren Kundern per DHCP 8.8.8.8 setzen. Das ist aus meiner Sicht ein starker Anreiz, sich schnell einen anderen ISP zu suchen.
Währenddessen haben Facebook, Reddit und Paypal (!!) angesagt, dass sie die Nazis rausschmeißen wollen. Gerade Paypal finde ich an der Stelle bemerkenswert. Wenn die ihr Schikane-Arsenal, das sie bisher nur gegen angebliche Raubkopierer und Pornographen einsetzen, gegen die Nazis in Stellung bringen, dann werden die nicht viel zu lachen haben. Das schießt dann vermutlich auch deren Spenden-Infrastruktur weg, wenn nicht demnächst auch die Kreditkartenfirmen folgen. Mal gucken, wie sich das entwickelt.
Update: Auch der russische Hoster hat die anscheinend runtergeschmissen.
Merken die nicht, dass sie ihren Erfolg wegpissen? Man betreibt doch so eine Site gerade, damit man mal einen Erfolg hat und viele Leute kommen!
Ich verstehe es nicht.
Gut, und es kann natürlich nur Gewinner geben, wenn sich sich Cloudflare mit Anwälten kloppt.
Hier sind die Details. "Cloudbleed" :-)
Die Forscher untersuchten rund 8 Milliarden TLS-Verbindungen zum Firefox-Update-Dienst, einigen E-Commerce-Sites und bei Cloudflare. Dabei stellten sie fest, dass bis zu 10 Prozent der gesicherten Verbindungen nicht mehr die typischen Verbindungsparameter des verwendeten Browsers aufwiesen – sie also irgendwo unterwegs unterbrochen wurden.10 Prozent finde ich ausgesprochen krass.
Konkret bedeutet das etwa: 13 von 29 untersuchten Antiviren-Programmen klinken sich in die verschlüsselten TLS-Verbindungen ein.Naja, TLS ist TLS, denkt ihr euch jetzt vielleicht. Ihr irrt. TLS handelt beim Handshake am Anfang aus, welche Verfahren verwendet werden, und wenn da ein Schlangenöl zwischen sitzt, das nur alte Gammelverfahren spricht, dann sinkt eben die Sicherheit der Gesamtverbindung dadurch. Wie schlimm ist es?
So erlaubten gemäß der Studie Produkte von Avast, Bitdefender, Bullguard, Dr.Web, Eset, G Data und Kaspersky direkte Angriffe auf die gesicherten Verbindungen. Bei den getesteten Security-Appliances für die Inspektion von TLS-Verbindungen sieht es nicht besser aus: 11 von 12 schwächten die Sicherheit etwa durch die Hinzunahme von kaputten Verfahren wie RC4.Ja prima!
Das Fazit ist:
"Viele der Verwundbarkeiten in Antiviren-Produkten und Proxies in Fimrenumgebungen [….] sind fahrlässig und ein weiteres Zeichen für den Trend, dass ausgerechnet Sicherheitsprodukte die Sicherheit verschlechtern statt sie zu verbessern" heißt es im Fazit.Ich weiß, ich weiß! Hätte uns doch nur jemand rechtzeitig gewarnt!!1!
Im Übrigen hatte ich gestern mal auf dem Smartphone bei heise.de geklickt, und da kam ein fettes Javascript-Popup, das man wegklicken musste. Wer das macht, für den schalte ich auch nicht meinen Adblocker ab. Das war der Deal, Heise. Eine Werbung für irgendeinen Hollywood-Film.
Update: So, wieder zuhause. Dann gucken wir doch mal, von wo die Süddeutsche überall Tracking-Scheiß nachlädt (falls den Punkt jemand nicht versteht: ALLES, was von IRGENDWO anders nachgeladen wird, ist per Definition Tracking-Scheiß. Wenn eure Webseite nicht ohne Nachladen von irgendwelcher JS-Framework-Gülle von sonstwo geht, dann ist sie Scheiße):
Hält das ernsthaft irgendwer für diskutabel, unter solchem Umständen das Abschalten des Adblockers zu verlangen? Ich nicht.
Update: Jetzt kommen hier lauter Umgehungstipps rein. Leute, das war nicht der Punkt. Ich will das auch nicht umgehen. Es geht nicht um mich sondern darum, ob ich das verlinken kann. Und auf Sites, die meine Leser beim Klicken ärgern, linke ich halt nicht.
Meine einzige Ausrede ist, dass ich diesmal erst am Vorabend ein paar Minuten Zeit hatte für die Vorbereitung. Ich wollte eigentlich auch einen node.js-Fehler nehmen, aber ein kurzes Recherchieren hat ergeben, dass node.js bei sowas abraucht / gar nicht erst hochkommt und keine Fehlermeldung per http ausliefert. Da hätte ich mir jetzt eine aus den Fingern saugen können, aber ich dachte mir dann, dass ich dann lieber eine Cloudflare-Fehlerseite nehme, da ist wenigstens ein bisschen Cloud-Ironie dabei. Leider hat offenbar niemand eine solche Fehlermeldung irgendwo archiviert. Ich fand bloß einen Screenshot.
Schade, da wäre mehr drin gewesen. Aber es sind immer noch genügend viele drauf reingefallen, dass ich es unter dem Strich als Erfolg verbuche.
Übrigens wäre schon das hier für mich ein Ausschlusskriterium für Cloudflare.
Die aktuelle Inkarnation war, dass die nervigen Selbstvermarkter von Cloudflare sich hingestellt haben, und behauptet haben, also in IHREM Setup käme man per Heartbleed aber nicht an die SSL-Zertifikate ran, daher müssten sie jetzt auch nicht alle zurückrufen und neumachen. Als Beweis haben sie eine Teststellung hingestellt, und das Internet herausgefordert, ihnen eine mit ihrem Schlüssel signierte Botschaft zu schicken. Hier ist ihre Challenge-Webseite.
Und siehe da: jemand hat den Key extrahiert.
Erstens: Wenn die beiden sich streiten, kann es nur Gewinner geben. Beide Parteien sind Unsympathen erster Güte.
Zweitens: Der "größte DDoS aller Zeiten", der "die Fundamente des Internet destabilisiert" ist reines Marketing-Geblubber von Cloudflare, dem DDoS-Abwehr-Dienstleister von Spamhaus. Die wollen ihre Dienste verkloppen. Nicht mehr, nicht weniger. Fallt auf diesen Scheiß bitte nicht rein.
Drittens: Dass das mit den DNS-Resolvern ein Problem ist, ist eine alte Geschichte. Das hat schon Dan Bernstein auf dem 27c3 anschaulich dargestellt, und wer sich dafür interessierte, konnte das schon seit 30 Jahren wissen.