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 .