Skip to content

DK84: Sammelsurium Teil 6

Unsere Sendung ist wieder eine Zusammenstellung verschiedener kleiner offener Punkte. Wir bekamen Kritik zu unserer letzten Sendung. Offensichtlich war der Eindruck entstanden, dass wir Kerning und optischen Randausgleich für gleich halten. Daher gehen wir hier nochmal kurz auf die Unterscheidung ein.

Nach einem kurzen Ausflug in TLS und OSCP sprechen wir über Public Money, Public Code und kommen auf die Anhörung im Thüringer Landtag zum Transparenzgesetz. Jens war dort zur mündlichen Anhörung geladen und berichtet von seinen Eindrücken. Jörg kommt dann noch auf Abi-Aufgaben zu sprechen. Hier hat FragDenStaat.de etwas.

Unser Browser zeigt eine Warnung bezüglich der Plugins an. Das bringt uns zu dem Debakel bei den Zertifikaten der Plugins.

Am Ende springen wir zu Google und der Ablehnung von Mails durch GMail. Diverse Leute fordern auch die Zerschlagung von Google. Jörg ist der Meinung, dass Google dem mit der Neustrukturierung zu Alphabet zuvorkommt. Eine Diskussion um die neuen Matrix-IDs bildet dann den Abschluss.

Download und Anhören

DK47: TLS: Gefährdungen für Anwender, Betreiber und CAs

Der 47. Datenkanal ist eine Fortsetzung unserer Gespräche über TLS. Wir diskutieren, wo Probleme und Gefahren für Endanwender, Serverbetreiber und CAs liegen. Dabei geht es uns um Schwächen in der Benutzung und Umsetzung. Die Schwachstellen im Protokoll haben wir uns für eine spätere Sendung aufgehoben.

Neben dem TLS-Thema sprechen wir anfangs über die Suchmaschine DuckDuckGo und deren Features sowie über Speed Listening, also das Anhören von Audio mit mehrfacher Geschwindigkeit.

Download und Anhören

Musik

Wir spielten in der Sendung den Titel Penumbra von Taro.

Shownotes

DK46: Vom Zertifikat zur HTTPS-Seite

SSL Added and Removed Here sticker, Ben "OpenSSL" Laurie's laptop, Whitecross Street, Barbican, London, UK

Unsere Sendung begleitet den Weg von der Stunde 0, also einem Webserver ohne TLS-Zertifikat, bis zu einer fertigen TLS-Verbindung. Wir starten dabei bei der Erschaffung eines Schlüssels und dem Anlegen eines Certificate Signing Requests (CSR). Jens geht kurz auf das ACME-Protokoll von Let’s Encrypt ein. Nachdem wir das Zertifikat erhalten haben, wird es installiert und im Webserver eingestellt. Jetzt kann die Webseite von außen über HTTPS erreicht werden. Wir versuchen zu erklären, wie das Handshake Protokoll bei TLS funktioniert und gehen kurz auf das Alert Protokoll ein.

Download und Anhören

Musik

In der Sendung gab es keine Musik.

Shownotes

DK45: TLS, Zertifikate und Seitenkanalangriffe

Die Sendung ist der Startpunkt einer Sendereihe zu SSL/TLS. Wir wollen uns über mehrere Sendungen dem Thema nähern. Der Datenkanal gibt erstmal einen groben Überblick zur Geschichte des Protokolls. Daneben sprechen wir Zertifikate an, erklären, wie man zu Zertifikaten kommt und gehen auf einige Probleme mit CAs ein.

Daneben verfolgen wir in der Sendung einige Seitenstränge. Jens spricht zu Anfang über seine weiteren Podcast-Ideen und verweist auf die Podcasts Lage der Nation und Technische Aufklärung, den Podcast zum NSA-Untersuchungsausschuss. Daneben diskutieren wir später diverse Seitenkanalangriffe gegen verschiedene IT-Systeme.

Download und Anhören

Musik

Shownotes

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