HTTPS o HTTPS all'interno di VPN per la sicurezza WIFI?

4

Ho letto che HTTPS può essere compromesso e non è sicuro come pensi. Con una VPN gratuita devi fidarti di un server VPN gratuito con i tuoi dati, e sicuramente i tuoi dati dal momento in cui lascia il server VPN alla destinazione devono essere crittografati a meno che la VPN non sia impostata su entrambe le estremità.

Quindi HTTPS in VPN è molto più sicuro di HTTPS o VPN per conto proprio, ad es. il server VPN può accedere ai tuoi dati quando HTTPS viene utilizzato all'interno del tunnel VPN?

O HTTPS è abbastanza sicuro da solo?

Uso molto il Wi-Fi pubblico e vorrei usare il più possibile una connessione sicura solo per le email sensibili e le cose importanti pur non essendo un problema da configurare e anche gratuito.

L'HTTPS all'interno di Hotspot Shield sarebbe più sicuro di HTTPS? Useresti il WiFi per la navigazione importante?

    
posta joe 22.11.2012 - 04:51
fonte

3 risposte

5

Per quanto riguarda i commenti sulla "sessione di sessione" sulla risposta di Terry Chia:

Il Session Session e la tecnica utilizzata da Firesheep è di indirizzare gli accessi al sito HTTP su una connessione di rete condivisa, ovvero: WiFi. Ciò viene realizzato intercettando i cookie di sessione che il sito invia dopo che si è verificato un accesso corretto. Se la connessione utilizza SSL [aka HTTPS], questi cookie non possono essere letti da terzi.

Quando il tuo browser indica "non tutto in questa pagina è sicuro" significa che alcune risorse sono state caricate su una semplice connessione HTTP. Questo non significa necessariamente che sei vulnerabile, dato che solitamente è semplicemente un file immagine o un file CSS / JS incluso.

Come per le VPN, dovresti fidarti solo della connessione VPN tanto quanto ti fidi del provider. Vale a dire se stai usando un servizio gratuito come HotSpotShield, allora è meglio che tu stia bene con loro in grado di intercettare ogni singolo pacchetto che invii loro. Inoltre, dal momento che si installa il proprio software client VPN, nulla impedisce loro di installare anche certificati SSL root / intermediate forgiati sul tuo computer che consentiranno loro di rimuovere la protezione SSL se ne hanno voglia.

In sintesi, è meglio non utilizzare una VPN che non hai configurato tu stesso e assicurarti che i tuoi dati di accesso e importanti vengano trasmessi tramite connessioni protette SSL / TLS, ad esempio: HTTPS, IMAPS, POPS, ecc. .

    
risposta data 22.11.2012 - 22:58
fonte
2

Non capisci le tecnologie che hai menzionato.

In primo luogo, identifichiamo le minacce di navigazione su una rete pubblica Wi-Fi. Chiunque si trovi sulla stessa rete come si sarà in grado di annusare i pacchetti inviati. Ciò significa che qualsiasi dato non crittografato inviato su reti pubbliche Wi-Fi può essere facilmente compromesso.

Questo problema viene attenuato da HTTPS. Che cosa fa HTTPS è incapsulare la comunicazione HTTP all'interno di un livello SSL. Ciò significa che tutti i dati inviati tra il browser e il sito Web sono crittografati. HTTPS garantisce inoltre che il sito Web è quello che dicono di essere tramite certificati.

Hotspot Shield crea un tunnel VPN tra il tuo computer e il loro gateway internet. Qualsiasi traffico tra il tuo computer e il gateway sarà crittografato. Tuttavia, qualsiasi traffico di dati tra il gateway e altri siti Web può ancora essere rilevato, a meno che non stiano comunicando tramite HTTPS.

Per il tuo caso d'uso, direi che una semplice connessione HTTPS si rivelerà sufficiente.

    
risposta data 22.11.2012 - 06:16
fonte
2

Il Le domande a cui ti colleghi (in un commento) non parlano davvero di punti deboli in HTTPS. La distribuzione della posta elettronica non ha nulla a che fare con HTTPS.

È importante comprendere i punti deboli relativi a HTTPS e SSL / TLS prima di passare a soluzioni alternative, alcune delle quali potrebbero presentare problemi simili.

  • Il problema della rinegoziazione (CVE-2009-3555) era piuttosto direttamente correlato al protocollo TLS stesso. Ci sono state delle attenuazioni usando le opzioni di configurazione (disabilitando la rinegoziazione), e da allora c'è stata una correzione (RFC 5746). (Nonostante sia un difetto, penso che sia stato piuttosto difficile sfruttarlo in modo coerente.)

  • Il problema CRIME può essere risolto disabilitando la compressione TLS.

  • Il problema BEAST può essere mitigato in vari modi, in particolare l'aggiornamento a TLS 1.1 o versioni successive.

La maggior parte di questi problemi richiede alcune modifiche alla configurazione o modifiche delle opzioni nel modo in cui alcune applicazioni usano le loro librerie SSL / TLS. Tuttavia, se sei aggiornato con il tuo software, dovresti stare bene.

L'intera specifica di SSL / TLS è molto modulare, quindi se vengono riscontrati determinati punti deboli con alcune suite di crittografia, ad esempio, sono disponibili spesso altre opzioni. Una buona e aggiornata configurazione è essenziale per qualsiasi sistema di sicurezza.

La maggior parte delle persone che affermano che "SSL è danneggiato" in realtà si rivolge al sistema PKI (ad esempio il modello di certificato). Le specifiche TLS non impongono effettivamente l'uso di certificati X.509, ma è vero che l'HTTPS su TLS implica l'uso di certificati X.509.

I PKI e i certificati riguardano il controllo dell'identità del partito remoto. Questa è una soluzione tecnica per un problema che si verifica nella vita di tutti i giorni (banca che verifica il tuo ID alla scrivania, ...). L'aspetto tecnico è solo una parte del problema. Le CA sono tutt'altro che perfette, ma offrono un sistema gestibile. La modellazione della fiducia è in realtà un problema molto difficile.

Ricorda che, in definitiva, controllare che l'HTTPS sia usato e usato con la parte giusta è responsabilità del cliente e il suo utente . I server possono al massimo dire ai clienti di utilizzare HTTPS, che il reindirizzamento potrebbe non essere protetto. È sempre compito dell'utente controllare. (Certo, è anche un problema con la GUI, per dare all'utente le giuste informazioni, con la minima confusione possibile.)

Confrontare HTTPS (e SSL / TLS) con VPN non ha senso. Questi sistemi hanno due scopi diversi. HTTPS riguarda la protezione della comunicazione tra client / browser e server. Le VPN riguardano il collegamento di due sottoreti insieme.

Esistono numerose tecnologie VPN, con vantaggi e svantaggi. Come tutte le soluzioni di sicurezza, devono essere configurate e utilizzate correttamente per essere efficaci.

  • VPN che usano SSL / TLS (come OpenVPN): in linea di principio possono soffrire alcuni degli stessi problemi di SSL / TLS con HTTPS quando si tratta di controllare i certificati. Detto questo, l'autenticazione del certificato client è più comune in questo ambiente (il che rende anche gli attacchi MITM rilevabili dal server con SSL / TLS, questo vale anche per HTTPS, ma i certificati client sono più rari lì).

  • VPN che utilizzano IPsec e certificati. Anche in questo caso, la verifica dell'identità può essere un problema anche lì. Un modo per risolvere questo problema è ridurre il numero di certificati CA considerati attendibili dall'implementazione IPsec. Questo è generalmente più gestibile per una VPN perché stai utilizzando un minor numero di VPN rispetto ai siti web remoti in generale, ma il problema fondamentale rimane.

  • VPN che utilizzano IPsec e segreto condiviso. Questo potrebbe funzionare se il segreto condiviso non è stato condiviso come ampiamente (e rimasto più segreto). Sembra che alcune università (ad esempio) pubblichino ampiamente il loro segreto condiviso VPN, che può potenzialmente apri la porta agli attacchi MITM .

Se si controlla correttamente il certificato, l'aggiunta di una VPN sotto la connessione HTTPS in genere non aggiunge alcuna sicurezza effettiva. C'è una piccola finestra in cui può aiutare: quando una CA di cui ti fidi (volontariamente o per impostazione predefinita nel tuo sistema operativo / browser) è stata compromessa e un certificato canaglia può essere utilizzato nella sezione della rete che potrebbe altrimenti essere protetta con una VPN. Ciò può anche aiutare in quella parte della rete con clienti mal implementati .

    
risposta data 27.11.2012 - 23:21
fonte

Leggi altre domande sui tag