Domanda:
La visita ai siti Web HTTPS su un hotspot pubblico è sicura?
Calmarius
2011-01-09 16:31:42 UTC
view on stackexchange narkive permalink

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

Supponiamo che io sia su un wifi pubblico e che ci sia un utente malintenzionato sullo stesso wifi che annusa ogni pacchetto. Supponiamo ora che stia cercando di accedere al mio account Gmail utilizzando questo wifi. Il mio browser esegue un handshake SSL / TLS con il server e ottiene le chiavi da utilizzare per la crittografia e la decrittografia.

Se quell'utente malintenzionato ha fiutato 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?

Penso che ciò sia appropriato, poiché la comprensione dei rischi di un tale ambiente rientra nelle competenze dei professionisti della sicurezza. Alcuni di noi hanno dovuto gestire hotspot pubblici all'interno di siti aziendali e alcuni hanno bisogno di lavorare da una varietà di posizioni, che possono includere hotspot pubblici.
Che mi dici di sslstrip? (http://www. Thoughtcrime.org/software/sslstrip/) Guarda anche [questo video] (http://bit.ly/1BylXv) su sslstrip
Da aggiungere alle risposte seguenti [dipende dalla sicurezza del sito web che stai visitando] (http://security.stackexchange.com/a/80363/8340) - [vedi anche i miei suggerimenti qui] (http: // sicurezza .stackexchange.com / a / 44976/8340).
Tieni presente che mentre i siti HTTPS possono essere sicuri in questo scenario, se in qualsiasi momento durante la tua sessione di browisng un sito HTTP viene mai caricato (anche in un iframe o scheda separata), un hotspot dannoso può sfruttarlo per rubare i tuoi cookie su _all_ popularsiti non HTTPS (anche quelli che non stai attualmente navigando) e installa backdoor per quei siti che persistono anche dopo che non sei più connesso all'hotspot dannoso: https://samy.pl/poisontap/ Quindi ... sì.
Undici risposte:
#1
+110
waiwai933
2011-01-09 16:51:24 UTC
view on stackexchange narkive permalink

HTTPS è sicuro sugli hotspot pubblici. Durante la configurazione di TLS, il livello di sicurezza utilizzato da HTTPS, vengono trasmessi solo una chiave pubblica e messaggi crittografati (e anche questi sono firmati dai certificati radice). Il client utilizza la chiave pubblica per crittografare un master secret, che il server decrittografa quindi con la sua chiave privata. Tutti i dati sono crittografati con una funzione che utilizza il segreto principale e numeri pseudo-casuali generati da ciascuna parte.

Pertanto,

  • i dati sono protetti perché sono firmati da il segreto principale e i numeri pseudo-casuali
  • il segreto principale e i numeri pseudo-casuali sono sicuri perché utilizza la crittografia della chiave pubblica-privata quando si verifica l'handshake TLS
  • la chiave pubblica-privata la crittografia è sicura perché:
    • le chiavi private sono tenute segrete
    • la crittografia con chiave pubblica-privata è progettata per essere inutile senza la chiave privata
    • le chiavi pubbliche sono note essere legittimi perché sono firmati da certificati di root, che sono
    • forniti con il computer
    • o sono stati specificatamente autorizzati da te (fai attenzione agli avvisi del browser!)

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

  1. ti fidi dei certificati forniti con il tuo computer,
  2. ti occupi di autorizzare solo i certificati di cui ti fidi.
Oh, dimenticavo che abbiamo sistemi di crittografia asimmetrica.
3. Assicurati che tutti i tuoi dati passino effettivamente su HTTPS (alcuni siti sono parzialmente crittografati e in parte no)
I miei bagni locali (Hillingdon, Regno Unito) restituiscono i propri certificati, quindi in realtà hai piena vista di ciò che invii, anche se viene mostrato l'https.Il 99,9% degli utenti non lo noterebbe.
Domanda: puoi chiarire come qualsiasi risposta dal server HTTPS potrebbe essere crittografata in modo tale che qualcuno che ascolta nel mezzo non possa interpretarla?L'unica chiave che il client ha è la chiave pubblica che è anche disponibile per l'ascoltatore / hacker.
@JoshG Il client ha anche una chiave privata, che solo loro conoscono.Questa è l'essenza della crittografia asimmetrica (coppia di chiavi pubblica / privata).Per decrittografare una risposta dal server, un uomo nel mezzo avrebbe bisogno della chiave privata del client.
#2
+48
AviD
2011-01-11 12:37:30 UTC
view on stackexchange narkive permalink

Risposta breve: dipende.

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

Tuttavia, ci sono alcuni altri aspetti da considerare:

  • Spesso gli utenti non navigano direttamente al sito HTTPS, iniziano dal sito HTTP e reindirizzano da lì . Ad esempio, navighi su http://example.org/ e fai clic sul link Email , che ti reindirizza a https://mail.example.org/ . Poiché la pagina HTTP originale non è crittografata, l'utente malintenzionato può modificare il tuo traffico, facendo sì che il link Email NON venga reindirizzato a HTTPS, ma forse da qualche altra parte. Ad esempio, se hai fatto clic sul collegamento Email sulla home page di example.org, noteresti che ti ha portato a http://mail.exxxample.org/ ? (come esempio). Tu potresti, qualcun altro no.
  • Se l'utente dirotta la tua connessione, ma fornisce il proprio certificato SSL fasullo invece di quello di example.org, il tuo browser lo mostra un errore, che il certificato non è valido. Tuttavia, la maggior parte degli utenti farà semplicemente clic su questo, consentendo all'attaccante di MITM sul tuo sito protetto, su 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 pwn sono fin troppo comuni e possono causare molti più danni irrilevanti per il tuo SSL.
Tutti i siti di Google sono a cura di HSTS. Meglio usare `example.org`.
@Pacerier sì, * ora *, non lo era :-) Anche i loro certificati sono per lo più bloccati (il mio secondo punto), quindi ... sì. Grazie!
#3
+22
Alex Howell
2011-01-09 17:11:23 UTC
view on stackexchange narkive permalink

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 solo il passaggio di autenticazione su HTTPS, quindi tornare a HTTP per il resto della sessione. Quindi, la tua stessa password è al sicuro, ma l'ID di sessione utilizzato dal server per identificarti per quella sessione viene trasmesso in chiaro dal tuo browser. Ciò riduce il carico sul server web (perché la crittografia / decrittografia richiede un uso intensivo della CPU) ma rende il sito molto meno sicuro. Gmail è sicuro perché utilizza HTTPS per l'intera sessione, ma Facebook e molti altri siti no.

Questo è il modo in cui 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 utilizzando una VPN per crittografare tutti i dati di sessione o utilizzando solo reti che dispongono di una crittografia avanzata per utente come WPA -PSK (WEP usa la stessa chiave per ogni utente, quindi non offre protezione da questo attacco).

Per quanto ne so, [WPA-PSK non è una difesa efficace contro attacchi simili a Firesheep] (http://www.kennynet.co.uk/2010/11/26/ubuntu-firesheep-aircrack-and-wpa/ ). Mi risulta che [aircrack-ng può decrittografare la crittografia WPA-PSK] (http://www.aircrack-ng.org/doku.php?id=airdecap-ng), se acquisisci l'handshake iniziale, che è facile da fare. WPA-PSK è [non è sicuro contro questi tipi di attacchi] (http://wifinetnews.com/archives/2003/11/weakness_in_passphrase_choice_in_wpa_interface.html) e [fornisce un falso senso di sicurezza] (http: //wiki.wireshark. org / HowToDecrypt802.11).
Inoltre, questa risposta trascura il rischio di attacchi MITM (attacchi attivi). Firesheep attualmente non conduce attacchi MITM, ma potrebbe, e quindi ci possono essere rischi anche se il sito utilizza esclusivamente HTTPS. (ad esempio, se non contrassegna i suoi cookie con il flag SICURO.)
@D.W., Grazie - ecco perché ho suggerito di spostare la domanda originale da superuser.com a qui - questa domanda proveniva da lì, non da un "addetto alla sicurezza". A proposito, quando vedi risposte negative, specialmente risposte esplicitamente SBAGLIATE, dovresti sottovalutarle. Ciò aiuta a far galleggiare le risposte corrette verso l'alto e ad affondare quelle sbagliate.
Probabilmente vale la pena notare che non è più il caso che "crittografia / decrittografia" sia intensivo per la CPU. È importante non perpetuare il mito secondo cui vale la pena considerare il carico della CPU quando si pensa di utilizzare HTTPS su tutte le parti del sito Web. vedere: https://istlsfastyet.com/
#4
+13
PulpSpy
2011-01-13 05:06:37 UTC
view on stackexchange narkive permalink

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

Per essere precisi, hai chiesto : "Se quell'utente malintenzionato ha fiutato 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.

Il motivo per cui non può calcolare le stesse chiavi sembra paradossale, e in effetti è stato un importante passo avanti nella crittografia quando è stato pubblicato 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 si sono mai scambiate informazioni prima di calcolare una chiave segreta che nessuno può visualizzare tutti i messaggi.

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.

  • Stiamo assumendo che il protocollo SSL / TLS sia corretto. Con la maggior parte dei protocolli crittografici coinvolti, i bug vengono trovati e corretti di volta in volta. SSL / TLS aveva un bug recente (menzionato in alcune risposte come motivo per cui non è sicuro), tuttavia è stato temporaneamente aggirato e ora risolto (RFC 5746) e la correzione è in varie fasi di distribuzione. (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 violare TLS / SSL a causa di un errore non pubblicato nel protocollo.
  • Un punto ovvio ma che 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 certo che SSL / TLS verrà utilizzato per le pagine future se la pagina corrente è HTTPS. Ad esempio, se ti trovi su una pagina HTTP che desidera che tu effettui l'accesso e dall'esperienza passata sai che facendo clic sul pulsante di accesso verrai reindirizzato 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).
#5
+2
RedGrittyBrick
2011-01-09 16:51:55 UTC
view on stackexchange narkive permalink

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

I certificati non validi sono un problema su tutti i tipi di connessione, non solo su un hotspot WI-FI pubblico.
Richard ha ragione, non c'è niente di speciale negli hotspot Wi-Fi pubblici per quanto riguarda i certificati. Ho ritenuto che valesse la pena menzionarlo perché si applica anche lì. Un operatore di hotspot canaglia potrebbe reindirizzarti al proprio server web utilizzando un certificato fraudolento.
ma i certificati non validi e il MITM sono molto più rischiosi sul wifi pubblico
#6
+2
Rory Alsop
2011-01-09 20:25:06 UTC
view on stackexchange narkive permalink

In pratica, SSL e TLS hanno entrambi problemi, ma riguardano il tipo di attacco Man In the Middle. Per un esempio di problema di rinegoziazione di TLS MITM vedi qui

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

#7
+2
D.W.
2011-01-12 08:02:56 UTC
view on stackexchange narkive permalink

Se sei preoccupato per la navigazione sicura in un sito su una rete non sicura, i passaggi migliori che puoi adottare per garantire la sicurezza sono:

  • Assicurati che il sito utilizzi HTTPS , non HTTP.

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

  • Utilizza HTTPS Everywhere o Force-TLS per assicurarti di utilizzare un HTTPS (cioè, crittografata con SSL) per tutto ciò che riguarda quel sito.

#8
+1
tobylane
2011-01-09 16:49:26 UTC
view on stackexchange narkive permalink

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

TLS è suscettibile al MITM
#9
+1
IrqJD
2011-01-09 23:44:02 UTC
view on stackexchange narkive permalink

La maggior parte sta dimenticando l'aspetto dell'utente e come potrebbe utilizzare quel PC anche nell'hotspot. La maggior parte delle persone usa password simili su altri siti, può blog, ... ecc. quelli potrebbero non essere sicuri come il gmail HTTPS / SSL a cui potresti connetterti. Problema che vedo dalla sicurezza, la maggior parte delle persone goto altri siti espone un programma di sniffing dei pacchetti con informazioni sufficienti per accedere ad alcuni dei tuoi account. La cosa migliore è come accennato se stai utilizzando una connessione wireless non crittografata, si spera che tu abbia una vpn a cui puoi connetterti dopo che aggiungerà un ulteriore livello di sicurezza.

#10
  0
Arjun sharma
2016-10-24 16:37:08 UTC
view on stackexchange narkive permalink

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

  • Non dovrebbe esserci alcun reindirizzamento da HTTPS a HTTP
  • Alcuni siti utilizzano anche HTTP cmd su pagine HTTPS, non dovrebbe esserci qualsiasi informazione sensibile trasmessa su questo
  • Server https configurati deboli e browser obsoleti sono ancora sfruttabili anche su socket sicuri
#11
-1
FrostyFire
2017-12-06 07:59:51 UTC
view on stackexchange narkive permalink

La risposta sull'ordinamento è, per quanto ne sappiamo, se HTTPS è impostato correttamente, sei al sicuro il 99% delle volte. È un grande se. Non è semplice come vedere HTTPS nel tuo browser. SSL-Strip funziona ancora su alcuni siti / browser sicuri.

Non dimentichiamo che prima di SSL-Strip nessuno pensava che uno strumento del genere potesse funzionare. La sicurezza informatica è un campo in continua evoluzione e un gioco di whak-a-mole per così dire. Ad un certo punto uscirà un nuovo exploit che ti consentirà di eseguire l'attacco menzionato su qualsiasi sito. Guarda lo standard WPA2 "infrangibile". Non così indistruttibile, dopotutto. Verrà aggiornato, ma non farà molto per le persone hackerate prima di allora.

Attualmente esiste un modo per decrittografare il traffico SSL configurato correttamente. Richiede l'accesso a una CA e il rilascio di certificati completamente affidabili. Il tuo browser non rileverà un attacco MiTm che lo utilizza. La buona notizia è che è estremamente difficile da realizzare ... per ora. L'utilizzo di una VPN non garantisce la sicurezza perché la VPN stessa potrebbe essere l'attaccante Mitm.

Fondamentalmente qualsiasi cosa online può e ad un certo punto verrà hackerata. Ci sono cose che puoi fare (VPN, browser aggiornato, ecc.) Per ridurre al minimo il rischio, ma non sei mai sicuro al 100%. Non lasciare che nessuno ti dica il contrario.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...