Fragen? Antworten! Siehe auch: Alternativlos
Denn was in der Theorie brillant funktioniert, scheitert in der Realität kläglich. Ilja Radusch von der TU Berlin zieht eine ernüchternde Zwischenbilanz und sagt: "Wir haben die Komplexität unterschätzt."Nein. Habt ihr nicht. Ihr habt einen Weg gesehen, quasi endlose Forschungsgelder abzugreifen, wenn ihr nur ein paar von Kompetenz ungetrübten selbstbesoffenen Zukunftsvisionen von Industrie und Politik nicht widersprecht. Was man da alles für Papers schreiben könnte! Und jemand anderes zahlt die Zeche!!1!
Gut, ich habe jetzt kein großes Mitleid mit den Autokonzernen, die da Milliarden verplempert haben.
Aber die Forscher? Die lasse ich nicht so einfach davonkommen.
Ihr habt sicher nicht die Komplexität überschätzt. Wenn das für einen ungewaschenen Blogger wie mich offensichtlich war, dass ihr das mit der Technik nicht hinkriegen können werdet, dann war euch Domain Experts das erst Recht klar. Ihr seid ja nicht doof! Nur gierig.
Wobei ich mich da auf der anderen Seite auch nicht zu weit aus dem Fenster lehnen sollte, denn wir reden hier von der Management-Schicht einer eigens für den Geldabfluss aus dem Verkehrsministerium und der Automobilbranche eingerichteten Abteilung der Fraunhofer-Gesellschaft. Klar wurde die nicht gegründet, um am Ende Ergebnisse präsentieren zu können. Bei Fraunhofer gibt es Rechnungen, nicht Ergebnisse. Fraunhofer findet nicht heraus, wie man etwas machen kann, sondern dass es theoretisch wahrscheinlich geht und man dringend mehr Forschungsmittel braucht, um weitere Details sagen zu können.
Sehr lustig ist auch, wo eigentlich die Idee herkommt, dass autonomes Fahren a) geht und b) eine gute Idee ist.
Denn bis heute wird noch regelmäßig eine McKinsey-Studie aus dem Jahr 2015 in der Argumentation pro autonomes Fahren herangezogen, wonach die Technik bis zu 90 Prozent aller Unfälle vermeiden könnte.HAHAHAHA, McKinsey! HAHAHAHAHAHA wie geil! Die sind echt alle so blöde in der Politik! Dabei ist der Algorithmus offensichtlich. Du tust das exakte Gegenteil dessen, was McKinsey sagt! (Danke, Karl-Heinz)
Highlights:
Arbitrary file write while creating workspaceslowclap.gifArbitrary API PUT requests via HTML injection in user's name
Immerhin, die Anstellung von jörnchen als Security-Mensch hat sich für Gitlab gelohnt *wink* (Danke, Martin)
Wofür braucht man die? Für selbstfahrende Autos.
Wie, Moment, warte, war das nicht eine krasse Wachstumsbranche? Die Zukunft der Mobilität gar? Wohl eher doch nicht.
Unter Berücksichtigung der Komplexität und der Markteinführungszeiten habe Bosch entschieden, keine weiteren Ressourcen in die Entwicklung der Hardware zu investieren, teilte eine Sprecherin laut dpa mit.Die Autobauer haben es so wenig eilig mit ihren Feigenblatt-Initiativen, dass sich die Entwicklung neuer Sensoren nicht lohnt.
Wer sich jetzt denkt: Ich mache keine Hardcore Mathe und Bitcoins mine ich auch nicht, das betriff mich nicht! Für den habe ich schlechte Nachrichten. Schon simple String-Funktionen wie strlen benutzen heutzutage Vektorregister. Sogar dietlibc.
Allerdings benutzt dietlibc nicht AVX2, daher wird zumindest dieser Exploit keine Strings leaken. AMD hat einen Microcode-Patch veröffentlicht. Hoffentlicht macht der nicht alles langsamer wie damals die Spectre-Microcode-Patches von Intel.
Rückblickend muss man noch mal festhalten, dass Komplexität der Feind ist. Auch hier wurden die Algorithmen in den CPUs wegen der Spekulation so komplex, dass die Ingenieure sie nicht mehr völlig durchschaut haben. Und so haben sich Hard- und Software angenähert. Alle setzen Dinge ein, die sie nicht verstehen, und selbst die ursprünglichen Entwickler verstehen den Scheiß nicht mehr.
Update: Die Patches sind nur für EPYC verfügbar. Consumer-CPUs müssen bis Ende des Jahres warten. Ja geil, AMD. So macht man sich Freunde. (Danke, Björn)
Warum sind die tot? Steht da nicht. Aber anhand der vorgeschlagenen neuen Dimensionen kann man riechen, von wo der Wind weht:
Das neuere DIE-Sicherheitsmodell (Distributed, Immutable, Ephemeral) ist ein Konzept in der Informationssicherheit, das auf die drei Aspekte Verteilung, Unveränderlichkeit und Vergänglichkeit von Daten abzielt.Na? Gemerkt? Hier wird Ergebnis-Kontrolle durch Implementationsdetails ersetzt. Und zwar Cloud-Heini-Implementationsdetails.
Das ist wie wenn du eine Kategorie "Objekt-Orientierte Datenhaltung" einführst. Das bedeutet nichts. Das hilft niemandem. Das ist Verkaufs-Blablah von Cloud-Heinis, die nicht auf die tatsächlichen Auswirkungen ihrer Vorschläge angesprochen werden wollen. Das ist "It's got electrolytes", falls ihr Idiocracy kennt.
Bislang, wenn jemand deine Daten geklaut hat, war die Confidentiality (Vertraulichkeit) beschädigt. das war nicht zu verhandeln. Wenn jemand deine Daten per Ransomware verschlüsselt, war die Availability weg. Wenn jemand deine Daten ändert, war die Integrity futsch.
Die neuen Kategorien geben diese Analyse nicht her. Die lügen dir direkt ins Gesicht, dass es sowas wie "vergängliche Daten" gibt. Gibt es nicht. Daten werden nicht schlecht. Wenn ich die heute auslese, kann ich die morgen, nächste Woche oder in 100 Jahren gegen dich verwenden.
Das neue Modell lügt dir ins Gesicht, dass das für dich als Kunden relevant ist, ob der Dienst die Daten verteilt oder zentral speichert. Spielt überhaupt gar keine Rolle für dich. Für dich ist wichtig, ob jemand unbefugt rankommt.
Was sollen denn die neuen Kategorien dann? Das sind Cloud-Kategorien! Da geht es nicht um Sicherheit, sondern es geht um das Errichten einer Nebelwand. Oh, und natürlich will dir hier jemand was verkaufen. So Golfplatz-mäßig. Habt ihr schon verteilte Datenhaltung?
Immutable kann helfen, wenn es um die Integrität von Daten geht. Wenn es um die Verfügbarkeit oder Vertraulichkeit geht, hilft das nicht. Distributed kann helfen, wenn es um die Verfügbarkeit geht, aber für Integrität tut es nicht viel und für die Vertraulichkeit ist es sogar kontraproduktiv.
Wieso also hier von Zielen auf Implementationsdetails umschwenken? Weil die Leute keinen Bock haben, ihre sinnlosen Schlangenöl-Maßnahmen gegen tatsächliche Auswirkungen bewerten zu lassen. Die Leute wollen lieber "wir haben die Daten verteilt" sagen, als sich auf Diskussionen einzulassen, was dem Kunden das bringt. In praktisch allen Fällen bringt das nämlich gar nichts. Aber man kann sich gegenseitig auf die Schultern klopfen und so tun, als haben hier nicht Geld verbrannt sondern einen Fortschritt erzielt.
Darum geht es hier aus meiner Sicht. Leute haben keinen Bock, ihre Leistung nach Auswirkungen oder anderen konkreten Kriterien bewerten zu lassen. Weil man dann sieht, dass sie nicht nur gar nichts geleistet haben, sondern die Sache sogar schlimmer gemacht haben, weil es jetzt eine Komplexitätsexplosion gab, die in der Zukunft im Weg stehen wird.
Lasst euch also nicht von irgendwelchen Cloud-Heinis verarschen, die euch irgendwelche Modelle reindrücken wollen, die die fundamental in einer Cloud-Umgebung nicht erbringbaren Anforderungen mit Neologismen und Schlangenöl-Bullshit zu übertünchen versuchen.
Besteht weiterhin auf einer Bewertung nach den konkreten Auswirkungen. Lasst euch nicht mit "aber wir haben da drüben eine Komponente immutable gemacht" abspeisen. Wichtig ist, ob eure Daten geklaut werden können oder nicht.
Heute so: Redhat bietet Kubernetes-Konfiguration als Clouddienst an. Ja geil! Da hat man ja MASSIV was gewonnen mit!
Aber die Frage, wieso man eigentlich auf eine Plattform migriert, bei der man nicht mal die Konfiguration ohne Assistenz im Griff hat, die stellt mal wieder keiner.
Wir sind auf dem direkten Weg in die Cyberpunk/Shadowrun-Welt. Alles ist kaputt, alles ist hackbar, keiner hat irgendwas im Griff. Nur Black ICE fehlt noch: Detektions-Tech, die den angeblich identifizierten Hacker physisch angreift. Aber der eine Teil daran, den Shadowrun und co nicht durchdacht haben: Wenn die Menschen so wenig in der Lage sind, ordentliche Software zu schreiben, dann würde die Einführung von Black ICE erstmal den eigenen Admins das Hirn frittieren. Denn soviel ist heute schon beobachtbar: Der typische Angreifer weiß deutlich mehr über das die Details des Systems als der typische Admin.
Was ich ja bei der Idee mit dem Konfigurations-Clouddienst auch krass finde: Wer würde denn in so einem Szenario merken, wenn die NSA ihm eine Konfiguration mit Hintertür in die Hand drückt?
Da hat jemand gelesen, wie geil Google angeblich skaliert, und was für einen tollen Zoo aus Microservices Netflix hat. Das brauchen wir hier auch!
Erst glaubten alle, sie bräuchten unbedingt Virtualisierung. Damit sie Server umziehen können. Hat jemals jemand von denen eine VM umgezogen? Eher selten bis gar nicht.
Dann glaubten alle, sie brauchen Kubernetes. Für ihre Flotte von Microservices. Wofür braucht ihr denn so viele Microservices? Isoliert und sandboxt ihr da Operationen voneinander? Nein. Soll das die Cores besser ausnutzen? Warum denn, wieviele User habt ihr denn pro Sekunde? Oh. Zehn? Hrmjanunäh.
Zumindest letzteres kann man über Reddit nicht sagen. Die haben genug Benutzer, um sich über Skalierbarkeit ernsthaft Gedanken machen zu müssen. Und im Allgemeinen flutscht deren Site ja auch, fühlt sich nicht träge an. Aber neulich war die mal für ein paar Stunden weg. Umso erfreulicher, dass es am Ende ein Post-Mortem gab.
Das Ergebnis ist: Sie haben einen Kubernetes-Cluster updaten wollen, und das Update flog ihnen um die Ohren. Naja, äh, kein Ding, denkt ihr euch jetzt vielleicht. Sowas macht man ja immer rollbackbar. Dafür hat man ja Microservices. Damit die einzelnen Einheiten eine möglichst kleine Granularität haben und man da einzeln Herumupdaten kann. Überhaupt sollte Kubernetes ja noch am problemärmsten hoch- und runter-schiebbar sein, denn da liegen ja alle gefährdeten Daten in Pods. Wir reden hier vom Kubernetes selbst, das sie geupdated haben. Würde man denken. Tatsächlich ist es aber so:
But, dear Redditor… Kubernetes has no supported downgrade procedure. Because a number of schema and data migrations are performed automatically by Kubernetes during an upgrade, there’s no reverse path defined.I-de-ale Voraussetzungen für ein Stück kritische Infrastruktur! Diese Enterprise-Fuzzys labern immer rum von wegen Verfügbarkeit und Metriken und setzen dann … sowas ein?!?Tsja. Nächstes Problem: Alle Metriken waren ausgefallen. Heutige Installationen sind so krass ultrakomplex, dass man da ohne Metriken nicht mehr so richtig diagnostizieren kann. Gut, wenn die Metriken ganz weg sind, dann klingt das nach einem Netzwerkproblem. War es dann auch.
At some point, we noticed that our container network interface, Calico, wasn’t working properly.Wieso haben sie das nicht sofort gemerkt, fragt ihr? Tsja. Da fehlte die institutionelle Erfahrung. Die hatten lauter Leute, die wussten, wie sie in ihrem Admin-Interface Dinge klickt. Aber was man tut, wenn das Admin-Interface nicht geht, weil das Netz dazwischen braun ist, das wusste keiner mehr, und inzwischen war die Komplexität so krass gewachsen, dass das wahrscheinlich generell niemand mehr von Hand gucken konnte. Sie haben da tolle selbstreparierende Prozesse gehabt, aber das lief halt wie bei Asimov. Wenn du selbstwartende Dinge baust, geht das Wissen verloren, wie man sie baut und wartet, weil das ja nicht mehr gebraucht wird, und wenn die dann irgendwann doch kaputt gehen, hast du dann halt komplett verloren. So war das auch hier. Sie haben den Pod mit dem Netzwerkmanagement-Kram gekillt und gelöscht und der versuchte sich dann neu zu installieren, aber die Installation hatte halt dasselbe Problem wie die davor.
Also haben sie ein Backup einzuspielen versucht. Aber wie bei Asimov:
Once that was finished, we took on the restore procedure, which nobody involved had ever performed before, let alone on our favorite single point of failure.Das ist generell nicht gut. Ein Backup ist erst dann ein Backup, wenn man es erfolgreich wieder einspielen konnte. Wenn man das nie probiert hat, dann ist das auch kein Backup sondern bloß ein Datenhaufen. This procedure had been written against a now end-of-life Kubernetes version, and it pre-dated our switch to CRI-O, which means all of the instructions were written with Docker in mind.Wie das halt ist, wenn man essentielle Dinge hinten runterfallen lässt, weil das ja alles selbstheilend ist und wir daher nicht so gut vorbereitet sein müssen.Was ich persönlich ja besonders unterhaltsam finde, ist dass sie dann über TLS-Zertifikate stolperten, weil sie ein Backup für Kiste A auf Kiste B eingespielt haben, und dann hatte der ein Zertifikat für die falsche Maschine und Clients wollten nicht mehr connecten.
Aber der eigentliche Kracher an dieser ganzen Story ist, was am Ende der Root Cause war. Achtung, stabil hinsetzen:
The nodeSelector and peerSelector for the route reflectors target the label `node-role.kubernetes.io/master`. In the 1.20 series, Kubernetes changed its terminology from “master” to “control-plane.” And in 1.24, they removed references to “master,” even from running clusters. This is the cause of our outage. Kubernetes node labels.Das ganze Kartenhaus ist eingestürzt, weil Kubernetes aus Wokenessgründen fand, dass da nicht mehr master stehen darf. Kubernetes, muss man an der Stelle wissen, hat ja historisch enorm viel mit Sklaverei zu tun hat. Und wenn man böse Worte nicht mehr verwendet, macht man damit böse Taten in der Vergangenheit rückgängig. Oder so.Deshalb war Reddit kaputt.
Update: Oh und erwähnte ich, dass sie beim Ausführen der veralteten Dokumentation, wie man Backups einspielt, merkten, dass eines der Kommandozeilentools seit dem die Argumente umbenannt hatte? Was zur Hölle ist denn das für eine unprofessionelle Kackscheiße schon wieder! Was denken sich denn bitte solche Leute?! Unseren Scheiß wird schon keiner einsetzen?
Bin selbst in der Branche der Arzneimittelforschung tätig, bin Einreichungen befasst und arbeite mich in einem Team seit Monaten in die Materie ein. Die EU-Kommission hat in 2014 die zugrundeliegende Verordnung erlassen und ist in der Verordnung davon ausgegangen, dass das System schon ab 2016 laufen könne. Was auch in dem Artikel untergeht: Es hat dann aber ab 2014 insgesamt sieben Jahre gedauert, bis das "EU-Portal" (heißt heute "CTIS") als "funktionsfähig" auditiert wurde (im Prinzip ist das eigentlich nur eine etwas komplexere Plattform zum Austausch von Dateien und die Interaktion mit noch ein paar anderen Datenbanken).Ich lass das hier mal so stehen, weil man da von außen nicht viel sagen kann. Ist das zu wenig Geld? Kommt drauf an. Wenn das von den Anforderungen her bloß etwas wie Dropbox war, dann vielleicht nicht?Na, wenn das auditiert wurde, muss es doch gut sein...
So war das aber nicht. Die EU-Kommission und die EMA waren nach all den Jahren nach 2014 auf die Knochen blamiert, weil sie es einfach nicht auf die Kette brachten, das digitale Rückgrat für das ganze System zu implementieren. 2021 war es dann der EMA genug und man hat ein fast schon inszeniertes Pseudo-Audit (wahrscheinlich mit irgendwelchen leicht einzuhaltenden Phantasieparametern) vorgenommen, dessen Ausgang politisch quasi vorweggenommen wurde: Am Ende hat die Funktionsfähigkeit des Systems belegt zu sein. So kam es auch, aber jeder in der Branche der Arzneimittelforschung wusste, dass das Teil nicht laufen würde, wie es soll. Der Rest war dann Propaganda und Leersprech und heute stehen wir vor einem Scherbenhaufen. Die globale Forschungslandschaft schaut angewidert auf die EU und ihr peinliches Konstrukt. Die ersten Praxiserfahrungen sind noch katastrophaler als in dem Artikel angedeutet. Es werden Workarounds für Probleme eröffnet, bei denen keiner meiner Kollegen (s.o.: wir arbeiten uns seit langem ein) überhaupt das Problem in seiner Komplexität und Abgefahrenheit nachvollziehen kann, vom Workaround ganz zu schweigen.
Irgendwann hatte sich herausgestellt, dass die EU-Kommission/EMA das Projekt heillos unterfinanziert hatte. Ich glaube, das waren irgendwie sowas wie 1,5 Vollzeitstellen für zwei Jahre, die man da für einen lachhaften Betrag ausgelobt hatte. Zwischendrin war dann auch noch der beauftragte Contractor abgesprungen... das ist also die Digitalisierung, von der alle immer sprechen!?
Wenn der Dienstleister in der Mitte abspringt, war das dann zuwenig Geld? Kann auch sein, dass der Dienstleister unseriös war, alle Kohle rausgetragen und dann in die Kamera lächeln Insolvenz anmeldete.
Eine Sache kann man sagen: Wenn Workarounds zu Problemen herumgereicht werden, die jemand, der sich ein halbes Jahr in das System eingearbeitet hat, nicht versteht, dann ist das System vermutlich (unnötig?) komplex. Ein so komplexes System wird nie von seinen Anwendern beherrschbar sein und das ist ein Garant für Probleme, inklusive Sicherheitsproblemen.
Eine Sache ist aber völlig klar, da werdet ihr mir zustimmen.
Softwareproblem. Kann man nichts machen.
Auf der einen Seite will ich nicht nur schreiben, wie kaputt alles ist. Auf der anderen Seite will ich aber auch nicht dafür sorgen, dass Leute länger bei Windows bleiben, weil sie dank irgendwelcher Konfigurationsratschläge den Eindruck haben, sie könnten das schon irgendwie absichern. Zu guter Letzt bin ich Code Auditor, nicht Admin. Was man da alles konfigurieren kann ist nicht mein Spezialgebiet. Am Ende verbreite ich noch Unfug?
Daher haben meine Zero-Trust-Folien am Ende eine eher allgemeine Vision.
Allerdings kam ein Leserbrief mit konkreten Ratschlägen rein, den ich jetzt mal veröffentlichen möchte. Nehmt das aber bitte nicht als abzuarbeitendes Howto sondern als Grundlage für eigene Recherchen. Ziel der Übung sollte sein, dass ihr ein bisschen mehr verstanden habt, wie die Dinge funktionieren.
zu deiner Zero Trust Präsi möchte ich mal etwas zur Windows Security einwerfen. Sorry, ist etwas länglich geworden.Anmerkung von mir: Die ct hatte dazu mal ein Tool veröffentlicht, da könnt ihr damit mal herumspielen.Wir sind IT Dienstleister und übernehmen in der Regel den Service einer bestehenden IT Landschaft die entweder vorher durch den Kunden oder durch einen anderen Dienstleister betreut wurde. KMU 1 bis 500 MA.
Dahin zu gehen und den Kunden Windows und Outlook wegzunehmen wird in der Regel nicht gelingen. Wenn es möglich ist einen neuen Server auf Linux hoch zu ziehen könnte man das vorschlagen und umsetzen, da hört es aber dann auch schon auf.Der Satz "Das geht, weil Sie Outlook und Office benutzen" stimmt leider in den meisten Fällen, obwohl das nicht so sein müsste.
MS liefert schon seit Windows 2000 allerhand Techniken mit die genau das alles verhindern. Wir haben aber noch nicht einen Kunden bekommen bei dem irgendwas davon aktiv war und holen das alles schleunigst nach. Das schlimmste was uns als Dienstleister passieren kann, ist ein Ransomwarebefall eines Kunden bei dem wir die Schuld tragen, weil deren Systeme nicht sicher sind, obwohl man es *ohne* Anschaffung zusätzlicher Software hätte besser machen können. Der Kunde verlässt sich darauf dass wir ihm eine sichere Arbeitsumgebung geben. Es ist ein Unding, dass ein aktueller Windows Server bei einer frischen Active Directory Installation immer noch fast die gleichen Sicherheitsdefaults verwendet wie es in 2000 eingeführt wurde und so kommt es, dass von all dem was nun kommt in freier Wildbahn oft nichts zu sehen ist.1: Software Restriction Policies (SRP), ja ich weiß ist deprecated, läuft aber selbst auf Win 11 noch. MS wollte das durch Applocker ersetzen. Ist aber auch deprecated. MS will das durch Defender Application Control ersetzen, geht aber nur per XML oder und nur in Enterprise oder so. Wir bleiben bisher bei SRP, weil das keine Enterprise Lizenzen braucht und seit Win 2000 unverändert läuft. Muss man halt nach jedem größerem Update testen ob es noch geht.
Was tut es? Windows führt nur noch EXE, CMD/BAT, PS1, sonstwas aus Pfaden aus die der Admin per GPO festgelegt hat. Outlook kopiert den Anhang aus der Mail in ein Temp Verzeichnis und will es dort starten. Das darf es dann nicht mehr. Admins installieren nach c:\program files\. Das ist erlaubt. Ein User darf da nicht schreiben.GPO ist ein Group Policy Object, oder in deutschen Versionen: Gruppenrichtlinien.
MS torpediert es aber selbst mit Programmen die sich unter AppData\Local installieren. Teams z.B. und andere Hersteller sind da auch keine Vorbilder. Muss man sehr enge Ausnahmen setzen und das Risiko in kauf nehmen.2: Makros. Ja, der gelbe Balken bringt nix. Per GPO hart ganz abschalten. Brauchen ohnehin die wenigsten Anwender. Die die es brauchen, kann man geziehlt auf die Dokumente einschränken für die es gehen soll. Was machen die Malware Makros? VBS oder Powershell Script ausführen und Payload nachladen und starten. Geht eigentlich durch SRP schon nicht mehr, aber es soll ja Bugs geben die vielleicht um SRP drum rum kommen.
3: Beschafft sich lokale Admin-Rechte und übernimmt den Domain Controller.In meinen Folien hatte ich gesagt, dass Lateral Movement nicht Teil des Threat Models ist. Ich bin mir unsicher, inwieweit man das verallgemeinern kann. Ich unterhalte mich zu Ransomware mit Kumpels, die weiter oben auf der Eskalationsskala sitzen, die sehen dann praktisch ausschließlich Fälle, bei denen der AD übernommen werden konnte. Ich habe leider keine Zahlen, wie hoch der Prozentsatz der Ransomware-Angriffe ist, die man verhindern könnte, wenn man Lateral Movement unterbindet. ALLERDINGS: Wenn man durch andere Maßnahmen dafür sorgt, dass der Sprung zum Domain Admin nicht geht, dann wird die Verhinderung von Lateral Movement plötzlich eine wichtige Maßnahme. Genau das spricht der Leserbrief hier an.
Wenn 1 und 2 versagt hat kommen wir dahin. Nächste Verteidigungslinie ist Lateral Movement zu verhindern.Es gibt genug GPOs zum härten der Systeme, aber man klemmt halt damit alten Legacy ab, was ich aus technischen Sicht eigentlich ganz gut finde. NTLM Auth weg, Credential Caching für Admins und generell Server abschalten, Debugging Rechte global abschalten und nur im Einzelfall erlauben. LAPS benutzen, auch für Server. Das macht es Mimikatz schon ganz schön schwer an verwertbare Daten zu kommen.
Mit ESAE hat MS schon lang ein Konzept die Admin Ebenen voneinander zu trennen. Man muss auch nicht zwingend mehrere Domänen betreiben um den wichtigsten Teil davon umzusetzen.Ich hab das in einem Nebensatz irgendwo erwähnt, dass man die Admin-Accounts aufteilen soll, und dass der Domain Admin nicht an die Datenbanken können soll. Der Leser hier hat völlig Recht, das kann und sollte man noch mehr auftrennen. Dann hat man tatsächlich etwas getan, um im Threat Model ein Bedrohungsrisiko zu senken.
Bei uns darf ein Domain Admin nicht mal PCs in Domänen aufnehmen. Niemals sollte sich ein Domain Admin an einem Client anmelden und das lässt sich auch per GPO verhindern.
Der darf auch nur an Domain Controller, die CA und ähnliche Systeme. Ein Server Admin darf da nicht hin und der darf auch nicht an Clients. Ja, der Domain Admin hat dann halt 4 User Accounts. User, Client Admin, Server Admin, Domain Admin. Natürlich mit Grundverschiedenen Passwörtern. Kommt man mit klar.
Selbst ein Keylogger auf dem Client bekommt dann höchstens den Admin für die Clients, aber kann immer noch nicht auf Server oder gar Domain Controller.Dazu sei angemerkt, dass auch mit Smart Cards im Hintergrund immer noch Kerberos läuft mit Kerberos-Tickets, die abgreifbar sind. Aber die laufen wenigstens nach einer Weile aus.4. Benutz Smart Cards für die Admins und lass nur Anmeldungen per Smart Card zu. In dem Fall kann ein Keylogger auf dem PC auch das Kennwort nicht einfach mal mitlesen.
USB Smart Cards sind nicht teuer. Die Menge an Admins überschaubar.
Für RDP gibt es dann noch den Restricted Admin Mode mit entsprechenden Komforteinbußen.
In Enterprise Editionen noch Credential Guard, usw.
5. Exchange kann Split Permissions. Nutzt das. Es entfernt die Berechtigungen dass der Exchange Server Domain Admin Rechte hat. HAFNIUM war damit nur halb so schlimm.Für die BMC und Hypervisoren würde ich dringend zu physisch getrennter Verkabelung raten, statt zu irgendwelchen Software-Geschichten.
Server müssen auch nicht überall ins Internet dürfen. Verhindert dass Malware auf euren Servern ganz bequem per HTTPS ihren Payload laden können.Erweitert das noch mit VLANs und Firewalls. Kein Anwender muss auf die ESXi Infrastruktur, einen Switch oder das BMC vom Server. Die müssen auch auf die wenigsten Ports für die Anwendungsserver. Da reichen oft ACLs auf dem Core Switch um zumindest bei Line Speed zu bleiben.
Backupserver aus der AD nehmen. Per Firewall/ACL einschränken, dass der an die Server darf, aber die Server nicht zum Backupsserver.Das ist ein guter Ratschlag!
All diese Dinge die ich beschrieben habe gehen mit Bordmitteln. Da ist nicht ein Anti-Virus, SIEM oder sonst eine 3rd Party Lösung beteiligt.Nur ein Nachsatz noch von mir: Der Feind ist Komplexität. Es ist zwar schön, dass man bei Microsoft eine Menge konfigurieren kann, so dass es weniger schlimm ist, aber am Ende des Tages überblickt niemand mehr den ganzen Softwarehaufen, und alle sind nur an der Oberfläche am Herumkratzen. Das betrifft glücklicherweise auch die meisten Angreifer. Wirklich sicher fühlen würde ich mich da nicht. Und wenn man erstmal diese Art von Knowhow aufgebaut hat, dann wird man wahrscheinlich nie wieder von Windows wegmigrieren wollen.
Wir setzen das meiste davon bei Firmen ein die keine 10 Mitarbeiter haben. Das kann man mit Routine an einem Tag umsetzen. (Den Windows Teil zumindest) Testet das selbst mit Mimikatz, Bloodhound und was auch immer. Hackt euch selbst und danach oder wenn ihr das generell nicht könnt, holt euch noch einen Pen Tester um die offensichlichen Lücken weg zu machen.Am Rande: Domain Joined Device Public Key Authentication muss man nicht einschalten. Das ist per Default an. Man muss es aber erzwingen wenn man das Fallback nicht haben will. Ist fast das gleiche, aber doch nicht ganz und geht erst mit Server 2016.
Am weiteren Rande: Patchmanagement. Es wäre schön, wenn MS nicht Patches raus bringen würden die großflächig zu Boot Loops auf Domain Controllern, Druckproblemen oder 802.1X/802.11X Problemen führen würden. Dann hätte man auch mit Auto-Updates weniger schmerzen. So muss man eigentlich schon zwangsweise ein paar Tage warten, wenn man nicht vor einem Totalausfall am nächsten Tag stehen möchte. Beides verfahren sind somit schlecht.
Ich gehe nicht davon aus das danach das System unhackbar sicher ist. Wir sprechen hier immer noch von Software und von Microsoft, aber zumindest hat man etwas in die richtige Richtung getan und die offenlichtlichen Scheunentore geschlossen.
Wer nun mit dem erhöhten Supportaufwand argumentiert, dem sei gesagt dass er bei uns gesunken ist, weil die Anwender eben nicht mehr alles ausführen können was bei 3 nicht auf den Bäumen ist und die Computer dadurch so bleiben wie der Admin es sich mal vorgestellt hat.
Entwicklungsabteilungen können zusätzlich Nicht-Domain Computer oder VMs bekommen um ihre systemnahe Arbeit durchzuführen.
Aus meiner Sicht ist der Vorteil von Linux und co, dass es da keine natürliche Schranke gibt, wie viel Verständnis man von dem Gesamtsystem aufbauen kann.
Update: Einer der Gründe, wieso ich solche Tipps ungerne gebe, ist weil das alles furchtbar komplex ist, und es da immer wieder Untiefen gibt, die man halt nicht kennt, wenn man nicht nach ihnen sucht. SRP und UAC sind da exzellende Beispiele für. Seufz. Siehe auch hier und hier.
Weil die von der Komplexität ihrer eigenen APIs überfordert waren?
Ich finde das ja bemerkenswert, wie die einfach immer weiter machen, egal wie viel Scams es gibt, egal wieviel Infrastruktur wegbricht, egal wie viele Hacks es gibt.
Man stelle sich das mal bei einem anderen Stück Infrastruktur vor! Ja gut, unsere Autobahn frisst wöchentlich ein paar Autos mit Leuten drin, aber die kannten ja die Risiken!1!!
Auf der anderen Seite ist mir das viel lieber, wenn diese Leute "DeFi" verkacken als irgendwas anderes. Vielleicht sollten wir das als Maßnahme begreifen, um inkompetente Deppen aus gesellschaftlich relevanten Bereichen fernzuhalten, wo sie tatsächlich Menschenleben von unschuldigen Passanten gefährden könnten.
Update: Der Hack hat einen Bug ausgenutzt, der ein paar Stunden vorher im Github-Repo gefixt worden war. Aber die hatten den Fix noch nicht produktiv ausgerollt.
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.
Auf 2.15.0? Oh nee, das reichte ja nicht.
Auf 2.16.0? Nee, das reicht auch nicht.
Nach dem Patch ist vor dem Patch! Und eines Tages wird ihnen auffallen, dass man Komplexität nicht essen kann.
Habt ihr schön gepatcht? Oder habt ihr diese eine Konfig-Änderung eingespielt, die rumging?
Nach der Vuln ist vor der Vuln!
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. [...] Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability.Gutes Zeichen, wenn die Leute, die den Code gerade warten, nicht in der Lage sind, einen weltweit Katastrophenalarme auslösenden Bug im ersten Anlauf zu fixen. Was sagt euch das über die Komplexität und Wartbarkeit des Codes? Seid ihr sicher, dass ihr da nicht lieber komplett drauf verzichten wollt?Oh, ich vergaß. Könnt ihr gar nicht. "Geht gar nicht mehr". Habe ich gehört. Von Java- und Javascript-Leuten. Komischerweise geht das bei anderen Sprachen wunderbar.
Und überhaupt: Diese Art von "den Bug kann man nicht debuggen" kennt man sonst nur von Programmiersprachen mit Speicherkorruption. Ihr wisst schon, die Art von Programmiersprache, über die sich Java-Leute gerne lustig machen.
Das ist nicht die Art von Hash, die man in der Kryptografie benutzt, eher ein Lookup-System für Funktions-Signaturen. Sowas baut man ein, wenn man glaubt, man habe den Gegenüber bereits ausreichend authentisiert.
Jetzt stellt sich natürlich die Frage, ob das eine Hintertür war oder Inkompetenz.
Ich finde aber die wichtigere Beobachtung an der Stelle, dass das so lange gedauert hat, bis das jemand gefunden hat. Heutige Software ist so komplex, das selbst eine relativ offensichtliche Schwachstelle wie diese monate- bis jahrelang hinter den Nebelwänden aus Pseudo-Krypto und Bullshit-Nebelwerfer-Terminologie verborgen bleiben kann.
Nicht nur bei den ganzen Kryptocurrency-Betrügern, auch bei so gut wie allen anderen aktuellen Projekten. Kaum noch jemand macht irgendwas ohne Krypto drüber zu sprenkeln.
Aber aber aber da haben doch die ganzen superschlauen Google-Ingenieure dran gearbeitet!!1!
Stellt sich raus: Komplexität verursacht Bugs. Völlig überraschend, seit es in den 1970er Jahren herausgefunden wurde.
Ich bin ja auch ein BPF-Benutzer, weil das die Syntax ist, in der man Seccomp-Sandboxing spezifiziert. Aber so viel Komplexität in den Kernel zu schieben macht mir schon länger Sorge.
Heute gibt es schon die ersten Bullshit-Startups, die "wir schieben Code per BPF in den Kernel" als Geschäftsmodell haben. Das kann eigentlich nicht gut gehen.
Das liegt nicht daran, dass die Thematik so furchtbar komplex ist, sondern das liegt daran, dass ich die Komplexität der Thematik vorher nicht kannte, und daher architekturelle Entscheidungen getroffen habe, die rückblickend nicht schlau waren.
Das kann man jetzt als Scheitern sehen, aber ich sehe es als Gewinn. Genau deshalb habe ich das ja gemacht, damit ich lerne, was die Probleme sind, und worauf man achten muss.
Das "Protocol Error"-Problem, das ihr heute sehen konntet, lag an einer dieser architekturellen Entscheidungen. gatling war ja auf hohe Skalierbarkeit ausgelegt, kann theoretisch zehntausende von Verbindungen offen haben. Wenn ich da einen neuen Prozess für ein CGI erzeuge, dann muss irgendjemand (entweder ich von Hand oder der Kernel über close-on-exec-Flags) die ganzen Sockets zumachen, sonst erbt das CGI die. Daher hatte ich damals entschieden, dass gatling ganz am Anfang einen Prozess aufmacht, der noch keinen Ballast geerbt hat, und wenn ein neuer Prozess gebraucht wird, dann erzeugt dieser jung gebliebene Prozess den. Dem schickt der Haupt-Gatling dann einen Request, und der macht dann den neuen CGI-Prozess auf und schiebt einen Deskriptor zu diesem neuen CGI-Prozess zurück zum Hauptprogramm.
Die Tage hat mir jemand einen Bug gemeldet. Wenn man HEAD auf ein CGI macht, kommt die falsche Content-Length zurück. Die Content-Length spielt bei HEAD an sich keine Rolle, denn der Content kommt ja nicht. Insofern sagt die Spec auch, Content-Length ist bei HEAD optional. gatling ging jetzt nicht davon aus, dass jemand HEAD auf ein CGI macht, weil das ja eine sinnlose Operation ist (wie HEAD überhaupt ziemlich sinnlos ist, seit es If-Modified-Since gibt). Es war ein bisschen Code dafür da, aber das war in keiner Testsuite und es hat bis jetzt auch nie jemand gemacht glaube ich.
Der Fix dafür hat jetzt subtil die Logik gebrochen, die in dem 2. Prozess den CGI-Dateinamen zu einem Request raussucht. Daher kam da "Protocol error".
Langfristig ist der Plan, gatling nochmal neu zu machen, nachdem ich jetzt gelernt habe, was die Probleme sind.
Neue Features, die ich initial für nicht so wichtig hielt, wären multithreading und Offenhalten und Cachen von Dateien.
This destroys the RSA cryptosystemWenn man auf das PDF dazu klickt, dann fehlt dieser Satz am Ende des Abstracts, das Datum des Papers ist Dezember 2019, aber (kaum weniger schockierend) ist der letzte Satz im Paper:This proves polynomial time bound.Der Upload gibt an, von heute zu sein, aber wirkt irgendwie nicht als sei er wirklich von Schnorr. Auf dessen Homepage an der Uni Frankfurt gibt es diesen Draft von März 2020, der auch mit dem polynomiellen Bound endet. Aber selbst wenn die Faktorisierung nicht polynomielle Komplexität hat, behauptet das Abstract dort, sein neues Verfahren sei viel schneller als das Number Field Sieve.
Ich habe das gerade erst gesehen und kann das auch nur sehr oberflächlich beurteilen. Soviel kann ich aber sagen:
a) Schnorr ist eine kryptographische Berühmtheit.
b) Wenn jemand tatsächlich viel schneller als das NFS faktorisieren kann, ist das alleine schon eine Sensation.
c) Wenn jemand bewiesen hat, dass Ganzzahl-Faktorisierung in P statt NP ist, ist das eine noch größere Sensation. Ich kann gerade nicht sagen, worauf sich dieser Satz genau bezieht. Ich glaube aber: Nicht auf die gesamte Faktorisierung.
Ich vermute, dass der Paper-Upload auf diesem Preprint-Server von irgendeinem Typen kam, der auch den Nachsatz angehängt hat, und nicht von Schnorr selbst. Selbst wenn man viel schneller als NFS faktorisieren kann, heißt das nicht automatisch, dass damit RSA gebrochen wäre, sondern erstmal, dass man längere Schlüssel braucht. Ich glaube nicht, dass Schnorr das so formuliert hätte. Und wenn das hätte er es auch in dem Paper selbst so formuliert, nicht bloß auf dem Preprint-Server.
Die Zahlen in dem Papier handelten von Zahlenlängen bis zu 800 Bit. Das sind für RSA schon länger zu wenig. Wenn ich das Paper richtig überflogen habe, wandelt der das Computation-Problem in ein Storage-Problem um. Wie gut das also für größere Zahlen skaliert, müsste man erstmal gucken.
Dieses Paper klingt also in jedem Fall wie eine Sensation. Ich bin mal auf die Erklärungen der Leute gespannt, die das im Gegensatz zu mir beurteilen können :-)
Es handelt sich um einen Bug in der Logik von libowfat. Ich habe einen Fix eingecheckt. Mal gucken, ob das hilft.
libowfat stellt ja ein API zur Verfügung, um sich Events auf Sockets geben zu lassen. Das läuft im Wesentlichen so:
io_fd(3); // ich bin an deskriptor 3 interessiert
io_wantread(3); // und zwar will ich lesen
io_wait(); // warten, bis ein angemeldetes Event eintritt
while ((fd = io_canread())) { // alle read events durchlaufen
...
}
while ((fd = io_canwrite())) { // alle write events durchlaufen
...
}Leider ergibt sich aus dieser einfachen API hinter den Kulissen eine bemerkenswerte Komplexität. io_wait ruft ein Low-Level-API des Betriebssystems auf, das (hoffentlich!) mehr als ein Event auf einmal melden kann.
io_wait hat pro mit io_fd angemeldetem Deskriptor ein bisschen State, und in dem State gibt es next-Membervariablen, einmal für den nächsten Deskriptor mit read-Event und einmal für den nächsten Deskriptor mit write-Event. Diese Liste traversieren io_canread und io_canwrite dann.
Nehmen wir mal an, jemand trägt auf einen Deskriptor sowohl Lese- als auch Schreib-Interesse ein. Dann kommen auf denselben Deskriptor gleichzeitig Lese- und Schreib-Events rein. Bei der Behandlung des ersten davon passiert ein Fehler.
Der Code schließt den Deskriptor.
Aber der State zu dem Deskriptor ist noch in der verketteten Liste für den anderen Event-Typ eingetragen!
Klingt jetzt nicht so schlimm. Der andere Event-Handler macht dann halt read oder write und kriegt einen Fehler, weil der Deskriptor geschlossen ist.
Leider kann aber der read-Event auch auf den Listen-Socket sein, und der Handler dafür ruft accept() auf, und accept() gibt einen neuen Deskriptor zurück. Das könnte derselbe sein, auf den in der Datenstruktur noch ein Write-Event eingetragen ist!
Um dieses Szenario zu verhindern, hat libowfat ein io_close(), das man statt close() aufruft. Wenn der sieht, dass da noch ein Event offen ist, dann markiert er den Deskriptor als geschlossen aber schließt ihn nicht wirklich.
Jetzt will man diese halboffenen Deskriptoren aber auch mal irgendwann loswerden. Dafür gibt es zwei Stellen, die sich anbieten.
Erstens: In io_canread und io_canwrite. Die müssen ja sowieso checken, ob der Deskriptor geschlossen wurde, und das Event aus der Liste dann verwerfen. Die könnten dann auch den Deskriptor ganz schließen.
Zweitens: In io_wait. Das ruft man ja erst wieder auf, nachdem man alle ausstehenden Events abgearbeitet hat. Der könnte dann alle als geschlossen markierten Deskriptoren final schließen.
Ich hatte Code in beiden drin, und der Bug ist glaube ich, dass die sich gestört haben. Mal laufen lassen und gucken, ob es das war.
Das kriegt man doch mit, wenn da was wichtiges passiert!
Ach? Tut man? Wie viele von euch haben mitgekriegt, dass der EU-Ministerrat einen Terroranschlag auf die EU durchgeführt hat?
Im EU-Ministerrat wurde binnen fünf Tagen eine Resolution beschlussfertig gemacht, die Plattformbetreiber wie WhatsApp, Signal und Co künftig dazu verpflichtet, Generalschlüssel zur Überwachbarkeit von E2E-verschlüsselten Chats und Messages anzulegen.Ach nee. Ach was. Das ist ja schon eher wichtig.
Das heißt, dass die Paranoiker natürlich mal wieder die ganze Zeit richtig lagen.
Insbesondere heißt es, dass man ab jetzt keinen Diensten mehr vertrauen kann, selbst wenn man den Betreiber persönlich kennt und für vertrauenswürdig hält.
Ich weiß, was ihr jetzt denkt, und ihr habt Recht. Das können die Sesselfurzer vom EU-Ministerrat doch unmöglich in fünf Tagen selbst erarbeitet haben. Haben sie auch nicht. Das ist die praktisch wörtliche Umsetzung der Vorgabe der Five Eyes. Die wissen nämlich genau: Wenn es erstmal eine Krypto-Hintertür gibt, dann können NSA und GCHQ die nutzen, um die EU abzuhören. Und zwar nicht nur so ein bisschen. Nein, nein. Flächendeckend.
Auch wenn es jetzt den Eindruck erweckt, der Vorschlag käme von Frankreich: Tut er nicht.
Frankreich treibt das ursprünglich von Großbritannien angestoßene Vorgehen gegen sichere Verschlüsselung auf Plattformen wie WhatsApp bereits das ganze Jahr auf EU-Ebene über voran.Ja, richtig gelesen. Frankreich verrät alle EU-Bürger an die Five Eyes, auf Geheiß eines Five-Eyes-Mitglieds, DAS SEINEN FUCKING AUSTRITT AUS DER FUCKING EU ERKLÄRT HAT.
Jetzt denkt ihr euch wahrscheinlich: Betrifft mich nicht. Update ich halt meine Client-Software nicht mehr, bin ich nicht betroffen. So einfach ist das leider nicht. Die meisten Krypto-Messenger sehen eine betreiberseitige Infrastruktur vor, über die man Schlüssel von potentiellen Kommunikationspartnern abfragen kann. Gute Software sieht dann auch einen Weg der manuellen Verifikation vor, aber das ist halt mit Aufwand verbunden, und die üblichen Verdächtigen unter den Saboteuren und Vollidioten haben ja seit Jahrzehnten eine Kampagne gegen Krypto-Software gefahren, dass die "zu schwer zu bedienen" sei und man daher die Komplexität vor den Nutzern verbergen müsse. Das hat dazu geführt, dass die Schlüssel-Übernahme bei praktisch allen Programmen implizit läuft. Als Gegenbeispiel fällt mir gerade nur Threema ein -- und GnuPG. Ja, das GnuPG, das seit Jahrzehnten den Hass der Deppen abkriegt, weil es angeblich so schwer zu bedienen sei.
Wenn Signal per Gesetz zu Hintertüren gezwungen wird, hilft dir jedenfalls auch die ganzen verifizierten Builds nichts und dass der Client-Quellcode Open Source ist. Signal hat sich entschieden, die Krypto-Komplexität vor dem Nutzer zu verbergen, und das bedeutet für das Szenario dann halt, dass der Nutzer wahrscheinlich nicht merken würde, wenn ihm ein falscher Schlüssel untergeschoben wird.
Aber Achtung: Nur weil ich sage dass GnuPG immun ist, heißt das nicht, dass eure Software oberhalb von GnuPG OK ist. Wenn die Software Schlüssel automatisch von irgendwelchen Diensten holt, oder wenn eure Ver- und Entschlüsselung auf irgendeinem Dienst und nicht auf eurem Privatrechner läuft, oder wenn ihr nicht manuell Fingerprints per Telefon oder sonstigem Seitenkanal abgeglichen habt, dann seid ihr Five-Eyes-Futter.
Die Zeit für halbherzige Krypto ist vorbei. Jetzt müssen wir alle in den Freiheitskämpfer-Modus wechseln. Und jetzt ist der Zeitpunkt, wo ihr alle versteht, wieso die Krypto-Anarchisten in ihrer Software einen Freiheitskämpfermodus vorgesehen haben.
Update: Hier vertritt jemand die These, dass Erich überreagiert. Ich finde nicht, dass man in solchen Fragen überreagieren kann. Dass die EU das alleine diskutiert ist in meinen Augen schon ein durch nichts zu entschuldigender Hochverrat. Die EU hat nichts, aber auch gar nichts, auch nur in der Nähe von meinen Krypto-Chats zu suchen.
Update: Wer mein Terror-Bingo schon länger mitspielt, kennt die Muster schon. Aber der Vollständigkeit halber: Es gibt natürlich mal wieder eine Geheimdienst-Verbindung und die Dienste haben so massiv und vollständig verkackt, dass Österreich sogar den Chef des "Verfassungsschutzes" abberufen hat. Wenn die Unterdrückungsbehörden Krypto-Backdoors kriegen, wird das keinen einzigen Anschlag verhindern. Es wird nur dazu führen, dass sie noch großflächiger hätten informiert sein können aber es wegen "Pannen" nicht waren. Ich finde ja, wer so ein Versagen "Panne" nennt, sollte direkt mitgefeuert werden. Eine Panne ist, wenn du das richtige tun wolltest, aber dich technisches Versagen der Infrastruktur daran gehindert hat. Wenn du informiert warst aber deinen Job nicht getan hast, dann ist das Versagen, keine Panne.
Das mag alles sein.
Ihr überseht aber den eigentlichen Skandal in der Meldung. Der eigentliche Skandal in der Meldung ist, dass das BKA argumentiert, das sei ja keine Quellen-TKÜ (für die das Verfassungsgericht ihnen vergleichsweise harte Auflagen diktiert hat), sondern ein weniger schlimmer Eingriff, und daher dürften sie das einfach so machen. Ich zitiere:
Nach Auffassung des BKA handelt es sich bei dieser Methode um eine Überwachung gemäß § 100a Strafprozessordnung – also der regulären Telekommunikationsüberwachung mit richterlicher Anordnung. Obwohl dabei auch umfassend Chatverläufe mitgelesen werden können, sei dies keine Überwachung wie etwa durch den Einsatz des sogenannten Staatstrojaners.Das war eine Medienkompetenzübung. Mein erklärtes Ziel ist es ja schon immer, dass ihr eben nicht nur meinen Kommentar und die Überschrift lesen sollt, sondern die Primärquelle, und zwar möglichst vollständig. In diesem Fall war die Hoffnung, dass ihr dieses Detail seht und merkt, was da gerade abläuft, und euch gewaltig aufregt über die Chuzpe des BKA. Das ist aus meiner Sicht ungefähr so krass wie die Weltraumtheorie des BND damals, ihr erinnert euch vielleicht.
Das ist ein ganz grobes Foul, was das BKA hier macht. Ignoriert mal den Whatsapp-Teil (aber nicht meine Ausführungen dazu, dass man Krypto-Komplexität nicht "in die Software schieben" kann und dann ist sie weg).
Ausgesprochen krass finde ich auch, dass sie es schon wieder mit der "aber wir machen das doch gaaaanz selten!!1!"-Ausrede probieren. Man stelle sich das mal an irgendeiner anderen Stelle vor! "Aber Herr Richter, ich habe den Mann doch nur ganz selten umgebracht, nur ein einziges Mal!!1!"
Unfassbar!
Frühe Krypto-Software wie PGP haben nicht versucht, diese Komplexität zu verbergen. Die haben sich das angeguckt und sind zu dem Schluss gekommen, dass man die Lage nur unsicherer macht, wenn man so tut, als könnte man das in der Software lösen.
Ergebnis: Jahrelanges Herumgeflenne von Vollidioten, dass die Software ja so schwer zu bedienen sei. Man muss neue Konzepte lernen und so!1!!
Also ist moderne Krypto-Software anders. Die macht faule Kompromisse und verbirgt die Komplexität hinter einer Nebelwand aus Lügen und "weitergehen, gibt nichts zu sehen hier"-Bullshit. Am besten noch mit ein paar Dark UI Patterns wie bei Signal, der dir gelegentlich anzeigt, ein Schlüssel habe sich geändert, aber dir nicht sagt, was das bedeutet, und ob du jetzt was tun solltest oder nicht.
Das Problem ist: Da kann die Krypto so geil sein wie sie möchte! Lücken, die das UI aufreißt, kriegt auch der tollste Algorithmus nicht kompensiert.
Nimm z.B. Signal. Signal hat das Key Distribution Problem nicht gelöst. Daher hängen bei denen die Accounts an der Telefonnummer. Was für Auswirkungen hat das, wenn du deine Telefonnummer oder Simkarte verlierst? Das ist dem normalen Anwender überhaupt nicht klar.
Ich will hier nicht Signal bashen, die sind noch einer der besseren Marktteilnehmer. Ich erwähne die hier nur, weil die ein Vorreiter von neuartiger toller Krypto sind.
Nächstes Problem. Sagen wir mal, du baust einen Keyserver auf, wo man seinen Schlüssel höchlädt. Wenn jemand mit mir reden will, holt der sich meinen Schlüssel von dort. Super? Nein! Was wenn der Schlüssel da nicht von mir sondern vom BKA hochgeladen wurde?
PGP hat hier auch keine gute Lösung. Die haben sich gedacht, das wird dem Anwender schon klar sein, dass er Schlüssel von irgendeinem Server aus dem Internet erstmal prüfen muss. Daher gibt es Fingerprints und Signaturen unter dem Schlüssel. Was hat es gebracht? Sobald jemand kam und Gibt-hier-nichts-zu-sehen-UI um Bullshit-Automatismen um die Keyserver gebaut hat, war es plötzlich ein legitimer Angriff, dort einen falschen Key für jemanden hochzuladen, um dessen Kommunikation zu sabotieren. Wenn die Leute alle ihre Keys verifizieren würden, wäre das überhaupt kein Problem. Aber Dark UI hat das kaputtgemacht.
Warum erzähle ich das alles? Nun, Keyserver gibt es auch bei Messenger-Diensten. Und da kann die Krypto so geil sein wie sie will: Wenn du den Key automatisch vom Keyserver holst, kann der dir auch "den BKA-Key" unterschieben und behaupten, das sei der, nach dem du gefragt hattest.
Oder noch besser: Was wenn du Synchronisation anbietest? Dann kann ein Angreifer mal eben eine Weiterleitung an das BKA eintragen bei dir, wenn der kurzzeitig Zugriff auf deinen Account hat, und dann können die alles mitlesen.
Ach komm, Fefe, das ist doch unsubstanziiertes Paranoia-Geraune! Nun, äh, genau das hat das BKA bei Whatsapp gemacht.
Aber hey, solange gemeingefährliche Heulsusen uns die Krypto-Anwendungen schlechtreden, die die Komplexität an den User weiterleiten, damit er sie managen kann, und den Leuten Weitergehen-Apps empfehlen, die die Komplexität hinter Nebelwänden verstecken und den Leuten eine warme Gemütlichkeit vorgaukeln, die nicht da ist, wird diese Art von Problem noch zunehmen.
Update: Das soll kein Signal-Bashing werden hier. Die geben sich immerhin Mühe und sagen dir, wenn sich ein Schlüssel geändert hat. Andere zeigen das nicht mal an, weil es ja "die Bevölkerung verunsichern würde".
Update: Da hab ich wohl einige Leser überfordert. Whatsapp ist Ende-zu-Ende-verschlüsselt. Das heißt der Server kann gar nicht die alten Nachrichten im Klartext weiterreichen, selbst wenn er wollte, weil die da nur verschlüsselt vorbeihuschen. Wenn man also Synchronisieren will, gibt es zwei Varianten: Entweder man rückt den Schlüssel raus (daher meine Ausführungen oben über Schlüsselaustausch) oder man macht eine Fernsteuerung der Handy-App von dem Browser aus, in welchem Fall man auch ein Zugriffstoken (vulgo: einen Schlüssel) hat, den man dem BKA gibt.
Das scheint ja jetzt so Konsens zu sein, dass wir alle mit unbeherrschbaren Systemen arbeiten, deren Komplexität uns mehrere Größenordnungen über den Kopf gewachsen ist. War ein Softwareproblem. Niemand ist schuld. *schulterzuck*
Leider zieht das EJPD (Eidgenössische Justiz- und Polizei-Departement) jetzt vor das Bundesgericht.
Ich drücke Threema ganz doll die Daumen. Das ist der einzige der großen Messenger, der nicht darauf besteht, dass man den Account mit der Telefonnummer assoziiert, und der auch nicht die Komplexität von Krypto hinter Bullshit-Automatismen versteckt (wie z.B. Signals "die Sicherheitsnummer hat sich geändert").
Von der Krypto her ist Signal noch ein bisschen cooler, aber Threema hat mehr dafür getan, das Vertrauen seiner Nutzer wirklich zu gewinnen, und nicht bloß Sicherheit zu behaupten. Ich habe in meinem Leben für eine einzige Smartphone-App Geld ausgegeben. Es war Threema.
Ich bin ja ehrlich gesagt sehr irritiert, dass die Schweizer Regierung das so kurz nach der Aufarbeitung des Crypto-AG-Skandals in der Presse wagt. Die letzten paar verbleibenden rauchenden Ruinen von Glaubwürdigkeit bezüglich Kryptografie in der Schweiz sind Threema. Die jetzt auch noch plattzumachen wäre ein irreparabler Rufschaden für die Schweiz.
Update: BTW: Glaubt mal gar nicht, dass nur die Schweizer Dienste freidrehen.
Das Niveau der Spionage gegen Deutschland sei auf dem Stand des Kalten Krieges oder sogar noch deutlich höher, schätzte Haldenwang.
Aha. Schätzt er. Wie früher. Oder deutlich höher. Schätzt er. Was machen Sie noch gleich beruflich, Herr "Verfassungsschutz"-Chef Haldenwang? Wofür waren Sie noch gleich zuständig? Oh ja richtig. Erkennen und Abwehr ausländischer Spionage. Und Sie können nicht mal sagen, ob das so hoch wie früher ist oder deutlich höher? Was muss eigentlich noch passieren, damit wir diese unnützen Dienste alle mal zumachen und das Geld unter den Hartz-IV-Opfern verteilen?
Ich wettere seit Jahren, dass die Systeme um uns herum viel zu viel Komplexität haben. In der Softwareentwicklung werden völlig unbesorgt und unbedarft Abhängigkeiten ins Projekt gezogen, bis der Arzt kommt. Das Endprodukt ist immer häufiger von einer Komplexität, die alle Projektbeteiligten um Größenordnungen überfordert.
Ich finde, der Crypto-Hack zeigt gerade, wass das Ergebnis dieser Entwicklung ist.
Der Endboss ist nicht mehr der Überhacker, der Bugs ausnutzt. Der Endboss ist jemand, der sich die Zeit nimmt, sich in das System einzuarbeiten. Jemand, der die Dokumentation und/oder den Code liest. So wenig Zeit, wie sich die übliche Softwarefirma dafür nimmt, ein durchblickbares System zu bauen, bzw. überhaupt ein System, führt eben dazu, dass niemand das am Ende mehr durchblickt.
Wer sich die Zeit nimmt, die wir als Entwickler uns nicht genommen haben, kann unser System angreifen.
Anders formuliert wird eine Erkenntnis daraus: Je mehr Zeit wir in der Entwicklung sparen, desto weniger Durchblick haben unsere Entwickler, desto tiefer liegt die Schranke für einen Angreifer. Der muss das System ja nicht in Gänze verstehen, um es angreifen zu könne. Es reicht, wenn der einen angreifbaren Aspekt des Systems besser versteht als die Entwickler.
Wenn man sich anguckt, wie tief das Verständnis der Werkzeuge und der Umgebung bei typischem Code ist, dann ist das eine sehr tiefe Schranke.
Ich habe mich ja bei Shadowrun immer gefragt, wie die darauf kommen, dass wir in der Zukunft von hackbarer Software umgeben sein werden. Jetzt weiß ich es.
Bei allem Geheule über die unfassbare Komplexität und die ständigen Lücken in Browsern: Das hier ist noch viel schlimmer.
Gut, das konnte bei den Monolithen am Anfang auch niemand. Aber da gab es eine realistische Chance. Jetzt nicht mehr.
Und dazu kommt, dass du am Ende mit einem Dutzend YAML-Dialekten zu tun hast, alle subtil unterschiedlich.
Für CI-Pipelines gilt Ähnliches. Die wirken im Allgemeinen auch komplexitätsverstärkend. Ich mache ja Code Audits bei Kunden, d.h. ich muss den Code nur lesen können, nicht bauen. Wäre natürlich schöner, wenn ich den auch bauen könnte. Aber das haben, wie sich rausstellt, praktisch alle Kunden schon vollständig aufgegeben.
Dafür müsste man mir in der Cloud eine Kopie der CI-Pipeline konstruieren. Und die durchblickt niemand mehr. Das ist völlig unrealistisch. Welche Präprozessor-Symbole gesetzt sind? Äh ... keine Ahnung? Wir wissen nur, dass wir hier clicken, und am Ende fällt ein Binary raus. Wir verstehen nicht mal genug, um die Fehlermeldungen der Pipeline und des Compilers auszuwerten.
Da lobe ich mir echt das GNU-Projekt und die BSDs, die ihre Buildsysteme auf einen gemeinsamen Standard normiert haben. Schade nur, dass die sich nicht auf denselben Standard einigen konnten.
Meine Zielvorstellung wäre ja, dass du in jedes Verzeichnis gehen kannst, make aufrufen kannst, und dann baut der die Libraries und Programme aus dem Verzeichnis.
Wenn man nur Open Source macht, könnte man geneigt sein, den Buildprozess von Firefox für den übelsten der Welt zu halten. Glaubt mir. Weit gefehlt. Der spielt nicht mal in derselben Liga wie so übliche Kommerzprojekte.
Das Argument würde natürlich viel ernster genommen, wenn es Malware gäbe, die über einen 0-day im Antivirus reingekommen ist.
Nun, … *drumroll* … die gibt es jetzt.
Hackers exploited a Trend Micro OfficeScan zero-day to plant malicious files on Mitsubishi Electric serversIch finde ja bei sowas immer, dass man nicht warten muss, bis die 0-days ausgenutzt werden. Remote Desktop und Antiviren sind beides Dinge mit viel zu viel Komplexität. Das kann praktisch gar nicht sicher sein.Benutzt ihr Wordperfect? Wem das nichts sagt: Googelt das mal. Das ist eine Textverarbeitung von früher, bevor alle nur noch bei Microsoft gekauft haben.
Habt ihr wahrscheinlich nicht. Aber der Antivirus muss einen Parser dafür haben. Könnte ja Malware drin sein. Schwupps habt ihr mehr Angriffsoberfläche. Die Schlangenöler sagen immer, wie viele Viren sie angeblich erkennen. Fragt mal euren Vertriebsbeauftragten, wieviele Dateiformate sie können. Stellt die Frage am besten so, dass es klingt, als hieltet ihr das für vorteilhaft, wenn das Ding viele Dateiformate versteht.
Der Verzicht auf unnötige Angriffsoberfläche ist die älteste Maßnahme in der IT Security. Dienste zumachen, die man nicht braucht. Ports zumachen, die man nicht braucht. IPs filtern, die nicht erreichbar sein müssen. Software deinstallieren, die nicht gebraucht wird. Schlangenöl ist die Antithese davon, und irgendwie scheint es niemand wahrzunehmen. Schlangenöl ist das Gegenteil von Security.
Update: Oh ach gucke mal, ich war ja gar nicht der einzige Rufer in der Wüste: Thierry und Sergio haben auf der Cansecwest 2008 auch was dazu vorgetragen. *winke*
Man beachte das übersichtliche Deployment-Diagramm!
Ich musste ja neulich über einen Forenkommentar schmunzeln, der so meinte:
Wir haben VMs eingeführt, um die Probleme mit Distros zu lösen.Und jetzt führen wir Serverless ein, um endlich mehr Geld an Amazon abzudrücken. Oh nee, warte, um die Probleme mit Kubernetes zu lösen! :-) (Danke, Lukas)Wir haben Container eingeführt, um die Probleme mit VMs zu lösen.
Wir haben Docker eingeführt, um die Probleme mit Containern zu lösen.
Wir haben Kubernetes eingeführt, um die Probleme mit Docker zu lösen.
Zusätzliche Probleme seien durch die Umstellung des Warenwirtschaftssystems auf SAP entstanden. Haribo habe hier die Komplexität der Umstellung unterschätzt. Dies habe zeitweise zu Lieferausfällen "bis zu zehn Prozent und darüber" geführt.SAP hat ja auch schon ihren Teil für die Abrüstung der Bundeswehr getan, und hätte fast Lidl versenkt. Ich glaube ja, SAP ist sowas wie ein Gütesiegel. Wenn deine Firma eine SAP-Einführung überlebt, muss sie grundsolide Basiswerte haben und solide und krisenfest gemanaged sein. (Danke, Frank)
Hier ist mal ein praktisches Beispiel:
We started in .NET Core 1.0 with a very minimal API set that only included ~18K of the .NET Framework APIs.Zum Vergleich: Linux hat so um die 300 Syscalls. Und ich kenne niemanden, der das API für minmal hält. 18k ist nicht minimal, nach keiner Definition irgendwo. Nichts an 18k ist minimal.With .NET Standard 2.0, we tried to make it much more viable to share code between .NET Framework, .NET Core, and Xamarin which resulted in approximately 38K .NET Frameworks APIs being available in .NET Core 2.0.Kann irgendjemand hier auch nur 18k Funktionsnamen gleichzeitig im Kopf haben? Wie ist es mit 38k?We also built the Windows Compatibility Pack which made another 21K .NET Framework APIs available to .NET Core, resulting in almost 60K additional APIs.Oh super, 60k! Wenn ich "völlig außer Kontrolle geraten" visualisieren müsste: So würde ich es visualisieren.And in .NET Core 3.0 we added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs.Fuck yeah! 120k! Damit sind wir über der Hälfte der APIs im .NET-Framework!!1!Wie absurd.
Und dann tun die auch noch so, als könne irgendjemand das verstehen oder warten oder für die Funktionsfähigkeit davon garantieren. Wer baut denn bitte auf so einem Komplexitätsmonster noch seine Business-Software auf, die nochmal einen Komplexitäts-Wolkenkratzer draufpackt?
Creating tomorrow's legacy, today!
Ja und nein. Auf der einen Seite ist das kein reiner Schlangenöl-Placebo. An der Spec haben sich Experten aus mehreren Fachgebieten die Hände wund-masturbiert. Da ist einmal alles drin. Von Challenge-Response über Public-Key bis hin zu USB und NFC. Die Spec erwähnt als Inspiration auch Smartcards, damit wirklich jeder an Bord ist.
Das hat technisch schon Hand und Fuß, was die da machen. Ich rede trotzdem von Masturbation, weil dem ein paar Annahmen zugrundeliegen, über die man, zurückhaltend formuliert, nochmal diskutieren sollte.
FIDO2 kombiniert zwei Trends, die wir gerade gehäuft sehen in der IT-Security. Erstens: Unsere Software ist so unfassbar komplex geworden, dass wir Security nicht mehr herbeiführen können, daher bauen wir jetzt einen kleinen Mini-Rechner, und der ist dann so klein, dass man ihm noch vertrauen kann. Das Muster kennt ihr wahrscheinlich aus dem Supermarkt oder von Banken, die euch dann da so ein kleines Mini-Terminal für Kartenzahlung hinhalten. Da ist auch der Gedanke, dass das klein und verplombt ist und man dem daher vertrauen kann, weil die Bank oder der Supermarkt daran gar nicht mehr herumpfriemeln könnte, selbst wenn sie wollten.
Der zweite Trend ist, dass wir von sich gegenseitig vertrauenden Komponenten und der Unterscheidung "Internet vs. Intranet" zusehends wegkommen und stattdessen überall Krypto ausrollen. Selbst innerhalb von Chips haben wir inzwischen Krypto, und innerhalb von Modulen einer Software. Selbst so ein SOC, wie er in Mobiltelefonen verbaut wird, besteht inzwischen aus sich gegenseitig nicht mehr vertrauenden Modulen, die Krypto einsetzen.
Welche Annahmen meine ich jetzt, über die man nochmal reden sollte? Na die erste ist offensichtlich, dass diese Hardware "tamper proof" ist. Einer meiner Lieblingssprüche zu tamper-proof hardware ist von Peter Gutmann, der sagte: It is said that the only tamper-proof hardware is Voyager 2. Und zwar nicht, weil die Hardware sicher ist, sondern weil man da so schlecht rankommt, weil das Ding so weit weg ist. Die Annahme, dass man so einen Stick überhaupt tamper-proof machen kann, würde ich schonmal direkt bestreiten wollen. Klar, billig ist so ein Angriff auf so eine Hardware dann nicht. Aber wer weiß, wie viel wert die Geheimnisse sind, die ihr mit so einem Gerät absichern wolltet?
Die andere, wichtigere Annahme ist, dass es mit 2FA nicht so schlimm ist, wenn der Rechner oder der Browser gehackt wird. Und das stimmt halt auch nur partiell.
Ohne 2FA ist es so, dass ein Eindringling alle eure gespeicherten Passwörter direkt auslesen und ausleiten kann. Das ist im Normalfall ein Totalschaden.
Mit 2FA ist es so, dass die Passwörter nicht reichen, weil man den 2. Faktor braucht. Allerdings kann ein Angreifer im Browser ja einfach warten, bis ich mich das nächste Mal mit 2FA anmelde, und dann mit meiner angemeldeten Session Unfug machen. Das ist von der Auswirkung her fast genau so schlimm.
Dann gibt es da auch wieder eine Convenience-Abwägung. Nimmt man ein Token, was man bloß einstecken muss? Oder eines, wo man zusätzlich einen Knopf drücken muss? Oder eines, wo man den Fingerabdruck geben muss, damit der freischaltet? Die meisten Leute werden fürchte ich ein Token nehmen, das man einfach einsteckt und dann stecken lassen kann, und dann hat man halt nicht viel gewonnen in dem Szenario, dass ein Hacker den Browser übernimmt.
Und so ist es wie so häufig in der Security. Ist eigentlich keine doofe Idee, aber bringt eben auch nicht so viel, wie einem das Marketing aufzuschwatzen versuchen wird.
Ich persönlich verkünde ja seit ein paar Jahren, dass Komplexität der Feind ist. Unter der Metrik sieht so ein Token recht komplex aus. Zwischen PC und dem Token gibt es ein Binärprotokoll, über das man möglicherweise die Software auf dem Token angreifen kann. Weiß ich nicht, ob das eine reelle Bedrohung ist, aber die Angriffsoberfläche gibt es jedenfalls schonmal, und vorher gab es die nicht. Mir persönlich stößt es sauer auf, dass die erstmal NOCH ein neues Binär-Serialisierungs-Verfahren "erfunden" haben dafür. Dabei kommt dieser Scheiß von Google, und die haben uns vorher schon völlig ohne Not ihre Protocol Buffers reingedrückt. Der Typ von Protocol Buffers ist inzwischen nicht mehr bei Google. Was hat er als erstes getan? Ihr werdet es geraten haben: Ein neues Binär-Serialisierungs-Verfahren gemacht ("Cap'n Proto").
Das sind die Leute, die uns vorher gesagt haben, ASN.1 sei gefährlich und wir sollen unsere Krypto lieber als JSON in Base64 machen (googelt man JWT, wenn euch das neu ist).
Also, zusammengefasst. Ist das Schuldabwälzung? Ja. Ganz klar. Wenn euer Account jetzt gehackt wird, dann habt ihr euer Token verbummelt und es ist eure Schuld.
Ist es nur Schuldabwälzung? Ich glaube nicht. Aber ob euch das tatsächlich was nützt, hängt davon ab, ob es wahrscheinlicher ist, dass ihr (im Vorher-Szenario) den Laptop verliert, oder (im Nachher-Szenario) das Token. Dass die Krypto von den Tokens ranzig ist, da müsst ihr euch glaube ich wenig Sorgen machen. Es kommt so gut wie nie vor, dass Krypto-Krams über die Krypto angegriffen wird. Ich würde mir eher Sorgen machen, dass mir ein Taschendieb das Token klaut, und weil das nichts wiegt, merke ich es nicht sofort. Und dann ist da am besten auf dem Fingerabdrucksensor noch ein rekonstruierbarer Fingerabdruck von mir drauf.
Im Übrigen: Wenn ihr euch für FIDO2 entscheidet, dann gilt natürlich dasselbe wie auch für andere Security-Produkte. Kann ich dem Hersteller trauen? Ist das Open Source? Kann ich das zur Not selbst patchen, wenn der Hersteller stirbt oder sich weigert? Wie sind die Recovery-Pfade, falls das Token verlorengeht? Fange ich mir damit eine Beweislastumkehr ein?
Update: Dies ist vielleicht die richtige Gelegenheit für den Hinweis, dass es auch außerhalb von 2FA Wege gibt, die Arbeitsumgebung sicherer zu machen. Es hat sich z.B. eingebürgert, sich bei Webseiten einzuloggen, und dann einfach eingeloggt zu bleiben. Während ihr bei einer Site eingeloggt seid, kann auch eine andere, böse Webseite auf allen anderen Webseiten, auf denen ihr noch eingeloggt seid, Daten abgreifen und eventuell sogar Transaktionen auslösen. Das ist ein häufiger Bug in Webseiten, gegen den es seit einer Weile ordentliche Browser-Gegenwehr gibt, die über "wir passen halt überall auf" hinausgeht. Aber das ist ein Risiko, das man sich gar nicht erst ans Bein binden muss. Ich jedenfalls halte mich auf Webseiten wenn möglich unangemeldet auf und logge mich nur kurz ein, wenn ich einen Kommentar abgeben will oder so. Und dann ist da noch die Frage, was man mit den Passwörtern macht. Hier gibt es ein weites Spektrum an Ratschlägen. Ein Master-Passwort im Browser vergeben hilft, falls einem der ausgeschaltete Rechner wegkommt. Hilft nicht, wenn man sich einen Trojaner einfängt oder einen Angreifer im Browser hat oder wenn der Rechner nur im Sleep-Modus war und nicht ganz ausgeschaltet, und da am Besten noch ein Browser offen war. Und für "der ausgeschaltete Laptop wird geklaut" habt ihr hoffentlich eh schon Full Disk Encryption aktiviert.
Meine Einschätzung ist im Moment, dass die Browser die Achillesferse der IT sind, und man immer sofort alle Security-Updates einspielen muss. Ich bin sogar soweit gegangen, meine Browser vom Beta-Channel zu beziehen, damit ich nicht nur einmal im Monat Bugfixes kriege.
Dass man nicht überall dasselbe Passwort nehmen soll, hat sich glaube ich schon herumgesprochen. Ich halte es so, dass ich Passwörter von einer Software zufällig generieren lasse. Dann weiß ich, dass die Passwörter ausreichend Entropie haben. Nachteil: Die Passwörter merkt man sich dann nicht mehr. Dafür gibt es Passwortmanager, oder man verlässt sich auf den Browser. Allerdings: Wer den Browser übernehmen kann, kommt auch an eure Passwörter, solange es da einen Automatismus gibt und ihr die nicht immer manuell rüberkopiert.
New hotness: Ransomware auf deiner Digitalkamera verschlüsselt deine Fotos.
Finde ich jetzt nicht weiter überraschend. Die Spezialexperten haben die Software auf so einer Kamera in ähnliche Komplexitätshöhen wie einen PC gehievt. Das ist im Moment ein Proof of Concept, und zwar einer Schlangenölbude. Ich würde mir da noch nicht viel Sorgen machen. Das Archiv mit den Fotos ist ja im Allgemeinen auf dem PC und der Infektionsvektor hier geht vom PC auf die Kamera. Wenn es so weit kommt, habt ihr eh schon Totalschaden.
Ach komm, Fefe, da kaufen wir eine Familienpackung abgelaufenes Schlangenöl, und dann wird das schon!1!! Und wenn wir trotzdem die Daten verlieren, heulen wir rum und stellen Forderungen an die Politik, die damit dann einen tollen Überwachungsstaat installiert!
Maintainers of the RubyGems package repository have yanked 18 malicious versions of 11 Ruby libraries that contained a backdoor mechanism and were caught inserting code that launched hidden cryptocurrency mining operations inside other people's Ruby projects.Das ist natürlich nicht die Schuld von Ruby, sondern davon, dass Entwickler heutzutage Libraries aus dem Internet automatisiert runterladen, einbinden und ausliefern. Das ist einfach mal generell eine schlechte Idee, aber gepaart mit der monströsen Komplexitätsexplosion in Code heutzutage ist es ein selbstverstärkendes Problem.Die Leute meckern immer rum, dass C und C++ keine Paketmanager haben. Ich halte das für einen Vorteil. Nicht nur einen Vorteil. Den Hauptvorteil von C und C++ im Moment. Von der Funktionalität her können C und C++ nichts, was nicht auch Rust oder Go könnten, bei einer grob vergleichbaren Performance am Ende. Oder wenn man auf Performance scheißt, dann wie Ruby, Python oder Javascript.
Der Vorteil von C++ im Moment ist, dass es eine Schwelle für das Einbinden von Libraries gibt. Das ist mit Kosten verbunden. Daher gucken Leute eher hin.
Ist nicht alles toll mit dem Modell. Eines der Hauptprobleme von C++-Code in Produktivsystemen ist, dass der Code veraltet ist und veraltete 3rd-Party-Komponenten einsetzt. Da muss mal was geschehen, keine Frage.
Aber habt ihr schonmal von einem C oder C++-Programm mit einem Kryptominer oder einer Backdoorkomponente gehört, wo der Autor auch nur versucht hätte, sich mit Paketen aus dem Internet rauszureden? Oder ein kompromittiertes Github-Paket, das es dann auch tatsächlich in irgendwelche ausgelieferte C++-Software geschafft hat?
Ich beobachte die aktuellen Bemühungen bei C++20 mit größter Sorge, sich da in Richtung NPM zu bewegen, um mehr Hipster anzuziehen. Leute, die auf sowas stehen, sind genau die, die man nicht in seinem Projekt haben will, weil das am Ende Kryptominer drin haben wird und der Verantwortliche wird nicht mal verstehen, wieso das seine Verantwortung gewesen wäre.
Sicherheitsforscher des Fraunhofer-Instituts für Sichere Informationstechnologie in Darmstadt haben in diesen VoIP-Telefonen insgesamt 40 teils gravierende Schwachstellen gefunden.Spoiler: Die Komplexität dieser Protokolle ist viel zu hoch.
Update: Einige Leser beklagen sich, dass die Lücken alle total triviale Anfängerfehler in deren Web-Komponenten sind. Niemand fand das ein schlechtes Zeichen, dass ein Telefon einen Webserver braucht.
CVE-2019-9511 “Data Dribble”: The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.CVE-2019-9513 “Resource Loop”: The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service.
Und noch ein Haufen dieser Art mehr. Welcher Vollpfosten hat sich denn bitte gedacht, dass es eine gute Idee ist, in einem Protokoll der anderen Seite diese Art von Freiheiten einzuräumen?! Das Protokoll ist schlicht ein Clusterfuck, und die einzige Implementation, die ich überhaupt erwägen würde, ist eine großflächig lobotomierte.Dass HTTP/2 jetzt Header-Kompression kann, löst ein Problem, dass wir uns völlig ohne Not selbst zugefügt haben. Niemand hat uns gezwungen, dass eine typische Webseite Hunderte von Requests lostreten muss. Mein Blog löst üblicherweise drei Requests aus. Und niemand hat uns gezwungen, so viele Cookies zu setzen, dass das ein Problem wird.
Das mit dem Multiplexing ist, wie ich hier schon ausführte, aus meiner Sicht eher ein Nachteil als ein Vorteil. Wenn die Leitung Paketverlust hat und stockt, dann bleibt bei HTTP/2 alles stehen, während bei HTTP/1 nur irgendein Inline-Bild stockt.
Und Pipelining geht auch in HTTP/1. Es trauen sich nur die meisten nicht zu benutzen, weil es da draußen angeblich irgendwelche kaputten Server gibt, die das nicht können. Ja, äh, na und? Die benutzt man dann halt nicht.
The Security Audit Working Group managed the audit over a four month time span.OK. Also das ist dann ziemlich katastrophal. Wenn die Auditoren nach vier Monaten Arbeit nur 37 Bugs gefunden haben, bei einem Projekt dieser Größe, dann heißt das im Allgemeinen, dass der Code so komplex und unverständlich war, dass man nicht entscheiden konnte, ob etwas ein Bug ist oder nicht, bis man da eine Woche dran herumgeforscht hat.Leider klingt das auch hier so:
Die Prüfer haben sich allerdings bei der Untersuchung auch nur auf acht Kernkomponenten der Software beschränkt und nur jene Probleme der Implementierung betrachtet, die "offensichtlich falsch" seien. Auch habe der Fokus der Untersuchung eher auf "Breite statt Tiefe" gelegen.Das klingt nach Nebelwand-Jargon für "wir haben nach Bugs gegreppt". Nach Bugs greppen macht man, wenn ein Projekt zu komplex ist, um es in der gegebenen Zeit sinnvoll zu verstehen zu versuchen. Bei vier Monaten Zeit könnt ihr euch ja selbst überlegen, wie krass überkomplex und unterverständlich das Projekt sein muss, damit Auditoren das machen. Der andere Indikator dafür ist "wir haben Fuzzing gemacht".
Die Auditoren kritisieren auch die hohe Komplexität von Kubernetes. Wir erinnern uns: Kubernetes war das Tool, das uns vor der Komplexität von Containern retten sollte. Das ist jetzt selber so komplex, dass es ein Rettungsprojekt braucht.
So wird Kubernetes als System mit "erheblicher Komplexität" bezeichnet. Ebenso seien die Konfiguration und das Deployment nicht trivial. Das wieder liege an "verwirrenden Standardeinstellungen, fehlenden Steuerungselementen und nur implizit definierten Security-Kontrollelementen".Das, meine Damen und Herren, ist das Ergebnis von agilen Methoden in der Softwareentwicklung. Genau das passiert, wenn man ein Projekt agil implementiert. Dann wird solange gefrickelt, bis den Use Case abdeckt, aber die interne Struktur ist Kraut und Rüben, Dokumentation "machen wir später" und sowas wie Codestruktur gibt es nicht oder nur zufällig.[…] So habe die riesige Codebasis große Teile mit nur "minimaler Dokumentation" sowie zahlreiche externe Abhängigkeiten. Außerdem gebe es viele Stellen, an denen bestimmte Programmlogik einfach reimplementiert wird.
Mir ist ja echt schleierhaft, wieso immer noch Leute auf diesen Agil-Hokuspokus reinfallen. Ich hatte gehofft, die Zeit von Wunderheilern und anderem Aberglauben ist vorbei. (Danke, Marian)
Dem würde ich generell widersprechen wollen. Doch, ist es. Das ist genau die Nummer Eins Gefahr, die von der steigenden Komplexität ausgeht. Gerade bei vlc, wenn man das mal selber baut und startet, und mal die Shared Libraries zählt, die das Ding reinlutscht, dann ist völlig klar, dass das Risiko enorm zugenommen hat, bis hin zur offensichtlichen Nicht-Beherrschbarkeit. Klar, dafür hängt da auch die Funktionalität von ab. Will ich nicht bestreiten. Aber die Laxheit, mit der Leute fremde Libraries reinladen, und dann so tun, als sei das nicht ihr Problem, wenn die räudig sind, die ärgert mich schon lange.
Auf der andere Seite ist das Problem in libebml zu dem Zeitpunkt seit über einem Jahr bekannt und upstream gefixt gewesen, aber die Knödel von Ubuntu haben es verpeilt, den Fix auszuliefern. Insofern bin ich dann doch auf der Seite von VLC in dieser Sache, denn das Sicherheitsloch war in Ubuntu, nicht VLC.
Die Geschichte ging aber noch weiter. Die VLC-Leute berichten, dass der Fuzzy, der die Lücke gefunden hat, direkt ein CVE beantragt und bekommen hat, ohne dass jemand auf dem Weg es für nötig oder höflich gefunden hätte, bei VLC mal nachzufragen. Nicht nur das: Der CERT-Bund, immerhin eine Regierungsorganisation Deutschlands, hat ein Advisory veröffentlicht, auch ohne bei VLC mal nachzufragen.
Da wird die Sache jetzt ein bisschen weniger klar. Denn VLC betreibt einen offenen Bugtracker, aber möchte gerne Security-Sachen per Mail vorab gemeldet kriegen, damit die mit Priorität bearbeitet werden können. Das will ich mal der Klarheit halber umformulieren: VLC hat einen Bugtracker, den sie als sedimentäre Datenhalde betreiben, und wo sie längst die Kontrolle über die Flut an Bugs verloren haben, daher haben sie eine Parallelgesellschaft in Form von einem Security-Bug-Mailverteiler geschaffen. Das, meine lieben VLC-Leute, habe ihr euch vollumfänglich selbst zuzuschreiben. Euer Bugtracker ist öffentlich, und das ist gut so. Dort hatte der Bug-Finder einen Bug aufgemacht. Den habt ihr mit den anderen Bugs in der ewigen Buglavine verpennt. Als Reporter ist es völlig OK, VLC nicht "Bescheid" zu sagen, wenn es einen offenen Bugtracker gibt. Denn dafür gibt es den. Und dafür ist der offen. Damit man sich dort über Bugs informieren kann. Dass ihr jetzt von der Presse verlangt, dass sie die Kosten für euer verkacktes Bugtracking trägt, ist absurd. DAS habt ihr euch echt selbst zuzuschreiben.
Und jetzt hört auf zu heulen, fixt eure Bugs, und haltet die andere Wange hin. Mit eurem Fake-News-Geschreie macht ihr die Sache nur noch schlechter.
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.
Ich finde ja schon die Kernel-Werkzeuge fürs Sandboxing zu komplex, als dass man davon ausgehen kann, dass sie richtig verwendet werden in der Praxis. Aber was Docker oder gar Kubernetes da nochmal an völlig überflüssigen Komplexitäts-Luftschlössern oben drauf packen, das ist echt nicht zu rechtfertigen.
Wiedem auch sei: Die sind weiter gekommen als alle vor ihnen. Und versuchen auch praxisrelevant zu ein, indem nicht nur eine Hochsprachen-Implementation verifiziert wird, sondern auch die plattformspezifischen Assembler-Implementationen.
Sie haben auch eine verifizierte TLS-Library, aber die ist in F# bzw. F* und da ist nicht klar, wie performant die ist und wie man die in existierende Projekte eingebunden kriegt. Dennoch: Ein großer Schritt vorwärts!
An attacker gained access to the servers hosting Matrix.org. The intruder had access to the production databases, potentially giving them access to unencrypted message data, password hashes and access tokens. As a precaution, if you're a matrix.org user you should change your password now.Das war wohl ein netter Hacker, der parallel schön Tickets aufgemacht hat.Der Bug war nicht in deren Matrix-Code, sondern in deren Drumherum-Scheiß, wo sie einen Jenkins hatten, der per SSH erreichbar war, und da lagen zu allem Überfluss dann auch noch die GPG-Keys herum, mit denen sie ihre Debian-Pakete signieren. Das lässt keine direkten Rückschlüsse auf die Codequalität zu, aber das ist ein weiterer Fall von "Projekt von seiner eigenen Devops-Komplexität erschlagen". Und wenn die da schon so schlampen, dann fragt man sich schon, ob man dem Rest trauen kann. Auf der Kiste, auf der er sich einloggen konnte, war gerade jemand anderes mit SSH Agent Forwarding eingelogt, der Root-Zugriff anderswo hatte. Ganz großes Kino.
Es gibt in Deutschland C++ Users Groups, aber offenbar ist keine von denen ambitioniert genug, ihre Vorträge mal auf Youtube zu packen. Das ist erstaunlich, denn es gibt diverse mehr oder weniger hochkarätige und überregional bekannte C++-Vortragende aus Deutschland, die auf Konferenzen im Ausland sprechen.
Oder vielleicht bin ich nur zu doof zum Suchen :-)
Die Developer-Konferenzen, die es im deutschsprachigen Raum so gibt, scheinen alle eine deutlich kommerziellere Ausrichtung zu haben. Vergleichsweise teure Eintrittspreise, und dann aber Vorträge, die nicht inhaltlich weiterbringen, oder Debattenbeiträge für wichtige Diskussionen liefern, sondern eher so "die Neuigkeiten in C++17" oder so Hype-Porn, wo Leute total begeistert irgendein Wundermittelchen anpreisen, seien es jetzt Kommerz-Tools oder irgendwas mit agile.
Was ich übrigens auch echt furchtbar finde, ist wenn Deutsche im Ausland Grusel-"Englisch" vortragen. Mein Englisch ist auch akzentbehaftet, aber come on, versucht es wenigstens! Bei C++ Russia kriegt man verständlicheres Englisch als bei so einigen deutschen Vortragenden!
Oder so Leute, die dann nach 90% der Zeit merken, dass sie erst 30% der Einleitung durch haben. Übt ihr eure Vorträge vorher nicht zuhause vor dem Spiegel oder Testpublikum!?
Ich bin auch inhaltlich ein bisschen am Verzweifeln mit C++, weil die so überhaupt keine Grenzen zu kennen scheinen bezüglich der Komplexität der Sprache. Ein statisch gegen LLVM gelinktes clang reißt unter Linux die 100 MB Grenze für ein Binary. Das Ausmaß an Cleverness und Hirnschmalz im C++-Compiler heutzutage fühlt sich an, als würde man mit einer KI interagieren. Und der Trend geht weiter in die Richtung, per Ausweitung dessen, was man per constexpr zur Compile-Zeit im Compiler an Code ausführen kann. Auf der anderen Seite scheint mir C++ gerade den Anschluss an Go und Rust zu verlieren. Die Multicore-Elemente der Sprache sind alle Parallelism, nicht Concurrency. So triviale Primitive wie Channels oder effiziente Fan-In- und Fan-Out-Mechanismen fehlen. Man kann sein Problem gar nicht concurrent ausdrücken, man verliert sich stattdessen in Details der Parallelism-Implementation. Wer den Unterschied nicht kennt, kann es sich hier von Rob Pike erklären lassen. In der Praxis sieht man dann entweder Contention-Hotspots, weil jemand eine Queue mit einem Mutex drum baut, oder man sieht Leute mit Atomics herumpfuschen und dann Corner Cases verkacken. Wenn ich das richtig sehe, ist auch C++20 an der Stelle noch unbekleidet. Ist mir ein Rätsel. Haben die alle Angst, dass normale Leute effizienten Code schreiben könnten, und ihr eigener Code dann nicht mehr so besonders aussieht? Oder was!?
Update: Mehrere Leser haben auf die Meeting C++ verwiesen. Deren Videos hatte ich gesehen, aber irgendwie dachte ich, die sei in Budapest gewesen. Muss ich falsch verstanden haben. Die sind insofern gut, dass sie ihre Videos kostenlos bei Youtube hochladen und auch internationale Vortragende einladen, aber irgendwie hat mich das inhaltlich nicht so vom Hocker gehauen. Da war irgendwie kein Vortrag, der so richtig was Neues hatte, fand ich. Alles schon woanders gehört, oder halt so Zusammenfassungs-Kram (wo ich immer finde: überlasst das lieber cppreference.com, außer ihr habt etwas wirklich Tolles).
Update: Leserbrief:
die Münchner C++ User Group hat einen Youtube-Channel:
https://www.youtube.com/channel/UCf3tX0nf8EFIwmgQBH6PIGw
Die Audio-Qualität könnte (deutlich) besser sein, aber inhaltlich reicht die Spannbreite von eher oberflächlichen Lightning-Talks bis hin Vorträgen von Prominenten.
Aus gegebenem Anlass: Für München sucht die Gruppe regelmäßig Locations wo mal mehr als 300 Leute reingehen. Der Andrang zu den Meetings ist oft größer als die Resourcen. Würdest Du da einen Aufruf machen?
In Bochum gibt es die embo++, die auch einen Channel haben:
Hat sich am Ende doch Open Source durchgesetzt im Browsermarkt auf Windows. Wer hätte das gedacht.
Hoffen wir mal, dass Microsofts Präsenz im Chromium-Projekt dazu führt, Googles Dominanz dort zurückzufahren. Google macht mit Chrome gerade genau dasselbe, wofür wir früher Microsoft gehasst haben. Entscheidungen nach Gutsherrenart, Einführen von "Features", anch denen nie jemand gefragt hat, Entscheiden über den Kopf der User hinweg. Ich bin daher seit Jahren Firefox-User, auch auf dem Smartphone. Leider ist der Marktanteil von Firefox gerade unter 10% gefallen — auf dem Desktop. Insgesamt ist es noch weniger, da die Plattformbetreiber alle alles in ihrer Macht stehende tun, um Firefox auf ihren Plattformen zu behindern, damit es ihrem Durchmarsch gegen die User nicht im Wege steht. Leider hat Firefox auch gefühlt jede Gelegenheit genutzt, ihren Usern das Gefühl zu geben, bei ihnen sei das alles dasselbe in Grün. Ich sagen nur: Werbung auf dem Startbildschirm, Tonnen von Tracking-Bullshit, und jetzt auch noch "Pocket".
Und dieser ganze dauernde Ärger verhindert dann, dass man an dem Rest Spaß hat. Mozilla macht ja eine Menge coole Scheiße, so ist das nicht. Rust zum Beispiel ist ein Lichtblick für die ganze Software-Entwicklungs-Branche. Es ist ein Wunder, dass das so weit gekommen ist, wie es ist. Da hätte ich dagegen gewettet, wenn mich jemand gefragt hätte.
Und es kann nicht darüber hinwegtäuschen, dass Firefox es nicht packt, unter Linux Hardware-Video-Playback hinzukriegen. Das verdoppelt mal eben den Stromverbrauch. Kriegt auch Chrome nicht hin unter Linux, übrigens. Aber wisst ihr, wer das hinkriegt? Ja richtig! Edge!
Update: Habt ihr eigentlich schon gehört? QUIC soll HTTP/3 werden! Ein weiteres beschissenes Google-Komplexitäts-Monster, nach dem keiner gefragt hat. Bei Microsoft haben die Leute wenigstens noch gemerkt, dass sie mit Microsoft Network gearbeitet haben und nicht mit dem Internet. Bei Google fahren alle Chrome und benutzen Google-Infrastruktur mit Google-Protokollen in der Google-Cloud, am besten noch über Google Fiber.
a malicious user could use the Kubernetes API server to connect to a backend server to send arbitrary requests, authenticated by the API server's TLS credentials.The API server is the main management entity in Kubernetes. It talks to the distributed storage controller etcd and to kublets, the agents overseeing each node in a cluster of software containers.
Das ist ein Container-Ausbruch-Szenario. Kubernetes ist ja seit Tag 1 Opfer seiner eigenen unnötigen Komplexität. Die Prämisse ist ja eigentlich relativ einfach. Man beschreibt ein System aus mehreren Containern deklarativ und ein Tool baut das dann auf. Ein Tool, um einen Container zu starten, geht in deutlich unter 100k statisches Binary. Ein Tool, um aus einer Beschreibung ein Image zu bauen, und sich die Bestandteile aus dem Internet zu ziehen, ist sagen wir mal 2 MB, da ist dann auch ein fettes OpenSSL mit drin.Aber Kubernetes hat da noch eine monströse Management-Infrastruktur draufgepackt, und alles riesige Go-Binaries natürlich. Ich habe hier gerade mal das aktuelle Kubernetes mit dem aktuellen Go gebaut -- da fallen 1.8 GB Binaries raus. Ja, Gigabytes! Kein Typo! Das ist völlig absurd. Und natürlich geht ohne die Management-Infrastruktur der Rest nicht. Aus meiner Sicht ein Architektur-Fuckup sondergleichen. Auf der anderen Seite tickt Docker ja genau so. Da muss man auch die ganze Zeit einen Docker-Daemon laufen haben. Was die sich dabei wohl gedacht haben? Ich glaube: Der läuft da hauptsächlich aus Branding-Gründen. Damit die Leute den Eindruck haben, Container sei eine hochkomplexe Docker-Tech, keine vergleichsweise einfache Linux-Kernel-Tech.
Das ist die eine Sache, die mir am meisten schlaflose Nächte bereitet. Wie wir sorglos und ohne groß nachzudenken immer mehr Komplexität auftürmen. Wir sind jetzt schon in einer Welt, wo praktisch jedes Problem als "Softwareproblem" wegerklärt werden kann, ohne dass irgendjemand verantwortlich ist oder gar mit negativen Konsequenzen zu rechnen hätte. Und der Trend ist gerade dabei, sich noch zu beschleunigen.
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.
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.
Facebook verliert Milliarden an Datensätzen, TLS benutzt bis heute niemand mit Client Certs, CAs failen links und rechts, … ach weißte, das kriegen die schon wieder hin. Machen die ein Update, ist wieder gut.
PGP macht nicht mal einen Fehler sondern wird nur schlecht integriert, und alle so: PGP IST TOT!!1!
Ich krieg echt Bluthochdruck. Seit Jahren schreiben Heise und Co PGP tot, weil das ja angeblich zu schwierig zu benutzen sei. Stattdessen empfehlen sie Signal, wo man selbst als Experte nicht viel Chancen hat, einen Man-in-the-Middle-Angriff zu erkennen. Irgendwo steht kleingedruckt, dass sich ein Key automatisch geändert hat. Nachdem sich Experten beschwert hatten. JA SUPER. Oh und Signal hat zentralisierte Infrastruktur. JA SUPER!!1! Genau die Plattform für internationales Dissidententum!
Heise, ich schlage vor, dass ihr mal ein paar Jahre den Ball flach haltet in Sachen Krypto. Das geht echt gar nicht.
Hier mal meine Ansage zum Thema Krypto-Usability: Traut keiner Software, die Krypto so wegabstrahiert, dass die Komplexität nicht mehr den User erreicht, oder die euch den Quellcode nicht zeigen wollen. Da werden immer irgendwelche faulen Kompromisse gemacht.
PGP ist nicht schwierig zu benutzen. Wenn Heise nicht seit Jahren den Leuten einreden würde, dass PGP zu schwierig ist, hätten wir vielleicht die doppelte Abdeckung. Auto oder Wohnungstür aufschließen ist auch ein extra Schritt, und wenn man den Schlüssel verliert, hat man Mehraufwand. Das hält auch niemanden davon ab, Schlösser zu verbauen.
Update: Ich finde das besonders tragisch, weil Heise jahrelang auf Veranstaltungen PGP-Keysigning-Parties gemacht hat. Die waren mal die Guten.
Jetzt hatte jemand die Idee, man könnte ja den starren Kernel-Filtercode durch BPF ersetzen. Es stellt sich nämlich raus, dass es Netzwerkkarten gibt, die BPF unterstützen, d.h. da kann man dann seinen Firewall-Filter hochladen und dann muss der Host nicht mehr involviert werden.
Auf der anderen Seite ist das halt noch mal eine Schicht mehr Komplexität. Und man muss den BPF-Code im Userspace aus den Regeln generieren, d.h. man braucht neues Tooling.
Update: Es gibt übrigens noch mehr solche Vorstöße, jetzt nicht mit BPF aber ähnlicher Natur. Google hat kürzlich "gVisor" vorgestellt, das ist auch eine ganz doll schlechte Idee. Das ist von der Idee her sowas wie User Mode Linux, falls ihr das kennt. Ein "Kernel", der aber in Wirklichkeit ein Userspace-Prozess ist, der andere Prozesse (in diesem Fall einen Docker-Container) laufen lässt und deren Syscalls emuliert. Also nicht durchreicht sondern nachbaut. Im User Space. In Go. Wenig überraschend verlieren sie viele Worte über die Features und keine Worte über die Performanceeinbußen. Und noch weniger Worte darüber, wieso wir ihren Go-Code mehr trauen sollten als dem jahrzehntelang abgehangenen und durchauditierten Kernel-Code.
Ich als oller Verschwörungsblogger stelle mir gerade vor, wie Intel sich in einer gammeligen Kaschemme mit schattigen Spooks trifft, die ihnen ihre Kumpels aus der US-Regierung genannt haben, einen Wanzen-Sweep macht und dann einen Blankoscheck auf den Tisch legt.
Aus meiner Sicht ist keine dieser angeblichen Lücken besonders gruselig. Keine davon erlaubt Elevation of Privileges von User Space in den Kernel (wie bei Meltdown). Das sind hauptsächlich Angriffe gegen Schlangenöl-Bullshit-Mist, den man eh nicht in seinem Prozessor haben will, weil es bloß unnötig die Komplexität erhöht und eh nicht klar ist, ob man dem jetzt trauen kann oder nicht.
Ich würde mir da jetzt keine großen Sorgen machen, wenn ich einen Ryzen hätte. Was ich im Moment noch nicht habe. Werde ich aber demnächst, denke ich. Alleine um die Meltdown-Fix-Verzögerung loszuwerden.
Update: CNET sagt, dass die "Forscher" AMD nur 24h Zeit gaben vor der Publikation. Ja, äh, nee, das riecht eher wie eine Schutzgelderpressung als wie eine legitime Veröffentlichung.
Update: Auf Reddit haben Leute noch herausgefunden, dass die "Büroräume" in deren Video aus Stock Footage kamen. Die Lektüre vom Disclaimer lohnt auch. Im Kleingedruckten stehen so Dinge wie dass sie sich vorbehalten, an der Börse Profit von ihren Analysen zu machen, und dass es sich alles bloß um ihre Meinung und nicht um Faktenbehauptungen handele. Ja nee klar.
Unter dem Namen Runtime Application Self-Protection (RAP) versprechen viele Anbieter von Sicherheitsdiensten ihren Kunden neue Schutzfunktionen, die Angriffe auf ihre Anwendungen zur Laufzeit abwehren können.Yeah! Wir haben so viel Komplexität aufgestapelt, dass wir nicht mehr in der Lage sind, auch nur grundlegende Aussagen über die Software zu treffen, geschweige denn sie sicher zu machen. Also tun wir … MEHR Komplexität auf den Haufen!
Faith-Based Programming!
Bedroht sind nur Nutzer, die die VPN-Funktion aktiviert haben. Ist das der Fall, müssten Angreifer Cisco zufolge lediglich präparierte XML-Pakete an das webvpn-configured-Interface schicken, um Speicherfehler auszulösen. Anschließend erfolgt ein Reload des Gerätes oder Angreifer könnten sogar die volle Kontrolle übernehmen.Schon toll, so Security-Lösungen. Wie die einen immer vor Angreifern schützen!
Aber mir glaubt ja immer keiner, wenn ich sage, dass man Komplexität senken und Angriffsoberfläche minimieren soll. You had me at XML.
Hans Hübner wird mal konkret, und er hat völlig Recht. Gut, Virtual Memory würde ich nicht generell verbieten wollen, Paging hat schon Vorteile. Memory Mapping von Datenbank oder I/O ist schon gut, das will man schon haben.
Aber die Frage stellt sich aus meinen Augen wirklich: Wieso konsolidieren wir immer mehr Kram auf immer weniger Rechner? Wieso stellen wir nicht einfach pro Dingens einen Rechner hin?
Ich kann euch sagen warum: Weil man dann lauter kleine CPUs kaufen würde, und an denen verdient keiner war. Die fette Profitmarge ist bei den großen CPUs. Also hat die Werbung und die Fachpresse die Entscheider überzeugt, dass man erst was wert ist, wenn man einen 512-Core MomomoMONSTER-Rechner im RZ hat. Und damit der sich amortisiert, muss man da hunderte von Aufgaben drauf machen, und dann halt mit Containern oder VMs "trennen". Was dann zu Stress führt, wie wir ihn gerade sehen.
Und ironischerweise im neuen DNSSEC-Support des DNS-Clients bei Windows. Auf mich hört ja immer keiner, wenn ich sage, dass Komplexität der Feind ist. Ach komm, das ist doch ein Security-Feature! Da kloppen wir noch ein paar metrische Tonnen Code drum herum, ist doch für die Security!1!!
Keynotes sind ja eher nicht so mein Gebiet, ich mache lieber Technik oder Entertainment. Keynotes sind überhaupt eine sehr merkwürdige Art des Vortrags. Ich habe mir mal gezielt ein paar Keynotes angeguckt, um zu sehen, was da von mir erwartet wird, und das ist ein ganz eigenes Genre.
Ca ein Viertel sind so "I have a dream"-Visionen, auch partiell "We shall overcome" (hier ist ein Problem, aber wir schaffen das!1!!), die Hälfte sind so Marketing-Blablah-Geschichten und Selbstbeweihräucherung der Branche, und ein Viertel sind so "wir werden alle störben"-Doomsday-Warnungen.
Das ist alles nicht so mein Metier. Ich bin eher ein Freund von Gedankengängen mit Erkenntnisgewinn am Ende.
Wenn man sich populäre TED-Talks anguckt, dann sind die Gedankengänge von der Komplexität her immer auffällig auf Ernie-und-Bert-Niveau. Ich glaube, dass das System hat. Der Zuschauer wird nicht überfordert und kann sich bestätigen, dass er zu den oberen 50% gehört, weil er das alles schon vorher wusste. Ich habe beobachtet, dass auch immer die Vortragenden am populärsten sind, die non-threatening sind, und zwar im körperlichen wie auch im übertragenen Sinn. Wo man keine Angst haben muss, dass er Chef das sieht und sich denkt: Ich feuer meine Leute und stell lieber den ein.
Ach naja. Ich mach mir da immer viel zu viel Sorgen. Publikumsbeschimpfung geht immer. :-)
Update: Die Veranstaltung stellt sich gerade als im Wesentlichen eine Schlangenöl-Verkaufsevent heraus. Ich bin ja immer wieder fasziniert, wie die Leute "Ransomware zieht dir Geld aus der Tasche" klar unmoralisch finden, aber "Schlangenölbranche zieht dir Geld aus der Tasche" ist halt Kapitalismus.
Ein mir neuer Aspekt, der mich gerade echt flasht, ist dass die Sales-Drohnen jetzt ernsthaft mit folgender Argumentation rumlaufen: Durch die EU-Datenschutzverordnung drohen ja Strafen bis zu 4% des Jahresumsatzes. Also werden bestimmt auch die Malware-Leute anfangen, ihre Schutzgelder entsprechend hochzudrehen. Also sollten Sie das als drohenden Schaden sehen. Also müssen Sie jetzt auch soviel (oder zumindest "entsprechend mehr" Geld für unser Schlangenöl ausgeben.
Wie geil ist DAS denn?!
Update: Oh und meine Keynote lief glaube ich ganz gut. Falls jemand wissen will, worum es ging: Ich erkläre, was Externalisierung von Kosten ist (Umweltverschmutzung, Atommüll, Bankenskandal), dass das gemeinhin als unmoralisch und verwerflich gesehen wird, und stelle dann die These in den Raum, dass das Verbreiten von schlechter Software auch Externalisierung von Kosten ist. Dann erkläre ich, wie Security-Bugs auch Bugs sind, und erzähle die Anekdote, wie ich herausfand, dass Format String Bugs gefährlich sind, und in Panik meine Quellen durchging, ob ich das auch mal falsch gemacht habe. Hatte ich nicht. Weil das vor Bekanntwerden der Security-Implikationen auch schon ein Bug ist, und ich meinen Code sorgfältig geschrieben hatte. Security-Probleme sind also Pfusch, schlussfolgere ich an der Stelle.
Dann geht es mir um die Frage, wieso wir Pfusch dulden, und beobachte, dass das immer ökonomische Argumente sind. Als letzten Teil versuche ich, das ökonomische Argument für Pfusch zu demolieren. Erstens ist der Vergleich einer billigen Pfusch-Lösung mit einer ordentlichen, sicheren Lösung unlauter, weil nur die eine die Anforderungen erfüllt. Zweitens, so habe ich bisher beobachtet, kostet das gar nicht mehr, etwas ordentlich zu machen, weil einem das noch vor Produktlaunch auf die Füße fällt, wenn man bei auch nur einem der Module gepfuscht hat. Da würde ich echt gerne mal ein paar wissenschaftliche Untersuchungen zu sehen, inwieweit man das nachmessen kann. Vielleicht irre ich ja.
Update: Jahresumsatz, nicht -profit. Mach ich jedesmal falsch, weil es so ungeheuerlich ist :-)
Also … wir haben es verkackt, aber trotzdem verkauft gekriegt, daher werte ich das mal als Gewinn. :-)
Und zwar möchte ich gerne wissen, wieso das aus eurer Sicht mit IT-Security nichts wird. Insbesondere interessieren mich dabei die Meinungen von Entwicklern, Testern und Management. Schreibt also bitte dran, aus welcher Perspektive eure Meinung ist.
Die offensichtlichen Antworten will ich mal gleich abräumen, um uns allen Arbeit zu sparen:
Wenn ihr das glaubt, ist das immer noch interessant für die Verhältnisse der Erklärungen innerhalb der jeweiligen Sparten. Aber eigentlich will ich gar nicht so sehr wissen, wer wie häufig was glaubt, sondern ob es möglicherweise Erklärungen gibt, die ich noch gar nicht auf dem Radar hatte. Ich will euch mal ein Beispiel geben, das mir neulich mein Kumpel Kris erzählt hat. Der meinte, dass Menschen evolutionär auf Gradienten lernen. Man geht geradeaus, bis man das Gefühl hat, man ist zu weit gegangen, dann geht man ein Stück zurück. Man streckt die Hand aus, merkt, dass es in die Richtung heiß wird, also geht man nicht weiter in die Richtung. Security ist aber kein Gradient. Du gehst zu weit, und du merkst es a) nicht sofort und b) bist du dann sofort tot und kannst nicht mehr einen Schritt zurück gehen. Kris verglich das mit Fahrradfahrern im Straßenverkehr, wenn Autos schneller als 30 fahren. Da hat der Fahrradfahrer auch keine Gelegenheit mehr, aus Fehlern zu lernen, wenn es zu einer Kollision kommt.
Ich würde diesen Gedankengang noch auf Komplexität ausweiten wollen. Komplexität fühlt sich wie ein Gradient an, aber Komplexität kann man nicht zurückrollen, wenn man merkt, dass man die Kontrolle verloren hat.
Also bitte, hier nochmal in Kurzform die Fragestellung, für die ich um eure Meinung bitte: Wieso fühlt es sich so an, obwohl wir immer mehr in Security investieren, dass immer mehr Leute gehackt werden?
Update: Eine Zusatzfrage noch. Häufig hört man als Ausrede, dass das ja teurer wird, wenn man es sicher macht. Glaubt ihr das auch? Wenn ja, warum? Gibt es da Zahlen für? Ich würde gerne wissen, wo das herkommt. Ich halte das für eine völlig transparente Schutzbehauptung. Hersteller wird beim Verkacken erwischt? "Sicher hätten wir auch gekonnt, aber wäre 200% teurer gewesen!1!!" Oh ach so, na dann ... *abwink* oder so
Update: Die ersten 100 Einsendungen waren praktisch unisono der Meinung, dass Security schlechter wird, weil niemand die Methoden anwendet. Nicht weil die Methoden nicht funktionieren. Als Hauptgründe werden genannt, dass Firmen das Geld nicht ausgeben wollen, dass die Teams gar nicht wissen, was sie tun müssten, dass Aufgaben an Outsourcer rausgegeben werden, die gar keinen Anreiz haben, Qualität zu machen, etc. Das ist natürlich auch ein Ergebnis, aber stimmt das wirklich? Gerade für mich als Security-Fuzzi ist die Frage wichtig, ob nicht vielleicht unsere Methoden Schuld sind. Weil sie zu teuer sind, weil sie nicht funktionieren, weil sie nur Theater sind. Ein Teil der Ansätze, bei denen das aus meiner Sicht offensichtlich so ist, beschimpfe ich ja hier auch immer als Schlangenöl.
Erstens: Gerade im Bahnumfeld gibt es harte Zertifizierungs-Zwänge, und eine Zertifizierung zertifiziert halt immer einen genauen Versionsstrang und da kann man dann halt nichts machen. Oh, und: Zertifizierung ist teuer und dauert Monate.
Tja, dann müssen wir da eben ansetzen. Dinge, die häufiger gepatcht werden müssen, als man nachzertifizieren kann, können dann halt kein Zertifikat kriegen. Wir müssen endlich Security als Teil von Safety betrachten.
Und zweitens: Das Patch Management der Hersteller ist auch Scheiße. Leute schrieben, dass Windows Update gerne mal hängt, das man tage nach dem Patchday noch nichts angeboten gekriegt hat, usw. Das stimmt alles und ist eine Riesensauerei. Insbesondere da man heute davon ausgehen muss, dass es unter 24h dauert nach der Verfügbarkeit von einem Patch, bis der Exploit dazu reverse engineered wurde. Wenn also das Patch-Verteilen länger als 24h dauert, ist es zu langsam. Das ist eine harte Grenze. Ich würde sogar "die Welt muss die Patches innerhalb von 12h haben" sagen. Da muss Microsoft halt in bessere CDN-Infrastruktur investieren, wenn sie die Load nicht hinkriegen.
Drittens: Neuronale Netze sind ja gar nicht so undebugbar. Ich zitiere:
die Aussage, dass wir nicht verstehen wie Neuronale Netze, Reinforcement Learning etc. ihre "Magie" wirken stimmt nicht so absolut. Das Feld ist zwar gerade noch im kommen, aber Paper wie dieses hier (was versucht CNNs auf Wavelet Filterbanken zurückzuführen), dieses (was ein RNN analysiert und dort ein "Sentiment Neuron" findet) und die bereits von dir verlinkten adversarial input paper zeigen, dass wir es eben doch verstehen können. Das verstehen und erklären warum die Modelle funktionieren ist ein aktives Forschungsfeld, und die zugrunde liegende Mathematik wird immer verstanden.Richtiger wäre es also zu sagen, dass die ganzen Machine Learning Ansätze instant-technical debt oder instant bloat sind. Wenn in einer Firma oder einem Software System nicht auf einen guten Prozess geachtet wird, ist es sehr schnell unmöglich (oder zumindest sehr teuer) den Code und alle Interaktionen zu verstehen. Vor allem bei den ganzen Compile-to-X Sprachen, dynamisch getypten Sprachen (NodeJS :-/) und Distributed Systems ist man von der Komplexität her schnell bei dem eines DNN. Der Unterschied ist, dass zumindest am Anfang jemand das ganze designed hat damit es läuft, und das organische im Nachhinein kommt wenn sich die Aufgabe verändert. Bei NNs ist das erschaffen organisch, das verändern mit der Aufgabe ist eingebaut und es ist nicht *zwingend* notwendig es zu verstehen, weil man ja eh nur mit statistischen Garantien arbeitet. Daher wird auf die Analyse WARUM und WIE dein System funktioniert meist verzichtet.
Das Problem mit ML ist also dasselbe wie mit Software Pfuscherei im allgemeinen: Qualitätssicherung macht kein Geld, man kann sich noch besser mit "Act of God" artigen Ausflüchten vor Verantwortung drücken und daher gibt es keinen Anreiz dafür sicherzustellen, dass man weiß was da passiert.
Viel gefährlicher finde ich aber (abgesehen von der Tatsache dass AI das Missverhältnis zwischen Kapital und Labor noch mehr zum Kapital kippt), dass wir noch kein Äquivalent zur GPL für ML haben. Bei normaler Software kann dank RMS und Linus wenigstens 99% der Zeit den Code überprüfen, selber fixen und mich zum Teil auf eine Community verlassen. Bei ML Modellen ist die Software vielleicht noch MIT, die Architektur VIELLEICHT noch dokumentiert, aber weder die Hyperparameter, die genauen Tainingsdaten noch die "ah Sepp, mach da doch noch diese L2 norm drauf" gegeben. Reproduzierbarkeit, Überprüfbarkeit, Identifizierbarkeit? Nope. Es kommt jetzt zwar wenigstens langsam pretraining in den Mainstream (was die Modelle modifizierbar macht) und Google hat vor kurzem einen underrated Paukenschlag mit ihrem Privacy respecting Distibuted Training rausgebracht, der es vlt. möglich macht dezentralisierte Datensätze unter einer AGPL style Lizenz zu organisieren, aber ich sehe da noch einen harten Kampf auf uns zukommen. Tivoization wird nix dagegen.
Hier ein Gedanke zum Vorschlag Software-Anbieter für den Schaden, der durch Sicherheitslücken entsteht haften zu lassen.Das ist in der Tat die Achillesferse bei dem Vorschlag mit der Produkthaftung. Fällt jemandem ein 3. Weg ein? Vielleicht wie in den USA, dass man sich dann halt dem Risiko von Millionenklagen aussetzt, selbst wenn man alles richtig gemacht hat? Ist auch nichts.Das kann den Software Markt schnell in Richtung Oligopol Markt verändern.
Märkte mit hohen Haftungsrisiken, tendieren dazu große Firmen zu begünstigen und kleine zu verdrängen. Ich kann das hier in der Pharma-Industrie ganz gut sehen. Für die Luftfahrt-Industrie gilt aber das gleiche.
Haftung für komplexe Produkte und Prozesse führt nicht etwa nur zur Perfektion des Produktes, wie von Dir angenommen, sondern auch zur Abwehr der Haftung mittels Versicherung und Regulierung.Stell Dir einfach mal vor, Du müsstest Software so anbieten wie die Pharma Industrie ihre Medikamente.
Es gäbe eine Aufsichtsbehörde, die festlegt, wer, mit welcher Bullshit-Zertifizierung, nach welchem Entwicklungsmodell, Software schreiben darf. Das ganze wird natürlich festgeschrieben und nur alle zehn Jahre aktualisiert.
Es gäbe regelmäßige Inspektionen, in denen Checklisten ausgefüllt würden ob nun dieses Merkmal guter Entwicklung oder jenes Sicherheits-Feature vorhanden und dokumentiert (!) ist.Bisher kann jemand der fähig ist, eine Software-Firma aufmachen und ein Produkt verkaufen. Egal wie gut oder wie sicher. Ich behaupte, die meisten Kunden wissen das. Kaum einen stört das.
Sobald Du die Haftung z.B. per Gesetz einführst, bräuchten Software Firmen eine Versicherung (wer würde da sonst kaufen, wenn das Kapital der Firma nicht reicht um Schäden zu ersetzen?). Und sie brauchen tausend "qualitäts"-Zertifikate. Ist jetzt schon so, wenn die für Krankenhäuser oder eben die Pharma Industrie entwickeln wollen.
Helfen für Zertifikate? Nicht in deinem Sinne, dass die Software dann wirklich sicherer ist.
Der Nutzen liegt an anderer Stelle.
Ab einer gewissen Komplexität ist es für eine Firma oder auch für einen IT Sicherheits Experten nicht mehr möglich, sicherzustellen, dass kein Virus eingefangen wird / die Firma nicht gehackt wird.
Wenn beides nicht passiert, ist das reines Glück.Was tut man also? Man tut das was branchen-üblich / gute Praxis ist und dokumentiert das!
Dafür gibt es IT Sicherheits Zertifikate, dafür kauft man Schlangenöl und man engagiert Pen-Tester.
Ein Pen-Test zeigt nicht nur, ob die Systeme hinreichend sicher sind, sondern er ist auch ein Signal, dass man etwas unternommen hat.Für die Firmen, welche Software herstellen gilt das analog. IBM, SAP und Microsoft könnten immer darlegen, dass sie alles nach dem Schema der XY Zertifizierung entwickelt und getestet haben und dass es praktisch höhere Gewalt war wenn ihre Software Schaden angerichtet hat.
Die könnten auch den Papierkram stemmen um das alles zu dokumentieren.Das Problem mit Haftung ist ja immer: es reicht nicht aus, gute Arbeit zu leisten. Man muss es auch dokumentieren… Und sich nach einem objektiven Standard richten… Wer setzt den?
Also überleg es Dir nochmal mit der Haftung für Schäden durch unsichere Software. ;)
So Leute, die einem Sätze sagen wie
Wenn Malware da war, haben wir die noch immer gefunden!Das hat mir jetzt so wörtlich niemand geschrieben, aber es klang ein paar Mal durch. Die Aussage sollte man sich direkt ausdrucken und über das Klo hängen. Die bringt das Problem wunderschön auf den Punkt.
Ich habe ja wirklich Angst davor, dass eines Tages mal mir irgendjemand was vorwirft, und dann das Gericht einen "Forensiker" beauftragt, und der zu inkompetent ist, meine Unschuld zu beweisen.
Es kommt vor allem immer das Komplexitätsargument. Aber aber aber es ist doch total schwierig, die ganzen verschiedenen Spuren alle falsch zu legen! Ja und? Ist im Casino Karten zählen etwa unkomplex und einfach? Und trotzdem machen das Leute! Oder dieses manipulierte Mobiltelefon neulich!
Du kannst nicht einfach davon ausgehen, dass die Angreifer weniger kompetent sein werden als du. Klar, die meisten Angreifer geben sich nicht viel Mühe, wenn sie es nicht müssen. Aber das sind auch nicht die, vor denen du dir Sorgen machen solltest!
Nein, wirklich. Tut es. Ist wichtig.
Der neue Adam Curtis-Film hat eine schöne Szene über Filterblasen. Er beschreibt anfangs, wie die Leute die Komplexität der Welt seit dem Kalten Krieg managen, indem sie sich in Scheinrealitäten zurückziehen, mit einfacherem Weltbild, die leider mit der Realität nichts zu tun haben. Und solange ihre politischen Aktionen in der Scheinrealität spielen, bewirken sie in der Realität nichts. Das ist sozusagen eine der Prämissen des Films. An einer Stelle beschreibt er dann, wie Trump irgendwas sagt, und die Liberalen sind "furious" und schimpfen laut, aber die Algorithmen haben dafür gesorgt, dass jeder nur noch Dinge aus seiner Scheinwelt sieht, und so sehen nur noch die das Geschimpfe, die eh schon überzeugt sind.
Ich glaube, da kommt noch ein Aspekt oben drauf, der bisher noch nicht so angesprochen wurde. Es gibt ja Momente, wo die Leute dem Gezeter aus den anderen Scheinrealitäten ausgesetzt sind. Und das wirkt dann so fake und außerirdisch, dass niemand sich ernsthaft mit den anderen Realitäten auseinandersetzen will. Der Grund ist, dass auf dem Weg dahin ein wochenlanges gegenseitiges Aufwiegeln stattfand, aber ohne Feindkontakt. Innerhalb der jeweiligen Gruppe. Zu dem Zeitpunkt, wo der Zorn dann rüberschwappt, ist es auf dem Weg nie mit anderen Realitäten konfrontiert worden, und die Argumente gehen dann a) von Annahmen aus, die die andere Seite nicht nur nicht teilt, sondern möglicherweise sogar noch nie gehört hat, oder b) zielt mangels Kenntnis nicht auf die für die Gegenseite schwachen, angreifbaren Punkte sondern auf fiktive Bruchstellen, die möglicherweise gar nicht da sind. Dadurch verpufft bei Kontakt von zwei Realitäten der Protest völlig. Und der, der den Protest geäußert hat, erklärt sich das mangels anderer Ideen so, dass der Feind halt fies und gemein und irrational ist. Nach wochenlanger Zustimmung aus den eigenen Reihen hält man das eigene Argument für völlig schlagkräftig und unhinterfragbar.
Meine Hoffnung mit den obigen beiden Links ist, dass ihr dieses Muster erkennt. Versucht mal, eine Liste der Prämissen und Annahmen zu machen, die den jeweiligen Artikel zugrundeliegen auf den beiden Sites.
Denn meine Hauptaussage ist: Filterblasen sind nicht etwas, das die anderen da draußen haben, die Kaputten auf Twitter. Filterblasen haben wir inzwischen alle. Unser gesamtes System besteht nur noch aus Feedbackschleifen. Der Onlinehandel, die sozialen Medien, die Nachrichten, alle zeigen uns nur noch, was wir sehen wollen. Mehr oder weniger erfolgreich, klar. Die Twitteria sitzt in einer Filterblase. Ich sitze in einer Filterblase. DU SITZT IN EINER FILTERBLASE. Schritt 1 ist, das anzuerkennen. Schritt 2 ist, gezielt durchzupieksen.
Das ist in NRW nicht anders. Ich würde dies nicht an den trigonometrieschen Funktionen aufhängen, sondern prinzipiell daran, dass mathematischen Denken nicht mehr gelehrt wird.Wissen über Gruppe, Ring und Körper wird nicht mehr vermittelt. Beweise werden ein paar mal vom Lehrer gezeigt, aber dieses Wissen wird nicht mehr abgefragt. Jedes Jahr fliegen ein paar Anforderungen aus dem Kalalog. Die Analysis kommt in NRW nun ohne Polynomdivision und Partialbruchzerlegung aus. Der Schüler muss nur noch ein wenig rechnen und nach Schema F die Aufgaben runterrechnen. Auch hier unterstützt durchgehend der CAS (graphischer Taschenrechner). Der Schüler braucht sein Arbeitsergebnis nicht mehr selbst überprüfen. Er lernt nicht wie man dies machen könnte, dies macht die Maschine für ihn. Überhaupt vergammelt hier das Potential von (normal) begabten Kindern, die vor Langeweile crashen und sich angewidert vom langweiligen Unterrichtsstoff abwenden.
Eine Mathematikklausur musste neu geschrieben werden, da 90 % der Schüler eine 5 oder 6 hatten. Der Stoff war nachweislich gründlich vermittelt worden, ich habe die Unterrichtsmitschriften meiner Tochter durchgesehen. Der Lehrer hat sogar eine Aufgabensammlung mit Musterlösungen verteilt, die aber von fast allen Schülern nicht bearbeitet wurde.
Meine beiden Töchtern (Abijahrgang 2016 und 2017) sind nach meiner Ansicht Prototypen (ich hab es bei vielen anderen begabten Schülern beobachtet). Beide hat die Schule dermaßen gelangweilt, dass sie sich während des Unterichts und auch danach mit anderen interessanteren Projekten beschäftigten. Sie hatten kein Interesse am Wiederkäuen trivialer Fakten. Selbstständiges Arbeiten bzw. Denken wird nicht vermittelt oder gefördert und die meisten Lehrer sind inzwischen lustlos, da sie selbst kein Interesse an diesem niveaulosen "Pepitaunterricht" haben - sie sind mit anderen Motiven Lehrer geworden. Die Mathelehrer hat es sehr hart getroffen; für diesen Unterricht braucht man kein Mathematikstudium in der vermittelten Komplexität.
Hier eine Kostprobe aus dem Geschichtsleistungskurs: "Die RAF war eine deutsche Terroristenorganisation und sie sind verantwortlich für viele Tote durch Anschlag auf ein Kaufhaus."
"Deutschland ist eine Vorzeigedemokratie - die Bundestagsabgeordneten werden direkt vom Volk gewählt. usw."
-> Die Lehrer passen sich an und nehmen Propagandamaterial vom Innenministerium für Unterrichtszwecke, aber nicht um diese dann kritisch zu durchleuchten.
Referate werden per Copy&Paste aus dem Internet kopiert und mit eins bewertet.
Ich habe als Vater versucht dagegen zu arbeiten, auch das Gespräch mit den Lehrern gesucht.
Ich habe meinen Kindern gezeigt, wie man ein Referat selbstständig erstellt. Zum Schluss habe ich aufgegeben, da es zum Dauerstreit geführt hat. Die Kinder hatten aus ihrer Sicht die besseren Argumente: Ein Referat in 1-4 Stunden zusammenkopiert mit fehlenden/unvollständigen Quellenangaben wurde mit 1 oder 1- bewertet. Ein mit viel Mühe und selbstständig erarbeitetes Ergebnis ergab auch nur eine 1.Die Schule war unter Strich verlorene Zeit, beide haben nun, trotz überdurchschnittlichem Denkvermögen und Begabung, kein Interesse an einem Studium. Sie haben für kein einziges Unterrichtsfach eine Form von Leidenschaft entwickelt.
Disziplin und sauberes kontinuierliches Arbeiten haben sie nicht gelernt, sie sind in dieser Hinsicht versaut. Sie konnten alles mit "Links" machen, die Anwesenheit im Unterricht hat ausgereicht für ein Abischnitt von 2,2. Beide haben zu Hause nichts für die Schule getan.
Verschwörungstheorie:
Dieses Kastrationsverfahren hat folgende Wirkung: Die Dumpfbacken erreichen durch Auswendiglernen und Anpassung den Hochschulzugang. Auch auf den Universitäten wurde alles verschult und selbstständiges Denken ist auf den Rückzug, Auswendiglernen ist gefordert. Damit schaffen wir uns verstärkt den Obrigkeitsstaat, den wenn wenig denkende Kritiker nachwachsen, wird das Regieren leichter. Durch die große Masse an Abiturienten wird der Konkurrenzdruck größer, das fördert zusätzlich angepasstes Denken.
Und nun stellt euch meine Überraschung vor, als der Rant in genau die Gegenrichtung geht.
Ich zitiere mal:
Chrome has had such a problem with performance they formed a special group just to work the problem, but in nearly two years time that group has yet to produce anything tangible.Wait, what? Chrome ist ihm zu langsam!?Ja gut, Chrome ist in der Tat gelegentlich langsam. Wenn so Leute wie dieser Vollpfosten monströse "Anwendungen" in Javascript zu machen versuchen. Guckt euch nur mal seine Beschwerdeliste an:
keep your JS/HTML/CSS payload under 1MB- Keeping the JS payload below 750kb seems to be the key point for Android, but keeping below 500kb is more ideal.
- Mobile Safari can honestly handle 2-4MB apps without blinking, yes, the parse and compile performance differences are that severe.
- complicated, verbose CSS is just as bad as complicated verbose JS
No Shit, Sherlock! "Complicated, verbose" irgendwas ist Scheiße. Auch ohne verbose ist complicated schon Scheiße!You want to keep a fairly low DOM node count, I target <5k nodes, ideally peak at <10k nodes and I make heavy use of occlusion and recycling to achieve that.Oder, alternativ, könnte man auch Sites mit weniger als 1k nodes machen. Ihr werdet lachen, das geht!Aber diese Javascript-Deppen gehen ja inzwischen dazu über (die Google-Ratschläge sind an der Stelle großartige Unterhaltung), Bilder nicht im HTML zu laden, sondern im HTML Platzhalter zu haben und die Bilder dann per Javascript später zu laden. Weil, äh, dann rendert die erste Seite schneller. Oder so.
Leute, wenn ihr euren Misthaufen immer größer werden lasst, dann könnt ihr am Ende nicht mit dem Finger auf Google zeigen, wenn der Gestank zu groß wird! Es ist euer Misthaufen, der hier stinkt, nicht Chrome!
Der Vollständigkeit halber hier meine früheren Ausführungen zum Thema "schnell landende Webseiten".
Wenn ich ein Bild zentriert über dem Rest positionieren will, dann nehme ich sowas hier:
position: fixed;Und das funktioniert auch ganz gut. So, jetzt will ich dieses Bild da aber nicht nur hinblenden, sondern es soll von oben angeflogen kommen. Wir reden hier von wichtigen Business-Bildern, ihr versteht schon, die müssen sich bewegen!
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
Dafür definiere ich eine Animation mit zwei Keyframes, die zwischen zwei translate-Statements iterieren sollen.
Nun stellt sich raus, dass das translate aus der Animation nicht etwas nach dem translate aus der Positionierung angewendet wird, sondern stattdessen. Ich befürchte jetzt, dass ich da für jede Kombination aus Richtung und Positionierung eine eigene Animation definieren muss. Das kann ja wohl nicht ernsthaft so sein. Also, was ist die Lösung?
Ich könnte jetzt ein div um das zu animierende Element machen, klar, aber das würde das Markup der Folien komplexer machen, und Komplexität ist der Feind. Das kommt also nicht in Frage. Ich könnte diese div-Elemente per Javascript in den DOM reinfummeln. Das würde ich gerne nur als letzten Ausweg nehmen.
Gibt es keine Möglichkeit, beim Animieren zu sagen, dass er bitte den translate-Teil aus dem Style des Elements übernehmen und nicht überschreiben soll? Ich finde gerade keine beim Rumklicken.
Update: Der Hack, der mir hier weitergeholfen hat, ist, die Animation nicht über translate zu machen sondern über margin-left und margin-top.
JSON ist halt für Leute denen XML zu komplex ist.Das bringt es ganz gut auf dem Punkt, finde ich.
XML ist für Leute denen ASN.1 zu komplex war.
Protobuf ist für Leute, denen JSON zu langsam ist
Wobei man das ja eigentlich noch erweitern müssten. Die Komplexität von XML hat ja die von ASN.1 übertroffen (es gibt eine ASN.1-Abbildung nach XML aber nicht umgekehrt).
Ich muss ja sagen, dass ich ein Freund von ASN.1 bin. Anfangs habe ich es für einen großen Mist gehalten, aber inzwischen habe ich meine Meinung geändert. Selbst der Schachtelungswahnsinn bei LDAP ist bei näherer Betrachtung verteidigbar.
Aber so im Vergleich zu ASN.1/DER hat Protocol Buffers irgendwie nur Nachteile. Besonders ärgerlich weil vermeidbar finde ich, dass sie am Anfang nicht die Länge mitschicken. Wenn man schon seine Daten serialisieren muss, dann will man doch wenigstens einen Zero-Copy-Decoder haben. Das heißt, ich will auf einen gesendeten String zugreifen, ohne den rauskopieren zu müssen. Und Zero-Copy heißt halt auch, dass man am Anfang weiß, wie groß die Nachricht werden wird. Denn sonst muss man lesen, was kommt, und immer mehr Speicher dazu allozieren und umkopieren, was wir ja gerade vermeiden wollten. Wenn ich das richtig sehe gerade, dann hat Protocol Buffers keine Längenübertragung am Anfang. Und keinen Ende-Marker. Wenn ich also zwei Protocol Buffers hintereinander übertragen will, weil ich im Protokoll Pipelining unterstützen will, dann gibt das einen Konflikt mit der Erweiterbarkeit. Hey, ASN.1/DER hat seit den 80ern Pipelining und Erweiterbarkeit drin. Wie arm ist DAS denn, sowas dann wegen "not invented here" wegzuschmeißen und neu zu machen und dann schlechter als das Original zu sein. Die sollten sich alle mal was schämen.
Aber das Tooling ist so toll!1!! Ja, äh, und? Du bist ein fucking Coder. Code dir halt dein Tooling selbst. WTF? Seit wann ist diese "wische mir doch mal bitte jemand den Arsch ab"-Mentalität eigentlich gesellschaftlich akzeptabel geworden?
Die Betreiber der Seite geben an, dass der Angriff nicht über das eigentliche Betriebssystem ihres Webservers erfolgte, sondern über den Hypervisor der Virtualisierungssoftware des Webhosters.Virtualisierung ist eine große zusätzliche Schichte Komplexität oben drauf auf der eh schon viel zu großen Komplexität eines Betriebssystems mit seinen Anwendungen. Das schafft völlig unnötig neue Angriffsfläche. Ich vertraue keiner dieser Lösungen.
Update: Diverse VM-Apologeten weisen gerade darauf hin, dass das ein schwaches Passwort war. Ja und? Was ändert das an dem Sachverhalt, dass die über den Hypervisor aufgemacht wurden? Der ist unnötige Angriffsfläche, über die sie jemand gehackt hat.
Erstens: "Known Plaintext" heißt die Angriffsart, bei der der Angreifer sowohl den Klartext als auch die verschlüsselten Daten hat und daraus den Schlüssel errechnen will. Intuitiv würde man denken, dass das total einfach sein muss, dann den Schlüssel zu errechnen. Bei antiken Verfahren ist das auch so, bei modernen nicht. Die von Truecrypt verwendeten Verfahren haben allesamt die Eigenschaft, dass bei ihrem Design darauf geachtet wurde, dass das nicht signifikant leichter geht, als mögliche Schlüssel durchzuprobieren.
Dann: Durchprobieren. Die Kryptographie geht schon immer davon aus, dass der Gegenüber über unbegrenzte Geld- und Material-Möglichkeiten verfügt und über das beste Know-How, das es auf der Welt gibt. Überspitzt gesagt, ist das Modell des Gegenübers, vor dem wir uns mit Kryptographie schützen wollen, die NSA. Schon immer. Unter der Annahme, dass sie Roswell-Technologie reverse engineered und im Einsatz haben. Verfahren werden grundsätzlich mit so großen Sicherheits-Margen versehen, dass selbst unter pessimistischsten Annahmen (und Kryptographien sind ausgesprochen pessimistisch, wenn es um die NSA geht) noch genug Raum für ein paar Jahrzehnte stetig schneller werdende Hardware drin ist. Die NSA hat über die Jahre mehrere Anläufe genommen, um Krypto-Standards mitzudefinieren. Weil allen anderen Beteiligten völlig klar ist, was die Kernaufgabe der NSA ist, traut denen grundsätzlich genau niemand über den Weg. Man lässt die dann ihren Standard machen, aber niemand benutzt ihn. Die Angriffe, über die man beim Diskutieren von Verfahren redet, sind daher nicht in der Liga "das wäre aber sehr teuer" sondern in der Liga "das würde so lange dauern, dass die Erde vorher in die Sonne stürzen wird". Hier rechnet das mal jemand für 256-Bit-Schlüssel aus.
Es hat sich daher aus meiner Sicht nichts geändert bei der Kryptographie. Wo sich etwas geändert hat, ist bei der Frage, wo man seine Krypto-Software eigentlich her hat, und ob man dem trauen kann. Aus meiner Sicht ist es jetzt an der Zeit, dass sich mal die Hacker der Welt zusammen tun, und in aller Ruhe und mit größter Sorgfalt die ganze Krypto-Software da draußen auditieren. Eine wirklich gute Hintertür sieht man bei einem Audit auch nicht notwendigerweise, aber wann soll man sowas denn bitte in Angriff nehmen wenn nicht jetzt? Ich für meinen Teil habe mir ja seit einigen Jahren vorgenommen, mal eine SSL-Library zu schreiben. Einen X.509-Parser habe ich schon, aber die ganzen Cipher und so noch nicht. So viel Arbeit ist das nicht, aber ich bin halt Hacker und kein professioneller Kryptograph und mache mir da natürlich Sorgen, einen subtilen Fehler zu machen, der dann meine Benutzer kompromittieren würde. Das (und die Komplexität der Sache) hat mich bisher davon abgehalten, das mal "einfach zu machen".
Übrigens, falls jemand mal sehen will, wie so NSA-Einflussnahme in der Praxis ausschaut: Dieser Thread hier scheint in der Hinsicht zu liefern. Die Sache mit IPsec ist seit Jahren bekannt, das Paper von Bruce Schneier ist von 2003.
Übrigens, der von der NSA unterwanderte Krypto-Standard, der in der New York Times erwähnt wird, ist wohl Dual EC DRBG.
Update: Übrigens forschen auch seit Jahren schon Leute daran, wie man weiter Daten verschlüsseln kann, wenn Quantencomputing eine Realität wird.
In her witness statement submitted to the British court on Friday, Detective Superintendent Caroline Goode, who said she was in charge of Scotland Yard's Snowden-related investigation, said that among materials officials had seized from Miranda while detaining him was an "external hard drive" containing data encrypted by a system called "True Crypt," which Goode said "renders the material extremely difficult to access."Goode said the hard drive contained around 60 gigabytes of data, "of which only 20 have been accessed to date." She said that she had been advised that the hard drive contains "approximately 58,000 UK documents which are highly classified in nature, to the highest level."
Goode said the process to decode the material was complex and that "so far only 75 documents have been reconstructed since the property was initially received."
Dazu gibt es ein paar Dinge zu sagen. Erstens: Der Weg, wie man Truecrypt angreift, ist dass man Passphrases durchprobiert. Die Komplexität eines Schlüssels ist viel höher als die typische Komplexität einer Passphrase, selbst wenn sich jemand Mühe gibt. Wir reden hier von mehreren Größenordnungen Unterschied. Das ist also schonmal ein Widerspruch zwischen deren Aussage und der Realität. Man greift da nicht einzelne Dateien an.Zweitens: In einem Truecrypt-Volume ist ein Abbild eines Dateisystems. Das ist eine komplexe Datenstruktur. Verschlüsselt wird pro Sektor innerhalb des Images. Der Schlüssel pro Sektor wird aus einem Masterschlüssel errechnet, der sich aus der Passphrase ergibt. Das Verfahren, wie man zu dem Schlüssel für einen Sektor kommt, wenn man den Masterschlüssel hat, ist bekannt, weil der Quellcode von Truecrypt ja offen ist. Die behaupten jetzt also, dass sie die Dateien zählen können. Das ist völlig unglaubwürdig. Wenn sie das könnten, hätten sie den Masterschlüssel, und mit dem könnten sie auch alle Dateien entschlüsseln. Die Frau hat da mit hoher Wahrscheinlichkeit keine Ahnung, wovon sie redet, und hat ein paar Dinge durcheinandergeworfen.
Die NSA hat Supercomputer, die genau mit dem Ziel gebaut wurden, möglichst effizient Passphrases für Truecrypt durchzuprobieren. Das dauert ewig und drei Tage, selbst mit Spezialhardware. Kurz: ich glaube nicht, dass die da überhaupt etwas entschlüsselt haben können in der Zwischenzeit. Wenn, dann nur weil sie die Passphrase raten konnten. Und wenn das der Fall wäre, hätten sie damit alles entschlüsseln können.
Ich bin jetzt kein Experte darin, wie Truecrypt intern funktioniert. Vielleicht ist es ja besonders schwierig, von einem Sektor-Schlüssel zum Masterschlüssel zurückzurechnen. Müsste mal jemand nachgucken, wie die das intern machen. Aber das ist normalerweise nicht der Angriffsweg bei sowas, wieso würde man da also besondere Schritte unternehmen, um das schwierig zu machen. Der Punkt ist, dass schon der Schlüssel für den Sektor so groß ist, dass man den nicht realistisch durch Durchprobieren erraten kann.
Ich habe mir in den letzten Tagen angefangen, Sorgen zu machen, dass die NSA dieses ganze Bruhaha für PSYOP nutzt. Wenn sie nur genügend häufig Truecrypt erwähnen und dass sie da Spezialhardware haben, dann kriegen die Leute vielleicht Angst und wechseln zu einem anderen, weniger sicheren System. Solange da nicht noch weitere, krasse Details rauskommen, würde ich Truecrypt weiterhin für so sicher halten, wie eure Passphrase halt ist. Wenn die kurz oder ratbar ist, dann bringt natürlich die tollste Verschlüsselung nichts.
Die WebM-Leute haben übrigens seit einer Weile "VP9" in ihrem libvpx-Repository eingecheckt, deren patentfreien Konkurrenten zu H.265. Konnte bei einem ersten Test noch nicht überzeugen, aber das kann man ja auch nicht erwarten zu einem so frühen Entwicklungszeitpunkt.
Wenn ich sowas sehe, muss ich mich schon fragen, wieso solche Leute nicht gleich Java programmieren. Das ist jetzt auch nicht gerade eine monströs umfangreiche Anwendung, das werden am Ende so — wenns hochkommt — 100-200 Zeilen C++-Code sein.
Und so wird ja heutzutage Software entwickelt. Man schludert ein paar Zeilen hin, und die gesamte Funktionalität kommt aus irgendwelchen 3rd-Party-Libraries. Diese ganze Komplexität, die man sich da in seine Programme reinzieht, überblickt ja schon lange niemand mehr. Die Leute haben ja nicht mal ein Gefühl dafür, wieviel Code in dem Programm am Ende tatsächlich von ihnen kommt. In diesem Programm hier sind das um die 1%, eher noch weniger.
Ein Programm dieses Funktionsumfanges hätte man auch in 10k Binary unterbringen können.
Update: Ich sollte dazu sagen, dass das Binary nicht statisch gelinkt ist. libstdc++ kommt dynamisch dazu.
Ich habe vor ein paar Jahren einen beeindruckenden Vortrag gesehen, wo eine Forschergruppe gezeigt hat, dass man bei einer SSH-Verbindung das Passwort rekonstruieren konnte. SSH ist verschlüsselt. Die Idee war, ein Modell der Tastatur und der Finger zu basteln, und dann kann man aus dem Timing der Pakete auf mögliche Tastenkombinationen schließen. Klingt unglaublich, aber das haben die Forscher probiert und haben damit tatsächlich Passphrases rekonstruieren können.
Heute weist mich jemand auf eine noch krassere Sache hin, nämlich dass man aus dem Beobachten von verschlüsselten VoIP-Paketen das gesprochene Wort rekonstruieren kann. Die Idee dabei ist, dass Voip-Sprachcodecs mit variabler Bitrate kodieren, je nach Komplexität des Signals. Wenn man also ein gutes Modell der Sprache hat, kann man mit einer gewissen Wahrscheinlichkeit Sätze rekonstruieren.
However, we show that when the audio is encoded using variable bit rate codecs, the lengths of encrypted VoIP packets can be used to identify the phrases spoken within a call. Our results indicate that a passive observer can identify phrases from a standard speech corpus within encrypted calls with an average accuracy of 50%, and with accuracy greater than 90% for some phrases.Das sind ausgesprochen beunruhigende Ergebnisse und Wasser auf unsere Mühlen. Die offensichtliche Paranoia-Lektion ist, dass man aus lärmenden Umgebungen heraus telefoniert, und untypische Formulierungen verwendet :-)Update: Wenn man eine Voip-Umgebung hat, in der man einen fixed bitrate Codec einstellen kann, dann ist das natürlich die bessere Lösung. Mir flüstert gerade ein gewöhnlich wohl unterrichtetes Vögelchen, dass das bei den Diensten schon etablierte Technologie ist, seit Jahren im Einsatz. (Danke, Thomas)
Häufig genannte Argumente pro Inversion of Control sind, dass man so bessere Unit-Tests machen kann. Hey, was soll ich euch sagen, das konnte ich in C++ auch immer ohne neue Indirektionsschichten. Das Argument kann ich nicht gelten lassen.
Ich verdiene mein Geld damit, anderer Leute Quellcode zu lesen. Der beste Code ist der, den kurz aber selbstverständlich ist. Code, bei dem man irgendwo nachschlagen muss, um zu sehen, dass er korrekt ist, ist schlechter Code. Code, bei dem nicht mal der Compiler erkennen kann, wer da eigentlich gerade aufgerufen wird, ist die Steigerung von schlechtem Code. Nicht nur, weil man einen riesigen Kontext braucht, um ihn lesen zu können, und damit um bestimmte häufige Fehlerklassen ausschließen zu können. Sondern auch weil der Compiler nicht inlinen kann, wenn die Interfaces alle dynamisch zusammengepfropft werden. Bei Java heißt es immer, der JIT-Compiler könnte das dann schon fummeln, aber guckt euch doch mal das Laufzeitverhalten von typischen Java-Anwendungen an! Sieht das für irgendjemanden so aus, als könne der JIT da irgendwas signifikantes rausoptimieren? Oder überhaupt optimieren?
Ich höre auch häufig als Argument, dass man mit Java so produktiv sein kann, dass man so schnell Projekte stemmen kann. Auch das kann ich nicht aus der Praxis bestätigen, im Gegenteil. Was in Java tatsächlich gut geht ist das Parallelisieren von großen Projekten. Weil sich die Java-Leute eben erstmal auf Interfaces einigen und die dann runterimplementieren. Das könnte man auch in anderen Sprachen machen, aber es macht keiner. Nicht weil es nicht ginge, sondern weil man am Anfang des Projektes noch gar nicht sagen kann, was man konkret für Interfaces brauchen wird, und wie die genau aussehen müssen. Das ist m.E. auch der Hauptgrund für diese ganzen Fummel-Patterns wie Interceptor und Proxy. Das Projekt wird zwar schneller "fertig", aber dann hat man eben den Mehraufwand, um die ganzen Teile zusammenzukleben.
Das ist auch bei C++ eines der Hauptprobleme beim Software Engineering, dass die Leute alle glauben, ihr Kram müsse wiederverwendbar sein. Und dann entsteht eben statt der Klasse mit den 8 benötigten Methoden die "generische" Klase mit den 23 Methoden, von denen nur 8 überhaupt jemals aufgerufen werden und der Rest kompiliert womöglich nur deshalb, weil es Templates sind, die nirgendwo instanziiert werden, und die fliegen einem dann bei der ersten Instanziierung um die Ohren. Und der erste, der das tatsächlich wiederverwerten will, der hat am Ende mehr Aufwand, als wenn er die 8-Methoden-Klasse bedarfsgerecht erweitert hätte.
Übrigens: hier gehen tatsächlich ein paar Mails und Tweets von Studenten ein, die mir vorwerfen, ich habe von Software-Engineering keine Ahnung. Nein, wirklich! Leute, die noch nie irgendwo eine Zeile echten Code geschrieben haben, die sich ihren Boilerplate von der IDE generieren lassen und ohne Eclipse-Plugins zum Webservice-XML-Definitions-Export nicht arbeiten können, solche Leute werfen mir vor, ich habe keine Ahnung von Software-Engineering. Köstlich! Gut, dass das Internet nicht vergisst. Das wird sicher lustig, wenn ihr euch das erste Mal irgendwo zu bewerben versucht, Jungs. Oh und googelt mal den Dunning-Kruger-Effekt.
Die mußten unterwegs ihre Arbeitsgruppe umbenennen, weil die Leute ihnen auf die Schliche gekommen sind, und keinen Bock auf diesen Bullshit hatten! Wenn jemand einen Satz wie diesen hier von sich gibt:
JSR 299 bietet ein neues Set an Funktionen für Java EE. Grundlage ist eine Menge von definierten Lebenszykluskontexten.Da hilft doch nur noch Einschläfern! Wenn die so einen Satz sagen, fällt denen dann nicht selber auf, dass sie auf dem Holzweg sind? Beim Formulieren im Kopf meine ich jetzt?
Darauf aufbauend bietet der JSR Modularisierung, übergreifende Aspekte (Decorators und Interceptors) sowie typsicheres Injizieren von Objekten, alles Dinge, die Java-EE-Komponenten zu einer geschmeidigen Kooperation bewegen sollen.Wenn jemand soweit ist, dass er Decorators und Interceptors braucht und Objekte injizieren will, dann sollte man das Projekt in einem Glassarg im Ozean versenken, alle Kopien und Dokumente darüber vernichten, und neu anfangen. Sicherheitshalber würde ich außerdem für eine Sicherheitsverwahrung aller Beteiligten plädieren.
Schon der erste Satz räumt schon alle Zweifel aus, dass man solche Leute nicht Software entwickeln lassen darf:
Dependency Injection ist eine Anwendung des Inversion-of-Control-Prinzips (IoC) und als solches ein Entwurfsmuster für die objektorientierte Softwareentwicklung.Inversion of Control, ja? Lest euch mal bei Wikipedia durch, in was für einer Traumwelt die Leute leben:
Replacing systems will have no side effect on other systems.Nee, klar, so läuft das ja immer bei komplexen Systemen!1!! Und damit das so bleibt, packen wir noch ein bisschen mehr Komplexität oben drauf!
Guckt euch auch mal an, was sie da für Probleme zu lösen versuchen:
Dank dieser Konstruktion ist es erstmals möglich, EJBs als JSF Managed Beans einzusetzen.Mit anderen Worten lösen Sie da selbsterzeugte Probleme. Probleme, die sie dank verkackten Designs in vorigen Pseudotechnologien haben. Meine Fresse ist das alles eine Bankrotterklärung für Java. Unglaublich. Und wieder machen sie da XML-Metadaten, die man mitpflegen muss. Die lernen halt nicht aus ihren Fehlern. Na dann, guten Absturz, liebe Java-Leute.
Oooooder vielleicht verstehe ich ja auch einfach nicht genug von modernen OO-Dingen, um die Genialität hinter diesem ganzen Framework-Gedudel würdigen zu können. Will mir das vielleicht mal jemand erklären? Das müsste aber jemand sein, der ein größeres Projekt vorzuweisen hat, dass dank dieser Technik funktioniert und sonst nichts geworden wäre.
Update: Mir erklärt gerade jemand, dass sich hierunter im Wesentlichen eine Indirektionsschicht zwischen einer Klasse und dem Class Loader verbirgt. Die Klasse gibt die Instanziierung eines benutzten Interfaces komplett an das Framework ab. Für mich liest sich das genau wie ich oben meinte: eigentlich wollten sie Lisp-Closures haben, aber das kann die Sprache halt nicht, daher pfuschen sie sich jetzt eine Callback-Struktur zurecht. Und dadurch, dass man die Implementation nicht kennt, und die jemand anderes instanziiert, kann man auch nicht am Interface vorbeiarbeiten (was ja eigentlich schon durch das Interface selber verhindert werden sollte, aber offenbar nicht genug…?). Insgesamt scheint es bei Java ein Riesenproblem zu sein, anderer Leute Code benutzen zu müssen, ohne ihn anfassen zu können. Und die existierenden Komponenten müssen so furchtbare Modularitätsverletzungen haben, dass man das architekturell erzwingen muss in Java. Was bin ich froh, dass ich nicht in so einem Umfeld programmieren gelernt habe. Die Leute sind sicher für ihr Leben gezeichnet und werden nie ordentlichen Code schreiben können.
Update: Mir mailt gerade jemand völlig zu Recht diesen Link, der schön illustriert, was hier gerade passiert (Spalte 1, Zeile 2).
Man hatte mir vorher diskret zu Verstehen gegeben, dass durchaus erwünscht ist, wenn ich provokante Thesen äußere und damit die anderen Teilnehmer ein bisschen animiere. Außerdem hieß es, ich sei der einzige Techie und das Publikum sei aus dem Gesundheitssektor, und damit war klar, dass ich da keine technischen Details ausbreiten kann.
Ich eröffnete mein Plädoyer also mit dem Satz, ich sei ja hier als Vertreter der Patienten da, weil für die anderen Interessengruppen für ausreichend Vertretung gesorgt sei. Das gefiel den anderen Teilnehmern schon mal gar nicht, besonders Thilo Weichert vom ULD in Kiel und der direkt neben mir sitzende Vertreter des Bundesverbandes der Verbraucherzentralen schienen mir zu zürnen :-)
Normalerweise auf solchen Veranstaltungen kommt das Gespräch dann irgendwann darauf, dass man ja Datenbanken verknüpfen könnte, oder bei einer technischeren Veranstaltung fällt der Begriff Datamining. In solchen Fällen weise ich normalerweise darauf hin, dass man das ja früher Rasterfahndung nannte und total doof fand. Bei dieser Veranstaltung passierte etwas, das mir so noch nie passiert ist: die redeten von sich aus von Rasterfahndung. Der Datenschutzbeauftragte der Barmer war als Vertreter der Krankenkassen auf dem Podium und fing da plötzlich an, seinem Bedauern Ausdruck zu verleihen, dass sie die ganzen schönen Daten ja gar nicht nutzen können, weil es so viel Datenschutz gibt bei uns in Deutschland. Im Schlußwort meinte dann der Vorstandsvorsitzende der Charité auch noch, der Forschungsstandort Deutschland für klinische Forschung sei im Hintertreffen und wir brauchen die Rasterfahndung auf den ganzen Daten, wenn wir ihn retten wollen. Das hat mich ziemlich schockiert. Denen ist klar, dass sie da von Rasterfahndung reden, und sie wollen es alle haben. Und die Krankenkassen glauben wirklich, wir glaubten ihnen, dass sie auf den Daten kein Datamining machen.
Ich habe mitgenommen, dass Herr Weichert böse ist, dass die Konnektoren gerade aus dem Konzept rausfliegen (was ich für einen Gewinn halte, weil es die Komplexität senkt). Herr Etgeton (Verbraucherzentralen) versuchte, einen positiven Gesamteindruck aufzubauen, nach dem Motto "wenn wir uns anstrengen, wird doch noch alles gut", und er hatte da auch ganz hehre (man könnte fast sagen: von jugendlichem Optimismus geprägte) Annahmen wie dass der mündige Bürger rational entscheidet, wem er seine Daten gibt und wem nicht. Insgesamt war Konsens, dass man etwas tun muss, um die Akzeptanz der Gesundheitskarte zu steigern. Irgendjemand sprach dann erfreulicherweise auch den Punkt an, dass die Gesundheitskarte in der aktuellen Planung überhaupt nichts leistet, was nicht auch das bestehende System leistet, und niemand widersprach. Alle nickten. Größter Verfechter der Gesundheitskarte war Herr Bartmann, der Präsident der Ärztekammer Schleswig-Holstein. Er argumentierte vor allem mit der und für die Fallakte (die AFAIK nur optional ist in der aktuellen Planung, nur die Rezepte sind tatsächlich Pflicht) und meinte z.B., im Moment dauere es teilweise Monate, bis der überweisende Arzt mal mitgeteilt kriegt, was die im Krankenhaus mit seinem Patienten gemacht haben, und das ginge ja per Schneckenpost und sei furchtbar ineffizient. Ich kam leider nicht mehr dazu, ihn zu fragen, welche Postdienstleister sie da verwenden, der Monate für die Zustellung braucht, wo doch sogar die gute alte Bundespost inzwischen bundesweit i.A. innerhalb eines Tages zustellen kann.
Meine Thesen waren noch, dass für den normalen Bürger überhaupt kein Unterschied zwischen der eGK und Google Health erkennbar sei, weil er in beiden Fällen irgendwelchen ihm unbekannten Leuten vergleichbare Datensicherheits-Versprechen schlicht glauben muss. Google ist sogar im Vorteil, wenn ihr mich fragt, weil denen ja noch nie irgendwas verloren gegangen ist (wenn man mal von dem China-0day neulich absieht, und das ist ja auch diversen Ministerien bei uns passiert, da ist also unentschieden), während bei der eGK der zuständige Dienstleister T-Systems ist, also die Telekom, und die hat ja nun gerade 2009 kein besonders überzeugendes Bild abgegeben in der Beziehung.
Ich habe auch noch argumentiert, dass wenn ich zum Arzt gehe, und es mir richtig schlecht geht, dass ich dann lieber einen Arzt will, der 80-90% seiner Hirnkapazität dafür frei hat, mir zu helfen, und keinen Arzt, der 40% seines Hirns mit Sorgen über seine komplexe IT-Umgebung verplempert. Das stieß auch auf breiten Widerstand. Alle Beteiligten legten Wert darauf, dass sie moderne Menschen sind und mit Computern umgehen können und das ja wohl selbstverständlich sei. OK, kann man ja nicht ausschließen, dass die Anwesenden da gerade die Ausnahmen in Deutschland sind, die sich auch mit Computern auskennen :-)
Ein Höhepunkt war noch, als Herr Bartmann (Ärztekammer) Ellis (Update: ich dachte Bartmann, aber Herr Krempl sagt Ellis und der hat mitgeschrieben, dem vertraue ich mal mehr als meinem Gedächtnis) dann erzählte, er habe ja mal in Skandinavien gewohnt, und bei denen sei das ja selbstverständlich, dass die da die ganzen Daten offen verknüpfen, und da hätten sie ganz tolle Erkenntnisse draus gewonnen, z.B. Krebsrisiko für Kinder von Schwangeren, die irgendwas nehmen. Nach entsprechender Anonymisierung der Daten kann man sowas auch in Deutschland machen, soweit ich weiß.
Update: Stefan Krempl von Heise war auch da und hat noch dieses tolle Zitat, das ich bestätigen kann:
Eine "Rasterfahndung mit Krebsdaten" zuzulassen sei legitim, da durch Tumore "mehr Menschen sterben als durch Terroristen".
Das klingt erst mal schlau, bis man sich näher mit HTTP auseinandersetzt. Denn da ist das so, dass die externen Referenzen hauptsächlich statisch sind, während sich das HTML auf der Seite ändert. Der Stylesheet ändert sich vielleicht einmal im Jahr, wenn es hochkommt, die Javascript-Library ändert sich, wenn mal wieder ein neuer Browser auf den Markt kommt, und die Inline-Bilder ändern sich einmal am Tag. HTTP hat das erkannt und bietet dafür eine Optimierung an, If-Modified-Since. Hier ist ein typischer HTTP-Request:
GET /rss.xml?html HTTP/1.1Der Client sagt hier also: ich war zuletzt um 19:07:32 GMT hier. Der Server sieht sich das an und antwortet:
Host: blog.fefe.de
Connection: Keep-Alive
User-Agent: Akregator/1.5.1; syndication
If-Modified-Since: Thu, 12 Nov 2009 19:07:32 GMT
Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, image/*;q=0.9, */*;q=0.8
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
Accept-Language: en-US, en
HTTP/1.1 304 Nix NeuesDas ist das HTTP-Modell, um unnütze Daten nicht zu übertragen. Für RSS ist dieser Fall häufig, aber noch viel häufiger ist er für Stylesheet, favicon.ico, Inline-Bilder und externe Javascript-Dateien (gut, die habe ich ja sowieso gar nicht bei mir). Das ist ja gerade der Grund, wieso man Javascript-Bibliotheken in eigene Dateien auslagert. Weil die sich eben nicht ändern und dann nicht bei jedem Zugriff neu übertragen werden sollen.
Google schlägt jetzt vor, der Server soll bei der Anfrage nach der Webseite auch gleich ungefragt die ganzen (ungeänderten) Dateien mitschicken. Das mag zwar im Benchmark die Latenz senken, aber es würde das Web-Verkehrsaufkommen im Internet mal eben verdoppeln. Beim ehemaligen Nachrichtenmagazin würde dann bei jedem Webseitenklicken das Spiegel-Logo mitübertragen. Wenn ihr mal sehen wollt, was das ausmacht, dann geht einmal zu spiegel.de, löscht einmal den Cache, startet den Browser neu, und geht nochmal zu spiegel.de Das dauert gleich fünfmal so lange!
Daher glaube ich, dass es Google hier um was anderes geht. Die wollen nicht wirklich die Stylesheets als Server Push machen. Die wollen die Google Ads als Server Push machen. User werden nämlich ungehalten, wenn eine Webseite langsam lädt, weil die Werbung so lange braucht. Und wenn wir das erst mal so machen, dann ist auch der zentrale Vorteil von Werbeblockern weg. Weil die Seite dann eben nicht schneller lädt mit Werbeblocker. Es flimmert nur nicht mehr so.
Oh und völlig unabhängig davon: der Server müsste, damit das überhaupt funktioniert, die Webseiten parsen und die Abhängigkeiten analysieren können. Das ist eine immense Komplexität, die man nicht im Webserver haben will. Schon aus Sicherheitsgründen nicht. Je komplexer, desto angreifbarer.
Oh und wenn ihr euch mal den HTTP-Request da oben anguckt: über die Hälfte davon ist vollständig überflüssig. Das sollte man nicht komprimieren, sondern einfach mal den überflüssigen Mist rausnehmen.
Spannend wird es z.B. auf Seite 17, wo man die Formeln für das Sizing findet. Mal 5000 Kunden angenommen, soll ein Anbieter folgende Abhörkapazitäten anbieten: Festnetz: 3%. GSM: 27%. Für diese Werte nimmt man die Formeln von Seite 17, und rechnet die erwartete Ausnutzung des Netzes aus, indem man den sogenannten Verkehrswert in Erlang (ich habe meine Zahlen von hier) mit der Anzahl der Anschlüsse multipliziert (bei Festnetz geht die Rechnung in B-Kanälen, von denen jeder ISDN-Kunde zwei hat).
Spannenderweise ist die Formel nicht linear sondern ungefähr wie die Quadratwurzel, so dass kleine Anbieter stark benachteiligt werden. Hier ist mal ein Plot für GSM nach Kundenanzahl (Achtung: bei mir beginnt die Y-Achse da nicht bei 0 sondern bei 2, das wird nicht wirklich negativ). Der Wert an der Y-Achse ist der Prozentsatz des Traffics, für den sie Ausleit-Kapazitäten halten sollen. Man sieht sehr gut, wie unfair das verteilt ist.
Auch lustig ist Seite 26 mit der Liste der zulässigen Anbieter für das IPsec-Gateway. Die Liste ist eher übersichtlich.
Aber zu dem Protokolldesign. Für die Übertragung der Daten supporten die FTP (hahaha) und FTAM (HAHAHAHAHA). Da ist ja schon mal aus Obskuritätsgründen so gut wie ausgeschlossen, dass da die Fehler gefunden wurden, und dann stehen da noch so Dinge dran wie
Der Initiator soll die QoS-Klasse 0 verwenden, da der Responder die Recovery-Prozeduren nicht unterstütztAlles sehr vertrauenswürdig. Die haben da ASN.1 als Basis für den Bulk ihres Protokolls, übertragen aber die Nutzdaten alle als ASCII-Strings. Z.B. gibt es da eine Notification, in der optional (!!) auch das Ziel der Überwachungsmaßnahme benannt wird, zu der gerade die Notification reinkommt, und das ist ein ASCII-String der Maximallänge 256. Das ist nicht schlau, da Email-Adressen schon 320 Zeichen lang werden können. Warum ist der optional (Seite 29)?
-- Aus Gründen der Rückwärtskompatibilität als optionalAber auch Datum, Uhrzeit und optionale zusätzliche Nachrichtenteile werden per in-band-signaling als ASCII übertragen (das Datum humoristischerweise nicht Y2K compliant als TT/MM/JJ). Besonders grob wird das dann auf Seite 44, "Anlage B.2.5 Zuordnungsnummer". Pro Vorgang innerhalb einer Schnüffelanordnung gibt es eine Zuordnungsnummer, wenn sie z.B. den Wiefelspütz überwachen würden wäre das dann eine Nummer pro Telefongespräch. Die Nummer wird auch als ASCII übertragen (OH DIE SCHMERZEN!!), und hat einen Wertebereich von 1 bis 65535. Wenn ich also glaube, dass ich überwacht werde, rufe ich einfach 65535 Mal von meinem Telefon aus eine 0800 Nummer an, z.B. die Störungsstelle oder die Korruptionshotline des LKA Westfalen, und schon ist dieses Feld übergelaufen und weitere Telefonate können nicht mehr abgebildet werden. Bei Protokolldesignern, die sowas verbrechen, ist die Grenze erreicht, bei der man noch einen Freitod anbietet. Aber wartet, wird noch besser! Gut, dass sie das als ASCII schicken, denn so konnten sie es wie folgt erweitern:
Zusätzlich (optional) kann von der TKA-V eine weitere Nummer hinzugefügt werden (z. B. in Mobilfunknetzen die Kennung der MSC), die zusammen mit der Zuordnungsnummer die Eindeutigkeit garantiert. Diese zweite Nummer hat Werte von 0 bis 65535. Wird von der TKA-V diese Variante genutzt, ist die zweite Nummer getrennt durch das Zeichen ‘#’ hinter die Zuordnungsnummer zu setzen.Da fällt die Unterdrückung des Brechreizes nicht leicht. Und wo wir gerade bei Freitod waren (Seite 30):
common [4] CommonMode OPTIONAL,und so geht das munter weiter. So, liebe Leser, macht man es NICHT. Pfusch am Bau. Das läßt die ganze Branche schlecht aussehen, wenn Einzelne sowas verbrechen.
-- moduls of the manufactures
alcatel [5] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
ericsson [6] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
Ganz großes Kino auch folgender Abschnitt von Seite 41:
Authentifizierung bei der berechtigten StelleEin echter Schenkelklopfer! Und das waren nur die bis Seite 60. Das Dokument hat 180 Seiten. Viel Spaß beim Schmökern! Für Unterhaltung ist gesorgt. Und so gilt mal wieder, was auch sonst schon immer gegolten hat: die Inkompetenz der Unterdrücker ist der beste Schutz vor dem Unterdrückungsstaat. Prost!Die technische Einrichtung der bS überprüft, ob die Rufnummer der TKA-V (Anschlussnummer an das Transitnetz), die im Informationselement ‘Calling Party Number’ übertragen wird, gültig ist. Daher darf die TKA-V zum Aufbau der Verbindungen zur bS nicht das Dienstmerkmal ‘Calling Line Identification Restriction’ nach ETS 300 090 [4] benutzen.
Tja, Leute, so sieht das aus. Das ist die Wahrheit. Unsere Geschäftsprozesse laufen auf Kartenhäusern einer derartig hohen Komplexität, dass der Boden komplett durchrosten kann, und wir merken das erst, wenn ein Gast durch ein paar Stockwerke gefallen ist.
Daher: Profis erkennt man daran, dass sie Komplexität minimieren. Kleine Module, völlige Trennung der Module, minimale (in Anzahl und Größe) Interfaces. Pfuscher erkennt man daran, dass sie Visio starten müssen, um ihr Projekt zu planen.
Von den 37 Aussichtsratmitgliedern der KfW können bestenfalls 5 Finanzmarkterfahrungen vorweisen. Fast alle Vertreter sind entweder Politiker oder Interessenvertreter öffentlicher Verbände und Gewerkschaften. Mit einer kritischen Bewertung und Kontrolle von internationalen Investitionsstrategien sind solche Vertreter angesichts der enorm gewachsenen Komplexität in den Finanzmärkten völlig überfordert. Die erstaunliche Größe des Aufsichtsrates allein legt schon nahe, dass hier sicher kein Manager mit kritischer Kontrolle seiner Investitionspolitik zu rechnen hat.Überraschung!!1! Als besonders inkompetent besetzt fallen die staatlichen Banken auf, wo nicht mal 15% der Aufsichtsräte schon mal in einer Bank gearbeitet haben, und wenn man nach Erfahrung mit dem US-Finanzmarkt sucht, sind es gar nur 2,5%. Nur 20% der Aufsichtsräte in staatlichen Banken haben Wirtschaftswissenschaften studiert, (Danke, Julius)
So mussten alle Arztausweise ersetzt werden, weil sie mit falschen Zertifikatsattributen geliefert wurden. Mitten im Test versagten 2000 Gesundheitskarten, weil ihre Zertifikate im Januar 2008 ungültig wurden."Totalschaden" würde eine KFZ-Versicherung dazu sagen. Und jetzt? Jetzt wollen sie die PINs reduzieren:Auch die im Ablauf geschulten Beteiligten trugen ihren Teil zum Test-Fiasko bei. Von 25 Ärzten in 17 Praxen, die freiwillig die Testphase bestritten, sperrten 30 Prozent ihren Heilberufsausweis, weil sie sich partout nicht mehr an die Signatur-PIN erinnern konnten. 10 Prozent davon sperrten ihren neuen Arztausweis irreversibel. Auch die Quote bei den Patienten war ernüchternd: Von den 7553 ausgegebenen eGK wurden 75 Prozent entweder durch falsche PIN-Eingabe gesperrt oder durch den Versuch, die Notfalldaten ohne Arztkarte zu speichern.
Ihre vorläufige Forderung nach einer "Komfort-PIN", bei der gerade keine PIN mehr eingegeben werden muss, wird von den Datenschützern nunmehr unter Verweis auf das Behindertengleichstellungsgesetz unterstützt: Wer nicht in der Lage ist, mit den (je nach Krankenkasse) bis zu 3 verschiedenen PINs umzugehen, müsse dennoch einen Zugang zur medizinischen Telematik haben, so die Datenschützer.Tja, und so scheitert ein weiteres IT-Großprojekt an seinen Ambitionen. Da sind noch mehr lustige Details in dem Artikel, z.B. dass die Apotheker die E-Rezepte ausdrucken, dass die Patienten lieber zu nicht umgerüsteten Apotheken gingen, um sich den E-Ärger zu ersparen, … aber nichts ist so schlimm, dass man es nicht noch schlimmer machen könnte: so schlug ein Professor aus Göttingen vor, man könnte die eGK ja auf die SIM-Karte des Mobiltelefons tun (OH NEEEEIIIINNNN!!!!!!), das mit den ganzen PINs sei doch viel zu rückständig.
gatlings Logformat verteilt seine Zugriffe auf mehrere Zeilen, damit man Statistiken über Sachen machen kann, die man sonst nicht sehen kann. Hier ist ein Beispiel:
Hier kann man an den Zeitstempeln sehen, wie viel Zeit zwischen dem Connect und der eigentlichen Anfrage vergangen ist (und so z.B. sehen, wenn jemand nur connected, dann keine Anfrage stellt, aber die Verbindung offen hält). Für eine Referrer-Analyse. Der Nachteil ist: wenn man nach GET grept, sieht man nicht die verbindende IP-Adresse. Daher habe ich ein kleines Skript namens "acc.pl" gehackt, das das zurück zuordnet. Kein Ding, 24 Zeilen, der formatiert auch noch etwas um.@400000004482340c3386c9cc accept 33 217.20.118.153 38748 1
@400000004482340c33933d4c GET/CGI 33 /rss.xml 0 Mozilla/5.0_(Windows;_U;_Windows_NT_5.1;_en-US;_rv:1.7.10)_Gecko/20050716_Firefox/1.0.6 [no_referrer] blog.fefe.de
@400000004482340c3395d174 cgi_fork 33 62 25805
@400000004482340d27f174cc cgiproxy_read0 62 159 10101
Die zweite Aufgabe ist etwas involvierter, nämlich soll da geguckt werden, welche Links extern referenziert werden. Ich möchte sehen, wer auf meine Meldungen linkt, welche Meldungen besonders häufig verlinkt werden, und von wo sie am meisten Hits zu mir tragen. Das ist gut, weil ich so auch Missbrauch sehen kann, wie z.B. als ich neulich über 1000 Hits pro Tag von irgendwelchen Foren-Sites auf ein Bild bei mir hatte. Dieses Skript nannte ich "deep-links", und es ist ähnlich komplex, 34 Zeilen perl. So, und jetzt schaut euch mal das typische Zeitverhalten an:
Gut, die Kiste ist nicht die schnellste, und das waren die Logdaten von mehreren Tagen, ein paar MB kommen da zusammen. In C ist das deutlich komplexer, weil es da keinen System-Hashing-Code gibt, und weil man da mehr Error Checking machen muss und mehr explizit hinschreiben muss, und so ist acc.c 136 Zeilen lang, und referrer.c 190 Zeilen. Ein deutlicher Sprung in Komplexität, keine Frage, aber schaut euch das Zeitverhalten für die selben Daten auf dem selben Rechner an:perl ~/acc.pl 5.99s user 0.07s system 81% cpu 7.449 total
deep-links 1.23s user 0.06s system 17% cpu 7.560 total
Und das ist der Grund, wieso perl und co ja ganz nett sind, aber man am Ende eben doch C nehmen will.acc 0.40s user 0.05s system 78% cpu 0.574 total
referrer 0.06s user 0.02s system 13% cpu 0.573 total
Python und Ruby sind übrigens noch viel langsamer als perl, von PHP mal ganz zu schweigen.
Eine andere häufig gehörte Ausrede ist, daß das ja keine Rolle spielt, ob eine kurze Aufgabe 0.2 oder 2 Sekunden braucht, das sei ja weniger Unterschied, als man bräuchte, um sich darüber aufzuregen. Das halte ich für groben Unfug. Es gab da Studien, aber mal von mir ganz persönlich aus gesprochen: auf den Computer warten zu müssen macht schlechte Laune. Das macht sogar so viel schlechte Laune, daß die Leute sich alle paar Jahre neue kaufen, obwohl ihr alter noch prima funktioniert. Schon eine halbe Sekunde ist spürbar zu langsam. Ich habe mal mit einem Aktientrader zu tun gehabt, und der hatte für seine Software das Ziel, daß die Software schneller den Bildschirm updaten (und auf Tastendrücke reagieren) muss, als der Bildschirm für seinen Refresh braucht. Das ist jetzt viele Jahre her, daß ich mit dem Mann zu tun hatte, aber denkt mal drüber nach. Im Grunde hat er Recht. Wenn ich auf meinem Rechner 5 Megabyte Logs durchgefummelt haben will, dann ist es bei 1,8 GHz nicht vertretbar, daß ich da länger als ne Sekunde drauf waren muss.
