Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell

„Ist Remote Desktop sicher" hat unterschiedliche Antworten, je nachdem, welchen Remote-Desktop Sie meinen. Native Windows RDP, das dem öffentlichen Internet ausgesetzt ist, ist eine der am häufigsten missbrauchten Angriffsflächen in der Unternehmens-IT und erscheint jedes Jahr im Verizon DBIR im Abschnitt zu Ransomware. Ein moderner, relay-basierter Client wie Tenvo, AnyDesk oder TeamViewer, der niemals einen lauschen­den Port ins Internet öffnet, hat eine grundsätzlich andere Sicherheitslage. Dieser Artikel erläutert das Bedrohungsmodell ehrlich: was tatsächlich geschützt ist, was nicht, und was Sie überprüfen sollten, bevor Sie eine Remote-Desktop-Lösung installieren.

Kurzfassung: Transportverschlüsselung (AES-256-GCM) und Schlüsselaustausch (X25519 + ED25519) sind heute Mindestanforderungen; die meisten seriösen Tools bieten sie. Interessant sind die Unterschiede darin, was der Relay sehen kann, wie unbeaufsichtigter Zugriff gehandhabt wird, ob 2FA erzwungen wird und ob der Quellcode geprüft werden kann. Springen Sie zur 5-Punkte-Checkliste am Ende, wenn Sie nur die Maßnahmen suchen.

Das Bedrohungsmodell: Wogegen verteidigen Sie sich tatsächlich?

Drei Klassen von Angreifern sind für Remote-Desktop relevant:

• Netzwerkangreifer (passiv oder aktiver MITM). Jemand im selben Wi‑Fi, ein Betreiber eines bösartigen VPN-Exit-Node, ein staatlicher Akteur, der großflächige TLS-Interception betreibt. Ziel ist es, den Verkehr zwischen Client und Host zu lesen oder zu manipulieren.
• Anmeldeangreifer. Jemand, der versucht, sich per Passwort beim unbeaufsichtigten Zugriff anzumelden. Brute-Force, Credential-Stuffing, Abgleich mit geleakten Datenbanken.
• Vendor/Relay-Angreifer. Das Remote-Desktop-Unternehmen selbst oder ein Kompromittierter davon. Sie sitzen definitionsgemäß in der Mitte — was können sie tatsächlich sehen?

Eine vierte Klasse, die Kompromittierung des Endpunkts (Malware auf einem der Rechner), schlägt jede Remote-Desktop-Lösung. Ist Ihr lokaler PC kompromittiert, hilft keine Verschlüsselung. Das behandeln wir hier nicht weiter, weil es außerhalb des Protokollumfangs liegt.

Transportverschlüsselung: AES-256-GCM

Tenvo verschlüsselt die Verbindung mit TLS und einem pro Gerät ausgestellten Zertifikat. Der Algorithmus, der in diesem Zusammenhang am häufigsten genannt wird, ist AES-256-GCM, ein authentifizierter Verschlüsselungsmodus, der sowohl Vertraulichkeit (kein Mitlesen) als auch Integrität (keine Manipulation) schützt. GCM ist derselbe Chiffre‑Modus, den TLS 1.3 verwendet, derselbe, den Ihre Bank nutzt, und derselbe, den das Signal-Protokoll für die symmetrische Schicht nutzt. Bis Mai 2026 gibt es keine bekannten praktischen Angriffe gegen AES-256-GCM.

Der Sitzungsschlüssel ist 256 Bit lang, wird pro Sitzung abgeleitet und niemals wiederverwendet. Selbst wenn ein Schlüssel nachträglich wiederhergestellt würde, wäre nur diese einzelne Sitzung betroffen; frühere und spätere Sitzungen sind unabhängig.

Schlüsselaustausch: X25519 + ED25519

Wie einigen sich die beiden Clients auf einen Sitzungsschlüssel, ohne dass das Relay ihn erfährt? X25519, ein elliptischer Kurven-Diffie‑Hellman über Curve25519. Jede Seite erzeugt ein temporäres Schlüsselpaar, tauscht öffentliche Schlüssel über das Relay aus und berechnet unabhängig mit dem eigenen privaten Schlüssel plus dem öffentlichen Schlüssel der anderen Seite dasselbe gemeinsame Geheimnis. Das Relay sieht nur die öffentlichen Werte, die ohne einen privaten Schlüssel nutzlos sind.

Um einen aktiven Man‑in‑the‑Middle (ein bösartiges oder kompromittiertes Relay, das die öffentlichen Schlüssel während der Übertragung austauscht) zu verhindern, ist die öffentliche Identität des Hosts mit ED25519 signiert. Beim ersten Verbindungsaufbau zeigt Tenvo Ihnen die Schlüssel-Fingerprint des Hosts — das ist das trust-on-first-use (TOFU)-Modell, wie bei SSH. Bei nachfolgenden Verbindungen prüft der Client, ob der Fingerprint übereinstimmt; wenn ein Relay einen MITM-Versuch unternähme, würde sich der Fingerprint ändern und der Client würde die Verbindung ablehnen.

X25519 + ED25519 ist dieselbe primitive Kombination, die von WireGuard, Signal, age und modernem SSH verwendet wird. Sie ist weitgehend auditiert und gilt als aktueller Best Practice.

Was das Relay tatsächlich sieht

Das ist die Frage, die Remote‑Desktop‑Produkte wirklich unterscheidet. Manche Produkte terminieren TLS am Relay und verschlüsseln zur Client‑Seite neu — das bedeutet, der Anbieter kann technisch gesehen Ihre Sitzung entschlüsseln. Fragen Sie nach, welches Modell für das von Ihnen bewertete Tool gilt, einschließlich diesem: Tenvo ist Ende‑zu‑Ende verschlüsselt bei direkten Peer‑to‑Peer‑Verbindungen und terminiert TLS am Relay, wenn eine direkte Verbindung nicht möglich ist.

Zwei Anmerkungen zur Tabelle. Erstens: "Der Anbieter behauptet, das Relay sieht nur Ciphertext" ist bei proprietären Produkten eine Aussage, die man glauben muss — ohne Quellcodezugang ist sie nicht prüfbar. Zweitens: klassisches VNC über das offene Internet ist die schlechteste Option in dieser Liste: Viele VNC‑Varianten werden standardmäßig ohne Transportverschlüsselung ausgeliefert, und die Authentifizierung erfolgt in einem Challenge‑Response‑Verfahren, das seit Jahren gebrochen ist. Betreiben Sie kein unverschlüsseltes VNC über das Internet.

Authentifizierung: Passwörter vs. 2FA

Beim unbeaufsichtigten Zugriff (wenn Sie auf dem Host ein Passwort setzen, damit Sie später verbinden können, ohne dass jemand das Prompt annimmt) ist das Passwort die gesamte Verteidigung. Zwei Ausfallmodi:

1. Schwaches Passwort: Eine 4‑stellige PIN ist in Sekunden brute‑forcebar. Ein 6‑stelliges alphanumerisches Passwort ist bei Netzwerkzugriff in Stunden brute‑forcebar. Verwenden Sie 12+ Zeichen aus einem Passwortmanager. Tenvo verlangt mindestens 6 Zeichen und warnt vor häufigen Passwörtern; wir empfehlen 16+ für jeden unbeaufsichtigten Host, der aus dem Internet erreichbar ist.
2. Kein zweiter Faktor: Wenn das Passwort geleakt wird, ist die Authentifizierung kompromittiert. Aktivieren Sie 2FA, wenn Ihr Tool es unterstützt; Tenvo unterstützt TOTP für die kostenpflichtigen Tarife. AnyDesk und TeamViewer bieten ähnliche Optionen.

Bei interaktiven Support‑Sitzungen (bei denen jemand Ihnen einen Einmalcode vorliest) ist die Gefahr deutlich geringer, weil die Sitzung zeitlich begrenzt ist und der Code verfällt. Der klassische Angriff ist Social‑Engineering, das Opfer dazu bringt, den Code an Betrüger weiterzugeben — die Microsoft „Tech Support“‑Betrugsmaschen nutzen genau diesen Vektor, und keine Kryptographie kann das alleine verhindern.

Risiko unbeaufsichtigter Zugriffe

Unbeaufsichtigter Zugriff ist die nützlichste und gleichzeitig risikoreichste Funktion. Per Definition hinterlassen Sie ein Credential auf dem Host, das bei Leck jedem Fernzugang ohne Bestätigung erlaubt. Empfohlene Maßnahmen:

• Verwenden Sie ein einzigartiges Passwort pro Host. Recyceln Sie Passwörter nicht über mehrere Maschinen.
• Aktivieren Sie 2FA, wo unterstützt.
• Setzen Sie eine Leerlauf‑Timeout, damit ruhende unbeaufsichtigte Sitzungen getrennt werden. Tenvo setzt standardmäßig 4 Stunden.
• Nutzen Sie die Zugriff‑Whitelist und beschränken Sie eingehende Verbindungen auf bestimmte Geräte‑IDs, die Sie kontrollieren. Tenvo unterstützt dies in den Sicherheitseinstellungen.
• Überwachen Sie das Verbindungsprotokoll regelmäßig. Unerwartete Verbindungen sind ein Warnsignal.

Warum native RDP, das dem Internet ausgesetzt ist, besonders problematisch ist

RDP an sich ist nicht unsicher; Microsoft hat das Protokoll deutlich gehärtet, und neuere Versionen nutzen TLS‑geschützte CredSSP. Das Problem ist die operative Praxis. RDP hört auf einem bekannten Port (3389), wird oft nur mit einem Windows‑Passwort abgesichert und ist Ziel ständiger Brute‑Force‑Scans. Hat ein Angreifer Zugriff, hat er eine eingeloggte interaktive Windows‑Sitzung — der nützlichste Einstiegspunkt für die Verbreitung von Ransomware. Deshalb nennen CISA und das FBI exponiertes RDP explizit als einen der Top‑3‑Initial‑Access‑Vektoren für Ransomware. Tools wie Tenvo, AnyDesk und TeamViewer umgehen dieses Problem, indem sie niemals einen lauschen­den Dienst im öffentlichen Internet öffnen.

Die 5‑Punkte‑Checkliste für jede Remote‑Desktop‑Lösung

Ganz gleich, welches Tool Sie wählen — überprüfen Sie vor dem Vertrauen in sensible Systeme diese fünf Punkte:

1. Ende‑zu‑Ende‑Transportverschlüsselung mit AES‑256 oder ChaCha20‑Poly1305. Alles darunter (keine Verschlüsselung, RC4, plain VNC) disqualifiziert das Produkt. Prüfen Sie die Dokumentation, nicht nur die Marketingseite.
2. Forward‑secrecy beim Schlüsselaustausch (Diffie‑Hellman irgendeiner Form). X25519 ist der moderne Standard. ECDH P‑256 ist akzeptabel. Statischer RSA‑Schlüsselaustausch ist ein Warnsignal.
3. Dokumentiertes Relay‑Modell: Sieht der Anbieter Ciphertext oder Klartext? Lesen Sie das Security‑Whitepaper. Wenn das Unternehmen das nicht beantworten kann, lassen Sie die Finger davon.
4. Zwei‑Faktor‑Authentifizierung für unbeaufsichtigten Zugriff. Bietet Ihr Tool keine 2FA, aktivieren Sie keinen unbeaufsichtigten Zugriff auf aus dem Internet erreichbaren Hosts.
5. Quellcode oder Drittanbieter‑Audit, das Sie nachlesen können. Open Source (wie Tenvo/RustDesk unter AGPL-3.0) ist der stärkste Beleg. Andernfalls ist ein SOC 2 Type II‑Bericht oder ein veröffentlichter Pentest akzeptabel.

Fazit

„Ist Remote Desktop sicher" ist die falsche Frage. Die richtige lautet: welcher Remote Desktop, und wie ist er eingesetzt. Ein modernes, relay‑basiertes Tool mit AES‑256‑GCM‑Transport, X25519‑Schlüsselaustausch, Ende‑zu‑Ende‑Verschlüsselung über das Relay hinaus und 2FA für unbeaufsichtigten Zugriff ist in etwa so sicher wie jedes andere Internetprotokoll, dem Sie täglich vertrauen. RDP auf einem weitergeleiteten Port mit schwachem Passwort ist es nicht. Lesen Sie Tenvo's vollständige Sicherheitsarchitektur für Protokoll‑Details, oder laden Sie den Client herunter und prüfen Sie ihn selbst — der Quellcode liegt auf GitHub.

FAQ

Kann das Tenvo‑Team meine Remote‑Desktop‑Sitzungen lesen?
Das hängt vom Verbindungsweg ab. Bei einer direkten Peer‑to‑Peer‑Verbindung ist diese Ende‑zu‑Ende verschlüsselt und das Tenvo‑Team kann sie nicht lesen. Wenn keine direkte Verbindung möglich ist, wird die Sitzung relayed und TLS am Relay terminiert: Wir zeichnen Sitzungsinhalte nicht auf und speichern sie nicht, aber wir würden nicht behaupten, dass es technisch unmöglich wäre, sie einzusehen. Der Client ist Open Source, sodass Sie das prüfen können, anstatt uns zu vertrauen.

Ist Open Source tatsächlich sicherer als Closed Source?
Quellcodeverfügbarkeit ist notwendig, aber nicht hinreichend. AGPL-3.0 erlaubt unabhängigen Prüfern, zu verifizieren, dass das Protokoll der Dokumentation entspricht; bei Closed‑Source‑Tools müssen Sie dem Anbieter vertrauen. Beide Ansätze können sicher implementiert sein; nur einer ist verifizierbar.

Sollten Sie sich vor dem TOFU‑Fingerprint‑Modell fürchten?
Nur, wenn Sie die Verbindung über ein Netzwerk einrichten, dem Sie nicht trauen. Für besonders paranoide Setups verifizieren Sie den Host‑Fingerabdruck außerhalb des üblichen Kanals (z. B. per Telefonanruf, nicht per Chat) beim ersten Verbindungsaufbau. Danach merkt sich der Client den Fingerabdruck lokal.

Gibt es bekannte CVEs in RustDesk / Tenvo?
Das RustDesk‑Projekt hatte über die Jahre einige veröffentlichte Probleme, meist in den optionalen self‑hosted Serverkomponenten, die jeweils zeitnah gepatcht wurden. Der Desktop‑Client selbst hatte bis Mai 2026 keine hochkritischen Remote‑Code‑Execution‑CVE. Prüfen Sie die GitHub Security Advisories für die aktuelle Liste.

Welche 2FA‑Methoden unterstützt Tenvo?
TOTP über jeden standardmäßigen Authenticator (Authy, 1Password, Google Authenticator) in den Lite‑ und Pro‑Tarifen. Hardware‑Schlüssel (WebAuthn) ist auf der Roadmap.