Steinzeit, XMPP, Hangouts

Heute sprechen wir mal etwas über Instant Messaging und dessen Entwicklung. Hintergrund ist das es (mal wieder) ein neues Tool dafür gibt, welches den Namen Hangouts trägt und von Google kommt.

Steinzeit

Fangen wir in der digitalen Steinzeit an, wir reden also von ICQ. ICQ war einer der ersten Instant Messaging Dienste die eine weitere Verbreitung fanden. ICQ konnte nicht viel und ist ein proprietäres Protokoll, es funktionieren aber die Grundlagen wie Authentifizierung, Autorisierung und Online Status was für damalige Verhältnisse bestimmt toll war.

Neben ICQ gab es, wohl etwas später, auch noch ein paar andere Protokoll welche selbstverständlich nicht kompatibel zueinander waren. Der Online CD Versandhändler AOL z.B. hatte mit AIM ein eigenes Produkt am Start, genauso wie Yahoo mit seinem Messenger oder auch Microsoft mit seinem MSN Chat.

In dieser Steinzeit mussten viele Menschen also mehrere Protokolle nutzen um alle Freunde zu erreichen, es liefen also mehrere Instant Messaging Programme auf dem selben PC. Das ganze zu einer Zeit als Hardware Ressource noch nicht im Überfluss vorhanden waren wie dies heute der Fall ist. Wir reden hier konkret von Hardware mit 64 bis 512 MB RAM, ein aktuelles Betriebssystem bekommt hier oft einen Lachkrampf.

Der nächste, und auch logische Schritt, waren dann Instant Messaging Programme welche mehrere Protokolle und Accounts gleichzeitig nutzen konnten. Das war schon ein großer Schritt für viele Anwender, zumal diese neuen IM Programme wesentlich weniger Ressourcen brauchten als die vom Anbieter gelieferten Tools. Nachteil war jedoch das die Unterstützung der jeweiligen Protokoll sich auf die Basisfunktionen beschränkte, das Austauschen von Dateien war z.B. nur eher schlecht bis nicht möglich.

Zusammengefasst war die IM Steinzeit ein großes Chaos, niemand wollte etwas miteinander zu tun haben und richtige Standards gab es auch nicht. Gewonnen hat damals ICQ, es hatte zumindest gefühlt die meisten Nutzer.

XMPP

Im Zuge des XML Hypes entwickelte sich ab 1998 ein Echtzeit-XML-Streaming Protokoll mit dem Namen Jabber, welches ab 2004 offiziell als XMPP bezeichnet wird. Es handelt sich dabei um das erste genormte IM Protokoll welches eine weitere Verbreitung fand. Für damalige Verhältnisse gab es viele neue Features und alle waren glücklich, hier ein Überblick:

• Transport ermöglichten auch fremde Protokolle wie ICQ, AIM, MSN über den Server zu erreichen.
• Ressourcen ermöglichten es direkt an unterschiedlichen Geräten erreichbar zu sein.
• Prioritäten ermöglichten es selbst zu bestimmen an welchem Gerät man eine Nachricht erhalten möchte.
• Durch den dezentralen Ansatz kann jeder selbst einen Server besteuern.

XMPP ist in vielen RFCs (z.B. 6120, 6121, 6122, …) genormt und es gibt viele verschiedene Server und Clients dafür. Und genau bei den Clients und den Servern fangen bei diesem ursprünglich tollen Ansatz die Probleme erst richtig an: Jeder Server und Client hat einen anderen Funktionsumfang.

Die Basisfunktionen funktionieren natürlich bei jedem Server/Client sehr gut, aber sobald es an den Dateiaustausch oder sogar Videochats geht ist man verloren. Auch ein Abgleich des Chatprotokolls zwischen mehreren Clients funktioniert nicht mal im Ansatz zuverlässig. Dynamische Gruppenchat werden ebenfalls vermisst, und über Sachen wie PEP oder die Information welches Lied gerade gespielt wird möchte ich nicht wirklich reden.

Dazu kommt noch das XMPP durch die vielen Erweiterungen (XEPs genannt) nicht wirklich einfacher wurde, ein komplexes Monster welches Administrator und Anwender gleichermaßen nervt. Im Zeitalter der Social Networks ist es meiner Meinung nach einem Anwender nicht mehr vermittelbar warum er ein abgeschlossenes Informatikstudium benötigt um Dateien über XMPP austauschen zu können oder einen Videochat zu starten.

Ich selbst mag XMPP wirklich, sehe aber auch zunehmend die Schwächen der starken Fragmentierung und die Prioritäten der normalen Anwender. Der Anwender beschäftigt sich nicht mit offenen Standards, sondern mit Tools die funktionieren.

Hangouts

Google hat hier meiner Meinung nach die Zeichen der Zeit erkannt und etwas neues entwickelt, dabei aber bewusst auf XMPP und bestehende Grundlagen verzichtet. Dinge wie dynamische Gruppenchats, Videoübertragungen oder synchronisierte Chatprotokolle sind auf einmal kein Problem mehr und funktionieren einfach. Der normale Anwender wird mit so einer Technik mit Sicherheit glücklich, zumal wir bisher nur die erste Version kennen bei welcher andere Dinge wie z.B. SMS/MMS noch nicht integriert sind.

Fazit

Hangouts ist meiner Meinung nach eine konsequente Weiterentwicklung des Konzeptes Instant Messaging mit großen Schwächen die Google beheben muss um damit auch bei uns Nerds Erfolg zu haben:

• Offenlegung und Dokumentation des Protokolls
• Fortführung des Dezentralen Ansatzes

DNS Tools

Einer der am meisten unterschätzten Dienste im Internet und auch in vielen lokalen Netzwerken dürfte wohl der DNS Dienst sein. Erst wenn er ausgefallen ist bekommen wir zu spüren das nichts mehr funktioniert und Namensauflösung nicht gerade unwichtig ist. Zusätzlich gibt es durch sog. Virtual Hosts sogar die Anforderung eine funktionierende Namensauflösung zu haben, den ein Webserver mit mehreren Hosts benötigt in der Anfrage zwingend den Hostname und nicht nur eine IP die man sich vielleicht noch merken konnte.

Es gibt insgesamt 5 Tools für DNS welche ich sehr gerne benutze, das wären:

host

Der Standard um zu schauen ob man einen Namen oder eine IP aufgelöst bekommt.

dig

Für Profis das Tool der Wahl wenn es um DNS Records geht und ein Fehler zu suchen ist.

nsupdate

Änderungen an DNS Records ohne ein Zone File manuell bearbeiten zu müssen.

rndc

Nützliches Tool um den Bind Nameserver auf die Sprünge zu helfen.

dnstop

Schauen was im Netzwerk eigentlich los ist.

host

Ist wohl bei den ganzen DNS Tools das am weitesten verbreitete, es gibt davon viele verschiedene Implementierungen mit teilweise vielen besonderen Features. Die Grundlegende Funktion ist aber das Auflösungen von Rechnernamen zu IP Adressen und zurück. Alle weiteren Features sind Optional und je nach Implementierung nicht vorhanden. Die Anwendung von host erfordert keine Erläuterung:

[stefan@pc2007 ~]$ host server.hornynet
server.hornynet has address 192.168.1.1
server.hornynet has IPv6 address fd07:4763:c4fd:8192::1
[stefan@pc2007 ~]$ host 192.168.1.1
1.1.168.192.in-addr.arpa domain name pointer server.hornynet.

dig

Gerne darf es etwas mehr sein, und hierfür nutzt man in der Regel das Tool dig. Der größte und wichtigste Vorteil von dig gegenüber host ist der hohe Informationsgehalt:

[stefan@pc2007 ~]$ dig server.hornynet

; <<>> DiG 9.9.2-P2 <<>> server.hornynet
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server.hornynet.               IN      A

;; ANSWER SECTION:
server.hornynet.        86400   IN      A       192.168.1.1

;; AUTHORITY SECTION:
hornynet.               86400   IN      NS      server.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat May 11 15:16:08 2013
;; MSG SIZE  rcvd: 80

Hier sehen wir unter anderem folgende Informationen:

• Antwort auf unsere Anfrage
• TTL Zeit vom Record (wichtig bei Sachen wie dynamischem DNS)
• Zeit die der Nameserver für die Antwort benötigt hat
• Welcher Server uns geantwortet hat
• Ob es beim bearbeiten unserer Anfrage Probleme gab

nsupdate

Um Änderungen am DNS durchzuführen hat man früher und auch heute noch in einigen Heimnetzwerken diese direkt in das entsprechende Zone File geschrieben. Das Zone File ist der Ort von welchem der DNS Server seine Informationen über einen bestimmten Bereich des DNS bezieht, meist also die eigenen Domains.

Das manuelle bearbeiten von Zone Files ist dabei relativ Fehlerträchtig und erfordert Zugriff auf das Dateisystem des DNS Servers. Die wenigsten Provider werden daher dem Anwender direkten Zugriff auf diesen (wichtigen) Dienst geben. Um Änderungen auch Remote durchführen zu können gibt es das Tool nsupdate. Mit diesem Tool können einem DNS Server über ein definiertes Protokoll die Änderungen zugespielt werden, dieser schreibt diese (wenn valide) in das Zone File und informiert wenn erforderlich auch gleich Slave Nameserver. Der größte Vorteil ist das hierbei gleiche eine Syntaxprüfung durchgeführt wird und der Nameserver nicht neu gestartet werden muss.

In der Praxis sieht das Anlegen eines neuen Hosts dann so aus:

[stefan@pc2007 ~]$ nsupdate -l
> update add server.hornynet. 86400 A 192.168.1.1
> send

rndc

Speziell für mich als Freund des bind Nameservers ist auch rndc ein nützliches Tool. Es wird zur Verwaltung dieses Dienstes verwendet, aber nicht zum bearbeiten der Zone Files sondern wirklich nur für den Dienst an sich. Eine gängige Anwendung wäre das neuladen der Zonen, oder aber auch das Einfrieren einer Zone. Eine Zone die eingefroren ist kann nicht mehr über Tools wie nsupdate verändert werden. Man kann sich aber auch nur den Status vom Server geben lassen:

[root@server ~]# rndc status
version: 9.9.2-P2 (version.bind/txt/ch disabled)
number of zones: 39
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

dnstop

Ein weiteres Tool welches ich gerne verwende, und auch das letzte in diesem Artikel, ist dnstop. Es handelt sich dabei um ein Tool welches auf einem Netzwerkinterface Traffic mitschneidet und Statistiken über den DNS Dienst anlegt.

Das ganze ist sehr informartiv, vor allem Datenschützer wundern sich immer wieder wie viele DNS Anfragen zu Diensten die man eigentlich nicht nutzen möchte rausgehen. Gleichzeitig kann man so auch sehen ob sich ggf. der Einsatz eines DNS Caches lohnt, den gerade bei Veranstaltungen im Bereich von > 20 Personen habe ich schon festgestellt das eine Fritzbox oder ein Telekom Speedport Router gerne mal bei vielen Anfragen in die Knie geht und die Gesamtperformance (wenn man davon bei einem SOHO Router überhaupt sprechen kann) spürbar leidet.

Fazit

Es lohnt sich mal die wichtigsten Tools anzuschauen, spätestens im Fehlerfall ist jedes dieser Tools Gold wert und spart wenn man damit umgehen kann viel Zeit.

DNS Tools

Einer der am meisten unterschätzten Dienste im Internet und auch in vielen lokalen Netzwerken dürfte wohl der DNS Dienst sein. Erst wenn er ausgefallen ist bekommen wir zu spüren das nichts mehr funktioniert und Namensauflösung nicht gerade unwichtig ist. Zusätzlich gibt es durch sog. Virtual Hosts sogar die Anforderung eine funktionierende Namensauflösung zu haben, den ein Webserver mit mehreren Hosts benötigt in der Anfrage zwingend den Hostname und nicht nur eine IP die man sich vielleicht noch merken konnte.

Es gibt insgesamt 5 Tools für DNS welche ich sehr gerne benutze, das wären:

host

Der Standard um zu schauen ob man einen Namen oder eine IP aufgelöst bekommt.

dig

Für Profis das Tool der Wahl wenn es um DNS Records geht und ein Fehler zu suchen ist.

nsupdate

Änderungen an DNS Records ohne ein Zone File manuell bearbeiten zu müssen.

rndc

Nützliches Tool um den Bind Nameserver auf die Sprünge zu helfen.

dnstop

Schauen was im Netzwerk eigentlich los ist.

host

Ist wohl bei den ganzen DNS Tools das am weitesten verbreitete, es gibt davon viele verschiedene Implementierungen mit teilweise vielen besonderen Features. Die Grundlegende Funktion ist aber das Auflösungen von Rechnernamen zu IP Adressen und zurück. Alle weiteren Features sind Optional und je nach Implementierung nicht vorhanden. Die Anwendung von host erfordert keine Erläuterung:

[stefan@pc2007 ~]$ host server.hornynet
server.hornynet has address 192.168.1.1
server.hornynet has IPv6 address fd07:4763:c4fd:8192::1
[stefan@pc2007 ~]$ host 192.168.1.1
1.1.168.192.in-addr.arpa domain name pointer server.hornynet.

dig

Gerne darf es etwas mehr sein, und hierfür nutzt man in der Regel das Tool dig. Der größte und wichtigste Vorteil von dig gegenüber host ist der hohe Informationsgehalt:

[stefan@pc2007 ~]$ dig server.hornynet

; <<>> DiG 9.9.2-P2 <<>> server.hornynet
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server.hornynet.               IN      A

;; ANSWER SECTION:
server.hornynet.        86400   IN      A       192.168.1.1

;; AUTHORITY SECTION:
hornynet.               86400   IN      NS      server.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat May 11 15:16:08 2013
;; MSG SIZE  rcvd: 80

Hier sehen wir unter anderem folgende Informationen:

• Antwort auf unsere Anfrage
• TTL Zeit vom Record (wichtig bei Sachen wie dynamischem DNS)
• Zeit die der Nameserver für die Antwort benötigt hat
• Welcher Server uns geantwortet hat
• Ob es beim bearbeiten unserer Anfrage Probleme gab

nsupdate

Um Änderungen am DNS durchzuführen hat man früher und auch heute noch in einigen Heimnetzwerken diese direkt in das entsprechende Zone File geschrieben. Das Zone File ist der Ort von welchem der DNS Server seine Informationen über einen bestimmten Bereich des DNS bezieht, meist also die eigenen Domains.

Das manuelle bearbeiten von Zone Files ist dabei relativ Fehler trächtig und erfordert Zugriff auf das Dateisystem des DNS Servers. Die wenigsten Provider werden daher dem Anwender direkten Zugriff auf diesen (wichtigen) Dienst geben. Um Änderungen auch Remote durchführen zu können gibt es das Tool nsupdate. Mit diesem Tool können einem DNS Server über ein definiertes Protokoll die Änderungen zugespielt werden, dieser schreibt diese (wenn valide) in das Zone File und informiert wenn erforderlich auch gleich Slave Nameserver. Der größte Vorteil ist das hierbei gleiche eine Syntaxprüfung durchgeführt wird und der Nameserver nicht neu gestartet werden muss.

In der Praxis sieht das Anlegen eines neuen Hosts dann so aus:

[stefan@pc2007 ~]$ nsupdate -l
> update add server.hornynet. 86400 A 192.168.1.1
> send

rndc

Speziell für mich als Freund des bind Nameservers ist auch rndc ein nützliches Tool. Es wird zur Verwaltung dieses Dienstes verwendet, aber nicht zum bearbeiten der Zone Files sondern wirklich nur für den Dienst an sich. Eine gängige Anwendung wäre das neu laden der Zonen, oder aber auch das Einfrieren einer Zone. Eine Zone die eingefroren ist kann nicht mehr über Tools wie nsupdate verändert werden. Man kann sich aber auch nur den Status vom Server geben lassen:

[root@server ~]# rndc status
version: 9.9.2-P2 (version.bind/txt/ch disabled)
number of zones: 39
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

dnstop

Ein weiteres Tool welches ich gerne verwende, und auch das letzte in diesem Artikel, ist dnstop. Es handelt sich dabei um ein Tool welches auf einem Netzwerkinterface Traffic mitschneidet und Statistiken über den DNS Dienst anlegt.

Das ganze ist sehr informartiv, vor allem Datenschützer wundern sich immer wieder wie viele DNS Anfragen zu Diensten die man eigentlich nicht nutzen möchte rausgehen. Gleichzeitig kann man so auch sehen ob sich ggf. der Einsatz eines DNS Caches lohnt, den gerade bei Veranstaltungen im Bereich von > 20 Personen habe ich schon festgestellt das eine Fritzbox oder ein Telekom Speedport Router gerne mal bei vielen Anfragen in die Knie geht und die Gesamtperformance (wenn man davon bei einem SOHO Router überhaupt sprechen kann) spürbar leidet.

Fazit

Es lohnt sich mal die wichtigsten Tools anzuschauen, spätestens im Fehlerfall ist jedes dieser Tools Gold wert und spart wenn man damit umgehen kann viel Zeit.

Datenschutzbeauftragte der Regierung

Das mit dem Datenschutz ist schon eine tolle Sache, wir haben in diesem Land und in vielen Unternehmen sogar sog. Datenschutzbeauftragte. Deren Job ist es dafür zu sorgen das Daten nur so wenig wie möglich gespeichert werden um einen Missbrauch vorzubeugen. Das klingt auf den ersten Blick sinnvoll, ist es auch, jedoch haben wir da in der Praxis ein paradoxes Problem: Auch die Regierung hat Datenschutzbeauftragte.

Doch wann immer unsere Rechte aufgeweicht werden sind diese Personen nicht oder zu leise am Werk, wenn jedoch ein Unternehmen wie Google oder Facebook seine AGBs verändert geht deren Arbeit so richtig los. Man möchte also ein Unternehmen dessen Dienste die meisten Personen (wenn auch aus Unwissenheit) freiwillig nutzen vor Gericht ziehen, und so eine Art Exempel für den guten alten Datenschutz statuieren. Auch wenn ein Unternehmen Daten von nicht verschlüsselten WLAN Netzwerken schneidet, sind diese Personen (Amtsinhaber) an der Front und setzen sich für die Bürger ein.

Aber wann verklagt einer dieser Datenschutzbeauftragten der Regierung endlich mal Deutschland? Wann verklagt ein derartiger Datenschutzbeauftragter endlich mal die Stasiparteien (CDU, CSU, SPD, …) anstatt sich über die AGBs freiwillig nutzbarer Dienste aufzuregen? Wann geht ein dieser Amtsinhaber gegen die Überwachung von Schülern in Schulen aufgrund möglicher Urheberrechtsverletzungen vor?

Ich finde es nicht gut was Google da macht, ich finde es auch nicht gut das Daten von öffentlichen WLANs mitgeschnitten wurden oder Facebook den Nutzer aussaugt. Aber hier hat der Anwender noch eine Wahl, den Nutzer kann auf Facebook, Google und viele andere verzichten. Diese Möglichkeit hat er bei den Überwachungsgesetzen der letzten Jahre nicht, weder bei der Bestandsdatenauskunft noch bei der Vorratsdatenspeicherung (R.I.P.) hatte er diese Option. Aber eins ist sicher, die Medien werden wieder mitmachen, den Unternehmen wie Google sind das pure böse, das wissen wir spätestens seit StreetView ein Sommerlochthema war und Hausfassaden Persönlichkeitsrechte haben.

Sofortüberweisung

Ein meiner Meinung nach überflüssiger und ausgesprochen dämlicher Dienst ist aktuell wieder in den Medien. Die Rede ist natürlich von Sofortüberweisung.de, einem Dienst der das schnelle und sichere Bezahlen im Internet ermöglichen soll.

Wer sich mit dem Prinzip beschäftigt hat, kann bei diesem Dienst nur mit dem Kopf schütteln, das ganze mag schnell sein, vielleicht auch bequem, aber auf keinen Fall sicher. Denn unabhängig von den AGBs seiner Bank sollte man den Zugang zu seinem Online Banking niemandem überlassen. Wenn ich in der Bäckerei einkaufe gebe ich dem Verkäufer der Backwaren auch nur einen bestimmten Geldbetrag, und nicht gleich meinen ganzen Geldbeutel inkl. EC Karten und passender PIN Nummern.

Das bisherige Bezahlsysteme nicht ausreichend sind ist meiner Meinung nach auch keine Rechtfertigung für dieses hässliche Workaround. Ich selbst kaufe nichts über diesen Dienst, und werde es auch in Zukunft nicht unterstützen.

Bisher ist noch nicht viel passiert, aber es ist nur eine Frage der Zeit, da hilft auch eine vermeintliche doppelte Verschlüsselung der PIN und TAN nichts. Ich werde mir das von Außen ansehen, und schon mal für einen entsprechenden Vorrat an Popcorn sorgen wenn der Laden Probleme bekommt ;-)