Capire quali dati trasmettono i programmi di Windows 11 richiede di collegare ogni connessione alla sua applicazione e osservare il traffico di rete. Wireshark aiuta a filtrare pacchetti e sessioni; mitmproxy consente di esaminare HTTPS, con le dovute cautele.
TCPView di Microsoft Sysinternals associa gli endpoint TCP e UDP ai processi che li utilizzano e mostra gli indirizzi e le porte locali e remoti. In Windows 11, la schermata offre un punto di partenza per osservare le comunicazioni di un programma. Per leggere le richieste HTTP o HTTPS si possono affiancare altri strumenti, tra cui un proxy d’ispezione.
La verifica comincia da un confronto ripetibile. Si osservano le connessioni del PC senza interagire con l’app, poi si avvia il programma e si esegue un’azione precisa: aprire una schermata, per esempio, oppure aggiornare un elenco. Il confronto tra le righe iniziali e quelle comparse dopo l’azione aiuta a isolare l’attività associata all’uso dell’app rispetto a quella abituale di Windows.
Per rendere il test più chiaro, conviene annotare o fotografare la schermata iniziale, eseguire una sola azione e controllare quali righe appaiono o cambiano. Chiudere e riaprire il programma, quindi ripetere la stessa prova, permette di confrontare i risultati con quelli della prima esecuzione. Gli aggiornamenti automatici e le attività periodiche possono comparire anche durante l’osservazione. Va considerato anche il ruolo dei processi di supporto: l’app può affidare le connessioni a un servizio o a un componente condiviso. Di conseguenza, nella schermata di TCPView il processo associato può avere un nome diverso da quello mostrato nella finestra principale.
Windows 11: collegare le connessioni ai programmi
Le colonne di TCPView aiutano a seguire ogni connessione. Il nome del processo indica chi la possiede; protocollo e stato descrivono il tipo e la condizione del collegamento; gli indirizzi remoti mostrano l’endpoint raggiunto. Anche la porta remota può orientare l’identificazione del servizio. La porta 443, ad esempio, è comunemente usata per HTTPS.
Accanto agli indirizzi IP, i nomi di dominio osservati nelle richieste DNS aggiungono un’indicazione sul servizio contattato. L’indirizzo IP identifica l’endpoint raggiunto in quel momento, mentre protocollo, orari e frequenza aiutano a ricostruire se l’attività è occasionale o ricorrente. Sono metadati della comunicazione, utili per organizzare l’indagine. Cache DNS e DNS cifrato possono rendere più difficile collegare una connessione a una specifica richiesta DNS visibile.
Wireshark: filtrare pacchetti e sessioni
Wireshark cattura il traffico di un’interfaccia di rete e consente di esaminare i pacchetti. Per collegare un flusso all’applicazione che lo ha generato, si può coordinare la cattura con la prova eseguita in TCPView e confrontare gli indirizzi, le porte e gli orari. Wireshark non associa automaticamente ogni pacchetto al processo Windows corrispondente.
Per restringere ciò che si osserva, si può usare il filtro di visualizzazione dns per le richieste DNS, tls per i pacchetti TLS oppure tcp.port == 443 per il traffico TCP sulla porta 443. I filtri di visualizzazione selezionano i pacchetti mostrati dopo la cattura. Quelli di cattura agiscono invece sulla raccolta stessa e hanno una sintassi diversa.
Le richieste DNS permettono di leggere i nomi di dominio cercati. Nelle sessioni TLS si possono esaminare gli handshake e i dettagli disponibili; gli orari e le dimensioni dei pacchetti aiutano a ricostruire la sequenza delle attività. Quando la connessione HTTPS è cifrata, l’analisi può concentrarsi sulle caratteristiche del flusso e sui metadati visibili. Il nome di dominio può comparire in alcuni passaggi della connessione. Anche il volume e la frequenza del traffico offrono elementi utili per confrontare le diverse prove.
mitmproxy: ispezionare HTTPS con cautela
Per leggere richieste e risposte HTTP o HTTPS, mitmproxy può essere configurato come proxy tra l’app e il server. In una prova autorizzata si avvia il proxy sul PC, si imposta Windows o l’app perché lo utilizzi e si installa nel sistema il certificato CA generato da mitmproxy. In questo modo il client accetta i certificati usati per l’intercettazione. Quando il traffico passa dal proxy e l’app si fida del certificato, diventano leggibili elementi come il percorso della richiesta, le intestazioni e il contenuto del messaggio.
Il comportamento dipende dall’applicazione. Alcune app ignorano il proxy di sistema, usano un percorso di rete diverso oppure rifiutano il certificato attraverso controlli come il certificate pinning. In queste condizioni il traffico resta illeggibile o la connessione fallisce; per una verifica ordinaria non occorre aggirare i controlli. Un certificato CA installato consente di intercettare le connessioni che lo accettano: va quindi usato soltanto per prove controllate e rimosso al termine.
Per una verifica ordinata, si può procedere per gradi, ripetendo la stessa azione e aggiungendo uno strumento solo quando serve:
- Registrare le connessioni a riposo, avviare l’app e ripetere sempre la stessa azione.
- Usare TCPView per associare processi, indirizzi remoti, porte e stato delle connessioni.
- Aprire Wireshark quando occorre esaminare pacchetti, richieste DNS, TLS e tempi. La cattura può comprendere anche il traffico di altri programmi.
- Ricorrere a mitmproxy quando serve leggere richieste HTTPS e l’applicazione consente l’ispezione.
Ripetere confronti coerenti rende più semplice individuare connessioni inattese e attività frequenti in background. Da lì si può passare alle impostazioni di privacy e alle autorizzazioni di Windows, comprese quelle per posizione, microfono e fotocamera. Per i programmi desktop tradizionali, i controlli disponibili possono differire da quelli previsti per le app Microsoft Store.
