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. :-)

Kommunikationswerkzeuge

Dirk beschreibt in einem Blogposting und dem Update dazu seine Kommunikationswerkzeuge. Ich habe mir mal angeschaut, wie das bei mir aussieht:

Nutze ich

  • E-Mail (ist für mich eines der Hauptkommunikationsmittel. Daher kann ich Dirks These so nicht unterschreiben.)
  • Signal
  • XMPP/Jabber
  • Jitsi
  • Keybase
  • Matrix (@qbi:matrix.kraut.space)
  • Mumble
  • Slack (nicht wirklich erreichbar, da ich den Client nur manchmal öffne)
  • SMS
  • Threema
  • Twitter DM (nicht aktiv genutzt, wird aber als Kanal genutzt)
  • Wire
  • Zoom

Nutze ich nicht (mehr)

  • Briar (würde ich gern, hier fehlen mir Leute, die das auch benutzen)
  • Mattermost
  • Telegram
  • WhatsApp

Alles, was nicht genannt ist, fällt vermutlich in die Kategorie nicht genutzt. ;-)

Eine Auskunft nach der DS-GVO bitte

Viele von euch werden Ende Mai viele E-Mails erhalten haben. Firmen wollten unbedingt Informationen über deren hervorragenden Datenschutz loswerden und in einigen Fällen wurde dazu aufgerufen, in irgendetwas einzuwilligen. Doch ging es euch auch so, dass da Firmen dabei waren, von denen ihr noch nie gehört habt?

Mir ging es so. Ich bekam einige E-Mails von Firmen, die ich nicht kenne und wo ich mich nicht erinnern kann, mit denen in einer Beziehung zu stehen. Ein Blick in die Datenschutz-Grundverordnung zeigt, dass es da ein wichtiges Recht für mich als Bürger gibt: das Auskunftsrecht.

Also werde ich das jetzt mal anwenden. Mit dem untenstehenden Muster schreibe ich die Firmen an und bitte um Auskunft. Falls ihr mögt, könnt ihr dies ebenfalls verwenden. Das lässt sich aber auch noch erweitern bzw. anpassen.

Sehr geehrte Damen und Herren,


die untenstehende E-Mail erreichte mich auf meiner persönlichen E-Mail-Adresse <FOO@example.com>. Nach Art. 15 DS-GVO habe ich ein Auskunftsrecht über meine personenbezogenen Daten.


Bitte teilen Sie mir daher gemäß Art. 15 Abs. 1 DS-GVO mit, ob Sie personenbezogene Daten verarbeiten und geben Sie ggf. Auskunft über diese Daten. Insbesondere möchte ich Sie bitten, mir die folgenden Informationen mitzuteilen:

  1. Welche Daten über meine Person sind bei Ihnen gespeichert oder werden durch Sie verarbeitet?
  2. Zu welchem Zweck wurden diese Daten verarbeitet?
  3. Welchen Empfängern oder Kategorien von Empfängern wurden meine personenbezogenen Daten offengelegt?
  4. Sofern die personenbezogenen Daten nicht bei mir erhoben wurden, geben Sie mir bitte alle verfügbaren Informationen über die Herkunft der Daten.
  5. Falls meine personenbezogenen Daten an ein Drittland oder eine internationale Organisation übermittelt wurden, bitte ich Sie, mir mitzuteilen, welche Garantien gemäß Art. 46 DS-GVO vorgesehen sind.

Gemäß Art.15 Abs. 3 DS-GVO bitte ich um eine Kopie der personenbezogenen Daten, die Gegenstand der Verarbeitung sind.


Ich bitte Sie, mir diese Auskunft unverzüglich zu erteilen. Sollte ich binnen eines Monats nach Versand dieser E-Mail keine Rückmeldung erhalten, werde ich mich an die zuständige Aufsichtsbehörde wenden.

Mit freundlichen Grüßen

Der oben zitierte Art. 15 bietet noch das Recht auf mehr Informationen. Die in dem oben genannten Schreiben sind mir aber die wichtigsten Punkte. Daher habe ich das etwas eingekürzt.

Wenn ihr den Brief ebenfalls verwendet, würde ich mich über eure Erfahrungen freuen. Ich werde ggf. ebenfalls interessante Begebenheiten bloggen.

Wer ist hinter APT3?

Habt ihr schon mal von APT3 oder Gothic Panda oder Buckeye gehört? Oder sagen euch die Operationen Double Tap oder Clandestine Fox etwas?

Zugegeben sind die Aktionen aus dem Jahr 2014 und damit schon etwas älter. Die Gruppe, die als APT3, UPS, Gothic Panda, Buckeye etc., bekannt ist, ist schon weit älter. Das Unternehmen FireEye berichtete bereits im Jahr 2010 zum ersten Mal darüber.

Die Operation Double Tap bestand aus einer Phishing Mail, die Leute zu einer Mitgliedschaft in einem Playboysclub einlud. Wer dann auf den Link in der Mail klickte, gelangte auf eine Webseite, die einen Exploit ausnutzte. Dieser installierte letztlich eine Schadsoftware auf dem Rechner und diese kommunizierte mit einem Server. FireEye hat mehr Details zu der Operation. Die Operation Clandestine Fox war ähnlich interessant.

Nun fragen sich viele, wer eigentlich hinter der Gruppe steckt. Wenn man aktuelle Pressemitteilungen liest, so ergibt sich der Eindruck, dass es immer entweder russische oder chinesische Angreifer sind. Im Falle von APT3 gibt es noch ein paar mehr Hinweise:

  • Die Domainnamen müssen von einer Person registriert werden. Dabei wurde die E-Mail-Adresse mxmtmw@gmail.com angegeben. Ausgehend davon gelang es, eine Person mit dem Namen Wu Yingzhou zu ermitteln. Die Seite https://intrusiontruth.wordpress.com/2017/05/02/who-is-mr-wu/ hat alle Details dazu.

  • Auch bei einer zweiten Domain spielte eine andere E-Mail-Adresse eine wesentliche Rolle. Die Forscher konnten die Person Dong Hao ermitteln.

  • Beide Personen sind Eigentümer der Firma Boyusec. Diese Firma wiederum ist Auftragnehmer des Ministeriums für Staatssicherheit in China.

Das ist doch ein recht klarer Hinweis, dass Boyusec hinter APT3 steckt. Dies folgt einem Trend. Denn viele Dienste lagern die Aufgaben an Privatfirmen aus.

Gedanken zur Sicherheit bei Wikipedia

Kürzlich fragte mich Sebastian Wallroth, ob ich nicht eine Folge seines Podcasts Wikistammtisch mit gestalten könne. Natürlich sagte ich zu und so entstand die Folge 14 der Sendung.

Das Thema sollte Sicherheit und Wikipedia sein. In der Sendung konzentrierten wir uns auf die Wikipedianer, die Texte lesen und editieren wollen. Dies sollte allen Menschen auf der Welt möglich sein. Daher war Tor und offene Proxys einer unserer Diskussionspunkte. Weiterhin sprachen wir HTTPS bzw. TLS kurz an. Passwortsicherheit und Mailverschlüsselung waren weitere Punkte, die wir ansprachen. Ich hätte natürlich noch viel länger zu dem Thema erzählen können. :-) Einige Punkte will ich untenstehend kurz erläutern.

Sicherheit in der Wikipedia für Anwender

Die meisten Menschen nutzen die Wikipedia, um Artikel bzw. Lemmata zu lesen. Einige bearbeiten Artikel. Aber es gibt unter den Leuten, die ich als Anwender sehe noch weitere Rollen:

  • Sichter: Diese Leute haben durch ihre Mitarbeit einen Vertrauensstatus gewonnen und deren Änderungen werden automatisch sichtbar. Weiterhin können sie Änderungen anderen anschauen und diese Änderungen als frei von Vandalismus markieren. Dadurch wird die Version auch unangemeldeten Besuchern angezeigt (siehe Gesichtete Artikel).
  • Administrator: aus der Hilfeseite:
    Sie haben die Möglichkeit, Benutzer zu (aktiven) Sichtern zu machen, ihnen diesen Status zu entziehen, Benutzer zu sperren und solche Sperren wieder aufzuheben. Außerdem können sie einzelne Versionen einer Seite löschen, so dass diese nur noch für Administratoren einsehbar sind.

    Das heißt, diese Benutzergruppe hat besondere Rechte. und darf insbesondere auf personenbezogene Daten zugreifen.

  • Bürokrat: Diese dürfen andere Benutzerrollen vergeben. Insbesondere dürfen sie auch Personen zu Administratoren ernennen.
  • Checkuser: Dieser Personenkreis kann sehr tiefgreifende Änderungen vornehmen und diese sollten ihren Zugang entsprechend stark schützen.
  • Daneben gibt es noch weitere Rollen. Diese unterscheiden sich aus meiner Sicht nicht großartig von einem normalen angemeldeten Benutzer.

Nicht angemeldete Anwender

Personen, die die Wikipedia besuchen, ohne sich ein Benutzerkonto angelegt zu haben, haben einige Anforderungen bezüglich der IT-Sicherheit. So wollen sie bei der Eingabe der URL http://de.wikipedia.org/ auch auf der Wikipedia-Seite landen.

Nach der Eingabe der URL macht das System zunächst eine DNS-Abfrage und erhält die IP-Adresse zurück. Diese Antwort kann natürlich gefälscht werden. Hier wäre es sinnvoll, wenn die Anfrage schon in einer gesicherten Form zurückkommt, so dass zumindest Fälschungen erkannt werden. Ich verweise mal auf die 33. Sendung des Datenkanals zu DNSSEC.

Nun versucht der Browser die Wikipedia-Seite zu besuchen. Wie ich beim Wikistammtisch erwähnte, erfolgt der die Eingabe zumeist per HTTP. Die diversen Wikipedia.org-Seiten sind einigen Browsern vorab bekannt und werden sofort per HTTPS geladen. Dies geschieht ohne das jemand eingreifen muss. Sollte ein Browser dieses Vorwissen nicht haben, so sagt der Webserver der Wikipedia, dass der Browser zur HTTPS-Version der Webseite wechseln soll. Die HTTPS-Version ist von einer externen Stelle (Certificate Authority) bestätigt und so wird versucht sicherzustellen, dass sich niemand zwischen die Verbindung mogeln kann. Damit ist nun eine Verbindung zu einer Seite aufgebaut, wo Anwender sicher sein können, dass es sich um die Wikipedia handelt. Ausnahmen hatte ich im Podcast beschrieben.

Wenn sich Personen auf den Seiten der Wikipedia bewegen, wollen sie die Inhalte sehen und weder Werbung noch Schadsoftware erhalten. Hier hat der Serverbetreiber eine Verantwortung sich um die Sicherheit der Server wie auch der Anwendung zu kümmern. Hin und wieder kommt es vor, dass in Server eingebrochen wird, um Schadsoftware zu verteilen. Ähnliches passiert bei Werbenetzwerken. Auch da wird gern versucht, über Werbung Schadsoftware zu verteilen.

Weiter gibt es in den USA die »Expectation of Privacy«, die sich aus dem Vierten Verfassungszusatz ergibt. Auch in Deutschland haben wir ein starkes Datenschutzrecht. Hier wäre es interessant zu wissen, welche personenbezogenen Daten die Wikipedia speichert und natürlich wie lange. Derzeit wird von der Seite ein Cookie gesetzt, der zwei Monate Gültigkeit hat und nur über einen sicheren Kanal (HTTPS) übertragen wird. Weitere Cookies werden nach Beendigung der Browsersitzung gelöscht. Die Foundation hat eine längere Erklärung zu den Cookies. Wenn ein Artikel bearbeitet wird, so verbleibt die IP-Adresse im Logbuch der letzten Änderungen.

Angemeldete Benutzer

Wenn sich jemand entscheidet, ein Benutzerkonto anzulegen, kommen weitere Betrachtungen hinzu. Insondere stellt sich die Frage nach der Sicherheit des Passworts. Für mich ist hier wesentlich, dass das Wikipedia-Passwort verschieden zu anderen sein sollte. Was die Länge und die Gestalt des Passworts betrifft, sollte man sich überlegen, wie wichtig das Konto ist. Denn wenn jemand das Passwort errät, kann diese Person im Namen des andere Bearbeitungen durchführen und am Ende wird das Konto vielleicht gesperrt. Das heißt, der Schaden für normale Benutzer hält sich in Grenzen. Daher würde ich die Anforderungen an das Passwort nicht so hoch ansetzen.

Die Lage ändert sich, wenn jemand CheckuserAdministrator bzw. Bürokrat ist. Diese Rollen habenhat wesentlich mehr Rechte und der potenzielle Schaden ist größer. Daher würde ich erwarten, dass es bei diesen Rollen stärkere Anforderungen an das Passwort bzw. andere Authentifizierungsverfahren gibt.

Im Podcast sprachen wir das Thema Mail an. So bekommt ein angemeldeter Nutzer verschiedentlich Mails. Facebook hat eine Möglichkeit geschaffen, einen OpenPGP-Schlüssel in seinem Profil zu hinterlegen. Alle Mails von Facebook kommen dann automatisch verschlüsselt und signiert an. Dadurch ist es unter anderem recht einfach Spam von echten Facebook-Mails zu unterscheiden. Es wäre wundervoll, wenn Wikipedia auch diese Möglichkeit bieten würde.

Sicherheit in der Wikipedia für andere

Wie ihr seht, sind die obigen Betrachtungen schon recht lang geworden. Aber innerhalb des Wikipedia-Universums gibt es noch andere Personengruppen. So betreiben Administratoren die Server. Das heißt, sie pflegen die Hard- wie auch die Software. Welche Anforderungen müssen diese Personen erfüllen? Auch gibt es einen Personenkreis, der die Software programmiert. Hier kann man sich ebenfalls Gedanken zu den Anforderungen bezüglich der Sicherheit machen. Doch beides wird sehr lang und viel. Daher lagere ich das mal auf einen eventuellen zukünftigen Artikel aus.

Wunsch für die Zukunft

Im Rahmen meiner Überlegungen zur Sicherheit in und um die Wikipedia fiel mir noch ein großer Wunsch ein:

Es wäre phantastisch, wenn die Wikipedia als Tor Onion Service zur Verfügung stehen würde. Dies macht es gerade Leuten in zensierten Ländern viel einfacher, die Seiten zu erreichen. Die Webseite ist von einem Ende zum nächsten verschlüsselt und es macht es Angreifern viel schwerer, die Verbindung aufzubrechen. Unter anderem macht es Facebook mit der Seite https://facebookcorewwwi.onion/ vor. Aber auch DuckDuckGo (http://3g2upl4pq6kufc4m.onion/) sowie Debian und Tor selbst betreiben viele Seiten im Tor-Netz. Daher wäre Wikipedia ein wundervolles Beispiel für einen weiteren Tor Onion Service, der vermutlich vielen Menschen großen Nutzen bringt.

Update: In der Diskussion wies mich Raymond darauf hin, dass Administratoren doch nicht die großen Rechte haben, die ich vermutete. Diese sind erst bei Checkusern gegeben. Daraufhin habe ich den Artikel angepasst.

Wer steckt fremde USB-Sticks in den eigenen Rechner?

Wer einen Vortrag über IT-Sicherheit oder Social Engineering besucht, wird zwangsläufig die Geschichte von den USB-Sticks zu hören bekommen. Demnach hat der Vortragende oder eine andere Person in einem Unternehmen USB-Sticks platziert und kurze Zeit später wurden diese an die Arbeitsplatzrechner gesteckt, obwohl dies strengstens verboten ist. Doch ist an der Geschichte wirklich etwas dran? Forscher verschiedener Universitäten veröffentlichten eine Studie, die dem Phänomen auf den Grund geht.

Dazu präparierten sie USB-Sticks und verteilten sie auf dem Campus der University of Illinois at Urbana-Champaign. Die Sticks waren unterschiedlich gestaltet. Das rangierte von neutral bis zu beschrifteten Sticks oder solchen, die an einem Schlüsselbund hingen. In der Studie finden sich Beispielbilder. Auf den Sticks befanden sich HTML-Dateien, die einen img-Tag zur Anzeige von Bilder beinhalteten. Dieses Bild wurde von einem Server geladen, den die Forscher kontrollierten. So sahen sie, wenn jemand den Stick einsteckte.

Insgesamt verschwanden fast alle der abgelegten USB-Sticks (290 von 297 Stück). Knapp die Hälfte wurde von den Findern geöffnet. Dabei zeigte sich, dass nur die Geräte, bei denen eine Adresse vermerkt war, weniger geöffnet wurde. Bei allen anderen Markierungen wurden jeweils so um die Hälfte in den eigenen Rechner gesteckt und geöffnet. Welche Dateien interessierten die Finder besonders? Je nach Stick trugen die Dateien unterschiedliche Namen. Besonders häufig wurde der Bilderordner mit Bildern des »Winter Break« geöffnet. Aber auch Prüfungen und Lebensläufe fanden die Finder interessant.

Ein weiterer interessanter Nebeneffekt der Studie fand im Web statt. Die Forscher überwachten verschiedene Seiten und wollten sehen, ob die USB-Sticks dort erwähnt wurden. Ein Student postete ein Bild seines Fundes auf Facebook, andere posteten dies bei der Sub-Reddit-Seite der Uni. Dort entspann sich eine Diskussion und die Diskutanten warnten sich, die Sticks in den Rechner zu stecken.

Insgesamt ist die Studie sehr interessant. Sie bestätigt genau die oben angeführte Geschichte, dass Sticks gern mitgenommen und in den Rechner gesteckt werden. Die Angreifer haben hier ein nahezu leichtes Spiel.

Doch wie könnt ihr euch schützen, dass euer Stick verloren geht und in einen fremden Rechner gesteckt wird? Die Erkenntnisse der Studie legen nahe, dass der Stick an einem Schlüsselbund sein sollte und mit einem Namen sowie Adresse beschriftet sein sollte. In diesen Fällen wurden die Sticks äußerst selten an den Rechner gesteckt und auch häufig zurück gegeben. Viel besser ist natürlich die Sticks zu verschlüsseln und ein Backup der Daten zu haben.

Spam-3.7688

In meiner Inbox fand ich heute dieses nette Stück Spam:

<html>                                                                                                             
<head><title>401 Authorization Required</title></head>                                                             
<body bgcolor=“white”>                                                                                             
<center><h1>401 Authorization Required</h1></center>                                                               
<hr><center>nginx/1.2.1</center>                                                                                   
</body>                                                                                                            
</html>

 

Wenn man das HTML interpretiert, kommt dann sowas raus:

401 Authorization Required


nginx/1.2.1

Ich verstehe nicht, warum man sowas als Spam in die Welt hinaus schickt. Die Nachricht wurde von einer IP-Adresse aus Südafrika eingeliefert. Neben der From:-Adresse hat der Spammer keine weiteren Header-Zeilen übermittelt. Vielleicht wollte derjenige einfach, dass ich das blogge. :-)

tweetbackcheck