Qbi's Weblog

In meinem vorigen Beitrag hatte ich über den vergleichsweise neuen RFC 9116 geschrieben. Der RFC 742 ist hingegen schon 45 Jahre alt. Der definierte damals das Finger-Protokoll, mit dem sich Informationen über Benutzer:innen gewinnen ließen:

jens@host:~$ finger
Login     Name               Tty      Idle  Login Time   Office     Office Phone
peter     Peter Ones        *:3             Apr 19 13:09 (:3)
paul      Paul Twos         *:2             Apr 17 21:01 (:2)
mary      Mary Threes       *:1             Apr  2 22:38 (:1)

Oder für einen bestimmten Username:

jens@host:~$ finger peter
Login: peter                       Name: Peter Ones
Directory: /home/peter             Shell: /bin/bash
On since Sun Apr 17 21:01 (CEST) on :2 from :2 (messages off)
No mail.
No Plan.

Kürzlich fand ich heraus, dass ich auch Personen bei Mastodon, einem Twitter-ähnlichen sozialen Netzwerk, fingern kann. Hierzu benötigt man im wesentlichen die Domain der Mastodoninstanz und den Usernamen. Daraus wird eine Anfrage gebaut, die wieder das .well-known-Verzeichnis nutzt, welches ich schon im letzten Beitrag erwähnt hatte.

Eine Anfrage auf die Adresse https://mastodon.social/.well-known/webfinger?resource=acct:qbi@mastodon.social liefert dann folgendes Ergebnis:

{
  “subject”: “acct:qbi@mastodon.social”,
  “aliases”: [
    “https://mastodon.social/@qbi”,
    “https://mastodon.social/users/qbi”
  ],
  “links”: [
    {
      “rel”: “http://webfinger.net/rel/profile-page”,
      “type”: “text/html”,
      “href”: “https://mastodon.social/@qbi”
    },
    {
      “rel”: “self”,
      “type”: “application/activity+json”,
      “href”: “https://mastodon.social/users/qbi”
    },
    {
      “rel”: “http://ostatus.org/schema/1.0/subscribe”,
      “template”: “https://mastodon.social/authorize_interaction?uri={uri}”
    }
  ]
}

Das bedeutet, den angefragten Username gibt es und dessen Profil ist unter der Adresse https://mastodon.social/users/qbi verfügbar.

Im Allgemeinen heißt dieses Protokoll Webfinger und ist für die Mastodon-Instanzen verfügbar. Probiert es doch mal aus!

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag.

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

• Reddit
• Wikipedia
• Zoom
• Netflix
• Stackoverflow
• Apple
• und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

• Eintrag in der Wikipedia
• Homepage securitytxt
• Beitrag bei KrebsOnSecurity

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

Dieser Text ist eine Übersetzung des Blogpostings Why offer an Onion Address rather than just encourage browsing-over-Tor? von Alec Muffett. Alex pflegt auch eine Liste nützlicher Onion-Adressen.

---

Es gibt eine Reihe von Gründen, eine Onion-Site einzurichten. Ein Reihe von Vorteilen waren für Plattformen wie Facebook, BBC oder NYTimes von Nutzen.

Die ersten Vorteile sind Authentizität und Verfügbarkeit: Wenn du den Tor-Browser benutzt und genau die richtige Onion-Adresse eingibst, bist du garantiert mit der erwarteten Seite verbunden, was du erwartest - oder eben gar nicht.

Das ist für die Menschen sehr einfach zu begreifen und auch einfach zu erklären.

Diese Funktion entschärft Angriffe, die von möglicherweise bösartigen “Tor-Exit-Knoten” ausgehen können. Die Angriffe sind zwar selten, existieren aber dennoch. Die Tatsache, dass du eine “.onion”-Adresse verwendest, setzt voraus, dass du Tor und den Tor-Browser verwendest. Dies entschärft die folgenden möglichen Angriffe:

• landesweite Websperren
• Man-in-the-Middle-Angriffe auf das TLS-Protokoll
• SNI-Filter
• Tracking und Zensur von DNS-Anfragen (betrifft sowohl Clients wie auch Exitknoten)
• Probleme beim Tracking durch Cookies und Fingerprinting-Angriffen
• … sowie eine Reihe weiterer Probleme

Um es anders zu formulieren: Die Werbung für eine Onion-Adresse ist ein implizites Verkaufsargument für die Nutzung von Tor.

Update: Eine Sache, die ich in der ursprünglichen Version dieses Beitrags vergaß zu erwähnen, ist, dass die Nutzung von Onion-Netzwerken für Seiten mit hohem Traffic den Druck auf die Exit-Node-Infrastruktur von Tor reduziert. Denn der Traffic fließt stattdessen durch die größere und reichhaltigere Menge an Middle-Relays, ohne Exit-Nodes und/oder das Klartext-Internet zu nutzen.

Letzteres ist wichtig und bringt uns zum zweiten (dritten?) Satz von Vorteilen:

Der Betrieb einer Onion-Site ist eine Verpflichtung [der Plattform], mit Tor-Benutzer:innen gerecht umzugehen; bei der normalen Benutzung von Tor werden die Benutzer mit allen anderen vermischt, die aus dem Internet kommen, und (seien wir ehrlich) einige Leute benutzen Tor manchmal zum Herunterladen einer kompletten Webpräsenz (Scraping) oder anderem unangenehmen Verhalten.

Das führt zu der Herausforderung, die “Spreu vom Weizen zu trennen”.

Das Einrichten einer Onion-Adresse ist jedoch ein praktischer Schritt, der zeigt, dass die Plattform explizit auf die Bedürfnisse von Tor-Nutzern eingeht, und nun kehrt sich das Problem um: Ein gewisses Maß an schlechtem Verhalten über die Onion-Adresse kann überwacht und als “schlechtes Verhalten” eingestuft werden, was den Tor-Nutzern maximale Freiheit gewährt.

Dies ist eine Angelegenheit, die ich bei Facebook hautnah miterlebt habe und auf einer Tor-Mailingliste beschrieben habe.

Wenn ich die Vorteile in einem Satz zusammenfassen sollte, wäre es folgender: Eine Onion-Adresse ist ein Versprechen und ein Mechanismus, der sicherstellt, dass du die Bedürfnisse der Leute, die Tor benutzen, ernst nimmst.

Anstatt ihnen zum Beispiel eine endlose Reihe von CAPTCHAs auf Basis der IP-Reputation aufzudrängen.

 

 

Im Podcast TILpod war Wissensmanagement mit Obsidian und Logseq kürzlich das zentrale Thema. Dirk Deimeke und Sujeevan Vijayakumaran berichteten über deren Erfahrungen mit den Tools Logseq und Obsidian. Im Rahmen meines Jobs betreue ich derzeit eine ERP-Software und dort gibt es viele Knöpfe, Einstellungen, Möglichkeiten etc. Daher wollte ich beide Werkzeuge mal testen und prüfen, ob die sich irgendwie in meine Arbeit integrieren lassen. Der Blogbeitrag ist das Ergebnis meiner ersten Schritte. Ich will hier mal die frischen Erkenntnisse niederschreiben.

Bei meiner Liste der Android-Apps fielen mir einige auf, die ich mal näher vorstellen will. Heute ist Noice dran.

Wie könnt ihr am besten arbeiten? Bei absoluter Ruhe, mit Musik oder stört euch der Geräuschpegel gar nicht?

Ich habe festgestellt, dass absolute Ruhe mich eher ablenkt. Für gute Konzentration benötige ich entweder Musik oder eine andere Form von Geräuschen. Vor einigen Jahren war ich in Deutschland unterwegs und in dem Ort gab es weder vernünftige Handyabdeckung noch funktionierendes WLAN. In fahrbarer Nähe gab es einen Erlebnispark mit kostenlosem und funktionierendem WLAN. Dort sass ich inmitten eines Kinderspielplatzes und konnte arbeiten, ohne dass mich die Geräuschkulisse stört.

Bei meinen Streifzügen durch F-Droid stieß ich auf die App Noice. Diese stellt verschiedene Geräusche zur Verfügung und spielt diese einzeln oder gemischt vor.

So könnte ich beispielsweise simulieren, dass ich in einem Flugzeug sitze, zu verschiedenen Zeiten kommt mal ein Anschnallsignal während es durch ein Gewitter fliegt und sich die Menschen im Flugzeug unterhalten. Oder ich sitze am Meer höre das Rauschen bei leichtem Wind und mildem Regen.

Durch diese Einstellungen ergibt sich eine Geräuschkulisse, die im Hintergrund da ist, ohne wirklich zu stören. Wenn ihr also auch auf Hintergrundgeräusche steht, holt euch die App aus dem F-Droid-Store.

Bei Jörg sah ich kürzlich eine Liste von Android-Apps, die er verwendet. Solch eine Liste kann eine gute Idee sein, um neue interessante Apps zu finden. Daher habe ich beschlossen, auch eine solche Liste aufzustellen.

Bei meinen Reisen durch die Statisken bei OWID verglich ich kürzlich verschiedene Länder bezüglich deren Impfungen, Einweisungen in Krankenhäuser etc. Dabei stieß mir der Vergleich zwischen den USA, Dänemark und Slowenien ins Auge.

Auf dem Bild links oben ist der Verlauf der Impfungen in den einzelnen Ländern gedruckt. Dabei liegt Dänemark weit vorn, gefolgt von den USA und am Ende liegt Slowenien. Zu Ende Januar 2022 sind in Dänemark weit über 80% der Bevölkerung vollständig geimpft (USA: 63%, Slowenien: 58 %).

Links oben sind die aktuellen Fallzahlen. Sowohl Dänemark wie auch Slowenien schießen nach oben während die USA weniger als die Hälfte der slowenischen Fallzahlen hat.

Links unten sind dann die Personen auf den Intensivstationen verzeichnet. Insbesondere Slowenien hat hier einen enormen Ausschlag. Leider fehlt bei OWID eine Möglichkeit, die Gesamtzahlen zu ermitteln. Aber grob geschätzt sind die Zahlen zwischen Oktober 2020 und Juli 2021 sowie September 2021 bis jetzt (Januar 2022) etwa gleich. Die Zahlen aus den USA sind leicht geringer geschätzt und Dänemark liegt dann deutlich darunter.

Schließlich finden sich rechts unten die Anzahl der Todesfälle. Bis Ende Oktober 2020 lagen die USA deutlich an der Spitze gefolgt von Dänemark und am Ende Slowenien. Ab Dezember 2020 bis heute sind die Todeszahlen in Slowenien am höchsten dicht gefolgt von den USA. Dänemarkt hat etwa ein Viertel der Zahlen der anderen beiden Länder.

Der Vergleich zeigt, dass Dänemark unter den drei Ländern bisher am besten durch die Pandemie gekommen ist. Sowohl Fallzahlen, wie auch Menschen in den Krankenhäusern wie auch die Todeszahlen liegen deutlich unter den USA und Slowenien. Aber auch im Zeitreihenvergleich steht Dänemark gut da. Heute hat das Land fünfzehnmal mehr Fälle als zu Weihnachten 2020. Jedoch liegen des Todesfälle deutlich unter den Hochs aus der Zeit. Aktuell liegen die etwa halb so hoch, sind aber noch am steigen.

Diese Entkopplung von Fall- und Sterbezahlen zeigt sich bei allen drei (und auch bei anderen) Ländern:

Ich habe die Ansicht in der obigen Grafik mal auf den Zeitraum zwischen Dezember 2020 und 2021 beschränkt. Denn durch den hohen Anstieg der Fallzahlen wird die Kurve zu “flach”. Bereits hier zeigt sich die Entkopplung von Fall- und Todeszahlen. In Dänemark und Slowenien gehen die Fallzahlen deutlich hoch, während die Zahl der Toten deutlich weniger steigt. Für Slowenien zeigt sich der Effekt noch viel deutlicher, wenn der Startzeitpunkt im OKtober 2020 liegt. Allerdings hinterlässt die Omikron-Wand in Slowenien schon jetzt deutliche Spuren. Dort hat sich die Zahl der Toten in den letzten beiden Wochen verdoppelt (bei einer Verdrei- bis Vervierfachung der Fallzahlen). Wenn sich das so fortsetzt, sollten die Zahlen etwas über die Spitze der Delta-Welle steigen und immernoch deutlich unter denen vom Jahresende 2020 liegen.

Aus meiner Sicht zeigt sich in diesen Zahlen der Erfolg der Impfung. Alle anderen Maßnahmen sind zu verschiedenen Graden in den betreffenden Ländern heruntergefahren worden. So dass die Impfung hier einen großen Schutzfaktor einnimmt.

Im Falle der USA ist der Effekt nicht so deutlich mit Bildern zu sehen. Hier müsste man die Daten mehr nach den einzelnen Ländern aufgliedern und würde dort dann ebensolche interessanten Erkenntnisse gewinnen. Das ist jedoch Thema für einen anderen (noch nicht geschriebenen) Blogbeitrag.