Rischi di usare HTTP quando mi fido della rete locale

Supponendo che la tua rete locale sia sicura, lo script kiddie / hacker medio con risorse minime non sarebbe in grado di attingere alla connessione anche quando si utilizza un semplice HTTP non criptato. Ciò non significa che l'HTTP semplice sia privo di rischi. I tuoi dati potrebbero ancora essere catturati e registrati o modificati liberamente da:

• Il tuo ISP e il tuo governo
• ISP e governi dei Paesi il tuo traffico viene instradato attraverso
• Chiunque sia in grado di lanciare un attacco di dirottamento della rotta BGP

E, naturalmente, uno dei precedenti potrebbe condividere i dati con terze parti di loro scelta, o anche dare a queste parti esterne l'accesso diretto al traffico di rete.

Alcuni esempi:

Alcuni ISP sono noti per iniettare JavaScript nelle pagine HTML. Potrebbe trattarsi di pubblicità o tracciamento aggiuntivi o notifiche personalizzate come nel caso di Comcast di recente.

Vivo in Finlandia e gran parte del traffico internet finlandese è diretto in Svezia. Nel 2009 la Svezia ha approvato una legge che consente all'agenzia svedese di intelligence FRA di monitorare tutte le connessioni Internet che attraversano il confine. Ciò significa che la Svezia è tecnicamente e giuridicamente in grado di utilizzare la sorveglianza di massa sugli utenti internet finlandesi. È stato inoltre segnalato che FRA collabora strettamente con NSA e GCHQ e probabilmente condivideranno i dati.

Nel 2013 la società di software di sorveglianza Hacking Team ha orchestrato un dirottamento BGP in collaborazione con il governo italiano e una società di hosting. I dirottatori di percorso simili potrebbero essere facilmente utilizzati per attingere alle connessioni HTTP da qualsiasi parte del mondo. I dirottamenti BGP o "perdite" non sono rari. L'account Twitter @bgpmon , tra gli altri, tiene traccia e segnala questi tipi di eventi. Spesso gli eventi sono attribuiti a errori di configurazione e errore umano, ma nella maggior parte dei casi non è possibile saperlo con certezza. Molto spesso i colpevoli sono singoli ISP in Cina o paesi simili, e non c'è alcuna garanzia che gli ISP stessi non siano l'obiettivo di un hack.

Oltre alla sicurezza, ci sono altri motivi per usare HTTPS. SPDY e HTTP / 2, che sono nuove versioni di HTTP con meno overhead, sono supportati solo su TLS nella maggior parte delle implementazioni. Molte tecnologie web JavaScript sono inoltre disponibili solo per i siti Web HTTPS, ad es. Service Workers e l'API Location.

A parte gli ostacoli tecnologici di ottenere un rubinetto sulle linee intercontinentali che potrebbero effettivamente leggere i dati, lo scenario che hai fornito è effettivamente possibile. Se utilizzi HTTP invece di HTTPS, i tuoi dati viaggiano come testo in chiaro da capo a punto, quindi il tuo ISP, chiunque si trovi in mezzo e l'ISP dell'host di destinazione può leggere o persino modificare i tuoi dati se lo desidera.

Il EFF ha un bel widget che specifica chi può vedere cosa con HTTP / S: link

HTTP è un protocollo intrinsecamente "fidato": contiene poca o nessuna sicurezza integrata. Ciò significa che è sensibile al seguente:

1. Monitoraggio del traffico Tutto ciò che viene trasmesso su HTTP può essere intercettato e letto da chiunque sia connesso a qualsiasi rete che si trova tra il dispositivo sorgente e il server di destinazione.
2. Reindirizzamento e manipolazione del traffico Con poco lavoro, il tuo traffico potrebbe essere reindirizzato a un server controllato da una terza parte senza che tu possa notare nulla. una volta che il traffico è stato reindirizzato, può essere letto ma anche modificato: qualcuno potrebbe inserire qualsiasi tipo di dati, incluso lo script, nello stream. A meno che tu non abbia un modo esterno per convalidare ciò che hai ottenuto tramite la connessione HTTP, non c'è modo di essere sicuri che provenga dalla sorgente "giusta".

Ci sono anche una varietà di attacchi meno ovvi che potrebbero essere eseguiti se usi abitualmente HTTP invece di HTTPS (come Attacco di reindirizzamento URL ).

Supponendo che un utente malintenzionato si trovi già nella rete wireless, è necessario sapere che è possibile sniffare anche le connessioni https utilizzando tecniche come sslstrip . La buona pratica per evitare questa tecnica è quella di creare tutti i segnalibri e le scorciatoie usando la stringa https:// all'inizio. Se si tenta di accedere direttamente a una pagina inserendo nella barra, ad esempio https://outlook.com , la connessione non può essere vittima di sslstrip. Se metti solo per esempio outlook.com senza usare il prefisso https puoi essere violato anche in una connessione SSL e i tuoi dati possono essere annusati in chiaro se un hacker esperto si trova sulla tua rete.

How sslstrip works?

Molti siti web utilizzano HSTS (Http Scrict Transport Security) che consistono fondamentalmente nel reindirizzare una semplice richiesta http a un https da proteggere. Ad esempio, puoi notare se inserisci outlook.com di un reindirizzamento e vedrai il sito con il lucchetto verde e utilizzando https. Ciò è dovuto al fatto che HSTS è configurato e altamente raccomandato per l'inserimento nei siti Web. Ma in questo scenario, c'è una richiesta a http ... che la prima richiesta è ciò che sslstrip prende per fare "la sua magia". L'attaccante che ha eseguito prima un MITM (Man in the middle), serve alla vittima la pagina in chiaro http e fa la connessione https al server reale. La vittima potrebbe notare che non c'è il blocco verde nella barra ... ma credimi, non te ne accorgi, quindi è molto efficace.

Alcuni siti come facebook non possono essere sslstripped perché da qualche tempo i browser hanno un elenco interno di alcuni siti che sono noti per usare https, quindi non importa se chiedi al brower per http://facebook.com , il browser chiederà direttamente a https://facebook.com quindi non c'è nessuna richiesta iniziale http e sslstrip non può funzionare. Ma non ci sono troppi siti nelle liste di quel browser ... Immagino che i siti dovrebbero pagare ai browser per essere in quella lista, non sono sicuro di questo. Quindi questo riguarda solo "grandi siti" come Facebook e altri che sono conosciuti in tutto il mondo.

Quindi, se l'hacker è già nella tua rete, è una questione di tempo per sniffare qualcosa di utile. Cerca di proteggere il tuo primo livello (per proteggere la tua rete da interruzioni). Se non è possibile e l'hacker è già in rete, usa sempre https:// sui tuoi segnalibri e scorciatoie ... fa la differenza ... credimi.

Ecco un video più esplicativo su sslstrip

La mia risposta preferita a questa domanda da WAHH:

eavesdroppers may reside:

1. On the user's local network
2. Within the user's IT department
3. Within the user's ISP
4. On the Internet backbone
5. Within the ISP hosting the application
6. Within the IT department managing the application

Stuttard, Dafydd; Pinto, Marcus. "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" (p. 169). Wiley. Kindle Edition.

In questa risposta, assumerò che i partner a cui l'OP, o l'obiettivo di comunicazione, ha una relazione commerciale, sia in rotta senza alcuna manomissione, o che sia un governo di quella località, è considerato affidabile. Ciò significa che, nell'esempio di banca, le seguenti parti sono fully trusted:

• La rete dell'OP e tutte le parti coinvolte in questo, ad esempio la sua famiglia.
• Il proprietario dell'OP, che ha accesso alle linee di comunicazione nell'edificio.
• L'ISP dell'OP e tutti gli ISP fino a, incluso l'operatore backbone.
• Qualsiasi agenzia governativa che opera nella sede dell'OP.
• L'istituto bancario Banks e tutti gli ISP fino a, compreso l'operatore backbone.
• Il proprietario delle banche, che può o non può avere accesso alle linee di comunicazione.
• La rete della banca e tutte le parti coinvolte in questo, ad esempio gli amministratori IT.
• Qualsiasi agenzia governativa operante nella sede della Banca.
• E infine, qualsiasi agenzia governativa che opera in qualsiasi paese che si sta dirigendo verso la località di destinazione, considerando che qualsiasi manomissione di qualsiasi router in rotta verso la località di destinazione NON è avvenuta, anche se su richiesta di tale governo.

Sulla sicurezza, suppongo anche che:

• Qualsiasi dispositivo di proprietà di OP è sicuro.
• Qualsiasi dispositivo di proprietà della banca è sicuro.
• Qualsiasi attrezzatura di proprietà del governo è sicura.

Il motivo per cui faccio queste ipotesi, è quello di isolare i casi in cui l'intercettazione o la modifica del traffico comportano un rischio per la sicurezza, piuttosto che essere solo una seccatura per l'utente. Se un governo annusa intenzionalmente il numero della carta di credito OP, non pone alcun rischio per l'OP, perché il numero della carta di credito non darà al governo alcun accesso maggiore, il governo potrebbe con una sola telefonata cogliere tutti i soldi dal conto OPs in ogni modo. Lo stesso con l'ISP, l'ISP che modifica il traffico per inserire pubblicità, non farà comunque alcun uso della password di Facebook di OPs.

Un'altra cosa importante è valutare se un'organizzazione è in grado di proteggere le proprie apparecchiature da aggressori esterni. Qui, presumo che l'OP sia ben informato e possa configurare i propri router e firewall in modo sicuro, quindi ho impostato le apparecchiature OP per garantire la sicurezza. Ciò significa che qualsiasi apparecchiatura di proprietà dell'OP non può essere compromessa da remoto. L'apparecchiatura delle banche è ovviamente configurata in modo sicuro. E le apparecchiature governative utilizzate per memorizzare dati intercettati o informazioni simili, sono ovviamente configurate in modo ancora più sicuro della banca.

Considerando questa valutazione di affidabilità, ciò significa che ci sono pochi vettori di attacco per attaccare HTTP su una rete cablata.

Gli unici vettori di attacco che riesco a vedere sono i seguenti:

• Intercettazione di collegamenti accessibili tramite pubblicità. Un esempio potrebbe essere l'ascolto dei segnali ADSL da un cablaggio telefonico aereo.

• Rottura e ingresso nelle sale delle apparecchiature locali. Ad esempio le sale attrezzature di proprietà dell'ISP o del proprietario. Ambienti di apparecchiature più grandi che servono un'area più ampia, normalmente hanno una protezione grave degli allarmi, guardie vicine se non sul posto e alta sicurezza, ma le sale delle apparecchiature locali sono spesso deboli di sicurezza, a volte un armadio rack chiuso in una cantina con cavi esposti che possono essere uniti e origliati senza influire sul blocco del cabinet del rack.

• Effettuare l'hacking in remoto su apparecchiature locali. Le apparecchiature per i proprietari di case più piccole sono spesso configurate in modo non sicuro con password errate, in alcuni casi ciò si applica anche alle apparecchiature ISP locali. Un router che l'OP ha assunto dall'ISP e che non ha alcuna capacità di amministrazione da parte del cliente, potrebbe anche essere sospetto per un semplice hacking.

• Intercettazione di collegamenti wireless con crittografia debole / non controllata che l'OP non può controllare. Questo può essere applicato a un collegamento point-to-point impostato da un ISP per il bridge di un'area difficile da instradare su qualsiasi cavo fisico. Questo può valere anche per determinati collegamenti mobili.

• Manipolazione del BGP annunciando le rotte per le reti che qualcuno non possiede. Questo è l'unico rischio che vale la pena considerare. Alcuni ISP possono anche utilizzare metodi che impediscono alle persone non autorizzate di annunciare la disponibilità delle reti degli ISP. Tali soluzioni di sicurezza possono includere, ma non sono limitate, la limitazione del traffico BGP da qualsiasi apparecchiatura di proprietà del cliente.

Oltre a ciò che alcuni degli intervistati hanno sottolineato, i siti più sicuri (ad es. sito web bancario, ecc.) non ti consentono nemmeno di accedere a contenuti protetti attraverso i loro siti tramite http. Quindi, l'uso di http non è nemmeno un'opzione con questi siti: devi usare https.

Puoi fiutare pacchetti HTTP usando strumenti come Wireshark ed è come una passeggiata nel parco per leggere i tuoi pacchetti di dati. Un utente malintenzionato può intercettare i pacchetti di dati, modificarli e inoltrarli. Ad esempio: chiedi alla tua banca di pagarti - l'attaccante modifica questo pacchetto e chiede alla banca di pagarlo.

Non capisco cosa intendi con

HTTP in your Wi-Fi network.

Non vuoi accedere al world wide web?