I siti Web HTTPS in visita su un hotspot pubblico sono protetti?

HTTPS è sicuro su hotspot pubblici. Vengono trasmessi solo una chiave pubblica e messaggi crittografati (e anche questi sono firmati dai certificati di origine) durante l'impostazione di TLS , la livello di sicurezza utilizzato da HTTPS. Il client utilizza la chiave pubblica per crittografare un master secret, che poi decodifica con la sua chiave privata. Tutti i dati sono crittografati con una funzione che utilizza il master secret e numeri pseudo casuali generati da ciascun lato.

Così,

• i dati sono sicuri perché sono firmati dal master secret e dai numeri pseudo-casuali
• il segreto principale e i numeri pseudo casuali sono sicuri perché utilizza la crittografia a chiave pubblica-privata quando si verifica l'handshake TLS
• la crittografia della chiave pubblica-privata è sicura perché:
  • le chiavi private vengono mantenute segrete
  • la crittografia della chiave pubblica-privata è progettata per essere inutile senza la chiave privata
  • è noto che le chiavi pubbliche sono legittime perché sono firmate da certificati radice, che
  • è arrivato con il tuo computer
  • o sono stati specificamente autorizzati da te (prestare attenzione agli avvisi del browser!)

Pertanto, le connessioni e i dati HTTPS sono al sicuro finchè:

1. ti fidi dei certificati forniti con il tuo computer,
2. hai cura di autorizzare solo i certificati di cui ti fidi.

Risposta breve: dipende.

SSL / TLS 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 sul sito HTTPS, si avviano sul 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 link Email a NON reindirizzare a HTTPS, ma forse da qualche altra parte. Ad esempio, se hai fatto clic sul link Email nella home page di example.org, ti accorgerai che ti ha portato a http://mail.exxxample.org/ ? (come esempio). Potresti , qualcun altro potrebbe non farlo.
• Se l'utente dirotta la tua connessione, ma fornisce il suo certificato SSL fasullo invece di example.org - il tuo browser mostrerà un errore, che il certificato non è valido. Tuttavia, la maggior parte degli utenti farà semplicemente clic su questo, consentendo l'aggressore a MITM per il tuo sito sicuro, su SSL.
• Un altro aspetto da considerare, non presumere che l'hotspot pubblico sia configurato in modo sicuro. Poiché questa domanda mostra , i router pwned sono tutti troppo comuni e possono causare un maggior numero di danni irrilevanti del tuo SSL.

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 e quindi torneranno su HTTP per il resto della sessione. Pertanto, la password stessa è sicura, ma l'ID sessione utilizzato dal server per identificare l'utente per quella sessione viene trasmesso in chiaro dal browser. Ciò riduce il carico sul server Web (poiché 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.

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

È possibile proteggersi da questo attacco utilizzando una VPN per crittografare tutti i dati di sessione o utilizzando solo reti con crittografia strong per utente come WPA-PSK (WEP utilizza la stessa chiave per ogni utente e quindi non offre protezione da questo attacco).

Poiché le risposte sembrano essere dappertutto (sì, no, potrebbe essere, dovrebbe essere), vorrei prima reiterare la risposta di @ waiwai933: è sicuro.

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 riesce a 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 tutti i messaggi può calcolare.

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.

• Supponiamo che il protocollo SSL / TLS sia corretto. Con la maggior parte dei protocolli crittografici coinvolti, i bug vengono individuati e risolti 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 corretto (RFC 5746) e la correzione è in varie fasi di distribuzione. (Nel tuo scenario, il bug permetteva a un utente malintenzionato di inviare pacchetti nel tuo nome ma non di leggere il tuo traffico.) È sempre possibile che l'utente malintenzionato sappia come interrompere TLS / SSL a causa di un errore non pubblicato nel protocollo.
• Un punto ovvio, ma vale la pena ripetere: 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 ci si trova su una pagina HTTP che richiede l'accesso e dall'esperienza passata si sa che facendo clic sul pulsante di accesso si reindirizzerà a una connessione HTTPS, questa funzionalità potrebbe essere eliminata 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).

HTTPS è piuttosto resistente alla decodifica dallo sniffing dei pacchetti. Tuttavia, il lato di 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 cert di Microsoft era rilasciato a un impostore . Vedi l'articolo sull'argomento di Bruce Schneier - in pratica, per i siti Web pubblici generali, non lo facciamo avere qualcosa di meglio.

In pratica, SSL e TLS hanno entrambi problemi, ma sono intorno al tipo di attacco Man In the Middle. Per un esempio del problema di rinegoziazione TLS MITM, vedere qui

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

Se sei preoccupato di navigare in sicurezza su qualche sito su una rete non sicura, i migliori passi da fare 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 ovunque o Force-TLS per garantire che si stia utilizzando una connessione HTTPS (cioè crittografata con SSL) per tutto ciò che riguarda quel sito.

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

La maggior parte sta dimenticando l'aspetto dell'utente e il modo in cui potrebbero utilizzare anche quel pc nell'hotspot. La maggior parte delle persone usa password simili su altri siti, può blog, ... ecc. quelli potrebbero non essere altrettanto sicuri come gmail HTTPS / SSL a cui ti potresti connettere. Problema che vedo dalla sicurezza la maggior parte delle persone goto altri siti espongono un programma di sniffing dei pacchetti con informazioni sufficienti per ottenere alcuni dei vostri account. La cosa migliore è come menzionato se si sta utilizzando una connessione wireless non crittografata, si spera che si abbia una VPN a cui connettersi, dopo di ciò si aggiungerà un ulteriore livello di sicurezza.

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

• Non dovrebbe esserci alcun reindirizzamento da HTTPS a HTTP
• Alcuni siti utilizzano anche HTTP cmd su pagine HTTPS, non dovrebbero esserci informazioni sensibili trasmesse su questo
• I server https deboli e i browser obsoleti sono ancora sfruttabili anche su socket sicuri

La risposta di tipo è, per quanto ne sappiamo, se HTTPS è configurato correttamente, sei al sicuro il 99% delle volte. Questo è un grande se. Non è così 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 un simile strumento potesse funzionare. La sicurezza informatica è un campo in continua evoluzione e un gioco di whak-a-mole per così dire. A un certo punto verrà fuori un nuovo exploit che ti consente di fare l'attacco che menzioni su qualsiasi sito. Guarda lo standard WPA2 "indistruttibile". Non così infrangibile, dopotutto. Sarà rattoppato ma non fa molto per le persone hackerate prima di allora.

Attualmente esiste un modo per decodificare il traffico SSL configurato correttamente. Richiede l'accesso a una CA e l'emissione di certificati pienamente affidabili. Il tuo browser non rileverà un attacco MiTm usando quello. La buona notizia è che è estremamente difficile da ottenere ..... per ora. L'utilizzo di una VPN non garantisce la sicurezza perché la VPN stessa potrebbe essere l'aggressore di Mitm.

Fondamentalmente qualsiasi cosa online può e ad un certo punto sarà compromessa. Ci sono cose che puoi fare (VPN, browser aggiornato, ecc.) Per minimizzare il rischio, ma non sei mai sicuro al 100%. Non permettere a nessuno di dirti altrimenti.