Problemi risolti

Come già precedentemente indicato, la fase 2 si è resa necessaria per poter arginare i problemi insorti nella fase 1, illustrati nel capitolo 4.1.3.

Si esporrànno di seguito, in modo dettagliato, i singoli punti critici di Webidence 1.0 precedentemente illustrati e come i nuovi approcci adottati da Webidence 2.0 abbiano risolto ognuno di essi.

Indeterminatezza

Se in Webidence 1.0 il contenuto visionato a schermo in fase di attività poteva non coincidere perfettamente con quanto successivamente il sistema andava in effetti ad acquisire, questo non accade nella versione 2.0 in quanto l'acquisizione risulta già essere attiva in background nel momento stesso in cui l'operatore effettua la visione dei contenuti che in conclusione andrà a finalizzare. Questo accorgimento rende di conseguenza ogni contenuto puntualmente omogeneo con quello effettivamente visionato e del quale si richiede l'acquisizione.

Alterazione dei sorgenti

In Webidence 1.0 era necessario introdurre delle alterazioni nel codice della pagina per forzare le singole risorse a puntare verso i server ospitanti che svolgevano da proxy intermedio. In Webidence 2.0 non vi è più la necessità di introdurre codice nelle pagine fruite in quanto tutto viene realmente visionato all'interno di un browser eseguito in un processo indipendente che risiede sul server, e il rendering viene inviato al browser dell'utente con uno streaming costantemente.

Video capture

Non essendo (ad oggi) possibile ottenere una condivisione dello schermo in maniera nativa su tutti i browser, presentandosi in alcuni casi la necessità di installare plugin aggiuntivi, risultava arduo (se non impossibile) creare una registrazione video della sessione di acquisizione che documentasse la “strada” e le azioni compiute dall’utente per raggiungere la risorsa di interesse.

Inoltre, sia che si facesse uso del supporto nativo a “WebRTC Sharing Screen” che tramite plugin aggiuntivi, risultava comunque necessaria la corretta azione di scelta da parte dell'utente. Proprio questa richiesta di interazione avrebbe potuto introdurre errori operativi, con il relativo rischio di rendere inutile la prova video.

Poiché lo scopo del progetto è anche quello di creare uno strumento che guidi l'operatore verso una corretta acquisizione in modo agevole, completo e sicuro, la presenza di una scelta così delicata e non gestibile si è ritenuto che fosse troppo “delicata” per essere lasciata nelle mani dell'utente.

Webidence 2.0 evita il presentarsi di questo ostacolo, in quanto tutto il processo esecutivo del meta-browser risulta essere residente sul server e così anche lo schermo virtuale dove esso viene renderizzato. Risulterà quindi sufficiente attuare una registrazione video di tale schermo virtuale per ottenere tutta l'attività di acquisizione correttamente registrata in un ottimale spazio asettico, privo di “perturbazioni” che potrebbero introdurre dannose imperfezioni.

Traffico di rete

Essendo Webidence 2.0 un sistema in esecuzione come processo autonomo su di un sistema server ospitante, risulta immediato risolvere il problema dell'intercettazione del

Massimiliano Dal Cero – Sistema server-side di acquisizione forense di contenuti Web asincroni

traffico di rete, in quanto ogni esecuzione genera un proprio traffico ben distinto e discriminabile facendo uso dello “User ID” (UID) con cui il processo è stato eseguito. In Webidence 1.0 questo aspetto non poteva essere realizzato in quanto tutta l'attività era separata su più punti:

• traffico generato dal client utente,

• traffico generato dal server durante la fase interattiva ed essa stessa suddivisa

ulteriormente in due direzioni, una dal server verso il Web e la seconda dal server verso il client,

• traffico generato dal server durante la fase di acquisizione non interattiva

Risultava sia difficile da implementare sia impossibile, oltre che inutile ai fini probatori:

• difficile, in quanto richiedeva la necessità di suddividere il tracciamento del

traffico nei 3 spezzoni distinti poc'anzi esposti

• impossibile, in quanto il traffico realmente generato dal client utente non poteva

essere totalmente messo sotto tracciamento, ma se ne poteva dare solo un estratto parziale

• inutile, in quanto l'attività di acquisizione era suddivisa in 2 fasi distinte:

1. l'operatore naviga tramite il meta-browser verso il contenuto di interesse e ne richiede l'esecuzione

2. il server mette in coda l'acquisizione che verrà effettivamente messa in esecuzione successivamente

Pertanto, tale suddivisione dell'attività comportava il rischio concreto che il tracciamento del traffico non avrebbe dato un risultato omogeneo, in grado di essere utili ai fini probatori.

Componenti client side

Il problema derivante dagli effetti collaterali causabili da componenti di terze parti installati sulla macchia client dell'operatore è per definizione aggirato dall'architettura adottata da Webidence 2.0. Se in Webidence 1.0 la fruizione del contenuto, in quanto formato da componenti HTML, poteva essere influenzata e/o bloccata da potenziali agenti software di sicurezza (antivirus, web filtering, ad-blocker, etc) residenti sul sistema dell'operatore, in Webidence 2.0 questo aspetto è del tutto arginato in quanto il

contenuto fruito dal client non comprende le reali componenti originali del sito remoto, ma la fruizione avviene tramite streaming binario e quindi, anche se il contenuto veicolato violasse le policy del sistema ospite, ciò non risulterebbe identificabile.

Complessità e sostenibilità

In Webidence 1.0 sono stati rilevati non pochi problemi per ottenere la piena (ma anche solo parziale) compatibilità verso determinati servizi comprendenti tecnologie poco amichevoli, se non proprio ostili, verso chiunque tentasse di frapporsi alla fonte originale.

Anche in questo caso, il problema è automaticamente arginato dalla fruizione tramite un vero browser (seppur limitato) senza nessuna mediazione intermedia che possa sollevare le eccezioni di quei servizi particolarmente pignoli.

Questo aspetto rende quindi anche lo sviluppo decisamente più sostenibile, sia qualitativamente che quantitativamente, permettendo di orientarsi verso il goal primario di generare uno strumento forense e non un sistema di “evasion” di navigazione.

Gestione certificati SSL/TLS per traffico HTTPS

Avendo la possibilità di gestire in autonomia la parte applicativa del meta-browser risulta potenzialmente possibile salvare la master key e la client random key TLS per poter permettere successivamente la decifrazione completa del traffico HTTPS acquisito tramite il tracciamento del traffico di rete.

Questo non era ovviamente possibile nella versione 1.0 in quanto non vi era la possibilità di gestire il client dell'utente, ne sarebbe pienamente prevedibile quale browser l'utente utilizzerà.

Questo tema ha però introdotto, in fase di implementazione, l’onere di trovare soluzioni originali, apportando di conseguenza un fattore di complessità che ha comportato la necessità di introdurre nuove valutazioni tecniche a quelle già sviluppate. Se ne parlerà maggiormente nel capitolo dedicato alla fase di implementazione, ma in sintesi sono stati considerati due approcci: 1) riscrittura completa su tecnologia differente o 2) introduzione di un modulo aggiuntivo avente come obiettivo quello di intercettare il traffico (e relative chiavi TLS) prima che questo arrivi al meta-browserr. Questo secondo aspetto cambierebbe quindi il ruolo del meta-browser rendendolo quindi un “mediatore” tra il nuovo componente introdotto e l'utente finale.

Massimiliano Dal Cero – Sistema server-side di acquisizione forense di contenuti Web asincroni