it-swarm.dev

Visitare i siti Web HTTPS su un hotspot pubblico è sicuro?

Si dice spesso che le connessioni HTTPS SSL/TLS siano crittografate e ritenute sicure perché la comunicazione tra il server e me è crittografata (fornisce anche l'autenticazione del server), quindi se qualcuno annusa i miei pacchetti, avranno bisogno di decine di milioni di anni per decrittografare se si utilizza brute forza in teoria.

Supponiamo che io sia su un wifi pubblico e che ci sia un utente malintenzionato sullo stesso wifi che annusa ogni pacchetto. Ora supponiamo che sto provando ad accedere al mio account Gmail usando questo wifi. Il mio browser esegue una stretta di mano SSL/TLS con il server e ottiene le chiavi da utilizzare per la crittografia e la decrittografia.

Se quell'utente maligno ha annusato tutti i miei pacchetti in entrata e in uscita. Può calcolare le stesse chiavi e leggere anche il mio traffico crittografato o persino inviare messaggi crittografati al server a mio nome?

148
Calmarius

HTTPS è sicuro su hotspot pubblici. Durante la configurazione di TLS , il livello di sicurezza utilizzato da HTTPS vengono trasmessi solo una chiave pubblica e messaggi crittografati (anch'essi firmati da certificati radice). Il client utilizza la chiave pubblica per crittografare un segreto master, che il server quindi decodifica con la sua chiave privata. Tutti i dati sono crittografati con una funzione che utilizza il segreto master e i numeri pseudo-casuali generati da ciascun lato.

Così,

  • i dati sono sicuri perché sono firmati dal segreto principale e da numeri pseudo casuali
  • i numeri master e pseudo-casuali segreti sono sicuri perché utilizza la crittografia della chiave pubblica-privata quando si verifica l'handshake TLS
  • la crittografia della chiave pubblica-privata è sicura perché:
    • le chiavi private sono mantenute segrete
    • la crittografia della chiave pubblica-privata è progettata per essere inutile senza la chiave privata
    • le chiavi pubbliche sono note per essere legittime perché sono firmate da certificati radice, che neanche
    • è venuto con il tuo computer
    • o sei stato specificamente autorizzato da te (fai attenzione agli avvisi del browser!)

Pertanto, le connessioni e i dati HTTPS sono al sicuro fintanto che:

  1. ti fidi dei certificati forniti con il tuo computer,
  2. ti occupi solo di autorizzare i certificati di cui ti fidi.
109
waiwai933

Risposta breve: dipende.

SSL/TLS stesso non è più vulnerabile su una connessione Wi-Fi pubblica, piuttosto che su Internet "normale". È stato progettato per essere utilizzato in canali aperti.

Tuttavia, ci sono alcuni altri aspetti da considerare:

  • Spesso gli utenti non accedono direttamente al sito HTTPS, iniziano dal sito HTTP e reindirizzano da lì. Ad esempio, vai a http://example.org/ e fai clic sul link Email, che ti reindirizza a https://mail.example.org/. Poiché la pagina HTTP originale non è crittografata, quell'utente malintenzionato può modificare il tuo traffico, causando il collegamento Email a NON reindirizzare a HTTPS, ma forse da qualche altra parte. Ad esempio, se fai clic sul link Email sulla home page di example.org, noteresti che ti porta a http://mail.exxxample.org/? (come esempio). Tu potresti, qualcun altro potrebbe non farlo.
  • Se l'utente dirotta la tua connessione, ma fornisce il suo falso certificato SSL anziché quello di example.org - il tuo browser lo farà mostra un errore, che il certificato non è valido. Tuttavia, la maggior parte degli utenti fa semplicemente clic su questo, consentendo all'attaccante di eseguire MITM sul tuo sito sicuro, tramite SSL.
  • Un altro aspetto da considerare, non dare per scontato che l'hotspot pubblico sia configurato in modo sicuro. Come questa domanda mostra , i router elaborati sono fin troppo comuni e possono causare molti più danni irrilevanti per il tuo SSL.
48
AviD

Una sessione interamente su HTTPS è abbastanza sicura, poiché tutte le richieste dal browser e le pagine trasmesse dal server sono crittografate.

Tuttavia, quando si accede tramite HTTPS, molti siti eseguiranno il passaggio di autenticazione solo su HTTPS, quindi torneranno a HTTP per il resto della sessione. Pertanto, la password stessa è sicura, ma l'ID sessione utilizzato dal server per identificarti per quella sessione viene trasmesso in chiaro dal browser. Ciò riduce il carico sul server web (poiché la crittografia/decodifica richiede molta CPU) ma rende il sito molto meno sicuro. Gmail è sicuro perché utilizza HTTPS per l'intera sessione, ma Facebook e molti altri siti no.

Ecco come strumenti come Firesheep sono in grado di dirottare gli account degli utenti quando un utente malintenzionato condivide una rete wireless non crittografata.

Puoi proteggerti da questo attacco sia usando una VPN per crittografare tutti i dati della sessione, sia usando solo reti che hanno una crittografia forte per utente come WPA-PSK (WEP usa la stessa chiave per ogni utente, e quindi non offrire protezione da questo attacco).

22
Alex Howell

Dal momento che le risposte sembrano essere ovunque (sì, no, potrebbe essere, dovrebbe essere), vorrei prima ribadire la risposta di @ waiwai933: è sicura.

Per essere precisi, hai chiesto: "Se quell'utente malintenzionato ha annusato tutti i miei pacchetti in entrata e in uscita. Può calcolare le stesse chiavi e leggere anche il mio traffico crittografato o persino inviare messaggi crittografati al server a mio nome?" La risposta è no e no. Con una nota a piè di pagina.

La ragione per cui non è in grado di calcolare le stesse chiavi sembra paradossale, e in effetti è stata una grande svolta nella crittografia quando è stata pubblicata per la prima volta da Diffie e Hellman. TLS utilizza un protocollo di scambio di chiavi, come Diffie-Hellman ma più sofisticato per proteggere dagli attacchi man-in-the-middle. Il protocollo consente a due persone che non hanno mai scambiato informazioni prima di calcolare una chiave segreta che nessuno può vedere.

Una volta che hai una chiave segreta condivisa, puoi usarla per crittografare il tuo traffico. Poiché l'utente malintenzionato non conosce la chiave, non può crittografare il traffico che sembra provenire da te.

Ora quelle note a piè di pagina.

  • Partiamo dal presupposto che il protocollo SSL/TLS sia corretto. Con la maggior parte dei protocolli crittografici coinvolti, i bug vengono rilevati e corretti di volta in volta. SSL/TLS ha avuto un bug recente (menzionato in alcune risposte come motivo per cui non è sicuro), tuttavia è stato temporaneamente risolto e ora risolto (RFC 5746) e la correzione è in varie fasi di spiegamento. (Nel tuo scenario, il bug consentiva a un utente malintenzionato di inviare pacchetti a tuo nome ma non di leggere il tuo traffico.) È sempre possibile che l'attaccante sappia come interrompere TLS/SSL a causa di un errore non pubblicato nel protocollo.
  • Un punto ovvio ma vale la pena ripeterlo: l'utente malintenzionato potrebbe vedere la tua richiesta e inviare la propria risposta utilizzando il proprio certificato. Quindi controlla il certificato.
  • Forse un altro punto ovvio: puoi essere sicuro che SSL/TLS verrà utilizzato per le pagine future se la pagina corrente è HTTPS. Ad esempio, se ti trovi in ​​una pagina HTTP che desidera che tu acceda e, per esperienza passata, sai che facendo clic sul pulsante di accesso ti reindirizzerà a una connessione HTTPS, questa funzionalità potrebbe essere rimossa da un utente malintenzionato attivo sulla tua rete. Quindi accedi solo a pagine che sono già HTTPS (a meno che tu non sappia come rilevare se la pagina di accesso è stata modificata).
13
PulpSpy

Se sei preoccupato di navigare in sicurezza verso alcuni siti su una rete non sicura, i passaggi migliori che puoi adottare per garantire la sicurezza sono:

  • Assicurarsi che il sito utilizzi HTTPS, non HTTP.

  • Assicurarsi che il sito abbia un certificato valido. Non fare clic sugli avvisi. Non accettare certificati non validi.

  • Usa HTTPS Everywhere o Force-TLS per assicurarti di utilizzare una connessione HTTPS (ovvero crittografata con SSL) per tutto ciò che riguarda quel sito.

2
D.W.

HTTPS è abbastanza resistente alla decrittazione dallo sniffing dei pacchetti. Tuttavia, il lato di autenticazione del server dipende da un metodo un po 'debole di distribuzione dei certificati CA e le CA non fanno molto in termini di verifica delle identità. Alcuni anni fa un certificato Microsoft era rilasciato a un impostore . Vedi Bruce Schneier articolo sull'argomento - in pratica, per i siti web del pubblico in generale, non abbiamo niente di meglio.

2
RedGrittyBrick

In pratica, SSL e TLS hanno entrambi dei problemi, ma sono legati al tipo di attacco Man in the Middle. Per un esempio di problema di rinegoziazione TLS MITM vedi qui

Naturalmente, questo attacco richiede che l'attaccante si trovi nel mezzo del percorso di comunicazione, il che limita un po 'la minaccia :-)

2
Rory Alsop

Interamente, in pratica. La crittografia inizia con le persone root ssl (Verisign, Thawte, ecc.) Ed è quindi adatta per linee non sicure. AFAIK TLS non ha alcun problema con gli attacchi man in the middle, sono solo le strette di mano più deboli/vecchie che hanno quel problema.

1
tobylane

La maggior parte sta dimenticando l'aspetto dell'utente e come potrebbe usare quel pc anche nell'hotspot. Molte persone usano password simili su altri siti, possono blog, ... ecc. quelli potrebbero non essere così sicuri come HTTPS/SSL gmail a cui potresti connetterti. Il problema che vedo dalla sicurezza molte persone andranno in altri siti esponendo un programma di sniffing dei pacchetti con informazioni sufficienti per accedere ad alcuni dei tuoi account. La cosa migliore è come detto se si utilizza una connessione wireless non crittografata, si spera che si abbia un VPN a cui è possibile connettersi dopo che aggiungerà ulteriore livello di sicurezza.

1
IrqJD

La connessione è abbastanza sicura per quanto riguarda le connessioni sicure (ssl). Fornito, se utilizzato con consapevolezza:

  • Non dovrebbe esserci reindirizzamento da HTTPS a HTTP
  • Alcuni siti utilizzano anche pagine cmd HTTP su HTTPS, non dovrebbero esserci informazioni sensibili trasmesse su di esse
  • Server https e browser obsoleti configurati sono ancora sfruttabili anche su socket sicuri
0
8zero2.ops