Onion Information

Page Clicks: 0

First Seen: 05/06/2024

Last Indexed: 10/25/2024

Domain Index Total: 219

Skip to content Entries tagged as https Related tags ca cacert dns duckduckgo hsts podcast protokoll ssl tls zertifikat browser dnssec git icann katzenpost matrix postel riot sicherheit webseite google android antivirus betriebssystem google play music http quic spdy udp cookie internet letsencrypt firefox frag den staat gmail latex open source transparenz Das Radio OKJ hat wieder seine Pforten geöffnet und so trafen wir uns wieder im Studio, um eine Sendung aufzuzeichnen. Anfangs mussten wir die richtigen Knöpfe und Regler finden. Doch dann konnte die Sendung, wie gewohnt, starten. Das Thema der Sendung war das Hypertext Transfer Protocol, HTTP. Wir sprachen ein wenig darüber, woher HTTP kommt und wie es funktioniert. Dadurch kamen wir auch auf einige der Probleme des Protokolls zu sprechen. Diese führten dann zu verschiedenen Weiterentwicklungen, wie SPDY, HTTP2 und schließlich HTTP3. Jörg erklärte einige der Neuerungen und wir hoffen, dass wir dann bald das Protokoll in der Realität einsetzen können. Download und Anhören DK094-HTTP3.opus DK094-HTTP3.ogg DK094-HTTP3.mp3 Shownotes DK77: Webseiten im Browser anzeigen I DK78: Webseiten im Browser anzeigen II HTTP3 explained What’s the Difference Between a URI and a URL? What is the difference between a URI, a URL and a URN? Gopher 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 DK045-TLS1.opus ( als torrent ) DK045-TLS1.ogg ( als torrent ) DK045-TLS1.mp3 ( als torrent ) Musik Manhat10 mit Look At You Shownotes DK23: Verschwörungstheorien Illuminati rückwärts DK25: NSA Deutsches Radioarchiv Kuchenstud.io DerSender Lage der Nation Technische Aufklärung, Podcast zum NSA-Untersuchungsausschuss WP: Transport Layer Security WP: Microsoft Edge WP: Thawte , die CA, von der Jörg sprach HTTPS Everywhere von der EFF sslstrip How does SSLstrip work? Verschlüsselung im Thüringer Landtag Technical White Paper: Traffic Analysis on Google Maps with GMaps-Trafficker (PDF) CAcert Color map of CAs von der EFF The EFF SSL Observatory Google Online Security Blog: Maintaining digital certificate security Operation Socialist: The Inside Story of How British Spies Hacked Belgium’s Largest Telco 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.