Warum die Frage schwer zu beantworten ist
„Ist die Verbindung verschlüsselt?" ist die häufigste Frage an einen Fernwartungsanbieter — und die am wenigsten aussagekräftige. Jeder wird sie mit Ja beantworten. Interessanter ist, welche Daten überhaupt entstehen, welchen Weg sie nehmen und wer sie unterwegs sehen kann.
Eine Fernwartungssitzung erzeugt drei getrennte Datenströme, die oft in einen Topf geworfen werden. Sie zu trennen ist der halbe Weg zur Antwort.
Strom 1: Die Signalisierung
Bevor zwei Rechner miteinander reden können, müssen sie sich finden. Beide sitzen in aller Regel hinter einem NAT-Router ohne öffentliche Adresse. Sie melden sich deshalb bei einem Vermittlungsserver, tauschen Kandidaten für mögliche Adressen aus und stimmen ab, wann sie gleichzeitig nach aussen klopfen.
Das ist die Signalisierung. Sie umfasst:
- Anmeldung und Sitzungskennung
- IP-Adress-Kandidaten beider Seiten, einschliesslich der öffentlichen
- Zeitpunkte für das koordinierte Durchstossen der NAT-Router
- Verbindungsstatus (verbunden, getrennt, Wiederaufnahme)
Der Vermittlungsserver sieht diese Daten zwangsläufig — er ist der Grund, weshalb es ihn gibt. Er sieht damit, dass und wann eine Verbindung zwischen zwei Endpunkten bestand, und die IP-Adressen beider Seiten. Das ist Metadatum, kein Inhalt, aber es ist nicht nichts.
Strom 2: Der Medienpfad
Bildschirmbilder, Mausbewegungen, Tastatureingaben, Zwischenablage, Dateiübertragungen. Das ist der Strom, an den die meisten denken, und der einzige, der Inhalte trägt.
Hier trennt sich die Architektur in zwei Lager, und der Unterschied ist grösser als er klingt:
Weiterleitung über den Anbieter. Der Host schickt die Bilder an einen Server des Anbieters, der sie an den Client weiterreicht. Technisch einfach, funktioniert auch hinter den härtesten Firewalls. Der Preis: die Daten laufen durch fremde Infrastruktur. Ob dort entschlüsselt wird, ist eine Frage der Umsetzung — dass die Bytes physisch durchfliessen, ist keine.
Direkt zwischen den Endpunkten. Beide Seiten öffnen einen eigenen Kanal zueinander; die Bilder nehmen den kürzesten Weg. Der Anbieter hat den Medienstrom nie in der Hand. Der Preis: es ist erheblich mehr Aufwand, und bei manchen Netzkonstellationen wird es richtig schwierig.
Bei WinDesk ist der zweite Weg keine Option, sondern eine Festlegung: Der Vermittlungsserver leitet keine Medienbytes weiter — kein Bildschirminhalt, keine Eingaben, keine Zwischenablage. Es gibt bei uns bewusst keinen TURN-Rückfall, also keinen Weiterleitungspfad, auf den ein Medienstrom im Zweifel ausweichen könnte. Harte NAT-Fälle lösen wir stattdessen über Signalisierung: gleichzeitiges Durchstossen, Vorhersage von Portbereichen, Wiederholungsschleifen.
Das hat eine unbequeme Kehrseite, die zur Ehrlichkeit dazugehört: Wo kein Rückfallpfad existiert, kann eine Verbindung scheitern. Ein Anbieter mit Weiterleitung bekommt in solchen Netzen eher eine Verbindung zustande. Wir haben uns bewusst anders entschieden — aber es ist ein Zielkonflikt, keine reine Überlegenheit.
Strom 3: Was gespeichert bleibt
Der dritte Strom ist der, den man am ehesten übersieht: was nach der Sitzung noch da ist. Bei WinDesk hält der Server je Sitzung im Wesentlichen fest:
- Sitzungskennung, Beginn, Ende, Dauer
- welches Konto verbunden hat und mit welchem Host
- Verbindungsart (begleitet oder unbeaufsichtigt)
- IP-Adressen beider Seiten und ein Geräte-Fingerabdruck
- Abrechnungsstand
Was nicht entsteht: kein Bildschirminhalt, keine Eingaben, keine Zwischenablage, keine Aufzeichnung. Diese Daten laufen nie über unsere Server, also können wir sie auch nicht aufbewahren — das ist die praktische Folge der Architekturentscheidung oben.
Der Schlüsselaustausch
Verschlüsselung ist nur so viel wert wie die Frage, wer die Schlüssel kennt. Ein Anbieter, der den Schlüssel erzeugt oder verwahrt, kann mitlesen, auch wenn die Leitung verschlüsselt ist.
Bei WinDesk handeln Client und Host das Schlüsselmaterial beim Verbindungsaufbau direkt miteinander aus (Diffie-Hellman auf elliptischen Kurven). Der Vermittlungsserver ist an diesem Austausch nicht beteiligt und lernt den Sitzungsschlüssel nicht. Er könnte den Medienstrom also selbst dann nicht lesen, wenn er ihn hätte.
Wie du das bei jedem Anbieter selbst nachmisst
Du musst niemandem glauben — der Datenfluss lässt sich in zehn Minuten sichtbar machen. Drei Messungen, kein Spezialwissen nötig:
1. Wohin fliesst der Verkehr? Starte eine Sitzung zwischen zwei Rechnern im selben Netz und schau mit netstat oder dem Ressourcenmonitor, mit welchen Gegenstellen die Anwendung verbunden ist. Siehst du eine dauerhafte Verbindung zu einem Rechenzentrum mit hohem Durchsatz, läuft der Medienstrom über den Anbieter. Siehst du stattdessen Verkehr direkt zur Gegenstelle, ist er P2P.
2. Wie viel fliesst wohin? Der Ressourcenmonitor zeigt Bytes je Verbindung. Ein Medienstrom liegt bei 0.5 bis 2 Mbit/s. Signalisierung liegt bei wenigen Kilobyte je Minute. Der Unterschied ist nicht subtil.
3. Was bleibt liegen? Fordere beim Anbieter eine Auskunft über die gespeicherten Sitzungsdaten an. Die Antwort sagt dir mehr über die Architektur als jedes Datenblatt — wer Bildschirminhalte aufzeichnen kann, wird es in der Auskunft nennen müssen.
Was das für deine Auswahl heisst
Es gibt keinen für alle richtigen Aufbau. Wer Verbindungen durch beliebige Firewalls braucht, ist mit einem Weiterleitungspfad besser bedient. Wer Inhalte fernhalten will, die niemanden ausserhalb der beiden Endpunkte angehen, will das Gegenteil.
Die Frage, die weiterhilft, ist deshalb nicht „ist es verschlüsselt", sondern:
Welchen Weg nehmen die Bildschirmdaten, wer erzeugt den Schlüssel, und welche Daten bleiben nach der Sitzung bei wem liegen?
Drei Fragen, drei überprüfbare Antworten. Jeder ernsthafte Anbieter kann sie beantworten, und du kannst jede davon selbst nachmessen.