Surfshark Dausos heißt das neue, selbstentwickelte VPN-Protokoll, mit dem Surfshark angetreten ist, die Branche umzubauen. Die offizielle Pressemitteilung verspricht 30 Prozent mehr Speed, einen dedizierten Tunnel pro Nutzer und vollständige Post-Quanten-Sicherheit. In unabhängigen Tests ist davon eine Zahl deutlich übrig geblieben, die nicht 30 ist.

Was Surfshark ankündigt
Dausos, litauisch für „Himmel“, ist das erste komplett selbst entwickelte VPN-Protokoll von Surfshark. Die Kernpunkte der Ankündigung:
- Ein eigener, dedizierter Tunnel für jede Nutzersitzung statt gemeinsamer Netzwerkschnittstelle.
- Hybrider Post-Quanten-Schlüsselaustausch mit ML-KEM und X25519 (X25519MLKEM768).
- Selbstsignierte Root-Zertifikate mit dem ML-DSA-Signaturschema.
- Post-Compromise-Security bei jeder neuen Sitzung.
- Port-Randomisierung pro Verbindung.
- AEGIS-256X2 als authentifizierter Verschlüsselungsalgorithmus.
Auditiert wurde das Ganze durch das Berliner Sicherheitsunternehmen Cure53. Verfügbar ist Dausos seit Mitte April zunächst nur für macOS. Wer das Protokoll in der App sucht, findet es unter den Protokolleinstellungen mit einem Beta-Label markiert, in der Pressemitteilung taucht dieser Zusatz nicht auf.

Die Pressemitteilung ist entsprechend euphorisch. Viel von dem, was drin steht, ist technisch korrekt. Nicht alles davon ist so einzigartig, wie es präsentiert wird.
Der 30-Prozent-Claim: Was unabhängige Tests zeigen

TechRadar hat Dausos am Launch-Tag getestet. Das Ergebnis war zunächst ernüchternd: „I couldn’t even load a speed test“, schrieb der Tester Samuel Woodhams. Die Verbindung lieferte nur unverschlüsselte HTTP-Seiten, HTTPS-Websites blockierten. Der Grund war ein MTU-Problem auf PPPoE-Verbindungen, das Surfshark laut eigener Aussage als Edge-Case übersehen hatte. Betroffen waren unter anderem BT- und EE-Kunden in Großbritannien, zusammen über 30 Millionen Anschlüsse.
Surfshark hat nach der TechRadar-Intervention einen Hotfix ausgeliefert (App-Version 4.27.1). Seitdem funktioniert das Protokoll auf Glasfaserleitungen zuverlässig. Die gemessenen Zahlen nach dem Fix liegen spürbar unter den Marketing-Versprechen. Gegen unverschlüsselte Leitungen verliert Dausos rund 21 Prozent Download-Geschwindigkeit, WireGuard im gleichen Aufbau rund 26 Prozent. Das ergibt einen Vorteil von Dausos gegenüber WireGuard von etwa 5,8 Prozent. Ein anderer Labortest kam auf nahezu identische Werte zwischen beiden Protokollen mit marginalem Vorteil für WireGuard.
5,8 Prozent sind nicht nichts. Aber sie sind auch nicht 30. Die offizielle Sprachregelung „bis zu 30 Prozent“ ist damit das, was Marketing nun mal manchmal ist: das bestmögliche Ergebnis unter Laborbedingungen, hochgerechnet. Für Leser, die VPN-Protokolle realistisch einordnen wollen, ist 5,8 Prozent die ehrlichere Zahl.
Eigener Kurztest: macOS, LAN, deutscher Server
Um die Größenordnung auf einer heimischen Vodafone-Gigabit-Leitung abzuschätzen, habe ich einen Drei-Fach-Test über Speedtest.net gemacht. macOS am LAN-Kabel, drei Durchläufe direkt hintereinander. Als VPN-Server jeweils Frankfurt, von der Surfshark-App automatisch gewählt.
| Download | Upload | Ping | |
|---|---|---|---|
| Ohne VPN | 923,77 Mbps | 35,78 Mbps | 28 ms |
| Dausos | 851,28 Mbps | 46,69 Mbps | 14 ms |
| WireGuard | 786,17 Mbps | 47,52 Mbps | 28 ms |
| Eigene Messung, 20.04.2026, Vodafone-Kabel 1 Gbit/s, macOS Sonoma, Surfshark-Server Frankfurt. | |||
Im Download liegt Dausos mit 851 Mbps rund 8,3 Prozent über WireGuard (786 Mbps). Das ist mehr als die 5,8 Prozent aus TechRadars Test, aber weit weg von den 30 Prozent aus dem Marketing-Video. Beim Upload dreht sich das Verhältnis leicht um: Hier liegt WireGuard knapp vorne. Beide VPN-Protokolle liefern im Upload sogar höhere Werte als die Baseline ohne VPN. Das ist ein Routing-Artefakt der Vodafone-Leitung, kein Protokoll-Verdienst.
Der Ping-Unterschied zwischen Dausos (14 ms) und WireGuard (28 ms) ist mit Vorsicht zu lesen. Speedtest hat bei beiden Durchläufen unterschiedliche Testserver in Frankfurt zugewiesen, und Pings messen die Latenz zum jeweiligen Testserver, nicht den Protokoll-Overhead. Wer belastbare Latenzwerte will, braucht einen festen Endpunkt und wiederholte Messungen.



Einzeltest auf einer Leitung zu einem Zeitpunkt. Keine statistisch belastbare Messung, sondern eine Orientierung für den Alltagsfall auf deutscher Gigabit-Infrastruktur. In schwacher Anbindung oder über lange Tunnel-Distanzen können sich die Verhältnisse verschieben. Das Muster bleibt aber erkennbar: Dausos ist messbar schneller als WireGuard, aber weit unter der Marketing-Zahl.
Der dedizierte Tunnel: echt, aber nicht einzigartig

Die Architektur-Entscheidung, jedem Nutzer eine eigene Netzwerkschnittstelle zuzuweisen statt eines geteilten TUN-Interfaces, ist technisch solide. Cross-Traffic-Exposure, das theoretische Risiko, dass Datenpakete verschiedener Nutzer sich auf derselben Schnittstelle stören, wird damit ausgeschlossen. Das ist ein sauberer Ingenieur-Ansatz.
„Das erste Protokoll“, das so etwas macht, ist Dausos trotzdem nicht. ExpressVPNs Lightway Turbo baut seit seiner Einführung mehrere parallele Tunnel pro Sitzung auf, um Bandbreite und Sicherheit zu erhöhen. Die Umsetzung ist nicht identisch mit Dausos, aber das Konzept „mehrere Tunnel statt einer“ ist im Premium-VPN-Segment nicht neu. Surfshark hat einen Patentantrag eingereicht. Ob der Antrag durchgeht, entscheidet, wie neu die Umsetzung tatsächlich ist.
Post-Quanten-Kryptografie: richtig gewählt, nicht neu
Dausos nutzt X25519MLKEM768, den hybriden Schlüsselaustausch aus bewährtem X25519 und dem NIST-standardisierten ML-KEM. Das ist die Kombination, die aktuell überall einzieht, wo Post-Quanten-Sicherheit ernst gemeint ist. Chrome und Edge nutzen sie seit Version 131 als Default in TLS, Firefox seit Version 132. Im VPN-Feld hat Mullvad bereits im Januar 2025 Post-Quanten-Tunnel standardmäßig aktiviert, damals mit Classic McEliece und Kyber (heute ML-KEM). Das ist 15 Monate vor Surfshark.
Das bedeutet nicht, dass Surfsharks Entscheidung falsch ist. Im Gegenteil, sie ist genau richtig. Aber der Claim, Dausos sei einer der ersten Schritte der VPN-Branche ins Post-Quanten-Zeitalter, ist sprachlich schief. Es ist eher der Anschluss an einen inzwischen etablierten Standard. Wer vergleichen will, sollte Mullvad mit auf die Liste nehmen.
Was bei Surfshark tatsächlich früh dran ist: Die Verwendung des ML-DSA-Signaturschemas für selbstsignierte Root-Zertifikate. ML-DSA ist die Post-Quanten-Variante für digitale Signaturen. Die meisten VPN-Anbieter nutzen dafür noch klassische RSA- oder ECDSA-Zertifikate. Hier geht Surfshark einen Schritt voraus, und das ist ein sauberer Punkt. Auch Post-Compromise-Security ist im VPN-Feld noch selten. Dass bei jedem Sitzungsschlüssel ein komplett neues Paar generiert wird, das nicht aus Vorgängern abgeleitet wurde, ist eine echte Verbesserung gegenüber klassischem Perfect Forward Secrecy.
Was das Cure53-Audit wert ist
Das Audit fand im Februar und März 2026 statt, also vor dem Launch. Penetrationstest und Source-Code-Audit, Fokus auf Netzwerkarchitektur und Kryptografie. Das Ergebnis: acht Findings, alle mit Schweregrad „medium“ oder niedriger. Keine kritischen oder hohen Funde. Surfshark hat laut Cure53 die meisten Findings umgehend behoben.
Acht Findings sind nicht nichts. Cure53 hat Dinge gefunden, die zu verbessern waren. Die Einordnung als „stabile und widerstandsfähige Plattform“ ist trotzdem fair. Wichtig für Leser: Audits prüfen den Code zu einem bestimmten Zeitpunkt und decken selten alle Praxis-Edge-Cases ab. Der MTU-Bug, der TechRadar zum Launch ausgebremst hat, ist vom Audit nicht gefunden worden. Audits sind ein Qualitätssignal, kein Bug-Freiheits-Zertifikat.
Offen bleibt die Frage nach dem Quellcode. Etablierte Protokolle wie WireGuard oder ExpressVPNs Lightway sind teilweise oder komplett open source, dasselbe gilt für Mullvads Post-Quanten-Stack. Surfshark hat Cure53 Einblick in den Dausos-Code gegeben, veröffentlicht hat Surfshark den Code nach derzeitigem Stand nicht. Damit bleibt die Nachvollziehbarkeit für die breite Öffentlichkeit hinter dem Industriestandard zurück.
Für wen sich Dausos jetzt schon lohnt
Wer ohnehin Surfshark nutzt und auf einem Mac unterwegs ist, bekommt mit Dausos ein modern gebautes Protokoll mit sauberer Krypto-Wahl. Ein paar Prozent mehr Speed gegenüber WireGuard, etwas besser aufgestellte Post-Quanten-Kryptografie als bei den meisten Konkurrenten, Post-Compromise-Security als sinnvolles Upgrade. Für diesen Anwendungsfall ist Dausos eine ernste Empfehlung, sobald der erste Hotfix raus ist.

Zwei Details aus der App selbst geben die ehrlichste Einordnung zum aktuellen Reifegrad. Erstens: Das Beta-Label neben Dausos, das in keiner offiziellen Pressemitteilung auftaucht. Zweitens: Der Automatisch-Modus, Surfsharks eigene Empfehlung für den Durchschnittsnutzer, hat Dausos nicht aktiviert. Als Default läuft weiter WireGuard. Wenn Surfshark dem eigenen Protokoll die Default-Einstellung noch nicht zutraut, ist die Zurückhaltung auch für Leser ein sinnvolles Signal.
Wer noch keinen VPN hat und sich zwischen Anbietern entscheidet, sollte nicht wegen Dausos zu Surfshark wechseln. Mullvad bietet vergleichbare Post-Quanten-Sicherheit seit über einem Jahr und ist komplett open source. ExpressVPN Lightway hat ebenfalls ein belastbares Eigenprotokoll. Die echten Entscheidungskriterien zwischen Anbietern bleiben die gewohnten: Standortpolitik und Preis auf der einen Seite, Audit-Historie und No-Logs-Glaubwürdigkeit auf der anderen.
Auf iOS, Android, Windows und Linux ist Dausos Stand heute nicht verfügbar. Surfshark verspricht den Rollout „in Kürze“, ohne Datum. Bis dahin bleibt Dausos ein macOS-Only-Feature mit einem holprigen Launch und einer Marketingzahl, die in der Praxis nicht hält. Das eigentliche Ergebnis ist ein ordentliches Protokoll, das keine Revolution ist, aber die Richtung zeigt, in die sich ernsthafte Consumer-VPNs 2026 bewegen müssen.
Quellen: Surfshark Blog (Dausos-Ankündigung), TechRadar (Initial-Test mit MTU-Problem), TechRadar (Hotfix-Nachtest mit 5,8 Prozent), Mullvad (Post-Quanten-Default seit Januar 2025), ExpressVPN (Lightway Turbo Multi-Tunnel), IETF Draft ECDHE-MLKEM. Stand April 2026.





