La crittografia HTTPS su un sito impedisce alla NSA di sapere che hai visitato il suo dominio / l'URL?

11

Il motivo per cui chiedo se HTTPS protegge i metadati della tua attività Internet da un'entità di intercettazione telefonica sul backbone come NSA o meno, è il seguente scenario:

Supponiamo che io stia sfogliando https://xsite.com/page.html crittografato e invii una libreria javascript non crittografata a http://ysite.com/library.js o immagine esterna a http://ysite.com/image.jpg .

La richiesta GET per questa richiesta cross-site passa sull'URL della pagina crittografata che visito al server ysite.com non crittografato, e quindi, se blocco la richiesta cross-site utilizzando un componente aggiuntivo del browser come RequestPolicy , impedirò alla NSA di sapere che il mio indirizzo IP ha visitato https://xsite.com/page.html (o anche il dominio xsite.com interamente)?

Oppure, tale preoccupazione per la privacy è un punto controverso, dal fatto che HTTPS non nasconde di fatto (a un backbone wiretapper) che il tuo indirizzo IP ha visitato https://xsite.com (o anche /page.html ), comunque ?

    
posta 08.01.2015 - 11:52
fonte

4 risposte

14

Does the GET request for this cross-site request pass on the URL for the encrypted page I am visiting to the unencrypted ysite.com's server

No. ysite.com non conoscerà l'URL della pagina che stai visitando. xsite.com non verrà visualizzato su nessuna richiesta effettuata su ysite.com.

if I block such a cross-site request using a browser add-on like RequestPolicy, I will prevent the NSA from knowing that my IP address visited https://xsite.com/page.html (or even the domain xsite.com entirely)?

Tutti sapranno di aver visitato xsite.com poiché HTTPS non crittografa il nome host. Questo perché è necessario il nome host per impostare la connessione. Tuttavia, non sarà possibile stabilire se hai visitato page.html o page2.html poiché il percorso verrà crittografato.

Tuttavia, se la NSA sa che http://ysite.com/image.jpg è incorporato solo su page.html e di recente hai effettuato una query DNS e sei connesso a xsite.com , possono indovinare che probabilmente hai visitato https://xsite.com/page.html .

Modifica: la lunghezza approssimativa del percorso URL è visibile a tutti gli intercettatori. Pertanto, se xsite.com ha solo poche pagine, potrebbe essere anche possibile per un utente malintenzionato indovinare quale pagina stai visitando.

Risorse aggiuntive sull'analisi del traffico HTTP: Gli URL vengono visualizzati durante le transazioni HTTPS su uno o più siti Web da un singolo IP distinguibile?

    
risposta data 08.01.2015 - 12:44
fonte
7

Sì e no . Per capire perché, dobbiamo guardare al modo in cui Internet è strutturato.

Internet non è costituito da un singolo protocollo, ma da un numero di protocolli che si sovrappongono l'un l'altro . Puoi classificare i protocolli in base a dove si inseriscono nello stack e i temi che emergono quando lo fai sono chiamati layers .

Ci sono due modelli in competizione per come funziona, e parlerò brevemente del livello più basso del modello OSI: questo non è il modello che usano gli utenti IP, ma ci offre alcune basi interessanti. Il livello più basso, secondo la gente dell'OSI, è il livello fisico : la cosa reale che usi per inviare segnali. È probabile che lo strato fisico in uso al momento sia "un filo di rame" o "onde radio", ma ce ne sono altri: in passato le persone hanno usato cavi in fibra ottica, onde sonore, raggi laser e così via. . Come uno scherzo del pesce d'aprile, qualcuno ha persino escogitato un modo per farlo con i piccioni viaggiatori, e anche se non è qualcosa che qualcuno vorrebbe usare, funziona davvero.

Il modello più basso usato dal popolo TCP / IP (il secondo più basso nel modello OSI) è chiamato link layer . Il livello fisico ci fornisce una connessione diretta tra due macchine, ma non dice nulla su come ottenere un segnale attraverso quella connessione: questo è ciò che lo strato di collegamento è per Ethernet è un protocollo di livello di collegamento comune oggigiorno per le macchine che sono connesso in modo permanente via cavo e Wi-Fi (che è derivato da Ethernet) fa la stessa cosa per le onde radio. Al giorno d'oggi, PPP è il protocollo più popolare per i modem a livello di collegamento. Esistono anche altri protocolli di livello link.

Ma ciò che è veramente interessante per questa domanda sono il secondo e il terzo livello . Il secondo livello è chiamato livello di rete o livello Internet (notare il piccolo I ; non è la stessa cosa di Internet). Qui vivono i segnali che cercano di ottenere un segnale tra due macchine che non sono direttamente connesse, usando una catena di macchine che sono direttamente connesse. IP, il protocollo Internet, vive in questo livello; è da dove provengono gli indirizzi IP.

Il terzo livello - il livello di trasporto - è dove smettiamo di parlare di segnali e iniziamo a parlare di dati: dato il segnale, iniziamo a fare qualcosa di coerente da esso. Se hai sentito parlare di TCP e UDP, è qui che vivono: TCP ti consente di collegare i pacchetti in sessioni, mentre UDP è un protocollo di livello più basso per le volte in cui l'infrastruttura TCP non è realmente necessaria. Il compito del livello di trasporto è quello di far dialogare gli host su entrambe le estremità della connessione in modo coerente.

Il quarto livello - il livello di applicazione - è dove si svolge la maggior parte dell'azione eccitante: si basa sull'infrastruttura del livello di trasporto per realizzare ciò che in genere si pensa come attività di rete. HTTP, il protocollo su cui il Web è costruito, vive in questo livello; così come i protocolli di trasferimento file FTP e BitTorrent, il trio di protocolli e-mail SMTP / POP / IMAP, il protocollo di chat IRC e molti altri.

TLS (e il suo predecessore SSL) vivono nel livello di trasporto . TLS ottiene persino il suo nome da lì: Transport Layer Security. Fornisce un'infrastruttura comune per i protocolli a livello di applicazione, come HTTP, per comunicare tra loro e, per questo, funziona bene.

Poiché TLS crittografa l'HTTP, protegge (teoricamente) i dati come l'URL. Tuttavia, tu continui a fare quella richiesta, incluso l'indirizzo IP del server che ti connetti a tramite IP, e TLS vive troppo in alto nello stack per crittografarlo . Quindi, se richiedi un sito dallo stesso host su cui si trova il sito, la NSA (o qualche altro agente) potrebbe capire l'host a cui ti stavi connettendo guardando ciò che stavi inviando nel livello Internet. Non possono ottenere il resto dell'URL, perché sono gestiti all'interno di HTTP (che TLS crittografa), ma potrebbero ottenere l'host.

Se stai utilizzando il tunneling HTTP, puoi in parte aggirare questo . Se tunnel una connessione HTTP attraverso un'altra connessione HTTP, non ti connetti direttamente a xsite.com o ysite.com: invece ti connetti a zsite.com, dì che vuoi collegarti a questi altri luoghi, e renderà la richiesta per te. Poiché il tunneling HTTP risiede in HTTP, TLS lo proteggerà: l'NSA potrebbe rilevare che sei connesso a zsite.com, ma non sarebbero in grado di dire nient'altro, compresi i siti a cui hai chiesto a zsite.com di connettersi. Certo, alla fine si prenderanno cura di te e inizieranno a guardare cosa fa zsite.com, ma prima devono notarlo.

Niente di tutto ciò entra nella praticità di rompere TLS. Sto solo provando a dare una panoramica di ciò che TLS può proteggere (a patto che regge), e cosa non può proteggere anche se funziona perfettamente.

    
risposta data 08.01.2015 - 22:28
fonte
2

No

Se accedi a un javascript esterno via HTTP, allora la NSA può man-in-the-middle la tua richiesta per questo javascript, e serve una versione compromessa, che trasmette le tue informazioni a loro, o peggio .

Tuttavia, esiste la possibilità che venga scoperto un attacco come questo, in modo che decidano se usarlo in base al valore delle informazioni che speravano di raccogliere e alla probabilità che il bersaglio rilevi l'attacco.

Per obiettivi di alto valore, potrebbero anche impiegare altre tecniche, come ad esempio:

  • Installazione di apparecchiature di sorveglianza, presso i tuoi locali o su xsite.com
  • Utilizzo delle vulnerabilità di sicurezza per accedere ai tuoi sistemi o a xsite.com, possibilmente dalla loro libreria di zero-giorni, o forse perché uno di voi non ha protetto i tuoi sistemi
  • Rilascio di un certificato SSL falso e collegamento della connessione a xsite.com - ad esempio, utilizzando una CA compromessa
  • Invio di una talpa per infiltrarsi in xsite.com o ricattare un dipendente esistente per servirli
  • Tecniche classificate e non ancora trapelate
  • Ti picchia con un sacco di maniglie finché non dici loro quali siti hai visitato
risposta data 08.01.2015 - 18:20
fonte
1

Qualcuno pacchetto che sniffing il tuo traffico non vedrà il nome host che hai richiesto con HTTPS. HTTPS non è altro che la semplice crittografia dell'intero socket utilizzando TLS. Una volta completato l'handshake TLS, nulla viene inviato in testo normale su quel socket (a meno che, per qualche strano motivo, TLS lo negozi). Tuttavia, vedranno l'indirizzo IP e il numero di porta a cui viene inviata la richiesta . E, da lì, di solito è banale determinare chi lo possiede. Inoltre, solo un singolo nome di dominio può utilizzare HTTPS su una determinata combinazione di indirizzo IP e numero di porta, in modo che siano in grado di determinare il nome di dominio che hai visitato, nonostante non sia in grado di annusarlo dal filo. Potrebbero, naturalmente, averlo annusato anche nella richiesta di ricerca DNS A non crittografata (e nella risposta corrispondente) inviata dal browser prima di iniziare la connessione HTTPS. In breve: HTTPS (e TLS in generale) protegge solo la riservatezza, l'integrità dell'origine e l'integrità dei dati della vostra comunicazione. Non rende anonima la tua comunicazione. Infatti, è progettato per, almeno opzionalmente, fare esattamente l'opposto di quello utilizzando i certificati per eseguire l'autenticazione reciproca del server e del client.

Come risolvere questo problema: utilizza Tor . Tor è progettato per fornire sia la riservatezza che l'anonimato.

    
risposta data 08.01.2015 - 22:24
fonte

Leggi altre domande sui tag