Skip to content

Delta Chat mit GMail betreiben

Vor kurzem schrieb ich in einem Artikel über meine Kommunikationswerkzeuge. Dort fehlte ein Werkzeug, welches ich schon seit längerem auf dem Schirm habe, aber noch nie wirklich getestet hatte: Delta.Chat.

Die Software erlaubt es, mit anderen zu chatten und nutzt im Hintergrund E-Mail zur Verteilung der Chatnachrichten. Damit kann man mit allen Leuten chatten, die eine E-Mail-Adresse haben. Das hat natürlich den großen Vorteil, dass nahezu alle erreichbar sind. Delta Chat legt einen OpenPGP-Schlüssel an und verschlüsselt die Nachrichten, sofern der Empfänger ebenfalls einen hat.

Somit werden die Nachrichten von Leuten, die Delta Chat einsetzen verschlüsselt verschickt. Vermutlich klappt das auch. Ich habe es noch nicht probiert. Bei allen anderen werden die Nachrichten als E-Mails unverschlüsselt geschickt.

Nun wollte ich ein GMail-Konto benutzen, um einen Test mit Delta Chat zu machen. Ich gab meine Zugangsdaten ein und es klappte nicht:

Fehler bei Delta Chat

Delta Chat nimmt zu Port 143 Kontakt auf, obwohl 993 eingestellt ist.

Auf eine Nachfrage bei Twitter und Mastodon meldete sich einer der Entwickler und bat darum, das Log zu exportieren. Ein Blick auf diese Meldungen verriet mir, dass Delta Chat erfolglos versuchte, sich bei Google anzumelden. Dies lag an der aktivierten Zwei-Faktor-Authentifizierung. Wer dies aktiviert hat, muss unter Umständen pro Anwendung ein spezielles Passwort anlegen. App-Passwort

Geht dazu auf euren Google-Account. Im Bereich Sicherheit gibt es einen Menüeintrag für App-Passwörter. Unten auf der Seite wählt ihr eine App und ein Gerät aus. Danach könnt ihr die App-Passwörter generieren. Dieses 16-stellige Passwort könnt ihr nun direkt bei Delta Chat als Passwort zusammen mit eurer E-Mail-Adresse eintragen. Solltet ihr einen “normalen” GMail-Account haben, so bestätigt ihr die Einstellungen und mit etwas Glück seid ihr fertig.

In meinem Fall lautete das GMail-Konto nicht auf @gmail.com, sondern auf eine andere Domain. Delta Chat versuchte daher zuerst, sich mit einem Server unter der Domain zu verbinden. Da dieser nicht existierte, gab es eine weitere Fehlermeldung.

Wenn man bei Delta Chat die erweiterten Einstellungen öffnet, kann man dann die korrekten Server von GMail einstellen. Allerdings klappte dies bei mir auch erst im zweiten Versuch. Denn obwohl der Port 993 eingestellt war und automatisch die korrekte IMAP-Sicherheit gewählt werden sollte, klappte dies nicht. Ich musste explizit SSL/TLS einstellen:

Screenshot
Screenshot mit den korrekten Einstellungen

Nach diesen Einstellungen klappte alles und ich konnte meine ersten Versuche starten. Falls es also bei dir auch nicht klappen sollte, hilft dir vielleicht die obige Beschreibung.

Wenn ihr mit mir Kontakt aufnehmen wollt, so könnt ihr die Adresse <deltachat@kubieziel.de> verwenden. Es kann jedoch sein, dass ich irgendwann das Testen einstelle und die Adresse wieder lösche. :-)

Blog entflickt

In einem Beitrag vor ein paar Tagen kam ich zu der Ansicht, dass spätestens mit der Anwendung der Datenschutz-Grundverordnung am 25. Mai 2018 Flickr nicht mehr genutzt werden kann. Das bedeutete für mich, dass ich mein Blog auf Bilder prüfen muss, die über Flickt eingebunden werden. Soweit ich das sehe, ist das jetzt abgeschlossen. Es sollten keine Bilder mehr über Flickr und andere fremde Quellen kommen.

Weiterhin habe ich geprüft, ob ich bei YouTube-Videos die Domain youtube-nocookie.com verwende. Auch dies sollte jetzt der Fall sein. Damit kommen die Videos hier im Blog entweder von obiger YouTube-Seite oder von media.ccc.de.

Solltet ihr noch Sachen finden, die von woanders eingebunden werden, freue ich mich über einen Hinweis in den Kommentaren.

Infosec Bytes -- Videoanleitungen zur sicheren Kommunikation

Ich habe in den letzten Tagen ein wenig mit Infosec Bytes zusammengearbeitet. Die Organisation enstammt dem Centre for Investigative Journalism und möchte anderen Journalisten Trainings im sicheren Umgang mit dem Rechner und dem Netz bieten. Hierzu wurden eine Reihe von Videos veröffentlicht, andere Publikationen sind noch in der Pipeline.

Hier findet ihr beispielsweise eine kleine Einführung zu Tor:

Why journalists and whistleblowers need to understand infosecurity

Vorsicht vor gefälschten PGP-Schlüsseln

Wer mir eine OpenPGP-verschlüsselte E-Mail schicken will, sollte demnächst doppelt vorsichtig sein. Ich entdeckte heute, dass es zur Key-ID 0xEA3E4D61 zwei Schlüssel gibt. Einer der beiden wurde vermutlich automatisch erzeugt und gehört mir nicht! Der Fingerabdruck meines derzeitig aktiven Schlüssels ist:

pub   4096R/0x65B3F094EA3E4D61 2010-01-15
Schl.-Fingerabdruck = 60D8 5B8D 9A1C D2D1 355E  BE9F 65B3 F094 EA3E 4D61
uid                  Jens Kubieziel <jens@kubieziel.de>
uid                  Jens Kubieziel <jens@freie-re.de>
uid                  Jens Kubieziel <kubieziel@gmx.de>
uid                  Jens Kubieziel <lugjena@kubieziel.de>
uid                  Jens Kubieziel <jens@torservers.net>
sub   4096R/0x7A0A527D47FFDBE1 2010-01-15

Wenn ihr mir eine verschlüsselte E-Mail schicken wollt, vergleicht unbedingt die obige zweite Zeile. Im Allgemeinen empfiehlt es sich in der Konfigurationsdatei von GnuPG die Variable keyid-format 0xlong oder gleich long zu setzen. Die kurze Key-ID ist, wie oben zu sehen, leicht zu fälschen.

Update: Das Problem betrifft nicht nur mich. Auf Twitter war von mehreren Fällen zu lesen und auch die Kernel-Entwickler sind betroffen.

Keysigning bei den Chemnitzer Linux-Tagen 2016

Am 19. und 20. März fanden in Chemnitz wieder die Chemnitzer Linux-Tage statt. Einer alten Tradition folgend organisierte ich das Keysigning. Das heißt, Leute mit einem OpenPGP-Schlüssel können teilnehmen und sich gegenseitig ihre Identität bestätigen. Durch die Prüfung und Signatur wird das Vertrauensnetz (Web of Trust) gestärkt.

In den letzten Jahren stellten wir uns dazu in einer Reihe auf. Die erste Person bewegte sich dann zur zweiten und anschließend zur dritten, vierten usw. Nachdem die erste Person vorbei war, fing die zweite an. So sah das ungefähr aus:

Startaufstellung:

1 2 3 4 5 6 7 8 9 10

Erste Person startet:

2 3 4 5 6 7 8 9 10
1

Zweite Person startet:

3 4 5 6 7 8 9 10
2 1

Nach einer Weile startet die sechste Person:

7 8 9 10 1
6 5 4 3 2

Das heißt, die erste Person reiht sich wieder ans das Ende ein. Eine Reihe zeigt jeweils den Ausweis und die andere Reihe vergleicht.

Bei dem Verfahren ist nun der Nachteil, dass anfangs sehr viele Leute im Leerlauf sind. Sie müssen warten, bis die erste Person endlich bei denen angekommen ist. Um dies ein wenig zu beschleunigen, haben wir die Reihe dieses Jahr direkt gefaltet. Nach der Sortierung in eine Reihe stellten sich alle gegenüber auf:

1 2 3 4 5
10 9 8 7 6

Die Idee war, dass wieder eine Reihe prüft und die andere den Ausweis zeigt. Leider habe ich das wohl nicht genau genug erklärt und es wurde parallel von beiden Seiten gemacht. Als die Reihe nun zur Hälfte abgearbeitet war, kamen die Teilnehmer bei ursprünglichen Gegenüber wieder an und nahmen an, alle erwischt zu haben. Dies ist aber nicht der Fall:

2 3 4 5 6
1 10 9 8 7

Die Aufstellung oben ist nach dem ersten Wechsel. In der initialen Aufstellung verglich beispielsweise Teilnehmer 3 mit Teilnehmer 8 die Daten. In obigem Schritt vergleicht 3 mit 10 usw. Nach fünf Schritten stehen sich 3 und 8 wieder gegenüber. Teilnehmer 3 hat dann die Identität der Teilnehmer 8, 10, 2, 4 und 6 verifiziert. Was ist mit 1, 5, 7 und 9? Diese fehlen offensichtlich. Es kostete mich einige Mühe die Teilnehmer zu überzeugen, dass der Lauf noch nicht beendet ist. Hoffentlich kann ich alle dann im nächsten Jahr auf diese Seite verweisen und die Überzeugungsarbeit wird einfacher. :-)

Wer sich für den Stand des Web of Trust interessiert:

Web of Trust @ CLT 16
tweetbackcheckcronjob