Onion Information

Page Clicks: 0

First Seen: 05/06/2024

Last Indexed: 10/25/2024

Domain Index Total: 219

Skip to content Unsere Webseite hat heute ein kleines Upgrade erfahren. Ab sofort könnt ihr unsere Beiträge auch im “Darknet”, also als Tor Onion Service (Hörempfehlung: DK51 Tor ) hören. Dazu könnt ihr die URL http://m7usgyjxnqd4bmt2oxleh2tijix47zcho5abdu6g6sjato7zmeewy4ad.onion/ in euren Tor-Browser eingeben. Wenn euer Tor-Browser neu genug ist, so zeigt er euch in der Adresszeile auch einen Hinweis an (siehe unten) und ihr müsst einfach nur drauf klicken. Viel Spaß damit! Continue reading "Datenkanal als Tor Onion Service" Nachdem der Umzug auf die neue Seite angekündigt war, meldeten sich einige Leute, die Webseite des Datenkanals nicht aufrufen konnten. Einmal gab einen Fehler 404 . Andere berichteten , dass ein Aufruf von datenkanal.org auf https://insecurity.radio.fm/ umleitet. Ich testete beides von meinem heimischen Internetanschluss oder über eine Tor-Verbindung. In beiden Fällen konnte ich das nicht nachvollziehen. Erst der Aufruf von einem anderen Server erbrachte Klarheit. Denn dieser Aufruf zeigte plötzlich auch eine Umleitung zu https://insecurity.radio.fm. Doch was war hier anders? Eine Sache, die mir direkt ein- und auffiel, war, dass der Server über IPv6 kommuniziert. Mein ISP bietet nur IPv4 an und die meisten Tor-Verbindungen laufen auch nur über IPv4. Ein Blick in die Konfiguration des nginx von datenkanal.org bestätigte dann den ersten Eindruck. Dort fanden sich nur die Zeilen listen 80 listen 443 Als ich die Seite einrichtete, hatte ich zwar daran gedacht, dies aber auf später verschoben. Tja, und dann geriet es in Vergessenheit. Also fügte ich die Zeilen listen [::]:80; listen [::]:443 ssl http2; an der richtigen Stelle ein und schon war dieser Fehler Geschichte. Die Webseite des Datenkanals lag lange Jahre bei einem Server von Thomas Lotze . Aber unsere Sendungen nehmen mittlerweile mehr als 20 GB Platz ein und war es an der Zeit, die auszulagern. Jetzt ist das passiert. Die Webseite läuft jetzt auf einem eigenen Server und hat wieder eine aktuelle PHP-Version. Ich habe die Chance genutzt, das Serendipity und die Plugins auf die letzte Version zu aktualisieren. Aufgrund eines Fehlers der PHP-Version in Verbindung mit Serendipity konnte ich seit einiger Zeit die statischen Seiten nicht aktualisieren. Auch dies habe ich nun getan. Damit ist das Archiv auch wieder auf dem neuesten Stand. Jetzt fehlen nur noch neue Sendungen. Auf dem Server liegen bereits die Sendungen für den Datenkanal 92. Ich will noch kurz warten, ob Probleme auftreten und die ggf. beheben. Sollte das nicht der Fall sein, kommen bald ein paar Sendungen auf die Seite. Genießt das neue Surf- und Hörerlebnis! Vielen Dank an Thomas für die langjährige Unterstützung des Datenkanals! Kürzlich kontaktierte uns ein Hörer und fragte nach, ob man uns auch bei Google Play Music hören könne. Ich bin daraufhin in die Untiefen der Anmeldung des Podcasts hinabgestiegen. Heute erhielt ich dann die Nachricht, dass der Podcast nun auch bei Google Play Music gehört werden kann. Solltet das nutzen, könnt ihr jetzt auch den Datenkanal darüber hören. Wir haben über die letzten Jahre mehr als 50 Folgen produziert. Die meisten der Sendungen gibt es in den Formaten MP3 , OGG und Opus . Das bedeutet grob überschlagen, brauchen wir pro Sendung 250 MB Plattenplatz. Dort liegt unser aktuelles Problem. Derzeit wird der Datenkanal von einem guten Freund und Softwareentwickler gehostet. Er informierte uns kürzlich, dass die Dateien einen großen Teil des Plattenplatzes auf dem Server ausmachen. So überlegten wir, wie wir künftig weitermachen. Ich würde die Dateien gern auf einen anderen Rechner auslagern und wir hätten gern wieder eine Lösung, die von unseren Hörerinnen und Hörern getragen ist. Daher meine Frage an euch: Habt ihr etwa 20 GB Platz auf einem eurer Rechner, der die Dateien per HTTP ausliefern kann? Jörg und ich freuen sich über Rückmeldungen als Kommentar, per E-Mail bzw. über Quitter oder Twitter . Vielen Dank! Im Datenkanal-Chat und anderswo gab es Diskussionen über die RSS-Feeds. Die unten stehende Liste zeigt, welche Feeds derzeit aktiv sind und benutzt werden können. RSS2-Feed mit MP3-Dateien (sollte für alle Abspielsoftware funktionieren) RSS2-Feed mit OGG-Dateien (kann Probleme mit manchen Smartphones geben) RSS2-Feed mit Opus-Dateien (funktioniert derzeit vermutlich auf keinen Smartphones) Die folgenden Feeds können bei mancher Software Probleme bereiten. Insbesondere wurde in der Vergangenheit immer Pocket Casts als problematisch genannt: RSS1-Feed mit sämtlichen Einträgen RSS2-Feed mit sämtlichen Einträgen ATOM-1.0-Feed mit sämtlichen Einträgen RSS2-Kommentar-Feed mit allen Kommentaren RSS2-Feed mit MP3-Dateien RSS2-Feed mit OGG-Dateien RSS2-Feed mit Opus-Dateien Bei den beiden obigen Feeds kann die Variable version andere Werte enthalten. Nach dem jetzigen Stand der Software sind das: opml1.0 , 0.91 , 1.0 , 2.0 , atom0.3 und atom1.0 . Feed zu allen Artikeln, die als »Sendung« eingeordnet sind . Diese Feed-Adressen sind im Menü bei anderen Kategorien verlinkt. Feed zu dem Tag »Interview« . Vor dem Namen des Tags im Menü befindet sich eine kleine Grafik. Diese verlinkt auf den Feed zu einem bestimmten Tag. Feed für Torrents als MP3 Feed für Torrents als OGG Feed für Torrents als Opus Dann hoffe ich, ihr findet den richtigen Feed für eure Zwecke und hört fleißig unsere Sendungen. Update: Die Feeds bei Bitlove funktionieren nicht mehr. Links gestrichen. Wer sich in den letzten Tagen mit der Webseite des Datenkanals verbinden wollte, erhielt unter Umständen eine Fehlermeldung vom Browser. Jens ist dem Problem auf den Grund gegangen und jetzt funktioniert alles, wie es soll. Woran lag das Problem? Wir setzen beim Datenkanal auf ein Zertifikat von Let’s Encrypt . Unser erstes Zertifikat wurde Ende 2015 ausgestellt und im März gab es eine Erneuerung des Zertifikats. Zur selben Zeit gab Let’s Encrypt eine Erneuerung der Intermediate-Zertifikate bekannt. Jens stellte zuerst Probleme fest, als er sich mit dem Tor-Browser zum Datenkanal verbinden wollte. Ein Chromium v50 sowie ein Firefox v45 funktionierten problemlos. Eine Nachfrage beim Twitter ergab ein bunt durchmischtes Bild: Wer von euch bekommt eine HTTPS-Warnung beim Besuch von https://t.co/a2XtkPupso (welcher Client/Browser)? /cc @datenkanal - Jens Kubieziel (@qbi) 24. April 2016 Chromium v49 warnte . Bei anderen warnte weder Chromium noch der Tor-Browser. Schließlich hatte Hanno den entscheidenden Hinweis : Browser speichern die Informationen über die Zertifikatskette zwischen. In seinem Blogbeitrag Incomplete Certificate Chains and Transvalid Certificates ist das detailliert erklärt. Woran lag dann also unser Problem? Die Ausstellung und Erneuerung der Zertifikate übernimmt das Shellskript lets_encrypt.sh . Das stammt von lukas2511/letsencrypt.sh ab. Im Skript finden sich folgende Zeilen: :> grep ROOTCERT lets_encrypt.sh ROOTCERT=“public-lets-encrypt-x1-cross-signed.pem” cat “${BASEDIR}/${ROOTCERT}” >> “${BASEDIR}/${domain}/${domain}-certchain.pem” printf “ ”; openssl verify -CApath $rootcerts ${ROOTCERT} printf “ ”; openssl verify -CApath $rootcerts -untrusted ${ROOTCERT} ${domain}/${domain}-certchain.pem curl -sS -L -o ${BASEDIR}/${ROOTCERT} https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem Das heißt, es wird eine Umgebungsvariable namens ROOTCERT angelegt und dort der Name des Let’s-Encrypt-Intermediate-Zertifikats gespeichert. Die Zeile, die mit cat beginnt, kopiert das Intermediate-Zertifikat an das Ende des eigenen Zertifikats und die mit curl beginnende Zeile lädt die Datei herunter. Das erneuerte Zertifikat hat jedoch ein x3 statt x1 im Namen. Damit kopierte das Skript also das falsche Zertifikat in die Datei. Der Fehler ließ sich schnell beheben. Wir fanden den Fehler anfangs nicht und begannen alternativ mit Neilpang/acme.sh zu experimentieren. Denn das Skript machte bei der Challenge immer noch Probleme. Die Challenge schien mit acme.sh gegen den Testserver von Let’s Encrypt zu funktionieren. Daher entschieden wir uns, das live zu testen. Die Challenge funktionierte, ein Zertifikat wurde erstellt. Doch, oh weh, die Zertifikatskette war wieder unvollständig. Allerdings zeigte sich bei einem Blick in die lokal gespeicherte Zertifikatsdatei, dass das Intermediate-Zertifikat fehlte. Das kopierte ich mit hinein und schon haben wir funktionierendes TLS . Jetzt muss unser Sysadmin nur noch die DH-Parameter anpassen und alles ist grün.