obscura/research/network-fingerprintingobscura/research/network-fingerprinting

Panoramica

Segnali visibili a livello TCP/IP e di trasporto, prima di qualsiasi esecuzione HTTP o JS.

---

1. Fingerprint Stack TCP/IP (JA4T / Satori / p0f)

Meccanismo

Il fingerprinting OS passivo legge il pacchetto TCP SYN per identificare il sistema operativo. Ogni stack TCP/IP del SO ha una combinazione unica di:

• TTL iniziale: 64 (Linux/macOS), 128 (Windows), 255 (Alcuni UNIX)
• Dimensione finestra: 64240 (Chrome/Linux), 65535 (macOS), 8192 (sistemi vecchi)
• MSS (Maximum Segment Size): Derivato da MTU
• Opzioni TCP: Ordine e selezione di MSS, SACK_PERM, TIMESTAMP, NOP, WINDOW_SCALE
• Flag IP: Comportamento DF (Don't Fragment)

Formati

JA4T: 64240_2-4-8-1-3_1452_10

Fingerprint Satori: 64240:64:1:60:M1452,S,T,N,W10:.

Rilevamento OS

Impatto su Obscura

Client  Container Obscura (termine TCP)  Internet
                                      
     Stack TCP client            Stack TCP container
     (visibile a Obscura)        (visibile alla destinazione)

Il server di destinazione vede lo stack TCP di Obscura, non quello del client. Questo è inevitabile perché il container termina la connessione TCP del client.

Mitigazione: Nessuna a livello TCP. Tuttavia, la maggior parte dei servizi di fingerprinting si concentra su fingerprint a livello applicativo (TLS, HTTP) piuttosto che a livello TCP. Il fingerprint TCP da solo raramente identifica un utente.

---

2. Fingerprint TLS (JA3 / JA4)

Vedi tls-fingerprinting.md per i dettagli completi.

Punti chiave per il livello di rete:

• L'handshake TLS è il segnale più importante a livello di rete
• Completamente controllabile tramite utls (Go) o Rust TLS personalizzato
• Critico per Obscura: deve essere falsificato o il proxy viene rivelato

---

3. Fingerprint HTTP/2

Meccanismo

Il preambolo della connessione HTTP/2 e i frame iniziali variano per implementazione.

Segnali:

• Parametri frame SETTINGS (l'ordine è importante):
  • SETTINGS_HEADER_TABLE_SIZE
  • SETTINGS_ENABLE_PUSH
  • SETTINGS_MAX_CONCURRENT_STREAMS
  • SETTINGS_INITIAL_WINDOW_SIZE
  • SETTINGS_MAX_FRAME_SIZE
  • SETTINGS_MAX_HEADER_LIST_SIZE
• Frame iniziale WINDOW_UPDATE
• Comportamento PING
• Struttura frame PRIORITY

Esempi per Browser

Impatto su Obscura

Se si utilizza net/http di Go per HTTP/2, il server vede il fingerprint HTTP/2 di Go. È necessario implementare HTTP/2 personalizzato o utilizzare una libreria che permetta l'override dei SETTINGS.

---

4. Fingerprint QUIC / HTTP/3

Problema

HTTP/3 funziona su QUIC (UDP). Le connessioni QUIC sono crittografate end-to-end, incluso il livello di trasporto:

Client  QUIC (UDP 443)  Server
                          
    Criptato            Criptato
    (non ispezionabile) (non ispezionabile)

I parametri di trasporto QUIC, gli ID di connessione e le informazioni sulla versione sono visibili nell'handshake iniziale, ma il proxy non può modificarli.

Strategia

Blocca UDP 443 per forzare il fallback a HTTP/2 o HTTP/1.1 su TCP:

iptables -A FORWARD -p udp --dport 443 -j DROP

Questo impedisce alle connessioni QUIC di bypassare il proxy.

Compromesso: Latenza leggermente più alta (TCP vs QUIC), niente 0-RTT, niente migrazione connessione.

---

5. Fingerprint Basati su Temporizzazione

5.1 Performance Timing

performance.now()  // Timestamp ad alta risoluzione in ms (precisione sub-millisecondo)
performance.timeOrigin
performance.getEntriesByType('navigation')

Mitigazione: Arrotonda performance.now() alla risoluzione di 100ms tramite iniezione JS:

const originalNow = performance.now.bind(performance)
performance.now = () => Math.round(originalNow() / 100) * 100

5.2 Clock Skew

I server possono misurare lo skew dell'orologio confrontando i valori di Date.now() tra richieste.

Mitigazione: Arrotonda la risoluzione di Date.now().

5.3 Temporizzazione di Rete tramite Caricamento Risorse

I siti misurano la latenza cronometrando quanto tempo impiegano le risorse a caricarsi:

const start = performance.now()
fetch('/image.png').then(() => {
  const rtt = performance.now() - start
})

Mitigazione: Non può essere completamente prevenuto: il proxy aggiunge la propria latenza ma la temporizzazione relativa perde comunque informazioni.

---

6. WebRTC IP Leak

Meccanismo

WebRTC bypassa il proxy utilizzando server STUN/TURN per scoprire l'IP reale.

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
})
pc.createDataChannel('test')
pc.createOffer().then(d => pc.setLocalDescription(d))
pc.onicecandidate = e => {
  if (e.candidate) {
    // e.candidate.candidate contiene l'indirizzo IP
    console.log(e.candidate.candidate)
  }
}

Mitigazione tramite Iniezione JS

// Blocca WebRC completamente
Object.defineProperty(window, 'RTCPeerConnection', { value: undefined })
Object.defineProperty(window, 'RTCDataChannel', { value: undefined })
Object.defineProperty(window, 'RTCSessionDescription', { value: undefined })

Effetto

---

7. Fingerprint DNS

Segnali

• IP del resolver DNS (Cloudflare 1.1.1.1 vs Google 8.8.8.8 vs ISP)
• DNS over HTTPS vs DNS over TLS vs DNS semplice
• Sottorete client EDNS0 (rivela posizione di rete approssimativa)
• Supporto DNSSEC

Mitigazione

Obscura controlla completamente il DNS. Usa un upstream coerente e orientato alla privacy (Quad9 9.9.9.9 o Cloudflare 1.1.1.1) e rimuovi la sottorete client EDNS0.

---

Conclusioni per Obscura