ShadowTLS v3 e Shadowsocks: camuffamento come HTTPS e schema robusto per bypassare il DPI

Introduzione

Internet nel 2026 è diventato uno spazio di continua lotta: l'ispezione dettagliata dei pacchetti e il sondaggio attivo evolvono, gli operatori aggiornano le firme, adottano analisi comportamentali e profilazione JA4, mentre gli utenti cercano modi per garantire privacy e accessibilità ai servizi. In questo contesto, la combinazione ShadowTLS v3 e Shadowsocks è diventata uno standard pratico per chi chiede non solo cifratura, ma un camuffamento credibile come traffico TLS 1.3 verso un sito reale. In questa guida esploreremo la tecnologia dai principi base a schemi di implementazione avanzati, ti mostreremo come scegliere l'SNI, configurare server e client, evitare gli errori comuni, valutare il successo e reagire alle nuove tecniche DPI. Alla fine avrai configurazioni funzionanti, checklist decisionali e un framework di debug utile nelle reti reali.

Basi

Cos'è il camuffamento del traffico come HTTPS

Il camuffamento non è solo cifratura. L'idea è far sembrare e comportarsi il traffico di rete come una legittima sessione TLS 1.3 verso un sito popolare. Oggi il DPI analizza non solo SNI e ALPN, ma anche l'ordine delle estensioni ClientHello, le lunghezze dei record, gli intervalli temporali, la distribuzione delle dimensioni dei pacchetti, i dati early e persino le caratteristiche probabilistiche della finestra TCP. Se il tracciato dei pacchetti non corrisponde a client e siti noti, il traffico viene marcato come sospetto.

Breve panoramica su Shadowsocks

Shadowsocks è un proxy ad alte prestazioni basato su cifratura AEAD. Da solo non si camuffa; per resistere al DPI e al sondaggio attivo si usano plugin: obfs, v2ray-plugin, simple-tls, shadowtls. I client moderni (sing-box, mihomo, v2rayN, Shadowrocket) possono combinare Shadowsocks e ShadowTLS in una catena unica: all’esterno un TLS 1.3 verso un sito reale, all’interno un flusso cifrato Shadowsocks.

L’idea di ShadowTLS

ShadowTLS fa due cose chiave. Primo, fa sembrare il traffico come una reale sessione TLS 1.3 verso un dominio scelto (SNI). Secondo, protegge dal sondaggio attivo: senza conoscere i segreti non si può continuare correttamente la sessione, e i segni esterni coincidono con un HTTPS legittimo. La versione v3 migliora la resistenza alle firme e agli attacchi temporali, semplificando anche la compatibilità con stack TLS moderni di client e server.

Minacce: DPI, sondaggio attivo, iniezioni RST

Il DPI usa più livelli di rilevamento: firme TLS (JA3/JA4), euristiche sulle sequenze di pacchetti, filtri su SNI/ALPN, sondaggio attivo (avviano sessioni proprie verso IP sospetti e verificano la risposta), iniezioni TCP RST e metodi ibridi con machine learning. ShadowTLS v3 mira a ridurre i falsi positivi e a imitare un handshake reale, mentre insieme a Shadowsocks offre cifratura a livello applicativo e proxing.

Perché serve l’SNI e perché è importante

L'SNI è il nome server nel ClientHello. È leggibile in chiaro in molte sessioni TLS 1.3 senza ECH. Il DPI spesso usa whitelist e blacklist per l’SNI. ShadowTLS fa in modo che la connessione mostri un SNI credibile di un sito popolare. È cruciale scegliere un SNI legale nella tua rete, stabile e il cui comportamento corrisponda a quello osservato in utenti reali.

Approfondimento

Architettura del canale: esterno e interno

Lo strato esterno è TLS 1.3 verso il dominio scelto: ClientHello corretto, estensioni realistiche, ALPN, lunghezze e ordine, tempi. Lo strato interno è un flusso cifrato Shadowsocks. La parte server accetta la sessione TLS, verifica il segreto ShadowTLS, apre un canale interno verso il server Shadowsocks locale e fa proxy bidirezionale dei byte. Il DPI vede solo un TLS normale verso un sito popolare con record applicativi oscurati. Anche se intercettato e decifrato in modello, il traffico appare come TLS corretto.

Perché v3 è migliore delle versioni precedenti

La versione v3 è ottimizzata per i profili TLS 1.3 attuali e si concentra sulla credibilità dell’handshake, inclusa la sequenza e i parametri più analizzati dagli ispettori. Ha una protezione migliorata contro il sondaggio attivo: senza le informazioni segrete giuste, il server non rivela comportamenti diversi da HTTPS. È anche più efficiente rispetto ai costi e più stabile in reti con perdita pacchetti.

JA3/JA4 e le euristiche comportamentali

JA3 e JA4 sono metodi per hasher i parametri TLS di client e server (versioni, cifrari, estensioni). Molti proxy e plugin hanno impronte uniche, facilmente bloccabili. La strategia ShadowTLS è adattarsi a un profilo legittimo. Ma non basta l’impronta: contano gli intervalli tra pacchetti, la dimensione del primo record applicativo, la priorità ALPN, i record precoci a lunghezza zero, ip-ttl e persino MTU tipici. Per ridurre i rischi scegliamo SNI e ambiente di rete affinché il profilo traffico sia naturale.

Limitazioni dell’approccio

Nessun metodo offre garanzie assolute. Se la censura implementa MITM attivo con sostituzione certificati o blocca tutto il traffico verso il dominio scelto, la connessione soffrirà. Inoltre, configurazioni errate (mancato allineamento v3, password, porta o ALPN sbagliati) smascherano lo schema. Infine, un’eccessiva quota di grandi record binari dopo handshake con poche richieste HTTP può farsi rilevare euristicamente. Serve quindi un approccio sistematico: scegliere SNI, configurare porte, fare padding, limitare parallelismo e monitorare.

Pratica 1. Architetture di deployment ShadowTLS v3 + Shadowsocks

Schema base su un server singolo

Componenti: host Linux (Debian 12 o Ubuntu 22.04), server Shadowsocks, server ShadowTLS. Porta esterna 443/TCP. Le connessioni entranti arrivano a ShadowTLS, che dopo verifica del segreto fa proxy dei byte verso Shadowsocks locale. I client si connettono come a un sito TLS 1.3 e internamente usano Shadowsocks.

Vantaggi

• Semplicità e minore latenza.
• Profilo realistico sulla porta 443.
• Buona compatibilità con client desktop e mobile.

Svantaggi

• Singolo punto di guasto.
• L’IP può finire in blacklist se usato impropriamente.

Schema con separazione dei ruoli

Server ShadowTLS su VPS di frontiera con porta 443. Tunnel interno verso server Shadowsocks dedicato tramite rete privata o canale inter-server protetto (WireGuard su porta non standard). Permette di separare il perimetro pubblico dal core del proxy.

Vantaggi

• Isolamento dei rischi e scalabilità.
• Scalabilità orizzontale con bilanciamento su backend multipli.

Svantaggi

• Gestione e monitoraggio più complessi.
• Aggiunge un hop extra.

Integrazione in sing-box o mihomo

Le implementazioni moderne supportano nativamente ShadowTLS come livello di trasporto. Semplifica la configurazione: si definisce un outbound shadowsocks con trasporto shadowtls v3 indicando password e SNI. Sul server si configura inbound shadowtls e inbound shadowsocks locali.

Quando usare la porta 443 e quando alternative

La porta 443 è la più credibile ma può essere occupata dal tuo sito. Alternative: usare 443 su IP dedicato, ospitare un web server su 8443 o 444 con backend SNI, o separare ruoli. Porte alternative vanno bene se non ci sono blocchi portuali severi, ma più si allontana da 443 più crescono i rischi euristici. Consiglio: 443/TCP con imitazione ALPN http/1.1 o h2 coerente al SNI scelto.

Pratica 2. Scelta di SNI e profilo traffico

Criteri per la scelta dell’SNI

• Alta reputazione e accessibilità nella tua rete: CDN grandi, piattaforme cloud, portali di notizie.
• Profilo TLS server stabile: set prevedibili di cifrari, ALPN, curve.
• Larga audience reale: il tuo traffico si perde nelle statistiche.
• Nessun divieto locale: se il dominio è in blacklist imitare non ha senso.
• Vicino geograficamente o con politica che coincide con la tua locazione: latenza e routing influiscono sui tempi.

ALPN e versioni protocollo

ALPN può essere http/1.1, h2 o h3. ShadowTLS usa TCP, quindi h3 (QUIC) non è praticabile come trasporto reale. Scegli SNI il cui ALPN server offre tipicamente http/1.1 e/o h2 su 443/TCP. Mimare h2 spesso è più credibile ma richiede coerenza col profilo reale. In caso di dubbio rimani su http/1.1.

Blacklist e whitelist

Alcuni censori usano whitelist per SNI. Usare domini rari può sembrare sospetto. Simulare domini soggetti a restrizioni regionali può violare politiche provider. Scegli risorse neutrali, popolari con traffico stabile. Cambia SNI se noti aumento blocchi o sondaggi attivi sul tuo IP.

Euristiche pratiche

• Misura RTT verso l’SNI da deployment e rete client; differenze grandi producono timing anomali.
• Controlla ALPN e cifrari reali del sito (es. openssl s_client); allinea ShadowTLS di conseguenza.
• Testa distribuzioni dimensione primi 10 record applicativi sotto vari carichi. Se il flusso ShadowTLS è anomalo aggiungi padding e limita parallelismo.

Pratica 3. Server: installazione e configurazione su Debian/Ubuntu

Preparazione VPS

• Scegli una distribuzione moderna: Debian 12 bookworm o Ubuntu 22.04 LTS.
• Aggiorna sistema con apt update; apt upgrade.
• Crea un utente senza privilegi root per il servizio; configura sshd con chiavi.
• Disabilita le password SSH, attiva fail2ban o equivalente.
• Abilita UFW o nftables: consenti 22/TCP, 443/TCP, porta Shadowsocks locale (es. 8388/TCP) solo da localhost.

Installazione Shadowsocks

Consigliato shadowsocks-rust per prestazioni e supporto AEAD moderne. Configura server su 127.0.0.1 con porta tipo 8388. Usa cifratura 2022-blake3-aes-128-gcm o 2022-blake3-chacha20-poly1305 a seconda di CPU e client. Genera segreti casuali di almeno 16 byte.

Installazione ShadowTLS v3

Usa implementazione compatibile v3 e col tuo stack client (sing-box o server binario separato). Avvia su 0.0.0.0:443. Configurazioni: protocollo v3, password condivisa (16-32 byte), SNI target, ALPN (di solito http/1.1; h2 se sicuro). Proxy verso Shadowsocks locale 127.0.0.1:8388.

Systemd e riavvii

• Crea unit per entrambi i servizi con Restart=always e limiti su memoria/CPU.
• Logga solo eventi chiave; evita log dettagliati di traffico per ridurre rischio fuga metadata.

Ottimizzazioni di rete

• sysctl: abilita TCP_FASTOPEN, aumenta net.core.rmem_max e wmem_max, ottimizza tcp_fin_timeout, abbassa tcp_syn_retries secondo rete.
• Imposta MTU corretto sulle interfacce; evita frammentazione.
• Se usi WireGuard per inter-server, usa porta non standard e permette solo peer noti.

Verifiche

• Porta 443 ascolta e accessibile da internet.
• Porta Shadowsocks locale non accessibile esternamente (solo 127.0.0.1).
• Log privi di segreti.
• Server si riavvia correttamente ed entra in autostart.

Pratica 4. Client: Windows, macOS, Linux, Android, iOS

Principi di configurazione

• Tipo proxy: Shadowsocks con trasporto ShadowTLS v3.
• Server: tuo IP:443.
• ShadowTLS: versione v3, stessa password server, SNI dominio scelto, ALPN come server.
• Shadowsocks: metodo 2022-blake3-aes-128-gcm o chacha20-poly1305-2022; password identica server.

Windows

Nel mondo Windows sono diffusi v2rayN e mihomo con supporto ShadowTLS come trasporto. Aggiungi server Shadowsocks, seleziona trasporto ShadowTLS v3, indica SNI e password. Attiva proxy di sistema se serve, oppure usa modalità TUN per routing trasparente.

macOS

Funzionano client GUI sing-box e build compatibili Clash. Configura Shadowsocks base, ShadowTLS v3 come trasporto, porta 443, SNI corretto. Per Safari e app con estensioni di rete usa proxy di sistema o tunnel di rete.

Linux

sing-box in modalità daemon: crea config con outbound shadowsocks e trasporto shadowtls. Configura policy routing per sottoreti e domini da proxy. Per browser usa PAC o proxy ambiente. Importante: configura ulimit e sandboxing systemd correttamente.

Android

App con supporto Shadowsocks e ShadowTLS (es. sing-box Android) permettono profilo: server, porta 443, password ShadowTLS e SNI. Attiva modalità VPN in app, aggiungi eccezioni per app bancarie se necessario.

iOS

Client con ShadowTLS v3 tramite Shadowsocks sono disponibili in alcuni store regionali. Configurazione identica: inserisci server, porta, password ShadowTLS, SNI e metodo cifratura Shadowsocks. Attiva On-Demand e regole Wi-Fi/Cellular per bilanciamento.

Verifiche client

• Controllo DNS: risolvi dominii preferibilmente via trasporto sicuro (DoH/DoT) dentro proxy o localmente con liste. Evita fughe DNS.
• Test di accessibilità: verifica risorse bloccate e stabilità sessione.
• Traceroute: conferma RTT e jitter coerenti col percorso al server.

Pratica 5. Testare credibilità e robustezza

Metriche di successo

• Percentuale handshake riusciti: almeno 99% con canale stabile.
• RTT handshake TLS medio entro 2x rispetto accesso reale a SNI nella tua rete.
• Distribuzione dimensioni primi N record applicativi simile a sessioni HTTPS normali per SNI scelto.
• Nessuna o minima presenza di iniezioni RST e pochi FIN imprevisti.

Strumenti di diagnostica

• Sniffer pacchetti su server e client filtrati per IP e porta 443; analizza ClientHello, ServerHello, ALPN, timing.
• Script per confrontare distribuzioni dimensioni pacchetti tra tue sessioni e riferimento SNI.
• Verifiche accessibilità da reti diverse: mobile, cablate, con DPI aziendale.

Test di carico

Crea un profilo con più flussi TCP paralleli che simulano attività browser. Evita flussi continui tutti uguali subito dopo handshake, aggiungi pause e padding. Valuta stabilità a perdita pacchetti 1%, 3%, 5% e varia MTU.

Pratica 6. Ottimizzazione e camuffamento comportamentale

Padding e frammentazione

Aggiungi padding casuale nei primi record applicativi per avvicinare il profilo ai siti web normali. Evita dimensioni fisse. Se serve, frammenta record grandi in porzioni medie con intervalli 5-20 ms.

Limite al parallelismo

Imposta limiti per connessioni simultanee per client e limita il ramp-up di connessioni. Connessioni troppo rapide sono indizio di proxy automatici.

Scelta ALPN

Se SNI reale usa spesso http/1.1 non forzare h2 e viceversa. Incoerenze producono impronte rare e riconoscibili.

Stack TCP

Configura congestion control (es. BBRv2 se utile) e buffer adeguati per ridurre retry e timeout rendendo il comportamento naturale. Nota: BBR modifica profilo traffico; verifica non ti evidenzi rispetto al canale locale tipico.

Pratica 7. Sicurezza operativa e rotazione

Gestione segreti

Conserva password ShadowTLS e chiavi Shadowsocks in secret manager. Cambia se compromessi o leak. Non trasmettere in chiaro. Evita segreti identici su nodi diversi.

Rotazione SNI e porte

Se vedi degrado (aumento RST, calo handshake, aumento latenza o anomalie DPI) valuta cambio SNI. Rotazione porte meno preferita; mantieni stabile 443. Cambia IP solo se in blacklist o bloccato direttamente.

Monitoraggio

• Raccogli metriche aggregate: sessioni, errori, distribuzione dimensioni record, percentili RTT.
• Conserva dati senza PII e senza raw packet.
• Imposta alert per deviazioni.

Aspetto legale ed etico

Verifica legislazione locale e policy provider. Usa tecnologia per privacy legale e accesso. Non abusare delle infrastrutture né per attività illecite.

Errori comuni

• Mancata corrispondenza versioni: client su v3, server su v2 o viceversa.
• Password ShadowTLS errata: server non conferma, DPI rileva anomalie e retry attivi.
• SNI bloccato localmente: il camuffamento perde senso.
• Porta Shadowsocks aperta esternamente: sondaggio attivo scopre il servizio subito.
• ALPN non corrispondente sito reale: combinazioni rare, impronte identificabili.
• Lunghezze record fisse senza padding: facilmente profilabili.
• Assenza monitoraggio: degrado non rilevato fino al blocco totale.
• Segreti prevedibili: aumentano rischio attacchi e leak.

Strumenti e risorse

Diagnostica TLS

• openssl s_client per test ALPN, catena certificati e parametri base TLS SNI simulato.
• Sniffer pcap per analisi ClientHello, ServerHello e primi record applicativi.
• Script per analisi distribuzione dimensioni pacchetti e intervalli.

Stack client

• sing-box: supporto integrato ShadowTLS v3 e Shadowsocks, regole di routing flessibili.
• mihomo e Clash-compatibili: ampia ecologia di client GUI.
• Shadowsocks-rust: server e client performanti con AEAD moderni.

Consiglio infrastrutturale pratico

Se gestire server da solo è complesso o vuoi testare rapidamente ipotesi su piattaforme e protocolli diversi, considera vpn.how come opzione funzionante di server personale per bypassare DPI. Il metodo è rilevante quando serve IP dedicato senza condivisione con altri client per minimizzare blacklist e per scegliere protocollo adatto alla rete. Punti chiave: VPN personale con IP unico, supporto WireGuard, OpenVPN, IKEv2, L2TP, SSTP, configurazioni resistenti a DPI (es. WireGuard su porte non standard, IKEv2 su 4500), server a Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San José, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenaghen, Stavanger, soluzioni no-log, avvio server in circa 5 minuti dopo pagamento, pagamenti con carte russe (inclusi Tinkoff, Ozon), SBP e criptovalute USDT o BTC, prezzi da 490 ₽ al giorno e da 2490 ₽ al mese con sconti per periodi lunghi. Se serve pieno controllo del profilo traffico un IP personale con porte e protocolli configurabili dà più libertà per adattarsi alle tolleranze della rete e ai modelli DPI.

Casi e risultati

Caso 1. Operatore con iniezioni aggressive RST

Situazione: traffico verso subnet VPS note con profili TLS non standard veniva sistematicamente interrotto con RST dopo 1-2 RTT, specialmente con ALPN insoliti. Soluzione: ShadowTLS v3 su 443 con SNI grande CDN, ALPN http/1.1, padding primi due record applicativi, limite parallelismo 4. Shadowsocks interno con 2022-blake3-aes-128-gcm. Risultato: sessioni riuscite da 70-80% a 99,7%, RTT handshake stabile a 120-150 ms, iniezioni RST praticamente scomparse.

Caso 2. Sondaggio attivo su 443

Situazione: IP sottoposto a tentativi attivi di stabilire sessioni TLS con ClientHello atipici. Senza segreto ShadowTLS corretto server chiude la connessione come HTTPS normale, senza segnali interni. Soluzione: rotazione segreti ogni 90 giorni, monitoraggio handshake falliti, limitazione frequenza connessioni nuove. Risultato: sondaggi con rilevamento proxy a zero in 60 giorni, nessun blocco IP.

Caso 3. Rete aziendale con whitelist

Situazione: solo traffico SNI selezionato autorizzato in uscita, tutto il resto filtrato. Soluzione: ShadowTLS v3 con SNI di dominio pubblico noto, ALPN e profilo comportamento coordinati, traffico interno limitato in velocità e frammentato in richieste piccole per simulare traffico web. Risultato: connessioni stabili, nessun falso positivo. Larghezza banda diminuita del 10-15% per frammentazione, ma accesso garantito.

Caso 4. Reti mobili con alto jitter

Situazione: variazioni elevate di ritardo e perdite causavano cadute sessioni. Soluzione: ottimizzazione buffer TCP, passaggio a chacha20-poly1305-2022 per client mobili ARM, padding adattivo con tolleranze dimensione, parallelismo ridotto a 2. Risultato: stabilità migliorata, picchi throughput smussati; cadute sessioni scese da 12% a 1,5%.

FAQ

Perché ShadowTLS v3 è meglio di obfs-tls o simple-tls

L'offuscamento cifra e altera header, ma spesso lascia pattern TLS riconoscibili facilmente bloccati via JA3/JA4. ShadowTLS v3 punta a un handshake e comportamento credibili, imitando un HTTPS reale e resistente a sondaggio attivo senza segreto.

Posso usare porta non standard tipo 8443

Sì, ma 443 è sempre più naturale. Porte alternative vanno bene se non c’è filtraggio di porta e l’SNI scelto le usa comunemente, scenario raro. Regola generale: 443/TCP.

Con quale frequenza cambiare SNI

Se le metriche sono buone, non cambiare. Motivi per rotazione: aumento handshake falliti, più RST, peggioramento latenza verso tuo IP, anomalie DPI. Solitamente qualche mese o a eventi mirati.

Quali metodi Shadowsocks sono meglio oggi

La serie 2022-blake3 (aes-128-gcm e chacha20-poly1305) offre performance e sicurezza moderne. La scelta dipende da accelerazione hardware AES-NI e classe CPU client.

Cosa fare se server risponde troppo veloce o lento

Risposte troppo rapide con RTT alto sembrano sospette. Aggiungi ritardi e padding. Se lente, verifica routing, CPU overload, MTU e perdite.

Posso inviare tutto tramite ShadowTLS, non solo Shadowsocks

In teoria sì, ma in pratica è più semplice e affidabile usare Shadowsocks internamente come layer, visto che ecosistema client e regole routing sono più mature.

ECH aiuta?

Encrypting ClientHello (ECH) riduce visibilità SNI, ma la sua diffusione non è ovunque completa e può essere bloccata selettivamente. ShadowTLS mira a imitare l’intera connessione verso sito reale in modo credibile. Insieme le due tecniche possono rinforzarsi, ma dipendono dal supporto client-server.

Come capire se sto subendo sondaggio attivo

Osserva anomalie: picchi di connessioni brevi con ClientHello diversi, tentativi regolari da più IP, geografie insolite IP uscita. Registra metriche aggregate, non dati grezzi per non conservare metadata inutili.

Come scegliere SNI: uno o più domini

Un dominio affidabile è più semplice da mantenere e monitorare. Più SNI offrono flessibilità e riducono rischio blocchi, ma complicano configurazioni e rotazioni. Parti con uno, poi aggiungi riserve se serve.

Problemi con alcuni proxy aziendali

Proxy aziendali possono fare MITM TLS con sostituzione certificati. In queste reti qualsiasi TLS non fidato può fallire. Soluzione: uscire evitando MITM aziendale o usare canali approvati dalle policy.

Conclusione

ShadowTLS v3 insieme a Shadowsocks è un metodo maturo e pratico per imitare credibilmente traffico HTTPS e contrastare le tecniche DPI moderne: firme JA3/JA4, euristiche comportamentali, sondaggio attivo e iniezioni RST. Il successo si basa su tre pilastri: scelta corretta di SNI e ALPN coerenti col sito reale, configurazioni precise server e client con proxy interno e tuning attento del comportamento (padding, frammentazione, limiti parallelismo). Importante anche la gestione operativa: monitoraggio metriche, rotazione prudente di segreti e domini, aggiornamenti puntuali e verifica configurazioni rete. Se affronti la sfida come un progetto ingegneristico con misure e feedback, la combinazione funziona stabile e a lungo. Passi successivi: scegli SNI con checklist, configura un server test, imposta client su più piattaforme, raccogli metriche di base e fai test di carico. Poi introduci gradualmente tuning e tieni d’occhio stabilità nelle reti target. Otterrai un’infrastruttura solida, difficilmente distinguibile da un HTTPS normale, pronta per le prossime evoluzioni nella corsa tra rilevamento e camuffamento.