Skip to content

Datenkanal als Tor Onion Service

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"

Fehlerbereinigung

Nachdem der Umzug auf die neue Seite angekündigt war, meldeten sich einige Leute, die 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.

Umzug der Webseite

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!

Datenkanal bei Google Play Music

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.

Listen on Google Play Music 

In eigener Sache: Wer hat Platz für ein paar Datenkanal-Dateien?

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!

Übersicht der verfügbaren Feeds

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.

Die folgenden Feeds können bei mancher Software Probleme bereiten. Insbesondere wurde in der Vergangenheit immer Pocket Casts als problematisch genannt:

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.

TLS-Probleme beim Datenkanal

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.

tweetbackcheck