Ich habe angefangen, mich mit Skype näher auseinander zu setzen, als es nicht so funktionierte, wie ich wollte. Einige meiner Gesprächspartner haben meinen Unmut sicherlich bemerkt und öfters mal geäußert – jaja der John und seine Firewall. Und dabei lagen sie gar nicht einmal so falsch.
Ich habe versucht, einen adäquaten Filter für Wireshark aufzusetzen, doch ehrlich gesagt, habe ich nach kurzer Zeit einen rauchenden Kopf bekommen. Bei dem Chaos, welches Skype verursacht, können einem schonmal die Zeilen vor den Augen verschwimmen: Skype arbeitet ganz anders, als ich es mir vorgestellt habe. Es wird hier keine Verbindung zu einem Node aufgebaut, sondern zu hunderten. Diese Nodes sind eigentlich keine Server, sondern Clients – überall in Dial-In Netzen – welche unter anderem die Präsenz von mir abfragen. Und der Verkehr ist hauptsächlich eingehend, nicht ausgehend wie ich zunächst vermutet hatte. Mal sind sie da, manchmal nicht. Mit eine Ursache für die katastrophale Ressourcenverschwendung dieses Clients – doch dazu später mehr.
Verschlüsselung:
Da ich in die proprietäre Verschlüsselung von Skype mit Wireshark nicht hineinsehen kann, ist mir die Zuordnung mangels Hirnschmalz nicht geglückt. Also muss ich nachlesen. Skype verwendet offiziellen Angaben nach AES256. Richtig, für UDP-Voicedaten. Doch inzwischen ist herausgekommen, dass primär für Chatnachrichten RC4 in TCP eingesetzt wird, auch für das penetrante Gequatsche mit den „Supernodes“, doch dazu später mehr. Das Verschweigen dieses Umstands ist eine offensichtliche Täuschung des Nutzers, m.E. eine grob fahrlässige Falschangabe. Zumal auch die Vermutung inzwischen geäußert wurde, dass der Schlüsselaustausch für Voice über den RC4 verschlüsselten TCP-Kanal stattfindet. Es ist – aufgrund der zunehmenden Anzahl an mobilen Endgeräten und deren geringer Rechenleistung – zwar nachvollziehbar, allerdings ein immenses Sicherheitsrisiko. Auch wenn der Algorithmus RC4 in vielen anderen Protokollen noch eingesetzt wird, @Ruedi sollte Dir ein Begriff sein und wird Dich – sofern ich es nicht schaffe – hoffentlich überzeugen können:
[youtube id=“1dhCDJ_LVuY“ width=“550″ height=“300″]
Da Skype selbst Closed Source ist, kann in Kombination mit RC4 sogar jeder halbgare „Sicherheitsexperte“ von der Verwendung dieses Kommunikationsmittels abraten. Spinnen wir die Theorie mal weiter: Wenn selbst simples Reverse-Engineering von Hackern schon ein Problem darstellt, wie sieht es dann mit der eingekauften Kompetenz von Regierungen aus? Ich kann mir gut vorstellen, dass Vupen und Gamma passende Tools bereitstellen. Da man – wie nach Snowden herausgekommen ist – bei triftigen Grund sogar selbst bei Microsoft nachfragen kann, ist „Lawful Interception“ meist gar nicht mehr notwendig. Ich darf also allerwärmstens von der Nutzung abraten, zumindest wenn man nur ansatzweise brisantes Material oder Firmengeheimnisse transportieren möchte.
Arbeitsweise:
Um zu verstehen, wie Skype netzwerktechnisch tickt, muss man erst einmal hinter die Arbeitsweise von Skype kommen. In klassischen Szenarien gehen wir von einer Heimanwendung von Skype aus. Und so ein Szenario will ich hier mal aufmalen. Der Anwender nutzt einen deutschen, typischen DSL-Hausanschluss mit einer IPV4 Adresse hinter einem handelsüblichen Plasterouter. Der Anwender hat geringe bis mittlere Erfahrung in TCP/IP und will Skype auf einem bis zwei Geräten für die Kommunikation mit der Familie und Freunden benutzen. Üblicherweise tritt folgendes Regelwerk zu:
Fall 1) Skype kann per UPNP bei Gateway erfolgreich anfragen und bekommt neben seinem UDP-Port auch noch TCP443:
Skype kann erfolgreich kommunizieren, der Client ist für eingehende Anrufe empfangsbereit. Ausgehende und eingehende Anrufe funktionieren problemlos. Je nach Internetbandbreite tritt nach 10 Minuten, 30 Minuten oder 90 Minuten Fall 4 ein.
Fall 2) Skype kann per UPNP bei Gateway keine erfolgreiche Anfrage umsetzen:
Skype Client setzt eine Horde von Paketen wild onanierend, ausgehend an. Irgendwann ist ein offener Port dabei und die Kontaktliste lädt. Ein ausgehender Anruf kann mit einer weiteren Horde von Paketen initiiert werden, jedoch dauert der Aufbau dabei teilweise bis zu 30 Sekunden, bis ein passendes Syn-Ack zwischen Client, Supernode oder Server und dem anderen Gesprächsteilnehmer stattfindet.
Der Anwender selbst bemerkt die Probleme (im schlechtesten Fall) und liest bei Skype nach – Link. Kurzerhand versucht er das Problem zu lösen, indem er bei der Firewall eine NAT/Maskeraderegel für einen Port für einen Skype-Client im Netzwerk einrichtet. Nach vermeintlicher Lösung des Problems kann der Anwender Skype erfolgreich wie in Fall 1 benutzen. Je nach Internetbandbreite tritt nach 10 Minuten, 30 Minuten oder 90 Minuten Fall 4 ein.
Fall 3) Mehrere Skype Clients in einem Netzwerk
Ein Skype Client hat wie in 1 oder 2 erfolgreich einen offenen, eingehenden Port. Es gibt einen weiteren oder mehrere Clients im Netzwerk: Client zwei kann umgehend und sofort kommunizieren, auch wenn dieser keinen Port vom Router bekommt. Je nach Internetbandbreite tritt nach 10 Minuten, 30 Minuten oder 90 Minuten Fall 4 ein.
Fall 4) Probleme bei der Internetnutzung
Die Prozessorlast auf dem Gateway steigt in’s unermessliche, auch wenn recht wenig Payload über die Leitung geschickt wird. Nutzt der Anwender im Heimnetz einen oder mehrere Mac-Computer, so verschärft sich das Problem exorbitant. Teilweise stürzt der Router ab.
Insbesondere Fall 4 hat mich zur Weißglut getrieben, da ich nur eine äußerst schwachbrüstige Firewall besitze.
Asoziales Verhalten!
Mein eigentliches Problem war: Die Nachrichten kamen nicht immer in Echtzeit an, sondern teilweise verspätet, teilweise sogar doppelt. Die Frage ist also, wie kommt das? Eine weitere Frage für mich war: Wie kann ich die Probleme mit meiner Firewall lösen und warum kommt es bei einer schwachbrüstigen Firewall nach einer kurzen Zeit zu hoher Prozessorauslastung auf der Firewall. Die Antwort in aller Kürze ist: Das Problem lässt sich nicht lösen.
Sehr deutlich wird das, wenn man mal den Anmeldevorgang eines Clients bei Skype mit Wireshark genauer beobachtet. In den meisten Fällen sieht der Ablauf wie folgt aus: Ein Skype Client meldet sich an. Dazu steht eine per Round-Robin DNS präsentierte Hundertschaft von Servern im Azure Netzwerk bereit. Bereits während der Anmeldephase geht vom Client eine Tonnage von Paketen gegen die Firewall los, welche alle vermeintlich offenen Ports prüft – das geschieht übrigens gleich nochmal bei jedem Anrufversuch. Dieser Mist unterbleibt, wenn der Client zuvor seine UPNP Anfrage für eine offene Tür durchverhandelt hat. Das dürfte in 99% aller Fälle klappen, denn die meisten Haushalte verwenden dumme, von ihrem Internetanbieter vorkonfigurierte Plaste. Das restliche 1% hat Pech. Eigentlich auch die anderen 99%, doch dazu gleich mehr. Kümmern wir uns erst einmal um das eine Prozent: Bereits während der Phase von rückläufig eindreschenden Paketen aus dem Internet können kleinere Firewalls zusammenbrechen. Bei teureren Derivaten ist die CPU so stark, dass sie das gerade soeben noch hinbekommen. Manche Lancom- oder Funkwerk- Kunden dürften davon sogar überhaupt nichts mitbekommen: Es gab eine Zeit, als die kleineren CPU’s bei diesen Herstellern ausgegangen waren und sie gleich die vierfache Leistung verbaut haben. Ist der Anwender so firm, dass er Maskerade oder NAT-Regel konfigurieren kann, so kommt es ein wenig später dennoch zu sehr merkwürdigem Verhalten des Netzwerks. Der Anwender merkt lediglich, dass der „Seitenaufbau“ mal länger dauert. Anbei mal eine Sicht über einen Windows-Client, der gerade eben erst beginnt, Supernode zu werden:
Quelle: Skype Community
Erstaunt war ich, als ich bei später wieder heruntergefahrenem Skype-Client auf der Firewall eine immer noch hohe Prozessorlast am Gateway feststellte. Kurzerhand schaute ich in die Protokoll-Liste der Firewall und bemerkte UDP-Anfragen aus Quellen kreuz und quer über den Erdball verteilt. Ein Fehler in der Software meines Routers meldete die Anfragen, auch wenn diese zu einer Maskerade passten und lediglich nicht – wegen heruntergefahrenem Client – beantwortet wurden. Fraglich ist also, warum wird von hunderten von Clients auf dem Erdball eine Verbindung zu meinem Skype Client aufgebaut? Ja warum nur…
Bereits während der Phase von eindonnernden Paketen aufgrund eines angemeldeten Clients ist es möglich, dass schwachbrüstige Router nicht einmal mehr eine klassische Sip-RTP-Verbindung aufrecht erhalten können, so geschehen bei meinem Derivat. Es kommt fast typisch zu Gesprächsaussetzern. Jetzt könnte man kontern und meinen, eine stärkere CPU im Router wäre die Lösung. jedoch halte ich jenes Verhalten, den Anwender ungefragt als Relay zu benutzen, und ihn nicht darüber aufzuklären, für ausgesprochen asozial. Wenn ich typisches Peer2Peer – z.B. Bittorrent machen möchte, dann kann ich die Konseqenzen abschätzen und werde transparent darüber aufgeklärt. Abgesehen davon verhält sich jedes Bittorrent deutlich diskreter und nur halb so daneben: Die Verbindungsanzahl ist begrenzt, und zwar so, dass es die Plaste von der Telekom aushält. Bei einem Kommunikationsclient jedoch für sensible Sprachnachrichten, welche lediglich RC4 verschlüsselt werden, halte ich jenes Verhalten für ausgesprochen „daneben“. Noch schlimmer wird es, wenn der Client ein Mac ist. Hier ist die Verbindungszahl nicht auf kleiner 100 Nodes limitiert. Je stärker die Bandbreite und je kürzer der Pingweg ist, und je öfter und länger der Client online ist, desto schneller kommt man in den Genuß, ein „Supernode“ zu sein. Bei schwachbrüstigen Computern in gut angebundenen Netzen wird dies auch durch die hohe CPU-Auslastung sichtbar:
Sollte sich in einem Netzwerk mindestens ein Computer mit direkt ansprechbarem Port befinden, kann er auch von anderen Clients als Relay im gleichen Netz mißbraucht werden. UDP verhält sich übrigens anders als TCP, es wird in den Kanal sozusagen „hineingebrüllt“ und keine Prüfsumme verhandelt. Die Anwendung kommt halt an, oder nicht. UDP wird typischerweise immer dann verwendet, wenn es um Realtime-Daten geht, z.B. Voice over IP oder Daddeln. Warum Skype UDP ebenfalls für Präsenz und Textnachrichten verwendet, wenn ein weiterer TCP-Kanal bereit steht, ist mir schleierhaft. Es wird zwar das Gerücht gestreut, die Relay-Nodes würden lediglich als Präsenz- und Directoryserver missbraucht, doch ich halte dagegen.
Das Offlinenachrichtenproblem
Schaut man sich einen gerade erst angemeldeten Client mit Wireshark an, so kommen die eingehenden Pakete zu passenden Chatnachrichten, welche man in Abwesenheit nicht direkt zugestellt bekommen hat, eben nicht aus dem Azure Netzwerk sondern teilweise mitten aus Frankreich, England oder sogar China. Dabei passieren die merkwürdigsten Fehler, Nachrichten werden doppelt bis dreifach dargestellt:
Jetzt stellt sich mir wirklich die Frage, was meine Chatnachrichten über ein proprietär RC4-verschlüsseltes Kommunikationstool auf hunderten von anderen Rechnern zu suchen haben?
Zwar wird die Voice- &Videoübertragung immer direkt zwischen zwei Clients durchgeführt, jedoch sind die Metadaten für alle Supernodes sichtbar, bei denen beide Gesprächsteilnehmer in Sachen Präsenz gemeldet sind. Und – sorry – auch das halte ich für äußerst daneben. Ich kann nicht wissen, wer mein aktueller Präsenzserver ist und ob ich dem vertrauen kann.
Immerhin, deutschen Universitäts-Admins scheinen ihre Kommilitonen mächtig auf den Zünder zu gehen. Das ist nachvollziehbar, denn die Unis haben – anders als die Privathaushalte – die beste Internetanbindung, die man sich wünschen kann. Deren Infrastruktur und Gateways sind ein schützenswertes Gut. Hierbei scheint der direkte Draht nach Frankfurt und Amsterdam der springende Punkt zu sein, denn alle Universitäten sind über allerhöchstens 1-2 Hops mit AMSIX oder DECIX verbunden. Deren Admins sind so angefressen, dass sie die Clients gleich reihenweise aus dem Campuswifi schmeißen. Mehr oder weniger höfliche Anweisungen gibt es an jeder Universität zu lesen: Link. Um so unverschämter finde ich es, dass insbesondere MAC-Clients überhaupt keine Chance mehr haben, die Supernode-Funktion zu verhindern. Abgesehen davon verursachen die Skypenodes in großen Netzwerken hohe Kosten, denn nicht jeder kann sich mit Gateway-Rechenleistung bewaffnen, bis an die Zähne. Insbesondere der Mittelstand kann hiervon ein Lied singen, zunehmend dürften auch die Carrier damit zu kämpfen haben. Ich kann jeden Companyadmin verstehen, der nicht nur aus Sicherheitsgründen im Anwendungsfilter Skype den Hahn abdreht. Er muss es sogar, um z.B. VOIP weiterhin am Leben zu halten.
Natürlich ist es nachvollziehbar, dass viele meiner Freunde dieses Tool nutzen. Es gibt zu wenig gute Alternativen. Auch wenn Google es mit Jabber vorgemacht hat – das Ding abzusägen zugunsten von Hangout – halte ich für absolut daneben. Es ist zwar schwierig, doch manchmal wünsche ich mir, manche meiner Freunde würden öfters zum Telefonhörer greifen…