burn a church
Zucht und Ordnung from hell

Das IRC ist die älteste und nach wie vor beliebteste Umsetzung von einem Internet Chat. Es entstand zu einer Zeit, wo das Internet nicht das war, wie wir es heute kennen. Entsprechend verstaubt und antiquiert wirkt das zugrunde liegende Protokoll heute auch, was gerade den Charme zu den unerträglichen browserbasierten Webchats ausmacht.

Doch ein Problem hat IRC: In der Spezifikation ist die Verschlüsselung von Kommunikation nicht einmal vorgesehen, geschweige den gefordert. Dies ist natürlich inakzeptabel.

Wozu verschlüsseln?

Der Grund einer Verschlüsselung, ergibt sich aus der Möglichkeit. IRC ist ein textbasiertes Protokoll, als solches ist es ein leichtes Kommunikationsstränge zu verfolgen, wenn man an geeigneter Stelle sitzt, von wo aus eine Abhörung möglich ist. Klassische Orte sind zum Beispiel der Netzwerkrouter, ein zwischengeschalteter Repeater (”Man in the Middle”) und - natürlich - im jederzeit abhörbaren WLAN.

IRC-Server die eine Verbindung über SSL ermöglichen verhindern erzeugen dabei lediglich ein falsches trügerisches Gefühl der Sicherheit. Denn IRC ist ein dezentrales, verteiltes Protokoll. Anders als zum Beispiel HTTP (das WWW, surfen im Web) wo es eine abgeschlossene Ende-zu-Ende Verbindung zwischen Webbrowser und Webserver gibt, ist dies beim IRC keineswegs so. Ein IRC-Klient kann sich natürlich verschlüsselt zu einem IRC-Server verbinden, dieser ist aber seinerseits mit Hunderten anderer Benutzer und Server verbunden und agiert lediglich als Proxy, als Nachrichtenverteiler. Es gibt keine Garantie, dass der Server diese Verbindungen ebenso verschlüsselt. Es ist also lediglich eine Frage des gewählten Ortes, wo man den großen Lauschangriff startet. So bezeugt dies auch nebenstehender Screenshot vom Netzwerkanalysator wireshark mit dessen Hilfe es kein Problem ist, IRC-Kommunikation zu filtern und zu decodieren. Im unteren Fenster erscheint die gesprochene Kommunikation im Klartext.

Benutzer von IRC-Netzwerken mit “Services” kennen den Befehl, einen registrierten Nickname beim Server anzumelden. Im IRC-Klienten tippt man “/msg nickserv identify geheimespasswort” und meldet sich so mit einem persönlichen Passwort beim IRC-Service “NickServ” an. Selbstverständlich ist auch dieses abhörbar. Dies ist einer der wenigen Fälle wo eine SSL geschützte Verbindung tatsächlich helfen könnte.

Im übrigen werden auch private Benutzer-Benutzer Verbindungen im IRC Query genannt über den Server transportiert, ermöglichen also den Serverbetreibern ohne weiteres ein abhören dieser vermeintlich privaten Kommunikationswege. Unabhängig von der Wahrscheinlichkeit ist es also problemlos für Serverbetreiber möglich sämtliche Kommunikation über ihre Server abzuhören. Und das ist keineswegs derart unwahrscheinlich, es gibt eine sehr große Anzahl an IRC-Netzwerken, viele davon von dubiosen und fragwürdigen Betreibern.

Es macht also durchaus Sinn, ähnlich wie sich das in Jabber und ICQ als unter dem Namen Off the Record Messaging langsam durchsetzt, eine Ende-zu-Ende Verschlüsselung zu benutzen die eben zwischen den einzelnen Teilnehmern eine Verschlüsselung unterstützt. Wieder ein Screenshot von Wireshark, diesmal allerdings wurde die Kommunikation verschlüsselt.

Ende-zu-Ende Verschlüsselung ist allerdings nur umsetzbar, wenn diese beide Seiten unterstützen. Dies erreicht man, indem der Anwender auf ein Protokoll zurückgreift, das diese von Haus aus unterstützt. SILC zum Beispiel ist ein dem IRC sehr ähnliches Protokoll bei dem dies von Grund auf in das Konzept integriert ist. Allerdings ist es nicht kompatibel zu herkömmlichen IRC, sodass eigene Klienten dafür benötigt werden, was sich nachteilig auf die Verbreitung von SILC auswirkt. Zum anderen und damit wesentlich besser, ist eine transparente Integration von Verschlüsselung im Klienten, wobei das herkömmliche IRC-Protokoll als Transport verwendet wird. Es ist damit völlig transparent für den Anwender, der nach wie vor herkömmlich in IRC-Channels verweilen kann, aber gleichzeitig in Privatfenstern und verschlüsselten Kanälen Verschlüsselung nach Bedarf verwenden kann.

FiSH

FiSH ist die gängigste Umsetzung für Verschlüsselung auf der Anwenderseite. Es ermöglicht sowohl in Privatfenstern (Queries) mit zwei Benutzern, als auch in Channels mit einer unbegrenzten Benutzeranzahl die Anwendung von Verschlüsselung. Anders als die asymmetrische Kryptoverfahren, die andere Umsetzungen (beispielsweise OTR) für diesen Zweck verwenden, steht hinter dem FiSH-Konzept eine symmetrische Lösung. Der Grund ist einfach wie plausibel: asymmetrische Verschlüsselung ist spezifisch für einen Empfänger bestimmt. Es ist also nicht möglich einen Text zu verschlüsseln, der von mehreren Teilnehmern gleichzeitig gelesen werden kann. Gerade dies ist aber in Channels mit mehreren, womöglich Hunderten, Benutzern aber unumgänglich.

Vor jeder Benutzung von FiSH steht in Channels also die (einmalige) Einigung auf ein gemeinsames, geheimes Passwort um die Kommunikation dort zu verschlüsseln. Dies muss im Vorfeld über einen sicheren Kanal stattfinden, damit die Verbindung nicht von vornherein kontaminiert ist. Symmetrische Verschlüsselung kann nämlich jederzeit nachträglich entschlüsselt werden, sobald das Kennwort dafür bekannt ist.
In Privatfenstern mit zwei Teilnehmern, den Queries, entfällt dieser lästige Zwang, da sich FiSH hier automatisch mit dem anderen Teilnehmer auf einen Schlüssel einigen kann, der über den DH-Schlüsselaustausch sicher erfolgen kann.

Plugins im verwendeten IRC-Klienten sorgen von da an dafür, dass die Kommunikation transparent verschlüsselt erfolgen kann. Gegenwärtig wird mIRC, irssi und xchat (einschließlich xchat Aqua und xchat für Windows) unterstützt. Das mIRC Plugin für Windows bringt ein grafisches Menü mit, die irssi und xchat Variante ein gutes, züchtiges Kommandozeileninterface, das über IRC-Kommandos (”/befehl”) gesteuert werden kann.

Korrekt geladen erscheint im xchat-Statusfenster die Meldung

[15:22] FiSH: Using default password to decrypt blow.ini... Try /setinipw to set a custom password.
[15:22] FiSH v0.98 - encryption plugin for XChat loaded! URL: http://fish.sekure.us

Danach ist das Plugin registriert und konfiguriert. Die Konfiguration kann auch händisch erfolgen, dies betrifft unter xchat vor allem kosmetische Dinge, wie die Kennzeichnung verschlüsselter Kommunikation und die Kompatibilität zu aktivierten Hervorhebungsmethoden (Nich-Highlighting und so weiter). Die Konfiguration erfolgt über die zugehörige Konfigurationsdatei “blow.ini”, die im selben Verzeichnis wie das Plugin liegt.

Eine gute Basis für xchat-Nutzer ist folgende blow.ini:

[FiSH]
process_incoming=1
process_outgoing=1
no_formatting=1
plain_prefix="+p "
nicktracker=1

[incoming_format]
crypted_privmsg="15<%s15>       %s"
crypted_chanmsg="15<%s15>       %s"

[outgoing_format]
crypted_privmsg="15<%s15>       %s"
crypted_chanmsg="15<%s15>       %s"

[#channel]
key=passwort

[nickname]
key=passwort

Dies aktiviert Verschlüsselung und Entschlüsselung automatisch für ein- und ausgehende Nachrichten wo ein Schlüssel bekannt ist und setzt eine graue Umrandung um den Nick für verschlüsselte ausgehende Kommunikation. Der Abschnitt “[#channel]” definiert einen Schlüssel für den Channel “#channel”, “[nickname]” tut dies äquivalent für ein spezifisches Dialogfenster mit einer Person diesen Namens. Letzteres ergänzt FiSH auch nach Bedarf automatisch, wenn man einen DH-Schlüsselaustausch initialisiert.

Diesen Schlüsselaustausch führt man in einem Query-Fenster durch den Befehl “/keyx” durch. Danach erscheint:

[16:34] FiSH: Received DH1080 public key from Nickname, sending mine...
[16:34] FiSH: Key for Nickname successfully set!

Von da an kann man verschlüsselt kommunizieren. Je nachdem ob man ausgehende Kommunikation automatisch verschlüsselt, einfach durch los tippen oder wenn nicht durch “/msg+ Nickname verschlüsselter Text“. Natürlich ist es auch möglich einen Schlüssel selbst zu setzen, wenn man sich nicht auf einen automatischen Schlüsseltausch einlassen möchte. Dies erfolgt dann über “/setkey Nickname schluessel“. Zu beachten ist, dass dies dann aber beide Teilnehmer selbständig mit dem selbsen Schlüssel durchführen müssen, damit wechselseitige Kommunikation möglich ist.

Möchte man die gesamte Channelkommunikation verschlüsseln, setzt man ebenfalls mit “/setkey #channel schluessel” einen Schlüssel, praktischerweise auf jenen, auf den man sich zuvor geeinigt hat. Auch hier müssen den Schritt alle Teilnehmer selbst wiederholen, damit verschlüsselte Channelkommunikation lesbar ist. Auch hier gilt wieder das selbe wie für private Fenster: wird ein Schlüssel gesetzt und ausgehende Kommunikation in der blow.ini automatisch verschlüsselt (”process_outgoing=1“) muss man lediglich tippen, das Plugin erledigt den Rest.
Ist dies nicht der Fall, kann auch hier mit “/msg+ #channel verschlüsselter Text” eine verschlüsselte Nachricht abgesetzt werden. Umgekehrt gibt es ebenso eine Möglichkeit. Betritt zum Beispiel ein neuer Teilnehmer einen Channel, der nichts von der Verschlüsselung weiß, wird dieser ziemlich verwirrt staunen, wenn er lediglich kryptische Zeichen auf dem Bildschirm sieht. Möchte man diesen armen Menschen darüber informieren, dass er FiSH-Plugin nebst Schlüssel benötigt, muss man die Kommunikation ausnahmsweise nicht verschlüsseln. Ist dies standardmäßig aktiviert hilft hier das “+p” Prefix vor Nachrichten. Mit “+p Unverschlüsselter Text” im Channelfenster wird die Nachricht im Klartext gesendet und ist für jeden lesbar.

Es gibt also zwei Möglichkeiten, Nachrichten zu verschlüsseln: explizit und implizit. Explizit markiert Nachrichten die ausdrücklich verschlüsselt werden sollen mit dem Befehl “/msg+” während das standardmäßige “/msg” nach wie vor unverschlüsselt bleibt. Implizite Verschlüsselung verschlüsselt hingegen transparent indem es sich in den “/msg” Befehl einklinkt.

Das selbe Prinzip gilt ebenso für die Befehle “/notice” und “/topic“, wofür es jeweils explizit verschlüsselte Pendants gibt: “/notice+” bzw. “/topic+“.

Alle verfügbare Befehle listet übersichtlich die zugehörige Dokumentation von FiSH.

… für Windows

Unter Windows ist die Installation zwar komplizierter, weil für Fish ein gepatchtes mIRC benötigt wird, dafür ist die Anwendung aber komfortabler. Um meinen guten Willen zu zeigen, scheute ich keine Kosten und Mühen und bootete gar mein unbenutztes, schrecklich veraltetes und kaum benutztes Windows (dort läuft noch Firefox 0.8 oder so) um dies zu demonstrieren.

Zur Installation installiert man die aktuelle Version von mIRC (6.31) am gewünschten Ort und lädt und entpackt den FiSH-Patcher im Installationsverzeichnis von mIRC. Nach einem Klick auf “Patch” kann mIRC regulär gestartet werden. Es bleibt noch, das ebenfalls in das Installationsverzeichnis entpackte mIRC-Script “FiSH.mrc” zu laden. Dies geschieht über “//load -rs1 $shortfn($nofile($mircexe) $+ FiSH.mrc)“. Danach kann es mit der verschlüsselten Kommunikation los gehen. Auch hier gibt es eine blow.ini, die jedoch anders als bei xchat und irssi auch mit einer grafischen Oberfläche konfiguriert werden kann, die einfach über Rechtsklick im Channelfenster zugänglich ist. IRC-Befehle gibt es hier nicht, die Konfiguration erfolgt ausschließlich über das zugehörige Menü.

Schön ist dabei, dass es auch zwischen den verschiedenen Implementierungen keinerlei Probleme, auch mit Zeichensätzen gibt. Einwandfrei klappt also die verschlüsselte Kommunikation zwischen Windows mit mIRC und Linux mit xchat.

Überhaupt funktioniert FiSH erstaunlich einfach und problemlos. Es gibt einzig und allein kleinere Probleme, die sich technikbedingt nicht beheben lassen, was zum Beispiel die Integration in IRC-Klienten betrifft. xchat-Benutzer werden zum Beispiel feststellen, dass das Highlight von Nachrichten problembehaftet aber nicht unmöglich ist. Störender ist jedoch, dass gelegentlich Nachrichten nicht komplett übertragen werden können, wenn man besonders lange Zeilen tippt. Problem dabei ist, dass FiSH zur Übertragung reinen Text verwendet, der über Base64 codiert ist.

Anders wäre es nicht möglich über das Textprotokoll IRC Binärdaten, wie sie der symmetrische Algorithmus Blowfish erzeugt, zu übertragen. Diese erzeugen aber viel größere Datenmengen, als dies bei Klartextnachrichten der Fall wäre, so kommt es schon mal vor, dass zu lange Zeilen vom IRC-Server abgeschnitten werden. Besonders bei Channeltopics ist das nervend. In einem Dialog wird so ein abgeschnittener Block aber markiert und der Gesprächspartner kann darüber informiert werden.

Kategorien

Eingeordnet unter: Überwachung und Technik

Verwandte Artikel

• Von (Un-)Sicherheit im WLAN (3)
• Privatsphäre im Internet: ein rares Gut (2)
• Ich weiß, was du heute gemacht hast (3)
• Dinge, die die Welt bewegen (4)
• Beispiel E-Mail: Kryptographie ist gut und züchtig (9)