- jabber.ru und xmpp.ru waren von einem MitM-Angriff betroffen, der das Abfangen von Traffic auf Ebene der Hosting-Anbieter mit der unbefugten Ausstellung von Domain-Validation-Zertifikaten kombinierte und Schutzlücken bei Nicht-Web-TLS-Diensten offenlegte
- Die Überwachung von Certificate-Transparency-Logs und TLS-Public-Key-Probing können helfen, Auffälligkeiten zu finden, doch gegenüber nicht in CT erfassten Zertifikaten und selektivem MitM ist eine vollständige Erkennung schwierig
- Wird ACME-CAA (RFC 8657) zusammen mit DNSSEC ausgerollt, lässt sich festlegen, dass nur ein bestimmtes Konto einer bestimmten CA Zertifikate ausstellen darf; es reicht für Angreifer dann nicht aus, einfach dieselbe CA zu verwenden
- Anders als Webbrowser erzwingen viele Nicht-Web-Clients keine CT-Nachweise (SCTs), und auch die CA/Browser Forum Baseline Requirements schreiben kein CT-Logging für alle Zertifikate vor
- Betreiber sollten ACME-CAA, DNSSEC, CT-Monitoring, Tor Onion Services und eine Verteilung über verschiedene Jurisdiktionen prüfen; Nutzer sollten Ende-zu-Ende-Verschlüsselung und Fingerprint-Prüfung als grundlegende Verteidigung nutzen
Kernstruktur des Vorfalls
- Die Betreiber von jabber.ru und xmpp.ru erklärten, dass ihr Dienst einem Man-in-the-Middle-Angriff ausgesetzt war
- Der Angriff bestand aus dem Zusammenspiel zweier Elemente
- Hetzner und Linode fingen den Traffic zu den Service-Maschinen ab
- Der Angreifer ließ sich unbefugt Domain-Validation-Zertifikate für den Dienst ausstellen
- Es wird als wahrscheinlich eingeschätzt, dass der deutsche Staat den Angriff koordinierte oder Deutschland ihn gemeinsam mit einem oder mehreren anderen Staaten koordinierte
- Andere Möglichkeiten bleiben bestehen
- Hetzner und Linode könnten ohne rechtlichen Zwang freiwillig auf eine Abhöranfrage einer ausländischen Macht reagiert haben
- Das wird jedoch als unwahrscheinlich bewertet, da es für beide Unternehmen sehr negative Bewertungen nach sich ziehen und illegal sein könnte
Erkennungsmethoden und Grenzen
- Die erste Methode besteht darin, Certificate-Transparency-(CT-)Logs zu überwachen und Zertifikatsausstellungen zu finden, die der Betreiber nicht angefordert hat
- Es gibt einige Dienste, die dies stellvertretend übernehmen
- Werkzeuge, die nur nicht angeforderte Zertifikate zuverlässig herausfiltern und melden, haben noch Verbesserungspotenzial
- Die zweite Methode besteht darin, sich regelmäßig mit dem Dienst zu verbinden und zu prüfen, ob der Public Key des TLS-Servers dem erwarteten Wert entspricht
-
Bereiche, die CT-Überwachung übersehen kann
- Selbst von einer legitimen CA ausgestellte Zertifikate werden nicht zwingend in CT-Logs eingetragen
- Die CA/Browser Forum Baseline Requirements machen CT-Logging bislang nicht zu einer Pflichtanforderung für CAs
- Webbrowser lehnen Zertifikate ohne kryptografischen Nachweis eines CT-Log-Eintrags ab, wodurch CT-Logging faktisch erzwungen wird
- Die meisten Nicht-Web-Client-Anwendungen prüfen oder verlangen nicht, ob ein Zertifikat einen CT-Nachweis enthält
- Ein Angreifer kann theoretisch ein nicht in CT erfasstes Zertifikat beschaffen
-
Umgehungsmöglichkeiten durch selektiven MitM
- Auch wenn man versucht, MitM per Service-Probing zu erkennen, kann der Angreifer Erkennungsverbindungen identifizieren und auf diese Verbindungen kein MitM anwenden
- Mindestens sollten Probes über Tor durchgeführt werden, um leicht identifizierbare Situationen zu vermeiden
- TLS-Stacks können anhand von Signalen wie der Reihenfolge von TLV-Listen gefingerprinted werden, sodass ein tatsächlicher XMPP-Client möglicherweise von einem Probe-Agent unterschieden werden kann
- Statt bekannte Probes per Blacklist auszunehmen, kann ein Angreifer auch nur den Traffic bestimmter interessanter Personen per Whitelist einem MitM unterziehen
- Beide Erkennungsmethoden bieten keine vollständige Zuverlässigkeit
Risiken, die sich mit ACME-CAA reduzieren lassen
- TLS-Zertifikate sind ein Mechanismus zur Abwehr von MitM-Angriffen, doch das Domain-Validation-Modell, mit dem CAs die Kontrolle über eine Domain prüfen, ist selbst anfällig für MitM
- Das Risiko steigt, wenn ein Angreifer nicht nur einen Teil, sondern den gesamten Traffic zur betroffenen Website abfangen kann
- ACME-CAA (RFC 8657) kann dieses Problem in bestimmten Situationen abschwächen
- Die Kernidee besteht darin, per DNS-Record festzulegen, dass nur ein bestimmtes Konto einer bestimmten CA Zertifikate für die Domain ausstellen darf
- Es reicht nicht aus, einfach dieselbe CA zu verwenden
- Erforderlich ist Zugriff auf dasselbe Konto bei dieser CA
- Bei Let's Encrypt ist Zugriff auf den für die Zertifikatsanfrage verwendeten privaten ACME-Schlüssel erforderlich
- Nach Maßgabe der bekannten Angriffsmethode wird eingeschätzt, dass die Bereitstellung dieser Erweiterung den Angriff hätte verhindern können
-
Hinweise zur Bereitstellung
- Damit ACME-CAA korrekt funktioniert, ist die Bereitstellung von DNSSEC erforderlich
- Ohne DNSSEC können auch DNS-Anfragen der CA abgefangen werden
- Wer den DNSSEC-Signaturschlüssel kontrolliert, kann diese Barriere umgehen
- Eine durch DNSSEC geschützte DNS-Zone kann betrieben werden, ohne den Signaturschlüssel an Dritte zu geben
- In diesem Fall hat der DNS-Hosting-Anbieter keine Berechtigung, die Zone zu kompromittieren
- Diese Vorgehensweise wird als beste Bereitstellungsstrategie bewertet
- Angreifer könnten versuchen, die Domain-Registrierungsstelle oder die TLD-Registry unter Druck zu setzen, um den für die Domain registrierten DNSSEC-Signaturschlüssel zu ändern
- Ein solcher Vorgang dürfte auffallen
- Aufgrund der Eigenschaften von DNS-Caching könnte es schwierig sein, wiederholte Probes daran zu hindern, eine Schlüsseländerung zu erkennen
- Ein Angreifer könnte auch die CA selbst unter Druck setzen, um eine Fehl-Ausstellung des Zertifikats zu erreichen
- Wenn eine Drittanbieter-CA die Regeln verletzt oder einen Fehler macht, bleibt weiterhin eine Verwundbarkeit
- Die CA/Browser Forum Baseline Requirements verlangen, dass CAs DNSSEC prüfen
- Dennoch kann eine Drittanbieter-CA ein Zertifikat ausstellen, obwohl sie in den CAA-Records nicht autorisiert ist
- Da CT-Logging nicht verpflichtend ist, wird ein solches Zertifikat möglicherweise nicht erkannt
Vorgehen, das ein geschickterer Angreifer wählen könnte
- Der Angreifer in diesem Vorfall war kein perfekter Angreifer, da er die illegalen Zertifikate ablaufen ließ
- Mit der Verbreitung günstiger und einfacher Verschlüsselung ist zu erwarten, dass staatliche Angriffe ausgefeilter werden und häufiger auftreten
- Ein geschickterer staatlicher Angreifer könnte folgendes Vorgehen wählen
- Ausnutzen, dass CAs nicht zwingend zu CT-Logging verpflichtet sind, und ein nicht erfasstes Zertifikat anfordern
- Den Hosting-Anbieter unter Druck setzen, den gesamten Traffic zur betroffenen Maschine per MitM abzufangen
- Interessanten Traffic und Erkennungs-Traffic heuristisch anhand von TLS-Stack-Fingerprints und Quell-IP unterscheiden
- Per MitM die CA davon überzeugen, dass der Angreifer der legitime Kontrolleur der betroffenen Domain ist
- Falls die Domain ACME-CAA und DNSSEC nutzt, versuchen, DNS-Hosting-Anbieter, Registrierungsstelle, TLD-Registry oder CA unter Druck zu setzen
Lücken in der heutigen TLS-Infrastruktur
-
Fehlende CT-Erzwingung bei Nicht-Web-TLS-Clients
- Webbrowser verlangen, dass CA-Zertifikate kryptografische Nachweise für CT-Log-Einträge enthalten
- Die meisten anderen TLS-Clients erzwingen keine CT-Nachweise und können daher nicht erfasste Zertifikate akzeptieren
- Darunter fallen vermutlich auch viele XMPP-Clients
- CT-Verifikation wird nicht automatisch aktiviert, nur weil man gegen OpenSSL linkt; sie muss separat implementiert werden
- Software für sensible Kommunikation sollte Unterstützung für erzwungene CT prüfen
-
Keine Pflicht zum CT-Logging von Zertifikaten
- Die CA/Browser Forum Baseline Requirements, also die Branchenregeln für CAs, verlangen nicht, dass Zertifikate in CT-Logs eingetragen werden
- Es wird als notwendig angesehen, alle Zertifikate verpflichtend in CT-Logs einzutragen
- Wenn CT-Erzwingung allgemein ausgerollt ist, könnte dieses Problem technisch bedeutungslos werden
-
Mangel an CT-Monitoring-Diensten
- Es werden mehr CT-Monitoring-Dienste benötigt
- Ein wichtiger aktueller CT-Benachrichtigungsdienst ist SSLMate's Cert Spotter
- Der Preis kann für Dienste auf ehrenamtlicher Basis und Ähnliches eine Belastung sein
- CT-Monitoring sollte so gestaltet sein, dass Fehlalarme reduziert werden und nur bei ungewöhnlichen oder offenbar unbefugten Zertifikatsausstellungen gewarnt wird
-
Fehlende DNSSEC-Transparenz
- Derzeit gibt es keine bereitgestellte kryptografische Infrastruktur, die Änderungen an den für eine Domain gesetzten DNSSEC-Schlüsseln erkennt
- Wenn Domain-Registrierungsstellen und TLD-Registries unter Druck geraten oder kompromittiert werden und die DNSSEC-Schlüssel einer Domain ändern, kann der ACME-CAA-Schutz geschwächt werden
- Eine Transparenzlösung, die Änderungen an DNSSEC-Zonenschlüsseln öffentlich sichtbar macht, wäre wünschenswert
- Eine solche Lösung müsste nicht alle Records einer Zone protokollieren, sondern könnte sich auf Zonenschlüsseländerungen wie DS-Records beschränken
Empfehlungen für Dienstbetreiber
- Für Dienste, die Ziel staatlicher Angriffe werden könnten, empfiehlt sich ein Ansatz, bei dem Gegenmaßnahmen in der Reihenfolge ihres Kosten-Nutzen-Verhältnisses umgesetzt werden
-
ACME-CAA und DNSSEC
- Die Bereitstellung von ACME-CAA kann es Angreifern erschweren, eine CA zur Ausstellung eines Domain-Zertifikats zu täuschen
- Als Bereitstellungsleitfaden kann der Beitrag zur ACME-CAA-Bereitstellung herangezogen werden
- Auch die Security Considerations des RFC enthalten wichtige Hinweise
- Wer ACME-CAA bereitstellt, sollte DNSSEC ebenfalls bereitstellen
- Wenn möglich, sollte ein DNSSEC-Anbieter gewählt werden, bei dem der Signaturschlüssel nicht dem Anbieter anvertraut werden muss
-
Proxy-Dienste und CT-Überwachung
- Die Nutzung von Diensten wie Cloudflare wird so bewertet, dass man sich bereits in einen Zustand versetzt, der einem selbst durchgeführten MitM ähnelt
- Man sollte sich bei einem CT-Log-Monitoring-Dienst anmelden oder die Logs regelmäßig selbst prüfen
- SSLMate's Cert Spotter bietet kostenpflichtiges automatisches Monitoring
- Cert Spotter ist Open Source und kann daher auch selbst gehostet werden
- crt.sh bietet manuelle Suche in CT-Logs
-
Verteilung über Jurisdiktionen und Tor Onion Service
- Man kann eine Verteilung über verschiedene Jurisdiktionen erwägen, bei der Domain-Registrierungsstelle, TLD-Registry, DNS-Hosting, CA und Hosting-Anbieter in unterschiedlichen Ländern liegen
- Bei der Auswahl können Länder oder geopolitische Blöcke berücksichtigt werden, die wahrscheinlich nicht miteinander kooperieren
- Das Anbieten eines Tor Onion Service kann zentrale Infrastruktur wie TLS und CAs umgehen
- Bei einem Tor Onion Service ist der Public Key des Dienstes die Adresse selbst
- Nutzer müssen die korrekte Onion-Adresse über einen vertrauenswürdigen Kanal erhalten
- Dritte können Nutzer auf eine falsche Onion-Adresse lenken
-
Automatisches Probing über Tor
- Automatisches Probing über Tor ist keine vollständige Lösung, kann aber in der Praxis vorkommende handwerkliche Fehler erkennen
- Tor verringert die Wahrscheinlichkeit, dass eine Probe leicht als solche identifiziert wird
- Um TLS-Fingerprinting zu reduzieren, sollte die Client-Software möglichst eine häufig genutzte TLS-Bibliothek verwenden
- Noch besser ist es, wenn möglich den tatsächlichen Client zu verwenden
- Bei einem XMPP-Dienst kann ein echter XMPP-Client genutzt werden
- Selbst im Erfolgsfall handelt es sich nur um Erkennung nach der Kompromittierung; zu diesem Zeitpunkt können Nutzer bereits geschädigt worden sein
-
Andere Angriffsvektoren und Worst-Case-Annahmen
- Wird MitM erschwert, steigt die Wahrscheinlichkeit, dass Angreifer andere Wege wie die Kompromittierung der Maschine selbst, den Diebstahl privater Schlüssel oder den Diebstahl sensibler Informationen nutzen
- Staatliche Angreifer können VM-Anbieter unter Druck setzen, Speicherdumps auf Hypervisor-Ebene durchführen zu lassen
- Auch dedizierte Server können durch physischen Zugriff des Angreifers kompromittiert werden
- Betreiber sollten Nutzer zu Ende-zu-Ende-Verschlüsselung anhalten und davon ausgehen, dass der Dienst trotz aller Bemühungen kompromittiert ist
- Über Webanwendungen bereitgestellte „Ende-zu-Ende“-Verschlüsselung wird nicht als sinnvoller Schutz bewertet
Notwendige Maßnahmen für CAs, Client-Entwickler und Nutzer
-
CA/Browser Forum
- Es sollte vorgeschrieben oder vorgeschlagen werden, alle Zertifikate in CT-Logs einzutragen
-
Entwickler von Anwendungs-Clients
- Sie sollten eine Funktion hinzufügen, die Signed Certificate Timestamps (SCTs) in TLS-Zertifikaten erzwingt, und sie standardmäßig aktivieren
- Nutzer sollten erkennen können, dass sie durch diesen Schutz abgesichert sind
- Da es bei erzwungenen CT-Nachweisen gewisse Schwankungen gibt, sollten auch entsprechende Diskussionen berücksichtigt werden
- Software sollte als Open Source bereitgestellt werden, damit öffentliche Audits möglich sind
- Auch Supply-Chain-Risiken und die Möglichkeit, dass das Entwicklerunternehmen selbst rechtlich zur Beschädigung der Software gezwungen wird, sollten berücksichtigt werden
- Distributionskanäle, die nicht direkt von den Entwicklern kontrolliert werden, wie Paket-Repositories von Linux-Distributionen, können helfen, Schäden zu reduzieren
-
Endnutzer
- Auch wenn ein Dienstbetreiber in guter Absicht handelt, sollten Nutzer davon ausgehen, dass der Dienst trotz bester Bemühungen kompromittiert werden kann
- Wenn das eigene Leben davon abhängt, dass der Dienst nicht kompromittiert ist, sollte man diesem Dienst nicht vertrauen
- Bei XMPP sollten Ende-zu-Ende-Verschlüsselungstechniken wie OMEMO oder OTR verwendet werden
- Fingerprints der Kommunikationspartner sollten immer geprüft werden
- Ende-zu-Ende-Verschlüsselung sollte nicht mit webbasierter Software durchgeführt werden, oder sie sollte zumindest als kompromittiert angenommen werden
- Wenn der Dienstanbieter einen Tor Onion Service anbietet, sollte dessen Nutzung geprüft werden; die Onion-Adresse muss jedoch aus einer vertrauenswürdigen Quelle stammen
-
CAs und Standardautoren
- CAs sollten die Implementierung von ACME-CAA (RFC 8657) prüfen, falls sie es nicht unterstützen
- Auch CAs, die nicht ACME-basiert sind, können ACME-CAA implementieren
- Selbst wenn die Regeln des CA/Browser Forum nicht erfasstes CT zulassen, kann eine CA die Policy übernehmen, alle Zertifikate in CT einzutragen
- Standardautoren können die Möglichkeit von DNSSEC-Transparenz zumindest für DS-Records erneut prüfen
Bewertung von Confidential Computing
- Wenn auch die Kompromittierung von Maschinen durch Hosting-Anbieter befürchtet wird, gelten heutige Confidential-Computing-Technologien nicht als ausreichende Lösung
- Ihre Bereitstellung kann besser sein als gar nichts zu tun, doch man sollte sie nicht als sicher betrachten
- Derzeitige Technologien, unter anderem von AMD und Intel, werden so bewertet, dass sie auf Vendor-Golden-Keys angewiesen sind, mit denen Systeme mit Backdoors versehen werden können
- Staatliche Angreifer können Vendoren unter Druck setzen, Schlüssel herauszugeben; dann bricht dieser Ansatz zusammen
- Confidential-Computing-Ansätze, die nicht auf Golden Keys angewiesen sind, könnten möglich sein, doch heutige Ansätze erfüllen diesen Maßstab nicht
Verwandte Materialien
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: XMPP-spezifische Empfehlungen zur Abschwächung
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: Bericht zum ursprünglichen Vorfall
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 Kommentare
Meinungen auf Hacker News
Die Angriffszusammenfassung unter https://notes.valdikss.org.ru/jabber.ru-mitm/ ist interessant.
Der Angreifer stellte ab dem 18. April 2023 über Let’s Encrypt mehrere SSL/TLS-Zertifikate für jabber.ru und xmpp.ru aus; vom 21. Juli bis 19. Oktober wurde nachweislich mindestens 100 % des Client-Traffics auf dem XMPP-STARTTLS-Port 5222 per Man-in-the-Middle angegriffen.
Nachdem die erneute Ausstellung der Zertifikate später scheiterte, lieferte Port 5222 von jabber.ru ein abgelaufenes Zertifikat aus. Kurz nachdem die Untersuchung sowie Anfragen bei Hetzner/Linode begannen, stoppte der Angriff, auf einigen Linode-Servern blieb jedoch passives Abhören über einen zusätzlichen Routing-Hop bestehen.
Die Server selbst scheinen nicht gehackt worden zu sein; vielmehr wirken die Netzwerke von Hetzner und Linode so, als seien sie gezielt auf die IPs des XMPP-Dienstes hin umkonfiguriert worden.
Weder die betreffende Seite noch die hier verlinkten Seiten erwähnen Certificate Pinning. Ich weiß nicht, ob XMPP das nicht unterstützt, aber wenn doch, hätte sich ein solcher Angriff damit vielleicht verhindern lassen.
Leider verwendet jabber.ru Serversoftware von 2016, und diese alte Version unterstützt das nicht.
Certificate Pinning ist heutzutage problematisch, weil Zertifikate kurze Laufzeiten haben und häufig erneuert werden. Wenn man Nutzer jeden Monat fragt, ob sie ein neues Zertifikat erlauben wollen, klicken sie irgendwann auch beim Zertifikat eines Angreifers gedankenlos auf „Accept“.
Channel Binding funktioniert unabhängig vom Zertifikat und stellt sicher, dass der TLS-Stream bei der erwarteten Gegenstelle endet.
Der Fokus auf die fehlende CT/SCT-Unterstützung in XMPP-Clients ist merkwürdig. Dieser Angriff verwendete gültige Zertifikate, die von Let’s Encrypt ausgestellt und auch in CT-Logs eingetragen wurden; mit CT/SCT wäre er daher nicht erkannt worden.
Mit strikten CAA-Records ließe sich ein theoretischer Fall, in dem eine andere Zertifizierungsstelle ausstellt, per SCT-Prüfung erkennen; tatsächlich gab es aber auch kein CAA, und Channel Binding ist datenschutzfreundlicher und weniger von Dritten abhängig.
Mit anderen Worten konnte er entweder im gehosteten HTTP auf das ACME-Protokoll antworten oder DNS-TXT-Records setzen; das wirkt so, als hätten die Opfer bereits die Kontrolle über einen Prozessserver oder Nameserver verloren.
Nach meinem Verständnis ist Certificate Pinning nur möglich, wenn man die Clients kontrollieren kann und die zu erlaubenden Zertifikate direkt in den Client einbaut, womit man die gesamte Web-Public-Key-Infrastruktur umgeht.
In einer Situation, in der generische Clients verbinden, gibt es keine Möglichkeit zu wissen, welches Zertifikat erlaubt sein sollte; genau dafür nutzt man ja die Web-Public-Key-Infrastruktur.
Selbst wenn man einen eigenen Client bereitstellt, verlagert sich das Problem natürlich nur eine Ebene nach oben: Der Ort, von dem Kunden den Custom-Client herunterladen, könnte kompromittiert werden und dann einen bösartigen Client ausliefern.
In dieser Liste fehlt die offensichtlichste Gegenmaßnahme: Als Authentifizierungsmethode sollte SCRAM-xxxxx-PLUS aktiviert und wenn möglich erzwungen werden.
Die Idee der PLUS-Varianten ist einfach, aber wirkungsvoll: Statt nur anhand des Salts zu prüfen, wird die Prüfung an eine bestimmte TLS-Verbindung gebunden, sodass die Authentifizierung nur innerhalb einer einzelnen TLS-Verbindung gültig ist.
Das wird auch Channel Binding genannt.
Ich frage mich, wer die Endnutzer von xmpp.ru und jabber.ru sind. Geht es darum, Traffic zwischen russischen Soldaten oder Spionen abzugreifen? Massenüberwachung finde ich schlimm, aber ich verstehe nicht, warum ausgerechnet russische Domains ins Visier genommen wurden.
Plausibler wäre ein Szenario, bei dem man Carder oder Botnet-Betreiber erwischen will. Jabber/XMPP ist in der russischen Szene dieses Milieus immer noch ziemlich beliebt, und in Artikeln wie bei Krebs on Security sieht man häufig Screenshots oder Logs mit Servern wie @exploit.in, @jabber.ru und anderen.
Trotzdem ist Massenüberwachung, was auch immer die Absicht ist, im Allgemeinen widerlich.
Ich weiß nicht genau, wie das Verhältnis zwischen krimineller und nicht krimineller Nutzung auf den beiden Servern ist, aber ähnlich wie bei Tor, wo eindeutig illegale Inhalte und legitime Nutzung vermischt sind, dürfte es auch hier eine Menge völlig normaler Unterhaltungen geben.
Deshalb bin ich grundsätzlich wenig dafür, die Privatsphäre zu verletzen, um beliebige Cyberkriminelle in Ländern außerhalb der eigenen Zuständigkeit zu überwachen, aus denen eine Auslieferung ohnehin schwierig ist.
Ich verstehe, dass Hetzner kooperieren musste, wenn sie nicht wie Lavabit enden wollten, aber da ich Hetzner oft empfohlen habe, wäre es ziemlich enttäuschend, wenn sie von einem Man-in-the-Middle-Angriff wussten und ihn zugelassen oder unterstützt hätten. Abgesehen davon halte ich sie für eines der besten Hosting-Unternehmen.
Die Transparenz ist gut, Uptime, Zuverlässigkeit und Support sind besser als bei den meisten Cloud-Anbietern, und die Kosten sind nicht überzogen. Auch die Bemühungen, umweltfreundliches Design zugleich wirtschaftlich sinnvoll zu machen, sind lobenswert.
Das „Reduzieren“ in „Reduzieren > Wiederverwenden > Recyceln“ zeigt sich im KISS-Design. Beispiele sind hohe, geneigte Dächer[2], die natürliche Wärmeabfuhr unterstützen, Server-Chassis, die eher minimale strukturelle Stützen und Luftstrom-Abdeckungen als echte Chassis sind, sowie ein Standard-Mainboard-Design[3], bei dem der Sockel um 90 Grad gedreht wurde, um VRM, CPU und Speicher mit einem einzigen Lüfter zu kühlen.
„Wiederverwenden“ zeigt sich bei den Serverauktionen. Ältere Hardware wird nicht entsorgt, sondern per niederländischer Auktion vermietet, wodurch sowohl die Kosten für neue Hardware als auch die Umweltkosten der Neufertigung jeder Generation vermieden werden.
Wenn sie dedizierte Server auch außerhalb Europas hätten, würde ich sie noch häufiger nutzen.
[1]: Auch „legal“ selbst ist schwer zu definieren. Ein Journalist in einem Land ist in einem anderen ein „ausländischer Agent“, und der „Freiheitskämpfer“ des einen Landes ist für ein anderes ein „Terrorist“.
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
Im Artikel heißt es, „CT ist optional“, aber ist das am Ende nicht eine Entscheidung des XMPP-Clients? Da Browser es inzwischen praktisch verlangen, frage ich mich, was XMPP-Clients daran hindert, CT ebenfalls zu verlangen.
Ich verstehe auch nicht, auf welchen Trust Store man sich da stützen würde, der Zertifikate ausstellt, die in Browsern nicht funktionieren.
Das Problem ist, dass das Verhalten, CT zu verlangen, in praktisch keiner TLS-Bibliothek standardmäßig aktiviert ist. XMPP-Client-Entwickler müssten es also bewusst einschalten, und derzeit tun das meiner Einschätzung nach die meisten oder alle nicht. Das kann sich natürlich ändern.
Der Artikel schlägt vor, OTR mit XMPP zu verwenden, aber leider nutzt OTRv3 veraltete Kryptografie, und OTRv4 ist noch nicht finalisiert.
https://dustri.org/b/time-to-sunset-otr.html
Auf die Frage „Was würde ein perfekter Angreifer tun?“: Wenn man physischen Zugang zu einem Computer hat, gäbe es vermutlich eine Art Bus-Abgriff, um Daten vom Gerät zu extrahieren.
In der Zeit von Dial-up und langsamen Breitbandanschlüssen mit hoher Latenz ergab das Sinn, aber heute gibt es vielerorts schnelle Glasfaser und niedrige Latenzen bis zu Peering-Punkten.
Je stärker wir uns von Rechenzentren und Cloud lösen, desto eher sollte die Internet-Infrastruktur so funktionieren, wie sie ursprünglich entworfen wurde, und desto weniger muss sie durch zentralisierte Aggregationspunkte laufen, die heute schwerwiegende Ausfallpunkte und große Sicherheitsrisiken darstellen.
Ich habe mir CAA angesehen, aber mein aktueller DNS-Anbieter unterstützt diesen Record nicht. Gibt es einen Grund, warum es ein neuer Typ sein musste und nicht der viel verbreitetere TXT-Record?
Wenn das nicht geht, solltest du Support dafür anfragen. CAA-Records werden immer häufiger genutzt, und sie heute nicht zu unterstützen, spricht nicht gerade für einen guten Service.
Ich kenne die Design-Diskussion zu CAA nicht, aber sie wurde sehr wahrscheinlich auf den einschlägigen IETF-Mailinglisten geführt.
DNS-Anbieter sollten verschiedene RR-Typen unterstützen, und Domaininhaber sollten mit NS-Records abstimmen.
Eine Liste von DNS-Anbietern mit CAA-Unterstützung gibt es unter https://github.com/StackExchange/dnscontrol/blob/master/docu....
Es kann sich lohnen zu testen, ob man einen versteckten primären Server betreiben und den Anbieter nur als sekundären Server verwenden kann. Bei Linode habe ich diese Einschränkung so umgangen.
Die Option, eine eigene Zertifizierungsstelle zu betreiben und Root-Zertifikate sorgfältig auszuwählen, fehlt.
Der Provider hat Zugriff auf den Host, kann also Arbeiten von außen überprüfen, ohne dass der Nutzer etwas bemerkt
Zum Beispiel müsste man ein Kernel-Modul einschleusen, das auch nach einem Kernel-Upgrade bestehen bleibt und sich selbst hochgradig versteckt. Der Artikel behandelt auch die Analyse von Rohspeicher-Dumps
Was wäre eine grundlegende technische Lösung gegen solche Angriffe durch Staaten oder ähnlich mächtige Akteure? Gibt es einen Weg, den geekigen Traum von Software zu erfüllen, die frei verteilt werden kann und zugleich von niemandem außer dem Autor zensiert, beeinflusst oder verändert werden kann?
Reicht ein sauber gebautes P2P-System auf der heutigen Internet-Infrastruktur als Antwort aus, oder muss man zusätzlich ein globales Mesh-Internet mit geringer Bandbreite über Funk aufbauen?
Ich hoffe, dass sich Freenet 2023 zu einer reibungslosen Developer Experience für P2P-Anwendungen weiterentwickelt