mandatoryprogrammer/thermopticUn proxy HTTP stealth di nuova generazione che maschera perfettamente le richieste come browser Chrome su tutti i livelli dello stack.
"Non ci credo, camuffamento thermoptic!"
Questo è un proxy HTTP progettato per bypassare i servizi che utilizzano tecniche di fingerprinting come JA4+ per bloccare determinati client HTTP. Utilizzando questo proxy, puoi usare i tuoi client HTTP preferiti come curl e avere comunque impronte digitali magicamente indistinguibili da quelle di un vero browser web (Chrome/Chromium). thermoptic include anche alcune funzionalità divertenti per mitigare il fingerprinting basato su JavaScript. Inoltre, semplifica lo scraping ibrido, usando insieme sia un browser web che client HTTP di basso livello.
Anche se non hai familiarità con il fingerprinting JA4+, se hai mai fatto scraping probabilmente sei già stato bloccato da questo sistema. Servizi popolari come Cloudflare usano queste tecniche (e altri trucchi) per rilevare l'uso di client HTTP "non umani" e bloccare le richieste. Questi servizi possono anche usare questo fingerprinting per rilevare se avvii una sessione con un browser reale e poi passi a un client di basso livello come curl. thermoptic risolve tutti questi problemi presentando un'impronta digitale unificata di browser "reale" per tutte le richieste di scraping.
Ecco un esempio di impronta JA4H (HTTP) di curl senza il proxy:```
$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc
Questo è piuttosto diverso dall'impronta digitale che Chrome produce quando visiti l'URL direttamente:```
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e
Tuttavia, quando usiamo il proxy per effettuare la richiesta, la nostra impronta JA4H è magicamente identica:``` $ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/ ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e
(Idem per il nostro fingerprint TLS JA4, ecc.).
## Setup
Per avviare un proxy `thermoptic` che maschera il tuo traffico tramite un'istanza Chrome containerizzata su Ubuntu 22.04:
Configurazione Docker standard (funziona su host senza runtime GPU):```
docker compose up --build
Ecco fatto, ora puoi inoltrare il traffico attraverso di esso:``` curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/
Note importanti:
* Di default il proxy viene eseguito senza autenticazione. Se hai intenzione di esporre il proxy esternamente, assicurati di impostare l'autenticazione con le variabili d'ambiente `PROXY_USERNAME` e `PROXY_PASSWORD`.
* Se non vuoi usare `---insecure`, devi usare il file CA generato situato in `./ssl/rootCA.crt`. Questo viene generato la prima volta che esegui `thermoptic`.
* Puoi connettere `thermoptic` a qualsiasi istanza di Chrome/Chromium avviata con il flag `--remote-debugging-port`. Questo è essenziale perché vorrai impostare e usare il proxy attraverso ambienti più comuni per mantenere il tuo fingerprint il più possibile sotto traccia (ad es. Chrome su Windows).
* L'override compose per la GPU è pensato per host NVIDIA che hanno già installato il runtime/toolkit NVIDIA di Docker. Riserva il dispositivo GPU, monta `/dev/dri` e consente al container Chrome incluso di passare al percorso di rendering NVIDIA/Vulkan. Per usarlo, esegui `docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build`.
## Caratteristiche
- 🕵️ [Proxy con parità di browser](#how-does-this-cloaking-work-exactly) che riproduce le richieste tramite una sessione Chrome reale per corrispondere ai fingerprint JA4 byte per byte.
- 🤝 Serve poco o nessun codice personalizzato per integrare il tuo client HTTP (ad es. `curl`, `requests`, ecc.) con `thermoptic`: basta [impostare il proxy](#setup) e ai tuoi fingerprint ci pensiamo noi.
- 🪝 [Framework di hook](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) per automazione before-request/after-request/on-start, così puoi pilotare l'intero browser per risolvere sfide o catturare artefatti.
- 📘 Un esempio di hook per la risoluzione di Cloudflare Turnstile è disponibile in [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js).
- 🖥️ [Interfaccia di controllo del browser web](#control-the-dockerized-chrome-browser-via-web-ui-xpra) (su `http://127.0.0.1:14111`) per controllare la finestra del browser Chrome in Docker. Utile per accedere manualmente ai siti e poi usare senza soluzione di continuità il proxy per effettuare richieste come la tua sessione autenticata (e per il debug).
- 🔌 Imposta un URI proxy HTTP o SOCKS upstream tramite la variabile d'ambiente `UPSTREAM_PROXY` in `docker-compose.yml`.
- 🛡️ Health check integrati e ciclo di controllo del riavvio per rilevare browser bloccati e recuperare automaticamente senza bisogno della supervisione di un operatore.
- ⚡ Supporta HTTP/1.1 e HTTP/2, consentendo di instradare il traffico tramite l'uno o l'altro protocollo. (_Nota: puoi parlare HTTP/1.1 con il proxy, e il Chrome pilotato può negoziare con il sito di destinazione su un protocollo diverso._)
## Come funziona esattamente questo cloaking?
* Una richiesta HTTP viene effettuata usando un client HTTP come `curl` con `thermoptic` impostato come proxy.
* `thermoptic` analizza la richiesta per determinare al meglio quale tipo di richiesta browser *dovrebbe* essere (ad es. visita manuale di un URL? Invio di un modulo? Una richiesta `fetch()`?).
* `thermoptic` usa il [Chrome Debugging Protocol (CDP)](https://chromedevtools.github.io/devtools-protocol/) per controllare il browser e predisporre una pagina che simula la richiesta esattamente come avverrebbe normalmente in un browser web reale.
* `thermoptic` innesca la richiesta tramite il contesto simulato e cattura la risposta HTTP.
* `thermoptic` invia la risposta HTTP al client.
Poiché il browser effettua realmente la richiesta usando l'intero stack, i fingerprint JA4 risultanti sono identici.
NOTA: Poiché molti WAF usano fingerprinting a livello JavaScript dei browser web, `thermoptic` espone anche hook per utilizzare il browser nei passaggi chiave del processo di scraping. Vedi [questa sezione](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) per maggiori informazioni.
## Perché *questo* approccio rispetto ad altre soluzioni?
Per dirla chiaramente: altri approcci hanno difetti fondamentali che impediscono loro di essere una soluzione pratica a lungo termine al problema del fingerprinting del browser.
Molti altri tentativi di "battere" il fingerprinting JA4+ del browser lo fanno reimplementando i vari livelli dello stack del browser. Questo approccio presenta una serie di seri svantaggi, come:
* Richiedere grande attenzione per corrispondere perfettamente al comportamento dell'implementazione "reale" del browser. Di conseguenza, *qualsiasi* stranezza o discrepanza può essere usata per distinguere questi client dall'implementazione "reale" del browser.
* Tentare di risolvere il problema solo a un livello dello stack. Chrome utilizza più protocolli per fornire un'esperienza di navigazione web. Di conseguenza, anche se hai creato un livello TLS perfettamente corrispondente, il livello HTTP potrebbe tradirti se non è perfetto byte per byte.
* Poiché i browser "reali" cambiano regolarmente il loro comportamento, i loro fingerprint cambiano e di conseguenza questi strumenti richiedono costantemente un lavoro di sviluppo più intensivo per compensare.