I'm on a killing spree...Nein, nicht so wie z. B. in diesem Game, sondern was Contacts auf meinen Jabber Roster angeht. Der ist jetzt erheblich leerer, nachdem ich etliche Conatcts gekickt habe. Und zwar solche Contacts, die um Autorisierung nachfragen, nur um eine Frage zu stellen - zu Linux, zu GnuPG, zu Jabber, zum Blog etc. etc. oder mir nur mitteilen wollen, wie gut oder wie schlecht sie XYZ im Blog oder auf der HP finden…und dann ist meistens Ruhe im Karton. Herrjeh, es gibt trotz ständiger Überallerreichbarkeit per Handy oder Instant Messaging auch noch E-MAIL, die sich hervorragend für solche Zwecke eignet. Muss man sich denn sofort und überall auf Kontaktlisten breit machen, nur weil es so bequem ist? Das ist in meinen Augen einfach nur saumäßiger Stil, der wie immer aus Gedankenlosigkeit und egoistischer Bequemlichkeit resultiert. Und wenn ich dann noch so etwas sehe, laufe ich rot an:
Sehr lustig, wie intelligent und kreativ. Anstatt die Jabber Userverzeichnisse sinnvoll zu nutzen, was die Nutzung der Userverzeichnisse als möglicherweise universales Yellow Book angeht und das Suchen und Finden von bestimmten Personen optimieren würde, rotzt man noch seine einmaligen Ergüsse in's Netz.
Bevor das irgendwo untergeht, Kurznotiz zum Wiederfinden: Skype wird ja auch deshalb von vielen eingesetzt, weil es verschlüsselt und per P2P funktioniert. "Irgendwie" verschlüsselt und P2P nutzt, denn Details sind so gut wie unbekannt, weil die Skype Leute alles unter Verschluss halten und nur hier und da mal allgemeine Bemerkungen zur Sicherheit von Skype fallen lassen. Die Sicherheit, auf die Skype Benutzer bauen, ist also mehr ein Gutglauben oder Vertrauen ohne Basis. Von Salman A. Baset and Henning Schulzrinne gibt es das Paper An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol und von Simson Garfinkel VoIP and Skype Security. In beiden Papern geht es um die Analyse des Slype Netzwerks und der Skype Funktionen, auch um die Bewertung der Aussagen von Skype Machern. Dabei müssen auch beide Paper aufgrund des Closed Source Charakters von Skype um den eigentlichen Kern - wie genau funktioniert die Verschlüsselung von Skype und wie ist sie impelentiert und wie sicher vor Angriffen ist VoIP über das Skype P2P Netz - mehr oder weniger herumlavieren. Dennoch werfen alle Autoren Fragen auf und ziehen Schlußfolgerungen, die für Skype Benutzer von Interesse sind. Zum Beispiel, dass eine VoIP über VPN allemal sicherer sei als Skype. Dazu habe ich noch in de.comp.security.misc gelesen, dass Studenten (wohl) im Fachbereich Elektrotechnik und Informationstechnik der Fachhochschule Jena zur Aufgabe bekommen, Skype zu "dekodieren". Mal sehen, was dabei rauskommt. Auch noch einmal der Hinweis auf die Vortragsmaterialen zur Veranstaltung Sicherheit bei VoIP-Systemen, eine Einführung des 21C3 (zu dem übrigens jetzt über den Fahrplan bereits eine Menge Dokumente und Folien in PDF Form verfügbar sind. Via EFF: Two on Skype. Siehe auch:
Heise - Spekulationen um Backdoor in Skype (24.07.2008)
Kaum dass man sich über die Rücknahme der Anwendung des Großen Lauschangriffs – wenigstens für Gespräche, die mit besonderen Berufsgruppen und Geheimnisträgern geführt werden – durch Bundesjustizministerin Zypries freut, kommt schon die nächste Meldung, die nichts Gutes in Sachen Privatsphäre verheißt.
In Abhören für jeden Geschmack berichtet Monika Emmert von einer neuen Version der Telekommunikations-Überwachungsverordnung, die im Herbst erscheinen soll und wohl stärker als zuvor die Überwachung der Kommunikation per E-Mail und VoIP ins Auge fasst. Gleichzeitig wird auch beim europäischen Standardisierungsgremium ETSI wieder an Standards gearbeitet, die die technischen Normen und Spezifikationen für die entsprechenden Überwachungsschnittstellen beschreiben. Darauf müssen sich schon jetzt Internet- und Telekommunikationsprovider vorbereiten, wie zuletzt während einer Tagung des Verbands der Anbieter von Telekommunikations- und Mehrwertdiensten (VATM), wo sich laut Artikel die Provider u. a. über bereits verfügbare technische Überwachungslösungen und ihrer Preise informieren konnten. Im Artikel ist auch die Rede von Lösungen zur Aufhebung SSL verschlüsselter Verbindungen zum Mailprovider.
Zu der in diesem Zusammenhang im Artikel angesprochenen NetUSE TKÜV Suite heißt es auf der Produktseite von NetUSE:
Die TKÜV (§ 11) fordert, daß auch EMail-Systeme abhörbar sein müssen. Die genauen Anforderungen zur Überwachung nach TKÜV werden in der Technischen Richtlinie TR TKÜ Ausgabe 4.0 vom April 2003, Anlage 9, Anforderungen an Speicherungen des Dienstes EMail, dargestellt (...) Die NetUSE AG bietet hierzu eine Lösung an, die als Plugin mit der Anwendung Mailserver zusammenarbeitet. Die hier vorgestellte Lösung ist sowohl unter Solaris als auch unter Linux verfügbar (...) Die Implementierung erfolgt durch sogenannte Plugins bzw. die Nutzung vorhandener Plugins in der verwendeten Software (sendmail/postfix und Cyrus-IMAP). Damit wird eine Überwachung auch bei Verschlüsselung des Transportweges mit SSL (SSMTP (SMTP/TLS), IMAPS/POPS) sichergestellt. Es wird ein Shell-Interface geliefert, mit dem sich das Überwachen für eine Kennung aktivieren, bzw. deaktivieren läßt, wobei auch die Art (vollständig oder nur Ereignisse) eingestellt wird.
Ende 2003 fand eine ähnliche "Leistungsshow" statt, die vom Branchenverband eco ausgerichtet wurde und über die Monika Emmert ebenfalls berichtete.
Zur Tagung hat der VATM die Pressemitteilung Überwachung im Telekommunikationsmarkt darf nicht weiter ausufern – Internet-Telefonie gerät ins Visier der Behörden herausgegeben. Das man verstärkt VoIP, Instant Messaging und Breitbandangebote per DSL in Angriff nimmt, verwundert nicht, wenn man bedenkt, dass das FBI bereits bei der FCC die Anwendung von Überwachungsgesetzen auf VoIP über Breitbandangebote erreicht hat und in den letzten Monaten alle großen Telko-Anbieter Pläne angekündigt haben, die alle eine Ausweitung der VoIP Dienste oder langfristig die komplette Umstellung ihrer Netze auf VoIP-Telefonie beabsichtigen. Führt man sich dann vor Augen, dass die Anzahl der DSL Nutzer immer weiter ansteigt, steht eigentlich schon fest, dass man VoIP den Überwachungsgesetzen unterwerfen wird.
Dazu mag auch die Stellungnahme des Bundesinnenministeriums zur VoIP Anhörung der RegTP erhellend sein. Das man auch mit einer steigenden Überwachung des E-Mail Verkehrs, Instant Messaging und VoIP Kommunikation die großen, bösen Jungs nicht schnappen wird, weil die wie die auf Privatsphäre bedachten User ihre Kommunikation zusätzlich verschlüsseln oder ganz andere, bzw. "konventionelle" Mittel wie Kuriere, Strohmänner und persönlich abgesprochene Schlüsselwörter einsetzen, scheint in den Häusern der Überwachungsbefürworter (noch) keine Zweifel und Bedenken hochkommen zu lassen. Das ist auch das Positive an der ganzen Geschichte, denn sie wird für einige Leute mehr Anlass sein, sich wieder verstärkt Gedanken über den Schutz ihrer Kommunikation mittels kryptografischer Anwendungen zu machen, was man an den Beiträgen zum Artikel im Forum ablesen kann. Bleibt nur zu hoffen, dass der ganze Überwachungsaktionismus nicht die alten Kryptoregulierungsideen zu Verboten kryptografischer Mittel, Schlüsselhinterlegung oder -zwangsherausgabe wieder aufkommen lässt.
Ich habe ja gerade nichts sinnvolles zu tun, also habe ich mir doch noch mal Gush für Linux angesehen.
Gush ist eine plattformunabhängige Kombination aus Jabber basiertem IM Client und RSS-Reader, garniert mit einem Desktoppager. Das alles eingepackt in einer Flashapplikation, die in einem Firefoxbrowser im Kiosk Modus läuft, weshalb zur Installation auch eine Gush Extension für den Firefox gehört. Unter Linux entpackt man einfach das Archiv, ruft das Installationsscript auf, Gush fragt wohin es installiert werden soll und wo sich das Firefox Binary befindet, der Rest läuft von selbst. Danach $ Gush und zuerst startet eine Eingabemaske, in die man die üblichen Jabber Account Daten einträgt. Anschließend verbindet sich Gush mit dem Jabber Server und startet den Gush "Desktop", den man unten in dem Screenshot sieht. Links ist die dynamische Navigationsleiste zu sehen, über die man zwischen den Einstellungen, der RSS-Reader Feedliste, dem Wallpaper-Switcher und der "Buddylist", d. h. dem Roster, hin und her zappen kann. Den Roster sieht man oben rechts noch einmal angepappt. In der Ecke unten-rechts schwebt der Pager. In der Mitte sieht man ein Chatfenster und den Gush Feed im Feedreader.
Kommen wir noch zu den Systemvoraussetzungen des Eyecandy-Monsters: Processor: Pentium/AMD 1GHz or better Memory : 256MB RAM (512MB Recommended) Disk Space: 50MB free disk space Flash Player: 7,0,19,0 (Win/Mac) | 7,0,25,0 (Linux) Mmh, ja, läuft hier mit meinem AMD Athlon 900TB und 512MB RAM etwas wie zähflüssiger Honig, aber es läuft. Trotzdem bleibe ich lieber bei Liferea als Feedreader und PSI als Jabber Client, "Ästhetik" hin oder her.
Ich bin gerade dabei, mich durch die Dokumentation und die Konfigurationsdateien des jabberd zu wühlen, um testweise einen Jabber-Server aufzusetzen.
Zuerst hatte ich den jabberd 1.4.3 über ein RPM für Red Hat installiert, weil ich von Leuten gehört und an verschiedenen Stellen gelesen hatte, der jabberd2 wäre instabil, hätte Memoryleaks usw. Aber der jabberd1.4.3 lief hier nicht so recht, also habe ich mir jetzt doch mal den jabberd 2.03s3 installiert.
Bis jetzt habe ich es schon einmal geschaft, dass der per initsript zu starten ist, SSL und die Registrierung von neuen Accounts über Psi funktionieren auch, über meinen dyndns.org Hostname ist der auch erreichbar, die Registrierung habe ich aber erst einmal deaktiviert 
Das Ganze scheint mir bei jabberd 2 etwas umständlicher zu sein, weil man statt einer jabberd.xml fünf verschiedene Konfigurationsdateien für die einzelnen Komponenten einstellen muss. Wobei ich per Jabber erfahren habe, dass es wohl auch grafisch gehen soll, aber entweder habe ich mal wieder Tomaten auf den Augen oder sehe den Wald vor lauter Bäumen nicht, jedenfalls habe ich nichts grafisches gefunden.
Bei der Vergabe von User-IDs und Passwörtern für User der router Komponente in der router-users.xml und in den entsprechenden XML Dateien der Komponenten verstehe ich auch etwas nicht. In der Doku war die Rede davon, die router-users.xml würde "IDs" und "Passwords" aufnehmen, also habe ich ganz paranoid für jede Komponente in ihrer Konfigurationsdatei eine eigene User-ID mit Passwort eingetragen und die Kombinationen dann auch in die router-users.xml. Das ging aber nicht, der Router meldete dann immer "Couldn't parse user table" – vielleicht habe ich das auch falsch in die Datei geschrieben. Mit einer User-ID und einem (geänderten) Passwort ging es dann wieder.
Die verschiedenen Transporte sind wohl für jabberd2 auch nur mit Umwegen über einen jabberd1 einzubinden, aber das ist mir nicht so wichtig, weil die mich nicht so interessieren. Allenfalls die Einbindung des JUDs und des Moduls für MUC wäre interessant – das müsste doch auch für einen Jabber-only Server reichen. Nunja, das Basteln und Lesen geht weiter. Nachtrag1: So, nach einigem Rätselraten läuft nun auch MUC über diese JCR Geschichte. Jedenfalls taucht das MUC Modul bei der Service Discovery auf und der Testaccount kann einen Chatroom öffnen. Nachtrag2: Nach Auskommentierung der item category für das jabber.org JUD in der sm.xml ist es nun auch in der Service Discovery zu sehen und durchsuchen kann ich es auch. Die gegenseitige Aufnahme eines Kontakts zwischen amessage.info (outgoing route 'testserver/amessage.info' is now invalid sagt das s2s.log, keine Ahnung, was ich da jetzt machen soll) und dem Testserver schlägt fehl, die zwischen Testserver und jabber.ccc.de funktioniert. Sowohl zu jabber.ccc.de als auch users.jabber.org steht 'valid route' in der s2s.log. Merkwürdig ist auch, dass zwei Kontakte von amessage als eingeloggter jabber.ccc.de User mit "Presence Error: Server connect failed" markiert sind – was ist denn da los bei amessage? Bleibt also noch ein Sack voller Fragezeichen. Nachtrag3: Präsenzbezug zwichen jabber.org und Testserver klappt auch.
Angeregt durch einen Trackback von basquiat zu Jabber - 'abe fertig habe ich die Jabber Anleitung um das Kapitel Jabber mit anderen IM Clients nutzen ergänzt, das den Benutzern anderer IM Netze und Multiprotokoll IM Clients zeigen soll, wie mit wenigen Schritten der eigene Client um Jabber Funktionalität ergänzt werden kann. Dazu wurde der Open Source/GPL Windows Client Miranda verwendet, den viele Windowsbenutzer als Alternative zu Trillian oder anderen Messengern verwenden.
Gerade habe ich den IM Client SIM im Zusammenhang mit GnuPG Verschlüsselung und Jabber getestet.
SIM kommt mit einer sehr guten Oberfläche einher, ist durch die Einbindung von Funktionen über einzelne Plugins, die man in den Einstellungen aktivieren oder deaktivieren kann, modular aufgebaut, die Einstellungen sind zumeist verständlich und die Verbindung per SSL mit dem jabber.ccc.de Server aufzubauen, war auch kein Problem.
Nun zu GnuPG. Bei der Installation legt SIM für jeden Jabber Account ein eigenes keys/ Verzeichnis an, das jeweils eigene Public und Secret Keyringe beinhaltet. Ziemlicher Unfug imo, denn die meisten User werden einen Public und Secret Keyring in ihrem ~/.gnupg Programmverzeichnis oder an anderer Stelle verwenden. Bei einer Vielzahl von Jabber Accounts hat man also eine Menge von Keyrings auf der Platte liegen. Nach der Änderung des Pfades wurde der eigentliche Keyring von SIM auch brav eingebunden. Die Steuerung der Aktionen für GnuPG geschieht jeweils über Befehlsketten, die in die entsprechenden Felder eingefügt werden, vorkonfigurierte Kommandos sind schon enthalten. Z. B. für Verschlüsseln: --batch --yes --armor --comment "" --no-version --recipient "%userid%" --trusted-key "%userid%" --output "%cipherfile%" --encrypt "%plainfile%". Na toll, genau das Richtige für Jabber und GnuPG Anfänger. Diese Form der GnuPG Einbindung, die nicht dem Jabber Standard zur Einbindung von OpenPGP folgt, wie es Psi macht und die einige IM Clients leider gemeinsam haben, bringt es mit sich, dass eine verschlüsselte Nachricht als kompletter GnuPG Cipherblock übertragen wird, also ----BEGIN PGP MESSAGE---- usw. D. h. Clients wie Psi, die dem Standard folgen, können selbst nichts damit anfangen und der Benutzer müsste zur Entschlüsselung selbst Hand anlegen.
Zur Aktivierung der Verschlüsselung mit SIM befindet sich im Kontextmenü eines Kontakts ein Eintrag "GPG-Verschlüsselung benutzen" der nicht funktioniert, sondern erst, wenn man den gleichen, versteckten Eintrag im Nachrichtenmenü des Chatfensters findet – Super! Eine verschlüsselte Nachricht mit Psi konnte nicht entschlüsselt werden, weil trotz richtiger Einbindung von GnuPG und zugeordneten Schlüsseln für beide Kontakte angeblich eine falsche Passphrase eingegeben wurde – nach der ich nicht gefragt wurde – und der geheime Schlüssel angeblich nicht vorhanden sei. Eine Durchsicht des SIM Forums bei Sourceforge ergab, dass eine Menge Benutzer Probleme mit der GnuPG Verschlüsselung haben, großartiger Response seitens der Entwickler war jedoch nicht auszumachen. Wahrscheinlich müsste man mit den Kommandos herumtricksen, aber bei so einem Murks habe ich keine Lust dazu. Fazit: Schöner Jabber Client, GnuPG Verschlüsselung katastrophal, Deinstallation. Es wäre zu wünschen, wenn sich alle Jabber Client Entwickler mal dazu durchringen könnten, einem Verfahren oder Standard zu folgen, natürlich am besten eines, wie es bei der JSF existiert und vorgegeben wird, anstatt so einen Wildwuchs zu fabrizieren, wie er schlimmer in der Windowswelt auch nicht sein kann.
Bei den Penguins vorhin gelesen, dass Skype, die P2P Software zum Telefonieren über das Internet nun auch für Linux verfügbar ist. Können wir nun auch in der Linuxszene einen Hype um Skype erwarten, wie er damals in der Winwelt ausbrach, als Skype vorgestellt wurde? An sich ein positiver Schritt, u. a. weil Skype wohl von den Windowsleuten stark frequentiert wird und ich mir habe sagen lassen, dass die Sprachqualität nicht schlecht ist. Zudem ist die Bandbreite an plattformübergreifenden Internettelefonieprogrammen mit Verschlüsselung nicht gerade groß.
Allerdings ist Skype closed Source Software, ein Merkmal, das ich bei Kryptosoftware generell negativ finde, besonders, wenn die auch noch von diesen merkwürdigen Kazaa Leuten stammt. Siehe dazu auch den Thread bei Slashdot: Skype VoIP Software Released For Linux.
Noch schöner wäre es doch, wenn man für Jabber eine Erweiterung des Protokolls schaffen könnte, mit der es dann möglich wäre, auch per Jabber Sprache zu übertragen, am besten noch verschlüsselt mit einem Sessionkey, der per Key Exchange zwischen den beiden Kommunikationspartner per Jabber ausgehandelt wird – nur ein paar Gedankensplitter, die mir gerade durch den Kopf jagen.
Apropos Jabber: Ich bin gerade dabei, die Jabber Clients durchzutesten, die auch OpenPGP Verschlüsselung anbieten. Gestern war Ayttm dran. Ayttm erinnert bei einem Blick in die Konfigurationseinstellungen an die Windows Chat Clients Miranda oder Trillian und kommt – jedenfalls unter Linux – mit einer hässlichen Oberfläche daher. Zwei Versuche, Verbindungen zum jabber.ccc.de und amessage.info Jabberserver aufzunehmen, scheiterten, so dass ich gar nicht mehr weitergetestet habe und Ayttm wieder deinstalliert habe. Gerade kompiliert seit 1000 Stunden SIM, der als nächster Client an der Reihe ist ... und bricht mit einem RPM build errors: File not found: /var/tmp/sim-0.9.3-root/usr/share/applnk-redhat/Internet/sim.desktop ab, na toll. Vielleicht dazu später mehr.
|
