Kategorie: Netzwerk / Transportschicht-Residuen
1. Beschreibung
Selbst mit TLS- und HTTP-Spoofing bleiben residuale Netzwerksignale bestehen, da Obscuras eigener Netzwerk-Stack für den Zielserver sichtbar ist. Diese Signale können nicht vollständig normalisiert werden, da sie Eigenschaften des Container-OS und des Netzwerkpfads sind.
2. Vektoren
2.1 TCP/IP-Stack-Fingerprint
Empfangenes SYN-Paket:
Window: 64240
TTL: 64
MSS: 1452
Optionen: MSS, SACK_PERM, TIMESTAMP, NOP, WINDOW
Window Scale: 10
DF: True
Container-OS-Fingerprints:
| Container-Basis | Window | TTL | MSS | Optionen | JA4T-ähnlich |
|---|---|---|---|---|---|
| Alpine Linux | 29200-65535 | 64 | 1460 | M,S,T,N,W | 29200_2-4-8-1-3_1460_7 |
| Debian/Ubuntu | 29200-65535 | 64 | 1460 | M,S,T,N,W | 29200_2-4-8-1-3_1460_7 |
| Distroless | 29200-65535 | 64 | 1460 | M,S,T,N,W | Hängt von Go/Rust-Laufzeit ab |
Entropie: ~4-6 Bits
Abschwächung: Keine auf Proxy-Ebene. Der TCP-Stack des Containers wird geerbt.
2.2 Netzwerk-Umlaufzeit (RTT)
Die RTT ist für den Server messbar:
Anfrage gesendet: T1
Antwort erhalten: T2
RTT = T2 - T1 // Inklusive Proxy-Verarbeitungszeit
- Echte RTT variiert je nach Netzwerkpfad
- Proxy fügt konsistente Latenz hinzu (erkennbar als zusätzliche Verarbeitungszeit)
- RTT-Varianz über Zeit erzeugt ein Muster
Entropie: ~5-8 Bits (Pfad + Proxy-Latenz-Signatur)
Abschwächung: Kann nicht beseitigt werden, kann aber teilweise hinter VPN/Tor versteckt werden.
2.3 Clock Skew
// Serverseitige Berechnung
const clientTimestamp = parseInt(getHeader('Date'))
const serverTime = Date.now()
const skew = serverTime - clientTimestamp
// Hardware-Clock-Drift ist konsistent
Jede Hardware-Clock driftet mit einer einzigartigen Rate (Parts-per-Million). Über Minuten der Interaktion wird die Drift messbar.
Entropie: ~4-8 Bits
Abschwächung: Obscura kann HTTP-Date-Header normalisieren, aber TCP-Timestamp-Optionen im SYN-Paket verraten ebenfalls Clock-Informationen.
2.4 HTTP/2-SETTINGS (Falls nicht gespooft)
Wenn Obscura kein benutzerdefiniertes HTTP/2-SETTINGS implementiert, verraten die Bibliotheksstandards den Proxy:
| Proxy-Bibliothek | Initial Window | Max Concurrent | Header Table Size |
|---|---|---|---|
| Go net/http | 6291456 | 250 | 4096 |
| Rust hyper | 65535 | 100 | 4096 |
| Node.js http2 | 65535 | 100 | 4096 |
| Envoy | 1048576 | 100 | 65536 |
Entropie: ~6-10 Bits
Abschwächung: Benutzerdefinierte SETTINGS-Frame-Werte, die dem Zielbrowser-Profil entsprechen.
2.5 MTU- & Pfadcharakteristiken
- Pfad-MTU beeinflusst TCP-MSS
- TTL verrät die ungefähre Hop-Anzahl zum Benutzer
- Router/ISP-Verhalten erzeugt einzigartige Muster (NAT-Stil)
Entropie: ~3-5 Bits
Abschwächung: Über VPN/Tor routen, um zu normalisieren.
2.6 HTTP/3 / QUIC (Falls nicht blockiert)
QUIC-Transportparameter:
- Verbindungs-ID-Länge und -Wert
- Versionsaushandlung
- Initiale Flusskontroll-Limits
- TLS-1.3-Handshake-Parameter über QUIC
Entropie: ~8-12 Bits
Abschwächung: UDP 443 blockieren, um TCP-Fallback zu erzwingen.
3. Stärken des Angreifers
| Stärke | Erklärung |
|---|---|
| Immer vorhanden | Netzwerksignale sind in jeder TCP/IP-Verbindung unvermeidbar |
| Kein JS erforderlich | Diese Signale sind auf der Transportschicht beobachtbar |
| Schwer zu spoofen | TCP/IP-Stack ist auf OS-Ebene, nicht auf Anwendungsebene |
| Konsistent | Netzwerkpfad ändert sich selten |
| Kreuzkorrelation | Wird zusammen mit HTTP/TLS-Signalen verwendet |
4. Schwächen des Angreifers
| Schwäche | Erklärung |
|---|---|
| Niedrige individuelle Entropie | TCP/IP allein kann keinen bestimmten Benutzer identifizieren |
| Geteilte Container-Umgebung | Mehrere Benutzer hinter demselben Container sehen identisch aus |
| Nur aggregiert nützlich | Benötigt Kombination mit anderen Signalen |
| VPN/Tor normalisiert | Routing durch VPN/Tor eliminiert Netzwerk-Fingerprints |
5. Erkennung von Manipulation
| Technik | Funktionsweise |
|---|---|
| TLS vs. TCP-Diskrepanz | Chrome-TLS + Linux-TCP-Stack = Proxy |
| RTT vs. behaupteter Standort | Benutzer behauptet US-Standort, aber RTT deutet auf anderen Kontinent hin |
| HTTP/2 vs. Browser-Behauptung | Go-HTTP/2-SETTINGS mit Chrome-User-Agent |
| IP-Geolokalisierung vs. Profilzeitzone | Diskrepanz zwischen Profil und tatsächlichem Netzwerkursprung |
6. Abschwächungen für Obscura
6.1 Was Obscura tun kann
| Abschwächung | Effektivität | Erkennbarkeit | Implementierung |
|---|---|---|---|
| TLS-Spoofing via utls | Hoch | Niedrig | Für Obscura erforderlich |
| HTTP/2-SETTINGS-Spoofing | Mittel | Niedrig | Benutzerdefinierte SETTINGS-Werte |
| Über VPN/Tor-Upstream routen | Hoch | Mittel | Benutzerkonfigurierbar |
| UDP 443 blockieren (QUIC) | Hoch | Niedrig | iptables-Regel |
| HTTP-Date-Header normalisieren | Niedrig | Niedrig | Header-Umschreibung |
6.2 Was Obscura nicht tun kann
| Kann nicht | Warum |
|---|---|
| TCP/IP-Stack des Containers ändern | Auf OS-Ebene, vom Container-Basis-Image geerbt |
| RTT eliminieren | Physik der Netzwerkentfernung |
| Clock Skew ändern | Hardware-Clock-Drift ist physikalisch |
| Hop-Count-Informationen entfernen | TTL-Dekremente sind unvermeidbar |
6.3 Empfohlener Ansatz
1. TLS-Fingerprint-Spoofing via utls (kritisch – höchste Priorität)
2. HTTP/2-SETTINGS-Spiegelung (mittlere Priorität)
3. UDP 443 blockieren (QUIC-Umgehung verhindern)
4. Optionaler VPN/Tor-Upstream (normalisiert alle Netzwerksignale)
5. TCP/IP-Residuen akzeptieren (niedrige individuelle Entropie)
7. Forschungsreferenzen
- FoxIO (2024). "JA4+ Suite: TLS, TCP, and QUIC Fingerprinting." FoxIO Blog.
- Zalewski, M. (2007). "p0f: Passive OS Fingerprinting." lcamtuf.coredump.cx/p0f.
- Beverly, R. (2004). "A Robust Classifier for Passive TCP/IP Fingerprinting." PAM 2004.
- Satori (2025). "Python rewrite of passive OS fingerprinting tool." GitHub: xnih/satori.