Architektur und Sicherheit

1Komponenten#

Browser-Erweiterung. 38 KB, reines JavaScript, ohne Minifizierung und Obfuskation — der Code lässt sich vollständig lesen. Das Routing steuert sie über die bordeigenen Mechanismen des Browsers: PAC in Chrome, die Proxy-API in Firefox. Sie braucht keine Administratorrechte, installiert keine Treiber und ändert weder Systemrouten noch DNS.

Gateway. Eine 8-MB-Binärdatei in Go, ohne Abhängigkeiten und Konfigurationsdateien. Sämtliche Einstellungen und Zertifikate erhält sie über einen gesicherten Kanal vom Dashboard und wendet sie sofort an. Den Zustand hält sie lokal, um Neustarts und Verbindungsabbrüche zu überstehen.

Control Plane (CP). Weboberfläche und API. Verwahrt die Konfiguration, verteilt Einstellungen an Gateways und Erweiterungen, führt Buch über Geräte und Limits.

2Der Weg einer Anfrage#

Browser ──TLS──► Gateway ──TLS──► Zielserver
   │
   └── ungeschützte Domains ──► direkt ins Internet

1. Über den Token erhält die Erweiterung die Liste der geschützten Domains und die Routing-Regeln.
2. Der Browser schickt Anfragen an diese Domains per CONNECT ans Gateway, alle übrigen direkt.
3. Das Gateway prüft die Verbindung, löst den Namen mit dem eigenen Resolver auf (unter Berücksichtigung der vom Administrator gesetzten IP- und Port-Überschreibungen) und baut eine Verbindung zum Zielserver auf.
4. Danach schiebt das Gateway nur noch Bytes zwischen Sockets hin und her.

Die entscheidende Folge: Die Route wird pro Domain gewählt, nicht global für den Browser. Über das Gateway läuft genau das, was im Token steht.

3Identifikation von Geräten#

Ein Token ist eine Einladung, kein Ausweis. Die Identität im System ist das Gerät.

Bei der Installation registriert sich die Erweiterung und erhält eine Gerätekennung (dev_id) und einen geheimen Schlüssel. Beide werden getrennt von den Token gespeichert und beim Löschen der Browserdaten nicht zurückgesetzt — nur beim Entfernen der Erweiterung.

Jede Anfrage an die API führt mit sich:

• die Gerätekennung
• einen Zeitstempel
• eine HMAC-SHA256-Signatur

Das ergibt drei Effekte:

Die API unterscheidet Nutzer desselben Tokens. Ein Token, an drei Auditoren ausgegeben, sind drei verschiedene Geräte mit eigener Statistik und eigenem Entzug.

Das Durchprobieren von Token wird erschwert. Anonym lässt sich die API nicht ansprechen: Es braucht eine registrierte dev_id mit gültiger Signatur. Rateversuche sind an ein konkretes Gerät gebunden und werden über dieses abgebrochen, nicht über eine IP, die sich leicht wechseln lässt.

Wiederholte Anfragen laufen ins Leere. Der Zeitstempel in der Signatur schützt vor Replay-Angriffen.

4Was einen Token schützt#

Fünf Zeichen im base58-Alphabet (Schreibweise zählt) sind eine Zugangskennung, nicht die einzige Barriere. Selbst wer den Token kennt, bekommt keinen Zugang, denn:

• die API lässt sich nur von einem registrierten Gerät mit gültiger Signatur ansprechen;
• die Zahl der Aktivierungen ist begrenzt — ist sie erschöpft, verbindet sich kein neues Gerät mehr;
• ein Token kann ein Aktivierungsfenster haben, außerhalb dessen er nicht funktioniert;
• ein Token kann durch ein Passwort geschützt sein: Die Konfiguration wird verschlüsselt heruntergeladen und ohne Passwort nicht entschlüsselt;
• jedes verbundene Gerät ist für den Administrator sichtbar und einzeln entziehbar.

Passwortgeschützte Token beginnen mit einem Großbuchstaben — das sieht man der Schreibweise an, das Passwort wird also sofort erwartet.

Richtlinien auf Domain-Ebene#

Sicherheitsanforderungen lassen sich an der Ressource selbst festmachen statt an jedem einzelnen Token:

• Nur geschützter Token — jeder Token, der eine solche Domain enthält, muss ein Passwort haben. Das Dashboard lässt ihn ohne nicht anlegen.
• Nur private Sitzung — ein Token mit einer solchen Domain läuft zwingend im privaten Modus der Erweiterung: Beim Schließen des Browsers werden Token und Konfiguration vergessen.

Das ist Schutz vor menschlichem Irrtum: Die Markierung wird einmal an einer sensiblen Ressource gesetzt und gilt für alle künftigen Token, unabhängig davon, wer sie anlegt und in welcher Eile.

Richtlinien greifen fail-closed, aber ohne laufenden Zugang zu zerreißen: Eine geschützte Domain lässt sich einem ungeschützten Token nicht hinzufügen, und wurde die Richtlinie später aktiviert, wird die Domain in bestehenden Token abgeschaltet und lässt sich erst nach Erfüllung der Anforderung wieder einschalten. Richtlinien einer Domain ändern dürfen nur der Workspace-Inhaber und ein Administrator; ein Manager nicht.

Unabhängig davon lässt sich eine Domain aus der Liste in der Erweiterung ausblenden — der Zugang funktioniert, die Ressource erscheint in der Oberfläche des Nutzers aber nicht. Nützlich für technische Domains, die der Nutzer nie direkt aufruft.

5Unsichtbarkeit des Gateways#

Das Gateway antwortet niemandem außer registrierten Geräten und verrät nichts über sich.

Eine eindeutige Adresse je Gerät. Jedes Gerät verbindet sich unter einem eigenen Hostnamen mit dem Gateway. Im öffentlichen DNS und im Zertifikat steht nur ein Wildcard — konkrete Namen werden nirgends veröffentlicht. Das ist wegen Certificate Transparency wichtig: Zertifikate pro Gerät wären eine öffentliche Liste aller Geräte, ein Wildcard schließt dieses Leck aus.

Vorautorisierung per SNI. Das Gateway prüft den Hostnamen im TLS-Handshake vor allem anderen. Ist der Name nicht erwartet, wird die Verbindung verworfen: kein ServerHello, kein Zertifikat, kein TLS-Alert. Der Alert-Typ ist für sich genommen ein Fingerabdruck und wird deshalb nicht gesendet.

Dieselbe Reaktion auf jeden Müll. Eine gewöhnliche HTTP-Anfrage und ungültiges TLS bekommen dasselbe Verwerfen der Verbindung — aus der Antwort lässt sich nicht ableiten, welches Protokoll der Port erwartet.

Sperre per IP. Die Quelle einer fehlgeschlagenen Sondierung landet auf der Sperrliste.

Was ein Scanner sieht: Der Port nimmt eine TCP-Verbindung an. Mehr nicht — kein Banner, kein Zertifikat, kein Fehlercode.

6Verschlüsselung des Traffics#

Öffentliche Seiten: Ende-zu-Ende-Verschlüsselung. Das Gateway routet per SNI und terminiert TLS nicht. Die Sitzung ist zwischen Browser und Ihrem Server verschlüsselt; das Gateway sieht den Domainnamen und die Menge übertragener Bytes, aber nicht den Inhalt. Entschlüsseln kann es den Traffic technisch nicht — es hat keine Schlüssel.

Interne Dienste über HTTP: Terminierung auf Ihrer Seite. Läuft ein Dienst ohne TLS (etwa Grafana auf 127.0.0.1:3000), wird das Gateway auf dieselbe Maschine oder ins selbe Netz gestellt und terminiert TLS lokal, während es den Dienst über Loopback oder eine private Adresse anspricht. Der unverschlüsselte Abschnitt verlässt Ihre Maschine oder Ihr Netz nicht.

In beiden Fällen läuft unverschlüsselter Traffic nie über öffentliche Netze.

7Synchronisation der Einstellungen#

Gateways beziehen ihre Einstellungen über eine dauerhafte Verbindung vom Dashboard.

Inkrementell. Übertragen werden nur Änderungen, nicht die vollständige Konfiguration aller Nutzer. Das hält die Anwendung schnell, unabhängig von der Größe der Installation.

Im laufenden Betrieb. Neue Einstellungen greifen ohne Neustart und ohne Abbruch laufender Verbindungen. Bekommt ein Nutzer gerade beim Herunterladen einer Datei mehr Traffic, bricht der Download nicht ab.

Mit erhaltenem Zustand. Das Gateway hält die Konfiguration lokal und arbeitet weiter, wenn die Verbindung zum Dashboard abreißt — auch über einen Serverneustart hinweg.

8Zugang entziehen#

Der Entzug eines Geräts oder eine Änderung der Limits erreicht die Gateways in Sekunden und greift sofort: Ein Neustart des Browsers hilft dem Nutzer nicht.

Eine wichtige Einschränkung. Ist ein Gateway im Moment des Entzugs für das Dashboard nicht erreichbar, greift die Änderung nach Wiederherstellung der Verbindung. Die Autonomie der Gateways schützt vor Ausfällen bei Problemen auf unserer Seite, sie bedeutet aber auch: Das Zeitfenster bis zur Wirkung eines Entzugs entspricht der Dauer bis zur Wiederherstellung der Verbindung. Unter normalen Bedingungen sind das Sekunden.

9Ausfallszenarien#

Das Dashboard ist nicht erreichbar. Gateways arbeiten mit der zuletzt bekannten Konfiguration weiter. Neue Geräte lassen sich nicht verbinden, bestehender Zugang bleibt. Geänderte Einstellungen greifen nach der Wiederherstellung.

Ein Gateway ist nicht erreichbar. Geschützte Seiten öffnen sich für die Personen nicht, die über dieses Gateway laufen. Der übrige Traffic des Browsers ist nicht betroffen. Domains lassen sich im Dashboard auf ein anderes Gateway umstellen.

Die Erweiterung wurde entfernt. Der Zugang endet, im System bleibt nichts zurück. Eine erneute Installation erfordert eine neue Aktivierung des Tokens.

Ein Nutzer hat sein Gerät verloren. Entziehen Sie dessen dev_id — der Zugang endet, andere Nutzer desselben Tokens sind nicht betroffen.

10Was wir sehen und was nicht#

Wir sehen:

• mit welchen Domains sich Geräte verbunden haben und wann
• das Volumen des übertragenen Traffics
• Gerätekennungen und Statistik zu ihrer Aktivität
• Scan-Ereignisse an den Gateways (Schutztelemetrie)

Wir sehen nicht:

• den Inhalt des Traffics zu öffentlichen Seiten — er ist Ende-zu-Ende mit TLS verschlüsselt
• Passwörter, Cookies, Formulardaten, Seiteninhalte
• Traffic zu Domains, die in keinem Token stehen — er läuft überhaupt nicht durch unsere Infrastruktur

Bei einem self-hosted Gateway sehen wir: vom Traffic gar nichts — er läuft in keiner Form durch unsere Infrastruktur. Das Dashboard tauscht mit dem Gateway dann nur Konfiguration und Statistik aus.

Bekannte Einschränkungen#

Eine ehrliche Liste, damit Sie keine Zeit mit Nachprüfen verlieren:

• Nur HTTP/HTTPS im Browser. SSH, Datenbanken und Zugriff aus der CLI werden nicht unterstützt. Ein Client für TCP-over-HTTPS ist geplant.
• Das Gateway muss von außen erreichbar sein. Betrieb hinter NAT ohne Portweiterleitung ist nicht möglich.
• ECH wird nicht verwendet. Browser wenden Encrypted Client Hello auf Proxy-Verbindungen nicht an, deshalb sieht ein Beobachter auf dem Weg (Provider, Corporate-DPI) den Hostnamen, unter dem sich ein Gerät mit dem Gateway verbindet. Der Name ist pseudonym und ohne die Schlüssel des Geräts nutzlos.
• Eine Domain, eine Route zur selben Zeit innerhalb eines Browsers.