Kreative Verschlüsselungsansätze für Jabber
Dieser Text ist im Cache von metaowl.de - das Original ist hier zu finden.
Peter Saint-Andre, einer der Direktoren bei der XMPP Standards Foundation berichtet in Got Encryption? in seinem Weblog "one small voice" über neue Ansätze und Spezifikation für die Verschlüsselung von Jabber Chats.
Zusammengefasst würden deren Resultate bei Umsetzung so aussehen, dass Jabber Clients zu Servern (c2s, client-to-server) und Jabber Server untereinander (s2s, server-to-server) wie bisher per SSL/TLS verschlüsselte Verbindungen aufbauen – jedenfalls solange noch nicht jeder Internetnutzer über feste IPs und Domains verfügt.
Danach wird aber Verbindung und Kommunikation zwischen zwei oder mehreren Jabber Nutzern immer direkt über XML Streams durchgeführt, basierend auf Google Talks Jingle. Jeder Jabber Nutzer bekommt ein Zertifikat, zum Beispiel von der XMPP Zertifizierungsinstanz oder CAcert. Als Alternative denkt man auch an OpenPGP Schlüssel, die man ja bereits mit Jabber zur Verschlüsselung nutzen kann, um sie nach RFC 5081 für verschlüsselte TLS Sitzungen, Zertifikate und Schlüsselaushandelungen zu verwenden. Zwei Jabber Nutzer bauen also direkt zueinander (e2e, end-to-end) verschlüsselte Jingle bzw. XML Streams über TLS und eigene Zertifikate auf, die sie natürlich vorher überprüfen müssen. In Zukunft könnten also die Jabber Server nur noch als Vermittlungsstellen dienen, wenn sich daraus nicht ein vollständig serverloses Jabber Messaging entwickelt oder die Nutzer können wahlweise entscheiden, ob sie direkt oder über die verschlüsselten Transportkanäle der Jabber Server miteinander kommunizieren möchten, was wiederum der Anonymisierung förderlich wäre.
Alles noch Zukunftmusik, da gerade mal die XMPP Erweiterungen 0247 - Jingle XML Streams und 0246 - End-to-End XML Streams spezifiziert wurden, aber wie Saint-Andre schreibt, möchte man so schnell wie möglich die darauf basierenden "encrypted e2e streams" testweise in eine Reihe von Jabber Clients einpflanzen. Nur zu, bei all den Überwachungs-Zwangsstörungen, die Regierungen und Unternehmensführungen seit Jahren plagen, kann man jedes Heil- und Abwehrmittel gebrauchen.
Zusammengefasst würden deren Resultate bei Umsetzung so aussehen, dass Jabber Clients zu Servern (c2s, client-to-server) und Jabber Server untereinander (s2s, server-to-server) wie bisher per SSL/TLS verschlüsselte Verbindungen aufbauen – jedenfalls solange noch nicht jeder Internetnutzer über feste IPs und Domains verfügt.
Danach wird aber Verbindung und Kommunikation zwischen zwei oder mehreren Jabber Nutzern immer direkt über XML Streams durchgeführt, basierend auf Google Talks Jingle. Jeder Jabber Nutzer bekommt ein Zertifikat, zum Beispiel von der XMPP Zertifizierungsinstanz oder CAcert. Als Alternative denkt man auch an OpenPGP Schlüssel, die man ja bereits mit Jabber zur Verschlüsselung nutzen kann, um sie nach RFC 5081 für verschlüsselte TLS Sitzungen, Zertifikate und Schlüsselaushandelungen zu verwenden. Zwei Jabber Nutzer bauen also direkt zueinander (e2e, end-to-end) verschlüsselte Jingle bzw. XML Streams über TLS und eigene Zertifikate auf, die sie natürlich vorher überprüfen müssen. In Zukunft könnten also die Jabber Server nur noch als Vermittlungsstellen dienen, wenn sich daraus nicht ein vollständig serverloses Jabber Messaging entwickelt oder die Nutzer können wahlweise entscheiden, ob sie direkt oder über die verschlüsselten Transportkanäle der Jabber Server miteinander kommunizieren möchten, was wiederum der Anonymisierung förderlich wäre.
Alles noch Zukunftmusik, da gerade mal die XMPP Erweiterungen 0247 - Jingle XML Streams und 0246 - End-to-End XML Streams spezifiziert wurden, aber wie Saint-Andre schreibt, möchte man so schnell wie möglich die darauf basierenden "encrypted e2e streams" testweise in eine Reihe von Jabber Clients einpflanzen. Nur zu, bei all den Überwachungs-Zwangsstörungen, die Regierungen und Unternehmensführungen seit Jahren plagen, kann man jedes Heil- und Abwehrmittel gebrauchen.
von ravenhorst - Owl,
gepostet am Donnerstag, 19. Juni 2008 um 13:26
