Wie der Datenverkehr verschlüsselt wird
Jeder Tunnel ist zwischen den beiden Geräten Ende-zu-Ende verschlüsselt. Schlüssel entstehen auf dem Gerät und verlassen es nie, und die Verschlüsselungsverfahren sind fest vorgegeben statt ausgehandelt.
SXAccess verschlüsselt den Datenverkehr direkt zwischen den beiden Geräten, die miteinander kommunizieren. Der Tunnel nutzt eine feste, moderne Cipher-Suite: ChaCha20 zur Verschlüsselung, Poly1305 zur Authentifizierung, Curve25519 für den Schlüsselaustausch und BLAKE2s als Hashfunktion. Beim Verbindungsaufbau wird nichts ausgehandelt; es gibt also keine schwächere Variante, auf die ein Angreifer die beiden Enden herunterzwingen könnte.
Keine Komponente dazwischen kann Ihren Datenverkehr lesen. Der Management-Dienst verteilt öffentliche Schlüssel und Zugriffsregeln, der Discovery-Dienst leitet Nachrichten weiter, die mit dem Schlüssel des Gegenübers versiegelt sind, und ein Relay leitet, falls eines nötig ist, Chiffrat weiter, für das es keinen Schlüssel besitzt. Datenverkehr zu einer Ressource hinter einem Routing-Gerät verlässt den Tunnel an diesem Gerät und legt das letzte Stück im dortigen Netz als gewöhnlicher Datenverkehr zurück.
Aufgabenteilung
| Übernimmt der Tunnel | Ergänzen der SXAccess-Agent und die Dienste |
|---|---|
| Einen verschlüsselten Tunnel zwischen zwei bekannten öffentlichen Schlüsseln | Das Wissen, welche Geräte existieren und welche öffentlichen Schlüssel und Endpunkte sie gerade haben |
| Paketverarbeitung unter Linux im Kernel, überall sonst im Userspace | NAT-Traversal, damit sich die beiden Endpunkte ohne Portweiterleitung finden |
| Kryptografisches Routing (ein Schlüssel ist einem erlaubten Quellbereich zugeordnet) | Zugriffsregeln, damit die erlaubten Bereiche abbilden, wer was erreichen darf, und einen Paketfilter für die Ports und Protokolle, die eine Regel erlaubt |
| Stilles, zustandsloses Verhalten auf der Leitung | Registrierung, Sitzungsablauf, Widerruf und eine Aufzeichnung der Änderungen unter Activity |
Schlüssel verlassen die Maschine nie
Der Agent erzeugt sein Schlüsselpaar beim ersten Start lokal. Der private Schlüssel bleibt im eigenen Speicher des Agenten auf dem Gerät und wird nie übertragen - der Management-Dienst erhält ausschließlich den öffentlichen Schlüssel. Ein Gerät behält seinen Schlüssel, bis es erneut registriert wird; einen anderen Weg zu einem neuen Schlüssel gibt es nicht.
Weil kryptografisches Routing einen öffentlichen Schlüssel an einen erlaubten Quellbereich bindet, kann ein Gerät, das nicht in Ihrer Netzwerkbeschreibung steht, keine Pakete in Ihre Schnittstelle einschleusen, selbst wenn es Ihre Adresse erfährt. Die Zugriffskontrolle setzen der Tunnel selbst und der Paketfilter des Agenten durch, der die von Ihren Zugriffsregeln erlaubten Ports und Protokolle anwendet, und nicht eine Firewall-Regel, an deren Einrichtung Sie denken müssen.
Kernel und Userspace
Nur der CLI-Agent unter Linux betreibt den Tunnel im Kernel, mit dem Tunnelmodul des Kernels, sofern der Kernel eines mitbringt. Der CLI-Agent unter macOS und alle Apps (macOS, Windows, iOS und Android) betreiben den Tunnel im Userspace. Beide Varianten sprechen dasselbe Protokoll mit denselben Schlüsseln; Geräte verbinden sich daher wie gewohnt miteinander, gleich welche Variante sie nutzen.
Welche Variante ein Gerät nutzt, zeigt sxaccess info -d in der Zeile Interface: Kernel oder Userspace.
Auch Nachrichten an die Dienste sind versiegelt
Der Agent kommuniziert mit dem Management-Dienst über TLS, und jede Nachricht ist zusätzlich mit NaCl box (Curve25519, XSalsa20 und Poly1305) zwischen dem Schlüssel des Geräts und dem des Dienstes versiegelt. Aushandlungsnachrichten, die über Discovery laufen, sind per NaCl box mit dem Schlüssel des Gegenübers versiegelt; Discovery leitet also Nachrichten weiter, die er nicht lesen kann. Die Verbindung zu einem Relay läuft über TLS, und das Relay akzeptiert nur Agenten, die ein vom Management-Dienst ausgestelltes Token vorlegen.