Sie sitzen in einem Café mit ordentlichem Espresso und fragwürdigem WLAN und brauchen den Desktop zu Hause. Ist die Verbindung sicher? Das hängt allein von der Transportverschlüsselung ab – eine Ende-zu-Ende-verschlüsselte Sitzung ist im zwielichtigsten Netz der Stadt sicher, ein veraltetes unverschlüsseltes Protokoll ist es im schönsten nicht. Hier ist das Bedrohungsmodell in einfachen Worten, die Protokolle geordnet danach, was sie preisgeben, und die Checkliste für das nächste Mal, wenn Sie sich von einem Ort aus verbinden, den Sie nicht kontrollieren.
Was ein öffentliches WLAN tatsächlich sehen kann
In einem Netzwerk, das Sie nicht kontrollieren, können zwei Parteien Ihren Datenverkehr beobachten. Die erste ist der Betreiber – wer auch immer den Access Point und den Router dahinter betreibt, was im öffentlichen WLAN den Veranstaltungsort, dessen Netzwerkdienstleister oder jemanden meint, der unbemerkt einen Access Point mit dem Namen des Ortes aufgestellt hat. Die zweite sind andere Geräte in der Nähe: In Netzwerken ohne Client-Isolation kann ein Laptop zwei Tische weiter den Datenverkehr mitschneiden, der um ihn herum läuft. „Beobachten“ heißt, die Pakete aufzuzeichnen, die Sie senden und empfangen. Die ganze Frage ist, was diese Pakete enthalten.
- Ist das Protokoll unverschlüsselt, enthalten die Pakete Inhalt. Bei Remote Desktop ist das so schlimm, wie es klingt: Bildschirmbilder, jeder Tastendruck, den Sie senden – auch Passwörter, die Sie am entfernten Rechner eingeben – und in den schlimmsten Altfällen Zugangsdaten, die beim Verbindungsaufbau ausgetauscht werden.
- Ist das Protokoll ordentlich verschlüsselt, enthalten die Pakete Chiffretext. Das Beobachten schrumpft auf Metadaten: mit welchen Endpunkten Sie Daten ausgetauscht haben, wann und wie viel. Genug, um zu schließen, dass Sie eine Remote-Desktop-App genutzt haben; nutzlos, um zu rekonstruieren, was in der Sitzung geschah.
Man sollte sich an der heutigen Realität orientieren statt an den Horrorgeschichten von 2010. Der meiste Datenverkehr, den ein Laptop heute erzeugt, ist bereits verschlüsselt – HTTPS hat dem beiläufigen Mitschneiden in einem Café den Schrecken genommen. Die realistischen verbleibenden Bedrohungen sind das Beobachten von Metadaten und Rogue-Access-Points: ein Angreifer, der den Netzwerknamen des Ortes ausstrahlt, um sich in den Pfad zu setzen, in der Hoffnung, alles abzufangen, was schwach verhandelt – alte Protokolle, nachlässige Zertifikatsabfragen, Geräte, die vertrauten Namen automatisch beitreten. Das ist kein Grund, das Netzwerk zu fürchten. Es ist eine genaue Beschreibung dessen, welche Werkzeuge man mitbringen sollte: solche, die nicht schwach verhandeln.
Die Protokolle, geordnet danach, was sie preisgeben
Produktnamen sind hier weniger wichtig als Konfigurationen – dieselbe Software kann je nach Version und Einstellungen harmlos oder alarmierend sein, daher ist die folgende Rangfolge nach Konfiguration geordnet, das Schlimmste zuerst.
- Einfaches RDP ohne TLS oder NLA (Altlast). Die ursprüngliche Sicherheitsschicht von RDP stammt aus der Zeit vor moderner Transportsicherheit, und ein Client, der bereit ist, sie auszuhandeln, kann von einem Man-in-the-Middle dorthin heruntergezogen werden. Aktuelle Windows-Versionen verwenden standardmäßig TLS mit Network Level Authentication, sodass das vor allem alte Hosts, alte Clients und aus Kompatibilitätsgründen gelockerte Gruppenrichtlinien beschreibt – aber in einem feindlichen Netzwerk sollte eine Sitzung, die sich herabstufen lässt, als lesbar behandelt werden.
- VNC ohne Verschlüsselung. Das klassische VNC-Protokoll sendet den Framebuffer – Ihren tatsächlichen Bildschirm – im Klartext, und seine herkömmliche Challenge-Response-Anmeldung ist nach heutigen Maßstäben schwach, mit Passwörtern, die häufig auf acht Zeichen begrenzt sind. Manche Server und Clients legen TLS darüber oder laufen über SSH; viele schnelle Setups tun das nicht. Unverschlüsseltes VNC in einem gemeinsam genutzten WLAN gibt den Bildschirminhalt jedem preis, der Pakete aufzeichnet.
- RDP mit TLS und NLA. Der moderne Standard, und auf der Leitung hält er stand: Die Sitzung ist vom Client bis zum Host oder Gateway transportverschlüsselt, und NLA verlangt eine Authentifizierung, bevor überhaupt eine Sitzung entsteht. Im öffentlichen WLAN ist die praktische Schwachstelle der Mensch – selbstsignierte Zertifikate machen Warnabfragen zur Routine, und ein Nutzer, der darauf trainiert ist, sie wegzuklicken, ist genau das, worauf ein Rogue-Access-Point hofft. Transportverschlüsselung sagt auch nichts über die Angreifbarkeit aus: Ein ins Internet geöffneter Port 3389 ist ein eigener, gut dokumentierter Fehler, von wo aus Sie sich auch verbinden.
- Moderne Ende-zu-Ende-verschlüsselte Apps. Sitzungen sind von Gerät zu Gerät verschlüsselt, bevor irgendein Netzwerk sie berührt. Das Hotelnetz – und alles dahinter – sieht Verbindungsmetadaten: Chiffretext, der zwischen Endpunkten fließt, mit Zeitpunkt und Datenmenge. Nie Pixel, nie Tastenanschläge, nie Zugangsdaten, weil es keine Protokoll-Zugangsdaten gibt, die man stehlen könnte.
| Konfiguration | Was ein Beobachter im Netzwerk erhält | Urteil für öffentliches WLAN |
|---|---|---|
| Einfaches RDP, ohne TLS/NLA | Sitzungsinhalt, wo ein Downgrade gelingt; Zugangsdaten gefährdet | Nicht verwenden – als lesbar annehmen |
| VNC ohne Verschlüsselung | Bildschirminhalt im Klartext; schwacher Anmelde-Handshake | Nicht verwenden |
| RDP mit TLS + NLA | Chiffretext während der Übertragung; Zertifikatsabfragen sind die Schwachstelle | Akzeptabel durch einen Tunnel; Port 3389 nie freigeben |
| Moderne E2EE-App | Nur Chiffretext und Verbindungsmetadaten | Genau dafür gebaut |
Warum E2EE die Antwort ändert
Transportverschlüsselung schützt einen Streckenabschnitt; Ende-zu-Ende-Verschlüsselung schützt das Gespräch. Der Unterschied klingt akademisch, bis man auflistet, wer zwischen einem Café und Ihrem Heim-Desktop sitzt: der Access Point des Lokals, dessen Provider, Ihr Provider, möglicherweise der Relay-Server eines Anbieters. Bei Ende-zu-Ende-Verschlüsselung werden die Schlüssel direkt zwischen Ihren beiden Geräten vereinbart, und die Bilder werden verschlüsselt, bevor sie das Gerät überhaupt verlassen. Jede Partei auf dieser Liste – auch die eigene Infrastruktur des Anbieters – leitet Chiffretext weiter, für den sie keinen Schlüssel hat.
Remio ist genau nach diesem Modell gebaut und dient daher als Beispiel. Vertrauen entsteht, wenn Sie zwei Geräte mit einem sechsstelligen Code koppeln, der vom Bildschirm des Hosts abgelesen wird – es gibt kein Konto, also kein Passwort, das im Café gephisht werden könnte, und nirgends eine Zugangsdaten-Datenbank, die geknackt werden könnte. Sitzungsschlüssel werden für jede Verbindung direkt zwischen den gekoppelten Geräten ausgehandelt, und jedes Bild, jeder Tastenanschlag, jede Synchronisierung der Zwischenablage und jede Dateiübertragung ist Ende zu Ende verschlüsselt. Erzwingt ein strenges Netzwerk den Weg über ein verschlüsseltes Relay, leitet das Relay verschlüsselte Bilder weiter, die es nicht lesen kann – das Sicherheitsmodell ist identisch, ob der Weg direkt oder über Relay führt. Das vollständige Konzept steht auf der Sicherheitsseite.
Das Ziel ist nicht, ein vertrauenswürdiges WLAN zu finden. Es ist, die Vertrauenswürdigkeit des WLANs bedeutungslos zu machen.
Eine ehrliche Grenze: Ende-zu-Ende-Verschlüsselung schützt die Sitzung während der Übertragung, und sonst nichts. Ist der Laptop im Café kompromittiert oder der Host zu Hause, ändert die stärkste Verschlüsselung dazwischen nichts – der Angreifer sitzt in einem Endpunkt und liest mit, was Sie lesen. Endpunkthygiene, die Geschichte von Anbieter-Sicherheitsvorfällen und der Rest des Härtungsbildes sind ein anderer Artikel, und den haben wir geschrieben: den Sicherheitsleitfaden zu Remote Desktop. Dieser hier bleibt beim Netzwerk.
Die Café-Checkliste
Sechs Punkte, in der Reihenfolge, in der sie sich auszahlen.
- Bevorzugen Sie eine Ende-zu-Ende-verschlüsselte Remote-Desktop-App. Sie klärt die Frage zum öffentlichen WLAN konstruktionsbedingt statt durch Disziplin – das Netzwerk trägt Chiffretext, egal ob Sie bei den anderen Punkten dieser Liste etwas richtig gemacht haben.
- Wenn Sie an RDP gebunden sind, geben Sie Port 3389 nie frei. Erreichen Sie ihn stattdessen über ein VPN oder einen anderen verschlüsselten Tunnel statt über eine Portweiterleitung am Router; die Alternativen, auch reine Ausgangsverbindungs-Apps, die gar keine Router-Änderungen brauchen, stehen in unserem Leitfaden zu Remote Desktop ohne Portweiterleitung.
- Lassen Sie die Betriebssystem-Firewall das Netzwerk als öffentlich behandeln. Fragt macOS oder Windows, welche Art von Netzwerk Sie betreten haben, ist das öffentliche Profil die richtige Antwort – es verhindert, dass Dateifreigabe, Erkennung und andere lauschende Dienste für Fremde im selben Netzwerk sichtbar sind.
- Halten Sie den Client aktuell. Ein Remote-Desktop-Client verarbeitet komplexe Daten aus einem Netzwerk, dem Sie nicht vertrauen wollen. Patches gibt es aus gutem Grund; auf einem Gerät, das reist, ist automatische Aktualisierung die richtige Einstellung.
- Prüfen Sie, dass Sie im echten Netzwerk des Lokals sind. Fragen Sie nach dem genauen Netzwerknamen und ignorieren Sie Doppelgänger – ein Access Point kann jeden Namen ausstrahlen, den sein Besitzer eintippt. Wenn Sie Ihren Laptop beim Gehen das Netzwerk vergessen lassen, verhindert das auch, dass er nächsten Monat einer Nachahmung automatisch beitritt.
- Behandeln Sie die Sitzung selbst als das Sensible. Sie bedienen Ihren Heim- oder Büro-Rechner aus einem öffentlichen Raum: Achten Sie darauf, wer Ihren Bildschirm sehen kann, und sperren Sie den entfernten Host, wenn Sie die Verbindung trennen, damit Sie hinter sich keinen offenen Desktop hinterlassen.
Und ein VPN obendrauf?
Ein VPN verschlüsselt alles zwischen Ihrem Gerät und dem VPN-Server, und in nicht vertrauenswürdigem WLAN ist das tatsächlich nützlich – es schirmt DNS-Abfragen, das Hintergrundrauschen von Apps und verirrten unverschlüsselten Datenverkehr vom lokalen Netzwerk ab. Wenn Sie am Flughafen ohnehin eines nutzen würden, spricht nichts an Remote Desktop dagegen.
Für die Remote-Desktop-Sitzung selbst ist die Logik aber enger, und sie wirkt in beide Richtungen. Ein VPN ist für eine Ende-zu-Ende-verschlüsselte Sitzung nicht nötig: Der Datenverkehr ist bereits Chiffretext, bevor er den Tunnel erreicht, sodass das VPN einen Sprung (und meist etwas Latenz) hinzufügt, ohne Vertraulichkeit zu ergänzen, die der Sitzung fehlt. Und es ist für eine unverschlüsselte Sitzung nicht ausreichend: Ein kommerzielles VPN schützt den Weg bis zum Ausgangsserver des VPN, danach läuft der Datenverkehr genauso ungeschützt zum Host weiter, wie er begonnen hat. Die Ausnahme, die die Regel bestätigt, ist ein Tunnel, der im Zielnetzwerk selbst endet – ein WireGuard-Server auf Ihrem Heimrouter, ein Firmen-VPN ins Büro –, der den gesamten Weg abdeckt und der Standardweg ist, RDP aus der Ferne zu nutzen. Wägen Sie ein VPN gegen eine Remote-Desktop-App als Zugriffsmethode selbst ab, ist das ein anderer Vergleich, und er hat einen eigenen Artikel: Remote Desktop oder VPN.
Hotel, Flughafen, Campus: die Netzwerk-Eigenheiten, die Verbindungen kappen
Sicherheit beiseite, haben öffentliche Netzwerke eine zweite Charaktereigenschaft: Sie brechen Verbindungen auf eine Weise ab, wie es Heimnetzwerke nicht tun. Drei Eigenheiten machen das meiste davon aus.
- Captive Portals. Solange Sie keinen Browser öffnen und die Bedingungen akzeptieren, verschluckt das Netzwerk alles – eine Remote-Desktop-App scheitert dann ohne ersichtlichen Grund. Schließen Sie zuerst das Portal ab; und stirbt eine Sitzung, die den ganzen Nachmittag lief, in der dritten Stunde, vermuten Sie ein Portal, das sich nach Zeitplan neu authentifiziert.
- Client-Isolation. Hotels und Campus-Netze blockieren häufig den Datenverkehr von Gerät zu Gerät innerhalb des Netzwerks, sodass zwei Ihrer eigenen Geräte im selben Raum im LAN füreinander unsichtbar sein können. Reine Ausgangsverbindungs-P2P-Apps verbinden sich trotzdem – beide Geräte wählen sich nach außen ein und treffen sich über das Internet –, aber der Weg kann länger sein als der Raum, in dem Sie sitzen.
- UDP-Blockierung. Strenge Gästenetzwerke erlauben manchmal kaum mehr als TCP auf Web-Ports. Echtzeitprotokolle bevorzugen UDP, und hier unterscheiden sich Apps: Eine mit TCP- und Relay-Fallback verbindet sich weiter, mit etwas Latenz-Einbuße, während eine reine UDP-Konfiguration stockt. Die Mechanik – Adresserkennung, Hole Punching und was wann als Fallback greift – steht in unserer Erklärung zu NAT-Traversal, und die genauen Ports und Protokolle, die eine Sitzung nutzt, stehen in der Dokumentation zu Firewall und NAT.
FAQ
Ist es sicher, Remote Desktop im Hotel-WLAN zu nutzen?
Ja, wenn die Sitzung Ende-zu-Ende-verschlüsselt ist. Mit einer modernen E2EE-Remote-Desktop-App trägt das Hotelnetz nur Chiffretext, sodass weder der Betreiber noch andere Gäste Ihren Bildschirm, Ihre Tastenanschläge oder Dateien rekonstruieren können. Altlasten sind der riskante Fall: RDP ohne TLS und NLA oder VNC ohne Verschlüsselung können Sitzungsinhalt und Zugangsdaten dem Netzwerk preisgeben und sollten im Hotel-WLAN nicht ohne verschlüsselten Tunnel genutzt werden.
Kann jemand im selben WLAN meinen entfernten Bildschirm sehen?
Nicht, wenn die Sitzung Ende-zu-Ende-verschlüsselt ist. Jemand im selben Netzwerk kann Ihre Pakete mitschneiden, aber bei E2EE sind diese Pakete Chiffretext, und die Schlüssel existieren nur auf Ihren beiden Geräten, sodass sich der Bildschirminhalt aus dem Mitschnitt nicht rekonstruieren lässt. Was ein Beobachter im selben Netzwerk weiterhin sehen kann, sind Metadaten – dass eine Verbindung besteht, wann sie aktiv ist und in etwa, wie viele Daten sie bewegt.
Brauche ich ein VPN, um Remio im öffentlichen WLAN zu nutzen?
Nein. Remio-Sitzungen sind bereits Ende-zu-Ende-verschlüsselt – die Schlüssel werden für jede Sitzung direkt zwischen Ihren Geräten ausgehandelt –, sodass die Sitzung nicht davon abhängt, dass das Netzwerk vertrauenswürdig ist. Ein VPN schafft weiterhin Privatsphäre für den Rest Ihres Datenverkehrs, etwa DNS-Abfragen und andere Apps, und Remio durch eines laufen zu lassen ist in Ordnung. Es ist eine Entscheidung über Ihren übrigen Datenverkehr, keine Voraussetzung für die Sitzung.
Ist RDP im öffentlichen WLAN sicher?
Mit TLS und Network Level Authentication – dem modernen Windows-Standard – ist die Sitzung transportverschlüsselt, sodass ein Lauscher im Café-Netz Chiffretext sieht. Die bleibende Regel betrifft die Angreifbarkeit, nicht den Ort: Öffnen Sie Port 3389 nie direkt zum Internet; erreichen Sie RDP stattdessen über ein VPN oder einen anderen verschlüsselten Tunnel. Alte Konfigurationen, die sich auf die alte RDP-Sicherheit ohne TLS herunterhandeln lassen, sollten in jedem nicht vertrauenswürdigen Netzwerk als unsicher gelten.
Was erfährt der WLAN-Betreiber trotzdem?
Verbindungsmetadaten. Auch bei einer vollständig Ende-zu-Ende-verschlüsselten Sitzung kann der Netzwerkbetreiber Zeitpunkt, Datenvolumen und die Endpunkte beobachten, mit denen Sie Pakete austauschen – genug, um zu schließen, dass eine Remote-Desktop-Sitzung stattgefunden hat und wie lange sie dauerte. Was er nicht rekonstruieren kann, ist der Inhalt: keine Bildschirmbilder, keine Tastenanschläge, keine Dateien, keine Zwischenablage.
Der rote Faden durch das Ganze: Nicht das Lokal entscheidet, ob Ihre Sitzung sicher ist – die Verschlüsselung tut es. Wenn Sie die Variante wollen, die gar keine Checkliste braucht, installieren Sie Remio auf beiden Rechnern, koppeln Sie sie mit dem sechsstelligen Code und verbinden Sie sich aus jedem Netzwerk, das Ihnen der Tag beschert; die Sitzung ist so oder so Ende-zu-Ende-verschlüsselt. Die Seite So funktioniert’s zeigt, was unter der Haube passiert.
