Bob schickt Alice eine Nachricht - wie sicher ist das denn?

red mailbox on blue wall

Zur Einordnung: Dieser Artikel soll keine fachlich bis ins kleinste fundierte Betrachtung von Verschlüsselungs- und Sicherheitesmechanismen sein. Dazu fehlt mir sicherlich auch die Expertise. Vielmehr möchte ich auf etwas vereinfachte Weise anschaulich darstellen, was man bei der Nutzung von Messengern für die Sicherheit tun kann und beachten muss.

Bob schickt Alice über $Messenger eine private Nachricht mit einem netten privaten Bild. Natürlich möchte Bob, dass die Nachricht sicher bei Alice ankommt und - da sie ja privat ist - auch nur von Alice gelesen werden kann. Mal schauen, was die beiden dabei so alles beachten müssen.

(Als Vorraussetzung nehmen wir mal an, dass Bob und Alice einen Messenger benutzen, bei dem ein Provider mit einer Server-Infrastruktur beteiligt ist. Dieses Konzept verfolgen die meisten Messenger, um die Problematik zu lösen, dass nich immer alle Beteiligten einer Konversation ständig online sind. Es gibt auch Messenger, die eine direkt Peer-to-Peer-Verbindung herstellen, aber diese Konstallation muss nochmal anders betrachtet werden.)

Abhörsicher

Zunächst einmal wollen Bob und Alice natürlich sicher gehen, dass ihre Nachricht dem Transportweg von Bobs auf Alice' Endgerät nicht von von unbeteiligten mitgelesen werden kann, die zufällig den Datenstrom von Bob zum Provider oder vom Provider zu Alice mitbekommen. Hierzu eignet sich ersteinmal eine Transportverschlüsselung über SSL. Dieses bewährte Verfahren sichert den Datenverkehr zwischen zwei Geräten (z.B. Smartphone und Server des Providers) mittels Zertifikaten ab, die - sofern sie richtig implementiert wurden - sicherstellen, dass der Datenverkehr vom und zum Provider verschlüsselt ist und sich niemand dazwischen schalten kann.

Das Problem bei diesem Verfahren ist, dass die Verschlüsselung nur bis zum jeweiligen Endpunkt der Server-Software beim Provider genutzt wird. Sobald Bobs Nachricht dort ankommt, wird sie entschlüsselt und vom Provider im Klartext gepeichert, bevor sie - dann wieder verschlüsselt - an Alice weitergereicht wird. Der Provider und jeder, der irgendwie Zugriff auf den Server erlangt, könnte also mühelos alle Nachrichten der Nutzer lesen. Dieses Verfahren reicht daher auf jeden Fall nicht aus, um Bobs Nachricht an Alice zuverlässig abzusichern.

(Heutzutage dürfte es keinen Messenger-Dienst mehr geben, der ausschließlich eine solche Transportverschlüsselung ohne zusätzliche Verschlüsselungsmechanismen nutzt.)

Hinter verschlossenen Türen

Um zu verhindern, das Bobs Nachricht auf dem Weg zu Alice entschlüsselt und eventuell sogar im Klartext gespeichert wird, sollte der Provider von $Messenger also zumindest eine serverbasierte Verschlüsselung einsetzen, um die Daten seiner Nutzer zu schützen.

(Wie funktioniert so eine Verschlüsselung eigentlich?
Grob gesagt nutzt man immer ein Schlüsselpaar, jeder Teilnehmer einer Konversation besitzt einen privaten Schlüssel, den nur er kennt, und einen öffentlichen Schlüssel, den er weiter geben kann.
Teilnehmer A kann etwas mit dem öffentlichen Schlüssel von Teilnehmer B verschlüsseln. Diesen verschlüsselten Inhalt kann danach nur noch Teilnehmer B mit seinem privaten Schlüssel wieder lesbar machen. Genauso funktioniert das in der anderen Richtung. Teilnehmer B verschlüsselt etwas mit dem öffentlichen Schlüssel von Teilnehmer A, der mit seinem privaten Schlüssel wieder lesbar macht.
Eine zweite Funktion dieses Schlüsselpaares ist das Signieren von Inhalten. Teilnehmer A kann mit seinem privaten Schlüssel etwas signieren und jeder andere kann mit dem öffentlichen Schlüssel von Teilnehmer A diese Signatur überprüfen, also die Herkunft des Inhalts sicherstellen. Beides, verschlüsseln und signieren funktioniert einzeln und kann auch kombiniert werden.)

Bei der serverbasierten Verschlüsselung benutzt der Provider einen einzigen Schlüssel für alle Benutzer. Je nach Verfahren werden die Nachrichten noch mit einer Session-ID des Clients oder einer Nachrichten-ID verschlüsselt. Die so verschlüsselten Nachrichten werden dann bei Bedarf auf dem Server des Providers gespeichert und können dann auch sicher an den Client des Empfängers weitergeleitet werden. Das ist schonmal insoweit gut, dass jemand, der den Server des Providers unter Kontrolle bekommt, die dort gespeicherten Nachrichten nicht lesen kann, sofern der Provider seinen privaten Schlüssel entsprechend abgesichert hat. So weit so gut, Bob und Alice können also beruhigt sein, oder?

Das Problem bei dieser Art der Verschlüsselung ist aber, dass der Provider jederzeit Zugriff auf die Inhalte hat (und haben muss). Ein Fehler im Sicherheitssystem des Providers oder auch eine Anfrage einer Regierungsorganisation, mit der der Provider zusammen arbeitet, würde die Offenlegung der Inhalte von Bobs Nachricht an Alice zur Folge haben. Wie kann man das also noch besser machen?

Du siehst mich nicht

Das Zauberwort heisst: Ende-zu-Ende-Verschlüsselung.

Hierbei nutzt der Provider keinen einheitlichen Schlüssel, um die Inhalte der Nutzer abzusichern. Die Schlüssel der Benutzer werden direkt ausgetauscht und Bob verschlüsselt seine Nachricht direkt mit dem öffentlichen Schlüssel von Alice. Nur Alice hat also mit ihrem privaten Schlüssel Zugriff auf diese Nachricht. Auch der Provider hat keine Möglichkeit, die Inhalte von Bobs Nachricht an Alice zu entschlüsseln, er kann auch nicht von dritter Seite dazu gezwungen werden. Bob und Alice können also sicher sein, dass ihre Inhalte sicher und nur für die beiden lesbar transportiert werden? Ja, allerdings gibt es dabei einige Voraussetzungen, die die beiden beachten und umsetzen müssen.

Wer bin ich und wie viele?

Erstes Problem: Wie erhält Bob den öffentlichen Schlüssel von Alice, um anschließend die Nachricht an sie damit zu verschlüsseln. Das sicherste wäre hier, die beiden würden sich treffen und Alive übergibt ihren öffentlichen Schlüssel direkt an Bob, der ihn dann auf seinem Client speichern kann. Es wäre aber ziemlich mühsam, wenn jeder Nutzer von $Messenger das mit jedem seiner Chat-Partner so machen müsste. Also sendet $Messenger den öffentlichen Schlüssel von Alice automatisch an Bob. Bob hat dann verschiedene Möglichkeiten, um die Echtheit des Schlüssels zu prüfen. So kann Bob zum Beispiel Alice anrufen und dann mit ihr gemeinsam am Telefon den Hash-Wert der Schlüsselsignatur zu vergleichen, den beide in ihrem Client aufrufen können. Sollten sich die beiden doch einmal persönlich treffen, könnten Bob mit seinem Smartphone auch einen QR-Code scannen, den Alice auf ihrem Device anzeigen lässt. Nach diesem Vergleich ist Bob also sicher, dass der öffentliche Schlüssel, den er bekommen hat, auch wirklich von Alice stammt.

Das Schlüsselpaar von Alice wird automatisch per Zufallsgenerator erzeugt, wenn sei $Messenger auf ihrem Smartphone installiert. Wenn sie $Messenger neu installieren muss oder ein neues Gerät erhält, wird ein neues Schlüsselpaar erzeugt, dessen öffentlicher Teil auch wieder direkt an Bob gesendet wird. Das ist auch wichtig, denn Nachrichten, die Bob mit dem alten öffentlichen Schlüssel von Alice verschlüsseln würde, könnte Alice ab sofort nicht mehr lesen. Der Client von Bob macht ihn auf diesen Umstand auch aufmerksam, in dem er einen Text wie "Die Sicherheitsnummer von Alice hat sich geändert." anzeigt. Für Bob bedeutet das, dass er ab jetzt nicht mehr sicher sein kann, ob dieser neue öffentliche Schlüssel immer noch von Alice stammt. Erst, wenn die beiden über eine der oben beschriebenen Möglichkeiten die Herkunft des Schlüssels sicher gestellt haben, ist die Kommunikation wieder sicher.

(Ihr macht das bei allen Kontakten in eurem E2E-verschlüsselnden Messenger so, oder? ;-) )

Es gibt noch ein Problem bei der E2E-Verschlüsselung. Die Sicherheit funktioniert nur dann, wenn Bob und Alice sicher sein können, dass sie jeweils das Original ihrer privaten Schlüssel besitzen und es keine weiteren Kopien (z.B. beim Provider) gibt. Das die Erzeugung und Verteilung der Schlüssel automatisch durch den Client von $Messenger erfolgt, haben die beiden hier keine Möglichkeit, auf diesen Prozess Einfluß zu nehmen. Um hier eine Kontrollmöglichkeit zu haben, könnten Bob und Alice zum Beispiel einen $Messenger verwenden, dessen Programmcode offengelegt ist, also Open Source ist. Hier hätte man die Möglichkeit zu überprüfen, ob der Client ordentlich mit den erzeugten Schlüsselpaaren umgeht. Natürlich ist auch eine Bestätigung durch einen unabhängigen Prüfer möglich, hierbei ist es aber immer nötig, dass Bob und Alice diesem Prüfer auch vertrauen.

Zum schlechten Schluß

Nun haben Alice und Bob alle oben beschriebenen Aspekte berücksichtigt, nutzen Ende-zu-Ende-Verschlüsselung, haben die Echtheit und Vertraulichkeit ihrer Schlüsselpaare sichergestellt. Bob kann seine Nachricht mit dem privaten Foto also sicher an Alice schicken. Allerdings habe ich jetzt noch eine schlechte Nachricht für die beiden. Sobald Nachricht und Foto auf Alice' Device angekommen sind, werden sie wieder entschlüsselt, damit Alice sie lesen kann. Ab jetzt hat Bob leider keinerlei Kontrolle mehr darüber, was Alice (oder ihr Smartphone) mit den Inhalten macht. Wird das Foto auf eine (wie auch immer gesicherten) Cloud hochgeladen? Wer hat dort Zugriff darauf? Gibt Alice das Smartphone ab und zu an ihre Kinder, damit diese damit spielen? Landet die Nachricht auf dem Uralt-Laptop von Alice, der noch unter Windows XP läuft und von dem ein oder anderen Trojaner verseucht ist?

Es ist für unsere beiden wichtig und richtig, einen sicheren $Messenger zu nutzen und sicherzustellen, dass Inhalte vertraulich und sicher an den jeweils anderen Gesprächspartner weitergeleitet werden. Wir sollten uns aber auch bewusst sein, dass unser Kontent, wenn er erstmal beim (sicher richtigen) Empfäger angekommen ist, weiter gesichert und geschützt werden muss. Nur das hängt dann in keinster Weise mehr vom genutzten Messenger ab.

Oysttyer 2.10 erschienen

Ja, er lebt noch! Oysttyer, der Twitter-Client für die Textkonsole, der aus einem einzigen Perls-Skript besteht, hat ein Update erhalten und ist jetzt in der Version 2.10 verfügbar.

Unterstützt wird jetzt endlich die neue Tweet-Länge von 280 Zeichen. Außerdem ist es möglich, mit der Option "separator" einen String zu definieren, der nach einem Refresh der Timeline angezeigt wird.

Nichts aufregend Neues, aber immerhin ist das Projekt noch am Leben und der ein oder andere nutzt es auch noch. Unter anderem ich, wenn ich mal meine nerdigen 5 Minuten habe. :-)

Kubuntu Cosmic Cuttlefish (18.10) Beta erschienen

Bald ist es Oktober und somit steht das nächste Zwischenrelease für die beliebte Linux-Distribution Ubuntu und damit auch für die verschiedenen Desktop-Flavours an. Auch für das von mir bevorzugte Kubuntu, welches auf die Desktop-Umgebung KDE optimiert wurde, haben die Entwickler nun die erste Beta der Version 18.10 zur Verfügung gestellt.

Wie immer gibt es den Hinweis der Kubuntu-Community, dass die Beta-Version nicht für Nutzer gedacht ist, die ein stabiles System benötigen. Eine Beta kann immer Fehler und Probleme enthalten, darüber sollte man sich im klaren sein, wenn man eine solche Version installiert.

Ich nutze schon seit langem immer nur die LTS-Versionen von Kubuntu und habe auf meinem Rechnern vor kurzem die letzte LTS-Version 18.04 installiert. Dennoch habe ich mir das ISO heruntergeladen und in einer virtuellen Maschine installiert, um mir Kubuntu 18.10 einmal kurz anzusehen.

Sofware aufgefrischt

Kubuntu Screenshot 1Für diejenigen Nutzer, die bereits mit der 18.04 unterwegs sind, ändert sich außer dem angepassten Standardhintergrund-Bild nicht viel. Das dunkle Theme der letzten LTS-Version, das mir übrigens sehr gut gefällt, wurde übernommen. Die Plasma-Version wurde auf 5.13.5 aktualisiert. Die KDE-Applications  kommen in der Version 18.04.3 daher.

Der Standard-Webbrowser ist nach wie vor Mozillas Firefox. Nutzt man die Standardinstallation, die eine große Auswahl von Software-Paketen mitinstalliert, steht als Office-Suite LibreOffice 6.1.1 zur Verfügung, das jetzt erstmals QT5 für die Darstellung des Frontends nutzt.

Snaps standardmäßig aktiviert

Discover mit aktiviertem Snap-BackendSchon in 18.04 waren die Paketverwaltungs-Tools Snap und Flatpak im Programmverwaltungs-Tool "Discover" integriert, beide mussten aber zunächst in den Einstellungen aktiviert werden, um genutzt werden zu können. In der Beta sind nun Snaps standardmäßig aktiviert. Das kann bei unerfahrenen Benutzern allerdings zu Verwirrungen führen, wenn auf einmal scheinbar identische Programme mehrmals auftauchen.

Programmliste in DiscoverErst ein Klick auf die verschiedenen Einträge offenbart die Quelle des Programms, ob es also aus einem (Ubuntu) Repository oder aus einem Snap installiert wird. Hier wäre es sicher schöner, wenn man das gleich in der Übersicht erkennen könnte.

Programmquelle im Detail

Kurzes Zwischenspiel für Wayland

Der alternative Anzeige-Server Wayland hat in dieser Beta ein kurzes Zwischenspiel. Man kann diesen bei der Anmeldung am System als Alternative zum X-Server starten. Die Entwickler weisen allerdings ausdrücklich darauf hin, dass die Implementierung noch sehr instabil ist nur zu Testzwecken genutzt werden sollte. In der stabilen Version von Kubuntu 18.10 wird die Option standarmäßig nicht mehr zur Verfügung stehen.

Testen und Bugs melden

Das Ziel einer Beta-Version ist es immer, mögliche Fehler und Stabilitätsprobleme vor dem eigentlichen Release zu finden und noch vorher beheben zu können. Wer sich Kubuntu 18.10 also schonmal installiert (zum Beispiel gefahrlos in einer virtuellen Maschine) und solche Bugs findet, kann die im Bugtracker melden und so zur Qualität vom endgültigen Release beitragen. Happy Testing!

Musik: Tears in the Rain

Mal eine ältere Nummer, aus besseren Tagen.

Jennifer Rush.

Tears in the Rain.

Bitte schön.

Thunderbird Filelink mit Nextcloud nutzen

Thunderbird Linkfile

Seit einiger Zeit bietet der Mail-Client Thunderbird die Funktion "Filelink" an. Wenn man große Dateianhänge per E-Mail versenden will, kommt es öfters vor, dass die Mailbox des Empfängers diese nicht akzeptiert oder voll ist. Mit der Filelink-Funktion kann man Thunderbird anweisen, Dateianhänge ab einer bestimmten Größe nicht an die Mail anzuhängen, sondern auf einen Cloudspeicher im Internet hochzuladen und lediglich einen Link zur Datei in die Mail einzufügen.

Nun gibt es für Thunderbird ein Add-On, mit dem ihr die Dateien auch auf eure eigene Nextcloud-Instanz hochladen könnt. Sucht dazu in den Add-Ons nach "Nextcloud" und ihr findet "Nextcloud for Filelink", das ihr dann installiert.

Danach erfolgt die eigentliche Konfiguration in den Einstellungen unter "Anhänge" im Reiter "Versand". Mit einem Klick auf "Hinzufügen" könnt ihr als Provider nun "Nextcloud" auswählen. Im nachfolgenen Dialogfenster werden die Daten zu eurer Instanz erfasst.

Filelink einrichten

Füllt die Felder entsprechend aus. Den Providernamen könnt ihr selbst wählen, ebenso das Verzeichnis, in dem eure Nextcloud die Dateianhänge speichern soll. Optional könnt ihr ein Passwort angeben, das zum Abruf der verlinkten Datei notwendig ist, dieses ist allerdings dann für alle Dateien gleich. Nach dem Klick auf "Konto einrichten" müsst ihr noch das Kennwort für den angegebenen Nextcloud-Nutzer angeben, welches bei Bedarf in der Passwortdatenbank von Thunderbird gespeichert werden kann, wenn man das möchte.

Jetzt könnt ihr eure Nextcloud mit Filelink nutzen. Entweder sie wird ab der definierten Dateigröße automatisch genutzt oder ihr wählt die Funktion beim Anhängen von Dateien in die Mail über das erweiterte Menü aus.

Filelink nutzen

Die Datei wird dann automatisch in eure Nextcloud hochgeladen, der Dateiname wird zum Schutz um eine zufällige Zahlenfolge ergänzt und per Link freigegeben. Der Link wird in eure Mail eingefügt.

Ich finde Filelink praktisch, wenn man mal größere Dateien versenden muss, die als E-Mail-Anhang gewöhnlich bei einigen Empfängern Probleme macht. Wenn ich dazu noch die eigene Nextcloud nutzen kann, über die ich die Datenhoheit habe, umso besser.

Mondfinsternis

Gestern fand sie also statt, die längste Mondfinsternis des Jahrhunderts. Nachdem sich bei uns der Mond lange gar nicht gezeigt hat, gab es am späteren Abend noch einen tolle Aussicht auf das Naturschauspiel. Hier habe ich einfach mal ein paar Bilder für euch (manchmal hat sich auch der Mars mit aufs Bild geschummelt).

Mondfinsternis_1

Mondfinsternis_2

Mondfinsternis_3

Mondfinsternis_4

Kubuntu 16.04 - Grafikprobleme nach Kernelupdate im Juli 2018

Auf meinem stationären Rechner daheim verrichtet nun seit über zwei Jahren ein Kubuntu 16.04 LTS brav seinen Dienst und macht eigentlich kaum Probleme, auch nicht bei den Systemupdates, die regelmäßig erscheinen. Beim letzten Update im Juli 2018, bei dem auch der Kernel auf die Version 4.4.0-130 aktualisiert wurde, gab es auf meinem Rechner aber einige Grafikprobleme. So war zum Beispiel die Transparenz der Kontrollleiste nicht mehr wie vorher, die Farben des hellen Breeze-Themes waren deutlich dunkler und irgendwie "nicht mehr stimmig".

Problematischer war jedoch, dass im Firefox-Browser einige der Icons in der Iconleiste nicht mehr angeklickt werden konnten, zum Beispiel das "Menü"-Icon und auch das von uBlock Origin.

Firefox Iconleiste

Nach einigem Suchen im Netz scheint es sich um ein Problem des Compositors in Verbindung mit OpenGL zu handeln. Das sorgt wohl für die komischen Farben und für die Probleme mit Anwendungen, die GTK-Stilelemente nutzen und nicht die von KDE/Plasma (wie z.B. Firefox). Folgende Systemeinstellung hat das Problem bei mir zunächt einmal behoben.

In den Systemeinstellungen unter "Anzeige und Monitor" im Reiter "Compositor" habe ich das Ausgabemodul auf "XRender" umgestellt.

XRender-Einstellung

Danach waren die Icons im Firefox sofort wieder klickbar, die Farbprobleme der Kontrollleiste waren nach einem Neustart des Systems auch verschwunden. Negative Nebeneffekte durch diese Umstellung habe ich bisher nicht festgestellt. Ich werde das Problem mal weiter verfolgen und wenn ich weitere Informationen finde, diesen Artikel aktualisieren.

Lokaler Einzelhandel - zweiter Akt

Wisst ihr noch neulich, als ich versuchte, einen Handbrems-Griff für das Fahrrad von K2 in einem Fachgeschäft hier vor Ort zu kaufen?

Ich habe der Versuchung widerstanden, online zu bestellen und bin dann in einem Fahrrad-Laden in der Nachbarstadt tatsächlich fündig geworden. Ohne Probleme bekam ich das entsprechende Ersatzteil und es war mit 5,95 Euro auch nicht sehr teuer. An der Kasse allerdings wurde mein "Ich möchte gern mit Karte zahlen." mit dem leider sehr oft gehörten Satz "Das geht erst ab 10 Euro." beantwortet. Zum Glück hatte ich auch Bargeld dabei, so dass ich nicht abermals mit leeren Händen den Laden verlassen musste.

Ich verstehe das Dilemma des Einzelhändlers. Bei kleinen Beträgen fällt die Transaktionsgebühr, die er an seinen Provider zahlen muss, natürlich mehr ins Gewicht als bei größeren Zahlungen. Allerdings sollte hier eine Mischkalkulation kein Problem sein. Momentan ist der Druck auf den Einzelhandel hierfür wohl noch nicht groß genug, denn so wie ich haben die meisten Menschen noch Bargeld dabei, wenn sie zum Einkaufen gehen. Erst wenn vermehrt Kunden den Laden ohne Kauf verlassen, weil sie schlicht nicht bezahlen können, wird sich das ändern.

Musik: Feuer

Heute habe ich mal etwas Mittelalter-Musik für euch.

Die Gruppe Faun mit "Feuer".

Bitteschön.

Nachtgedacht (15)

Laugh hart.

Run fast.

Be kind.

- The Doctor