Utilizza HTTPS, TLS, S / MIME, SSL e.t.c. ti proteggono dall'analisi Deep Packet e dall'analisi dei Big Data?

L'ispezione approfondita dei pacchetti (DPI) è un termine che comunemente si riferisce agli utenti di rete standard, come i router di un ISP, che esaminano il contenuto a un livello di protocollo superiore al livello necessario per elaborare il pacchetto ( ispezionando così "più a fondo" nel pacchetto del necessario). Ad esempio, un router IP potrebbe dover solo guardare il livello IP (livello 3 nel modello OSI) del pacchetto, ma se ispeziona anche i dati del livello applicazione (livello 5/7), allora sta eseguendo un'ispezione approfondita dei pacchetti.

HTTPS (facendo riferimento all'ampia suite che hai menzionato) è un protocollo a livello di applicazione. Difenderà dall'analisi approfondita dei pacchetti che legge il contenuto del livello dell'applicazione, ma non contro DPI a livelli inferiori del protocollo di avvolgimento. Ad esempio, HTTPS non impedirà a DPI di guardare il pacchetto TCP e di esaminare la porta di destinazione per indovinare il protocollo a cui è destinato. Ma impedirà al DPI di apprendere il reale carico utile dei dati dell'applicazione del protocollo.

L'analisi dei Big Data fa riferimento all'analisi eseguita su database molto grandi di dati raccolti, ma il modo in cui tali dati vengono raccolti ha poco a che fare con HTTPS. HTTPS è progettato solo per proteggere i dati nel transito di rete, quando il server di destinazione nel protocollo HTTPS legge i dati, i dati vengono decrittografati e la protezione HTTPS non esiste più. Quello che succede a quel punto dipende da qualsiasi cosa il client e il server stiano utilizzando sopra HTTPS. Probabilmente, il server può fare praticamente tutto ciò che vuole a quel punto. (In altre parole, i Big Data generalmente si riferiscono a Data At Rest, mentre HTTPS protegge Data In Motion. Dal momento che affrontano diverse fasi dei dati, ha senso che la protezione in una fase non si applichi ai dati quando viene spostata in una fase diversa.)

Will transport layer encryption (SSL/TLS/https) prevent you from Big Data Analytics?

Dipende. Il server all'altra estremità usa i tuoi dati per l'analisi dei big data? Se non lo fanno, sei al sicuro dalle analisi dei big data. Se usi google / facebook / amazon, ecc. Stanno analizzando i tuoi dati (e potenzialmente condividendo con altre entità (come il governo USA / NSA)), stanno usando le analisi dei big data sulle informazioni che hai fornito.

TLS (e SSL è solo una vecchia versione di questo e HTTPS è solo HTTP + SSL / TLS) limita solo gli intercettatori della rete a conoscere solo quando , chi ( Indirizzo IP) e quanto dati stai inviando e ricevendo. (Ciò presuppone che non abbiano compromesso una CA oi certificati attendibili dei browser per un attacco sofisticato). Questa informazione limitata a volte è molto utile negli attacchi di canale laterale per dedurre quali informazioni private si stanno inviando ( specialmente se ci sono funzioni di auto-completamento ajax come suggerimento di google) .

Tuttavia, in generale, la crittografia di trasporto lascia solo vedere il tuo computer e i server https alla fine della connessione vedono i tuoi dati; anche se ogni computer è quindi libero di condividere quei dati con gli avversari da analizzare.

Per essere esplicitamente chiari, sì la crittografia del livello di trasporto impedisce al tuo ISP / altri intercettatori della rete da Deep Packet Inspection; con l'eccezione di vedere quando, chi e quanti dati crittografati si stanno inviando / ricevendo. Se sei paranoico anche su queste informazioni limitate, puoi delegare tutto il tuo traffico attraverso un tunnel / VPN / tor crittografato per nascondere quali siti / macchine web stai visitando, così l'ISP può solo scoprire quanti dati stai inviando al tuo proxy in qualunque momento. (Se l'ISP del server proxy è in grado di intercettare i siti visitati dai suoi server proxy e i computer collegati al server proxy.)

SonicWALL DPI-SSL è principalmente utilizzato in una rete gestita in cui gli amministratori possono controllare un'autorità di certificazione di root e quindi i client di sicurezza devono fidarsi del certificato firmato da SonicWALL nel mezzo.

Un esempio di questo sarebbe una scuola che estrae / costringe la ricerca sicura su Goolge (dato che ora usa https come predefinito) - senza questa ripartizione del pacchetto "man in the middle" l'utente potrebbe guardare qualsiasi cosa volesse e verrebbe segnalato solo come link .

In termini semplici, il cliente richiede al collegamento nel proprio browser: SonicWALL (come periferica Edge) inoltra quindi questa richiesta a Google per suo conto (quindi creando la connessione sicura tra Google - > SonicWALL) - SonicWALL quindi Firma nuovamente il traffico e lo indirizza al dispositivo interno corretto.

Questo può essere fatto solo se l'amministratore di rete ha accesso all'infrastruttura a chiave pubblica o alle stazioni di lavoro è stato detto di fidarsi del certificato sonicwallCA autofirmato.

In termini reali puoi verificarlo facendo clic sul lucchetto del tuo browser e verificando se si tratta di una terza parte attendibile o della tua azienda locale. Questo attacco sarebbe MOLTO difficile se non sei responsabile dell'infrastruttura di una rete.

In realtà esiste una quantità sorprendente di dati che possono filtrare attraverso una tipica connessione HTTPS.

Se il server TLS e il client sono aggiornati, i dati sono crittografati e sicuri, ma le dimensioni, i tempi e il numero di pacchetti e messaggi TLS all'interno dei pacchetti contengono informazioni interessanti. Prendi in considerazione il Bicycle Attack ; l'ordine e la lunghezza approssimativa delle intestazioni restituite dal server web potrebbero essere visibili nel flusso crittografato.

Gli aggressori osservanti, compresi i DPI che controllano i firewall incluso il Great Firewall, possono creare le proprie connessioni al server web di destinazione per ottenere il contenuto crittografato che non è univoco per un utente.

Ad esempio, chiunque può vedere la pagina di accesso del sito, anche se si dispone di TLS, perché è necessario mostrarlo agli utenti non autenticati.

Le pagine che rispondono agli eventi degli utenti inviando dati a un server, come la funzione di ricerca come tipo di google, possono esporre la velocità di battitura o i modelli dell'utente, che possono servire a identificarli.

E ovviamente ... Le informazioni DNS e proxy sono in genere al di fuori del livello HTTPS e possono esporre i siti e i client utilizzati.