Content from 2013-05

Locked-in by Google

posted on

For several years now WhatsApp is spreading on the smart phones of my contacts. Of course my friends are asking me to install the software as well. But I hate using a proprietary service if there are open alternatives. This open and comprehensive alternative was and is Jabber respectively XMPP (two names for the same thing).

But this is nothing more then a protocol. Especially nothing anybody could use. What a Jabber user needs is software and a service provider. Until now my recommendation for both was Google Talk. The software perfectly integrated and pre-installed on every Android phone. An easy to use user interface, comprehensible to John Doe. Nothing made for freaks by nerds. And as an operator Google provided a rock solid service.

That was a smasher: you could get everything well co-ordinated from Google, you could chat with users of other providers, and you could even operate our own server if you wanted to. Real class!

With my denial of using a closed system and my continuing referral to free alternatives, I brought several contacts to Google Talk.

Google Talk gets Hangouts

At the I/O 2013­–Google's annual developers conference–"Talk" has become "Hangouts". A reasonable move. The last years Google had started several communication products, that had not work well with each other. Besides "Google Talk" there was "Google Voice", "Google+ Messenger", the previous "Hangouts", and some time they even had "Google Wave". For a user it was confusing to have different products to do essentially the same: communicate with their contacts. You could have your contacts multiple times: in Talk, in Google+, and so on. Before you started to chat, you had to decide which application to use this time. Thus I am completely fine to integrate everything into one product. Using a communications product must be easy and clear.

But actually there was another thing that happened at the same time: Google decided to close their platform. Until now Google users where able to communicate with users of other providers. Nikhyl Singhal, director product management real time communications at Google expressed it (starting 5:07 in the video below): "Hangouts is not based on top of the XMPP standard. […] We have essentially made a hard decision to focus less on the XMPP standard and more on what are users looking for." Well maybe that sounds good, but with regards to content it is dreck.

As I said XMPP is a protocol and nothing the user is working with. Users care about the experience, the interface, and the fun. Where is the conflict? Why not concentrate on all the things a user cares and still building this based on top of XMPP? XMPP is the "eXtensible Messaging and Presence Protocol". The key word here is "extensible". There is really no problem to create all the nice things Google wants to deliver using XMPP.

In my opinion the actual reason of Google to close their platform is something else: Google wants to look users onto their services. It is not wanted anymore, that users may communicate with users of other providers. Google wants these other people to have an account at Google as well.

This is very similar to another shut down of a Google service next month: Google Reader. This as well is a product, that allows Google users to subscribe to and read feeds from third party services. Google closes this service supposedly in the hope, that former Reader users start using Google+ instead. (No need to mention, that on Google+ you can only subscribe to content of other Google+ users.)

What now?

The reason why I used Talk instead of other messengers has fallen away. I do not want to be caged in the service of a single provider. My formally Google hosted Jabber address m@tthias.eu is now hosted on a free server again. I am stilly also reachable using the same address on the Google Hangouts platform. But probably this will stop sooner or later.Until then I am looking for a user friendly Jabber application for Android, that I able to work well with mobile internet connections. Who knows, maybe the application is already there, I just do not know it yet. After Google announced the shut down of Reader I also was surprised to find Feedly. Some software that already did exist and feels better than what I used before. Recommendations are always welcome.

And what's about WhatsApp? If Google is not better anymore, will I start supporting what "everyone else already uses"? No, I do not think so.

Further reading

Eingesperrt von Google

posted on

Seit einigen Jahre macht sich WhatsApp auf den Smartphones meiner Kontakte breit. Natürlich werde ich von meinen Bekannten auch immer wieder aufgefordert das Programm doch zu installieren. Ich wollte das nie. Mir war es zuwider mich auf einen proprietären Dienst einzulassen wenn es offene Alternativen gibt. Diese offene und Anbieter übergreifende Alternative war und ist Jabber bzw. XMPP (zwei Namen für das gleiche).

Nun ist dies erst einmal aber nur ein Protokoll und damit nichts was man nutzen könnte. Was ein Jabber-Nutzer braucht ist ein Programm und Diensteanbieter. Hierfür war meine Empfehlung bisher Google Talk. Als Programm super integriert und vorinstalliert auf jedem Android-Telefon. Eine einfach zu bedienende Oberfläche, die auch für einen „Normalmenschen“ verständlich ist. Nichts was von Freaks für Freaks gemacht ist. Als Anbieter stand Google mit einem super stabilen Dienst dahinter.

Bisher eine tolle Sache: einerseits konnte man komplett abgestimmt alles aus einer Hand bekommen, andererseits konnte man mit Nutzern bei anderen Anbietern chatten und wenn man wollte sogar einen eigenen Server installieren. Echt klasse!

Mit meiner Weigerung ein geschlossenes Messaging zu nutzen und meinem andauernden Hinweis auf die freie Alternative habe ich auch einige Freunde und Bekannte zu Google Talk gebraucht.

Aus Google Talk wird Hangouts

Zur diesjährigen Konferenz Google I/O wurde „Talk“ nun zu „Hangouts“. Ein soweit vernünftiger Schritt. Google hat in den letzten Jahre mehrere miteinander nicht wirklich sinnvoll verzahnte Kommunikationsdienste gestartet. Neben „Google Talk“ gab es „Google Voice“, „Google+ Messenger“ die bisherigen „Hangouts“ und eine Zeit lang sogar „Google Wave“. Für einen Nutzer hat es keinen Sinn gemacht das gleiche über verschiedene Produkte machen zu können. Auch für mich war es verwirrend einen Kontakt mehrfach online zu sehen: mal als Talk-Kontakt, dann als Google+-Kontakt und als was weiß ich noch. Wieso sollte ich bevor ich mit jemandem chatten oder (video)telefonieren wollte erst überlegen in welchem Programm ich das mache? Ich habe also überhaupt nichts dagegen einzuwenden, dass hier aufgeräumt wurde und die verschiedenen Kommunikationswege unter eine Haube mit dem Namen „Google Hangouts“ gebracht werden. – Im Gegenteil: das ist eine prima Sache. Die Nutzung eines Kommunikationsdienstes muss einfach und übersichtlich sein.

Tatsächlich passiert ist aber gleichzeitig noch etwas viel weitreichenderes: Google hat beschlossen die eigenen Nutzer ihrer Plattform nicht mehr mit Nutzern anderer Anbieter kommunizieren zu lassen. Nikhyl Singhal, Direktor Produktmanagement für Echtzeitkommunikation bei Google drückt das (ab 5:07 in unten stehendem Video) so aus: „Hangouts is not based on top of the XMPP standard. […] We have essentially made a hard decision to focus less on the XMPP standard and more on what are users looking for.“ (Hangouts baut nicht auf den XMPP-Standard auf. Wir haben im Wesentlichen die schwere Entscheidung getroffen uns weniger nach dem XMPP-Standard zu richten und mehr danach was Nutzer suchen.“) Nun das klingt vielleicht gut, ist inhaltlich aber Mist.

Wie oben schon erwähnt ist XMPP ein Protokoll und nichts was Nutzer direkt nutzen. Nach was die Nutzer schauen ist das Nutzungserlebnis, die Oberfläche und der Funfaktor eines Dienstes. Wo liegt da der Widerspruch? Wieso sollte man wenn man sich hierauf konzentriert darunter nicht XMPP benutzen? XMPP ist das „eXtensible Messaging and Presence Protocol“ (erweiterbares Protokoll für Nachrichtenvermittlung und Präsenz). Das Schlüsselwort hierbei ist extensible bzw. erweiterbar. Es ist gar kein Problem in XMPP all die schönen Dinge zu tun, die Google mit Hangouts machen möchte.

Ich denke, der Grund wieso Google die eigene Plattform gegen außen abschottet ist auch ein ganz anderer: der Nutzer soll an Google gebunden werden. Man möchte es einfach nicht mehr, dass auch mit Kontakten bei anderen Anbietern die Kommunikation möglich ist. Man möchte, dass diese Kontakte auch zu Google kommen müssen.

Das ganze ist ähnlich wie die Einstellung von Google Reader nächsten Monat. Auch dies war ein offener Standard über den ein Google-Nutzer Nachrichtenfeeds von anderen Anbietern abonnieren und lesen konnte. Auch dieser Dienst wird eingestellt, da man es lieber sieht, dass der Nutzer sich seine Nachrichtenfeeds über die geschlossene Platform „Google+“ bezieht.

Was nun?

Für mich ist der Grund wieso ich Talk anstatt anderer Messenger benutzt habe weggefallen. Ich will nicht in den Dienst eines Providers eingesperrt sein. Meine bisher bei Google gehostete Jabber-Adresse m@tthias.eu läuft seit gestern wieder auf einem freien Server. Noch bin ich unter der gleichen Adresse auch bei Google Talk/Hangouts erreichbar. Aber vermutlich wird dies über kurz oder lang ein Ende haben. Bis dahin bin ich noch auf der Suche nach einem benutzerfreundlichen und gut mit Mobilfunkverbindungen klarkommenden Jabber-Programm für Android. Wer weiß, vielleicht gibt es das ja schon und ich kenne es nur noch nicht. Nach der Ankündigung, dass Google Reader eingestellt wurde, war ich auch überrascht welche tolle Alternative ich in Feedly finden konnte. Empfehlungen nehme ich gerne entgegen.

Und WhatsApp? Wenn Google nicht mehr besser ist, werde ich nun auch das unterstützen „was alle eh schon haben“? Nein, ich denke nicht.

Weitere Infos in folgenden Artkeln:

DHL: Erfolgloser Zustellversuch, Empfänger nicht zu Hause

posted on

Ich kann mal wieder von DHL berichten: ich habe dringend ein Buch benötigt und Amazon konnte dies nur noch mit der Lieferoption „Morning Express“ am nächsten Tag liefern. Nicht schlecht, dachte ich: da die Lieferung an einem Freitag und ins Büro erfolgt, ist es super die Sendung „garantiert“ vor zwölf Uhr zu erhalten.

Am Tag der Zustellung schaue ich also immer mal wieder aus dem Fenster des Büros, wenn ein Paketdienst vorbeifährt. Mittag kommt immer näher und ich wundere mich, dass die Sendung noch nicht angekommen ist. Es wird doch hoffentlich alles klappen? Ich brauche das Buch dringend um mich auf einen Kundentermin vorzubereiten.

Punkt zwölf Uhr kommt der Paketboote – fast ein wenig außer Atem – durch die Türe und hat mein Paket in der Hand. „Das hat ja gerade noch geklappt,“ denke ich schmunzelnd und nehme das Paket entgegen.

Wirklich verärgert hat es mich nun aber, als ich am Wochenende ins Tracking von DHL geschaut habe. Ich wollte wissen, welche Uhrzeit DHL als Zustellzeitpunkt erfasst hat. Dabei stelle ich fest, dass angeblich schon eine halbe Stunde zuvor ein Zustellversuch stattgefunden habe, jedoch der Empfänger nicht anzutreffen war. („Erfolgloser Zustellversuch. Empfänger nicht zu Hause.“)

Was ist denn das für ein Unsinn? Die Lieferung ging an eine Firmenadresse. Einerseits saß ich im Büro und habe auf die Lieferung gewartet und andererseits waren zusätzlich auch noch Kollegen im Büro, die die Sendung genauso hätten annehmen können – wenn denn jemand da gewesen wäre, der einen Zustellversuch unternommen hätte.

Es scheint mir doch sehr, als habe der Kurier hier einfach schon einmal einen Zustellversuch in seinem Gerät vermerkt, ohne dass er vor Ort gewesen wäre. Vermutlich war im klar, dass es knapp wird mit der rechtzeitigen Zustellung. Die Liefergarantie gilt nämlich nur für den ersten Zustellversuch.

Mein DNSsec-Setup

posted on

Vor ein paar Tagen habe ich bereits über einen Teil meines Nameserver-Setups mit Bind geschrieben. Ich habe erklärt, wie DDNS mit bind verwendet werden kann um beispielsweise Kunden die Möglichkeit zu geben Änderungen an Ihren Zonen über ein standardisiertes Protokoll durchzuführen oder die sich häufiger ändernde IP des Internetanschlusses zuhause immer aktuell im DNS zu hinterlegen. Dabei habe ich erwähnt, dass ein interessantes Argument für den Einsatz von DDNS zum Updaten von Zonen auch ist, dass bind in diesem Fall sich automatisch darum kümmert diese erneut zu signieren. Wie dieses Setup funktioniert möchte ich in diesem Artikel beschreiben.

Ziele meines Setups

Wenn man versucht etwas kryptografisch abzusichern, dann sollte der erste Schritt immer der gleiche sein. Es ist zu bestimmen, gegen welche Arten von „Angriffen“ man sich schützen möchte. Je nachdem was man sich hier für Vorgaben macht kommt man zu teilweise komplett verschiedenen „optimalen Lösungen“.

In meinem Setup kommt es mir nicht darauf an die höchstmögliche Sicherheit herzustellen. Vielmehr ist das Ziel meines DNSsec-Einsatzes die Grundsicherheit zu erhöhen. Einfache Angriffe mit dem Ziel DNS-Einträge im Cache von DNS-Resolvern zu verfälschen sollen verhindert werden. DNSsec soll bei mir deswegen möglichst breit und damit für alle Zonen verwendet werden. Es ist deshalb wichtig, dass möglichst kein zusätzlicher Aufwand in der Verwaltung der Zonen entsteht oder dieser nur minimal ist.

Indem ich bei meinem Setup die zur Signatur der Zonen genutzten Private-Keys auf meinem Server ablege(n muss), habe ich an einem anderen Punkt jedoch keinen erhöhten Schutz meiner Zonen: wenn es einem Angreifer gelingt durch irgendeine Lücke in meinen DNS-(Master-)Server einzudringen, so kann er Modifikationen an meiner Zone vornehmen und für diese trotzdem eine gültige Signatur erzeugen.

Ein weiterer Punkt bei dem mein Setup keine Verbesserung der Sicherheit bringt ist der Schutz gegen Angriffe, die meine Zonen unerreichbar machen. Es gibt sogar Überlegungen, dass der Einsatz von DNSsec prinzipiell die Sicherheit im Internet gegen DOS-Angriffe vermindert. Bei der DNS Amplification Attack werden DNS-Server genutzt um andere Server mit einem DOS-Angriff zu überziehen. Die Aktivierung von DNSsec vergrößert dabei die Gefahr, dass der eigene DNS-Server hierfür missbraucht wird.

Konfiguration von bind

In diesem Abschnitt erkläre ich welche Änderungen an den Konfigurationsdateien von bind vorgenommen werden müssen, damit die eigenen Zonen signiert ausgeliefert werden. Wie sich zeigen wird ist dies gar nicht viel. Es reichen zwei kleine Änderungen.

Grundsätzliches aktivieren von DNSsec

Damit bind grundsätzlich den Umgang mit DNSsec aktiviert, muss dies in der Konfiguration im options-Abschnitt angegeben werden:

options {
    directory "/var/cache/bind";

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };

    allow-recursion { 127.0.0.1; ::1; };

    dnssec-enable yes;
    dnssec-validation yes;

    allow-transfer {
        key doux.amessage.eu.;
        key eder.amessage.eu.;
    };
};

Zur Aktivierung muss hier einfach der Eintrag „dnssec-enable yes;“ angegeben werden. (Der Eintrag „dnssec-validation yes;“ ist nicht notwendig und auf einem reinen autoritativen Nameserver auch nicht sinnvoll. Der Eintrag ist bei mir nur vorhanden, da ich meinen bind für localhost als recursive DNS-Server nutze.)

Diese Konfigurationsänderung muss sowohl auf dem Master-Nameserver wie auch auf allen Slave-Nameservern erfolgen.

Den einzelnen Zonen mitteilen wo sich die zugehörigen Keys befinden

Die zweite notwendige Änderung ist es, dass die Definition der Zone noch um zwei Zeilen erweitert wird:

zone "mwimmer.com" in {
    auto-dnssec maintain;
    type master;
    notify yes;
    file "/etc/bind/zones/mwimmer.com.zone";
    update-policy {
        grant root.user.invalid.     subdomain mwimmer.com. ANY;
        grant matthias.user.invalid. subdomain mwimmer.com. ANY;
    };
    allow-transfer {
	key root.user.invalid.;
	key doux.amessage.eu.;
        key matthias.user.invalid.;
    };
    key-directory "/etc/bind/keys";
};

Hier habe ich über „auto-dnssec maintain;“ bind mitgeteilt, dass er bei Updates der Zone diese automatisch neu signiert. Außerdem habe ich mit „key-directory "/etc/bind/keys";“ angegeben wo bind nach den notwendigen Private-Keys zur Signatur der Zone sucht. Ohne letzteren Eintrag würde bind in seinem working Directory suchen. Dieses ist auf einem Debian-System (wie man auch im vorherigen Config-Ausschnitt sieht) /var/cache/bind, was für eine Ablage der DNSsec-Keys nicht geeignet ist, da dieses Verzeichnis normalerweise nicht mit gebackupt wird.

Diese Änderung ist nur auf dem Master-Nameserver notwendig.

Einrichten einer Zone

Zum Einrichten einer neuen Zone auf meinem Nameserver erstelle ich hierfür zuerst eine normale, nicht signierte Zonendatei. Außer den Einträgen auto-dnssec und key-directory in der Bind-Konfiguration, die ich sofort mit eintrage, wird die Zone also zuerst vollkommen normal und ohne Signaturen angelegt und mit einem Aufruf von rndc reconfig auch aktiviert. (Wurde die Konfiguration einer bestehenden Zone geändert um beispielsweise bei einer bereits vorhandenen Zone DNSsec nachzurüsten, so muss stattdessen rndc reload benutzt werden.)

Die Zone wird ab diesem moment von bind ausgeliefert, ist aber noch unsigniert. Im nächsten Schritt geht es jetzt also darum die notwendigen DNSsec-Schlüssel zu erzeugen. Es werden hierzu zwei Schlüsselpaare erzeugt. Das eine paar ist der Key-Signing-Key (KSK). Ein Fingerabdruck hiervon sollte soweit möglich später in die übergeordnete Zone hinterlegt werden. Mit diesem Key-Signing-Key wird später von bind das zweite Schlüsselpaar, der sogenannte Zone-Signing-Key (ZSK), unterschrieben. Erst mit dem Zone-Signing-Key werden dann tatsächlich die eigenen Records in der Zone unterschrieben.

Die Erstellung der beiden Schlüsselpaare erfolgt mit dem Tool dnssec-keygen, das Teil der bind-Distribution ist (Debian-Paket: bind9utils):

dnssec-keygen -K /etc/bind/keys -a RSASHA512 -b 2048 -f KSK mwimmer.com
dnssec-keygen -K /etc/bind/keys -a RSASHA512 -b 1024 mwimmer.com

Je nachdem wie viel Entropie auf eurem System vorhanden ist, kann die Erzeugung dieser zwei Schlüsselpaare durchaus mehrere Stunden beanspruchen. Also nicht verzweifeln, wenn lange Zeit nichts vorwärts geht. Am besten startet ihr die Schlüsselerzeugung also in einem screen.

Nach der Erstellung der Schlüsselpaare muss noch sichergestellt werden, dass die Schlüssel von bind gelesen werden können. Da dnssec-keygen den Private-Key nur für den Datei-Owner lesbar macht (Zugriffsrechte „rw-------“) müssen wir auf einem Debian-System die erzeugten Dateien beispielsweise dem User „bind“ zuweisen.

Wenn nun beide Schlüsselpaare erzeugt und für bind lesbar sind, müssen wir bind noch mitteilen, dass er diese Keys ab sofort zur Signatur der Zone verwenden soll: rndc sign mwimmer.com

Voilà: bind liefert ab diesem Moment eine signierte Zone aus und kümmert sich auch darum, wann die Zone neu signiert werden muss.

Signaturen der Zone in der übergeordneten Zone eintragen (lassen)

Damit fremde Nameserver die Signaturen in der Zone prüfen können, müssen diese wissen welche Keys überhaupt berechtigt sind die Zone zu signieren. Bei DNSsec geschieht dies, indem die Signatur(en) des/der berechtigten Keys in die übergeordnete Zone eingetragen werden. Die Keys mit denen ich die Zone „mwimmer.com“ signiere sind entsprechend also in der Zone „com“ eingetragen. Indem die Zone „com“ wiederum selbst signiert ist und deren Schlüssel in der DNS-Root-Zone eingetragen ist usw. reicht es auf anderen Nameservern aus, dass dort nur die gültigen Keys für die Root-Zone eingetragen werden müssen. Die Funktionsweise ist also sehr ähnlich zu der von X.509-Zertifikaten. Auch bei diesen müssen einem Browser nur die Stammzertifikate der Zertifizierungsstellen bekannt.

Wie konkret in die übergeordnete Zone eingetragen wird was die gültigen Key-Signing-Keys sind ist sehr unterschiedlich. Was man allgemein nur sagen kann ist, dass dieser Eintrag über den Registrar erfolgt bei dem man die Domains registriert hat. Ob dieser DNSsec überhaupt unterstützt und wenn ja wie man ihm die Keys bekannt macht, ist von Registrar zu Registrar verschieden.

Ich persönlich habe mir für InterNetX entschieden und bin wegen DNSsec extra zu diesem Provider gewechselt, da meine vorherigen Provider leider alle nicht in der Lage waren DNSsec-Signaturen anzunehmen.

Außerdem ist es auch so, dass noch nicht bei allen Top-Level-Domains überhaupt eine Delegation mit DNSsec möglich ist. Bei den meisten größeren TLDs (z.B. .DE, .com, .net, .org, .eu) ist dies allerdings kein Problem mehr.

Ich möchte euch noch kurz zeigen, wie die Konfiguration der DNSsec-Delegation vom Falle von InterNetX geschieht.

DNSsec bei InterNetX (AutoDNS 3.0)

Hinweis vorweg: DNSsec unterstützt das Eintragen der Fingerprints von DNSsec-Schlüsseln in die übergeordneten Zonen. Wenn man DNSsec benutzen möchte, so muss man die Nameserver jedoch (mit den oben beschriebenen Einstellungen) selbst betreiben. Die Nameserver, die man über den AutoDNS verwalten kann, sind selbst nicht für DNSsec aktiviert.

Damit InterNetX die Signatur des Schlüssels mit dem wir unsere Zonen signieren an die übergeordnete Registry weiter gibt, müssen wir unseren öffentlichen Teil des Key-Signing-Keys bei der jeweiligen Zone hinterlegen. Damit der entsprechende Reiter bei der Zone im AutoDNS erscheint, müssen wir „DNSSEC aktivieren“ in den Einstellungen der Benutzeroberfläche aktivieren.


Grundsätzliches aktivieren von DNSsec in der Oberfläche des AutoDNS 3.0

Nachdem diese Einstellung aktiviert ist, erhalten wir in der Domainverwaltung wenn wir eine Domain bearbeiten einen zusätzlichen Reiter „DNSSEC“:


Reiter „DNSSEC“ in der Oberfläche des AutoDNS 3.0

In diesem Reiter müssen wir den verwendeten Algorithmus unseres Key-Signing-Keys eintragen (in obigem Beispiel haben wir einen RSASHA512-Schlüssel erzeugt, wir wählen also „10 (RSA/SHA-512)“. Außerdem tragen wir den BASE64-enkodierten öffentlichen Schlüssel (public Key) in das darunter stehende Eingabefeld ein. Zu diesem öffentlichen Schlüssel kommen wir am einfachsten, wenn wir unseren Nameserver fragen:

dig mwimmer.com DNSKEY | grep 257

Hinweis: Ich habe die Erfahrung gemacht, dass es mit AutoDNS 3.0 bei DE-Domains nicht funktioniert, wenn ich den DNSsec-Schlüssel bereits bei der Registrierung mit angebe. Die Domain wird dann zwar registriert, aber der Fingerprint des DNSsec-Keys nicht mit eingetragen. Ich habe mir deswegen auch bei der Registrierung angewöhnt diese zuerst ohne DNSsec durchzuführen und wenn sie fertig ist, bearbeite ich die Zone nochmals und trage die DNSsec-Einstellungen im AutoDNS 3.0 nach.

Mis primeros libros reales en Español han legado :-)

posted on

Esto son mis primeros libros normales en Español. No son libros para estudiantes de Español.

Creo que leer libros que sea interesante para mi es mejor para aprender un nuevo idioma.

Mis primeros libros españoles


Unless otherwise credited all material Creative Commons License by Matthias Wimmer