Questa è in realtà una configurazione piuttosto brutta. Stai diventando complicato al punto in cui ciò che vedi come difesa in profondità è in realtà una superficie di attacco extra. Ad esempio, l'utilizzo di una VPN sconfigge gli algoritmi di rotazione della guardia di Tor, che sono messi a punto per ridurre la possibilità di colpire sia una guardia maliziosa che di uscire allo stesso tempo.
Utilizzare i bridge quando non si viene bloccati dalla censura è anche una pessima idea Riduce la quantità di possibili punti di ingresso con cui ci si può fondere. I ponti sono così onnipresenti che ci sono possibilità che tu sia una delle uniche, se non le uniche, a usare quel ponte in un dato momento. Ciò rende gli attacchi alla correlazione del traffico molto più utili quando un avversario non deve demultiplexare le comunicazioni dalla guardia (o dal bridge) al nodo centrale. Pensaci in questo modo: se sei l'unico che usa il bridge, allora c'è qualche dubbio che il traffico che va dal ponte al nodo centrale non è tuo? Ora, se stai usando una guardia popolare, molto altro lavoro dovrebbe essere fatto per correlare quale flusso di traffico è tuo e che è solo rumore di altri utenti.
Inoltre, tu dici di cambiare frequentemente i ponti. Proprio come cambiare le guardie, questa è un'idea MOLTO CATTIVA. Il primo nodo nel circuito Tor dovrebbe essere longevo. Di fatto, Tor Project ha recentemente modificato i parametri di guardia per renderlo ancora più longevo, perché anche cambiare ogni pochi mesi era troppo veloce e rendere gli attacchi di sybil molto più facili. La loro modifica dei parametri per mantenere una singola guardia per un anno o più ha causato attacchi di sybil e altri tipi di attacchi di correlazione del traffico molto più difficili. Cerca nel blog del progetto Tor "parametri di guardia" per ulteriori informazioni sulla matematica che sta dietro.
I log sono mantenuti sulla tua VPN. Solo perché il servizio VPN afferma di non effettuare il log non significa che nemmeno il loro ISP upstream (che probabilmente è qualcosa come OVH) non lo sia. Se l'ISP upstream registra, cosa che certamente fa, allora l'affermazione che il tuo VPN non registra diventa moot.
L'uso di CCleaner è spesso abbastanza inutile. I moderni filesystem che sono file system di journaling (come ext4, jfs, ecc.) O filesystem copy-on-write (come NTFS, che è parziale di CoW, btrfs o zfs) non possono avere file o spazio libero cancellati in modo affidabile. Inoltre, molti formati di dischi rigidi virtuali VM sono comunque in CoW, quindi anche se si passa a FAT32 o qualcosa del genere, non si finirebbe per essere abbastanza inutile.
Anche l'uso non necessario di VM e RDP si aggiunge alla superficie di attacco. Inoltre, su tutti gli x86 e la maggior parte dell'hardware ARM, è piuttosto semplice montare attacchi di canale laterale da una macchina virtuale. Questi attacchi sono in grado di rilevare in modo affidabile quali frasi vengono digitate sull'host e possono anche rubare le chiavi dalla memoria di alcune applicazioni crittografiche non sicure. Gli attacchi che possono farlo in modo affidabile sono chiamati prime + probe, flush + reload e flush + flush, chiamati in ordine di furtività ed efficienza. Inoltre, le macchine virtuali espongono ancora hardware di basso livello all'ospite e le fughe banali non sono affatto rare.
Tutto sommato, la tua configurazione ti rende più facile sia per deanonymize dall'esterno, ma anche dall'interno, esponendo l'enorme superficie di attacco di RDP e VM. Vorrei molto, molto strongmente esortare a interrompere questa configurazione e utilizzare invece Tails, o anche solo Tor Browser su Debian.
Prima di provare nuovamente a fare qualcosa di simile (creando la tua configurazione complessa), prima formalizza il tuo modello di minaccia. Le informazioni sulla modellizzazione delle minacce online sono onnipresenti. Finché non lo fai, usare Tails è quasi sempre una scommessa sicura per l'anonimato.