Esiste una soluzione ai problemi di sicurezza in corso con ssl / tls? [chiuso]

-2

Sembra che i metodi che usiamo per garantire uno scambio di informazioni sicuro con i server falliscano continuamente. Dati i problemi in corso con SSL / TLS e i metodi in continua evoluzione per risolvere problemi come:

  • Inserimento di chiavi pubbliche HTTP - per delineare meglio la chiave pubblica corretta mediante la sua firma.
  • Trasparenza certificato - un'estensione certificato X509
  • deprecazione o eliminazione di versioni di SSL e TLS
  • varie altre correzioni per altre vulnerabilità del sistema

Sembra sicuro affermare che l'infrastruttura PKI si trova in una cattiva situazione (sull'orlo del collasso) quando è evidente che non siamo nemmeno in grado di dire quale certificato / chiave pubblica è valido.

Quindi esiste effettivamente una soluzione realistica per i problemi SSL / TLS in corso?

C'è molto movimento ma nessuna indicazione che i problemi siano risolti!

    
posta Surly Canuck 31.05.2018 - 23:45
fonte

1 risposta

12

TL; TR: TLS non è rotto oltre la speranza e non c'è una "correzione dei problemi di sicurezza in corso con ssl / tls" necessari. Sono comunque necessari miglioramenti regolari, ma sono anche fatti.

Seems like the methods we use to ensure secure information exchange with servers continually fail.

"continuamente fallire" è secondo me un'interpretazione molto pessimista e sbagliata. Il fatto è che la maggior parte dell'uso di SSL / TLS è piuttosto sicuro, cioè è molto più successo che fallimento. Ma non è perfetto, soprattutto perché il mondo di oggi è diverso da quando inizialmente era stato progettato SSL / TLS. E poiché il mondo sta cambiando, SSL / TLS deve adattarsi ai cambiamenti e quindi ha bisogno di continui miglioramenti: anni fa lo stato dell'arte era TLS 1.0, ora sono anche TLS 1.2 e TLS 1.3.

I miglioramenti al protocollo TLS e ai cifrari utilizzati sono fatti in genere molto prima che i potenziali problemi nascano veramente da un problema. Mentre c'erano molti problemi in passato (CRIME, BREACH, POODLE ....) questi erano solo attacchi teorici all'epoca, cioè possibili solo all'interno di un caso d'uso stretto e di solito insolito e / o avevano bisogno di risorse considerevoli. Direi che nessuno di questi problemi ha causato problemi di sicurezza nella pratica quando sono stati trovati, ma potrebbero aver causato tali problemi in un secondo momento se non fossero stati corretti. Gli attacchi diventano più semplici con il tempo, sia perché gli attacchi vengono migliorati, sia perché le risorse necessarie (potenza di calcolo, larghezza di banda) diventano più facili ed economiche da acquisire.

Contrariamente a questo bug nelle implementazioni del protocollo erano molto più gravi, ad esempio Heartbleed , goto fail o la vulnerabilità di schannel ha causato problemi reali. Ma questi non erano bug nel protocollo come progettato ma bug nell'implementazione.

Per quanto riguarda i problemi con la convalida dei certificati: questi non sono in realtà problemi di SSL / TLS stesso dal momento in cui la convalida viene eseguita non fa parte del protocollo TLS. Sono però problemi da tenere d'occhio quando si utilizza praticamente SSL / TLS all'interno di HTTPS o simili su Internet.

Il problema con la convalida dei certificati è in realtà meno tecnico, ma più umano - su chi fidarsi e su come aumentare la fiducia e quanto fidarsi. Nei primi giorni di utilizzo di HTTPS c'erano solo poche autorità di certificazione che avevano una rigorosa gestione dei certificati. Impersonare i siti usando i loro certificati non era un problema reale in questo momento poiché nessun sito richiedeva effettivamente HTTPS, cioè l'autore dell'attacco poteva semplicemente usare HTTP se necessario.

Oggi la situazione è diversa: i siti più importanti richiedono HTTPS e quindi attaccare le autorità di certificazione per impersonare i siti è diventato più attraente e reale in molti casi. Per scoraggiare tali attacchi sono stati sviluppati e utilizzati miglioramenti come la trasparenza dei certificati o il blocco dei certificati o l'autorizzazione dell'autorità di certificazione (CAA) e sono state chiuse anche diverse autorità di certificazione con scadente sicurezza (cioè non più attendibile dai principali browser). Metodi come la spillatura OCSP, OCSP deve graffetta , CRLSet e l'uso di certificati di breve durata ma aggiornati automaticamente sono stati propagati per risolvere i crescenti problemi con i certificati rubati che devono essere revocati. Quindi è lo stesso di TLS: non è rotto oltre la speranza ma c'è spazio per miglioramenti e miglioramenti.

Un altro problema è che la fiducia in TLS (HTTPS) si è ridotta con gli anni, meno a causa dei problemi con le autorità di certificazione ma più a causa dell'uso massiccio di TLS: oggi è facile ed economico / gratuito ottenere certificati e è previsto in molti casi che venga utilizzato HTTPS. Ciò significa che anche i siti di phishing ottengono i certificati oggi e il malware viene consegnato da HTTPS. Mentre HTTPS era in passato spesso commercializzato come un segnale che il sito stesso è sicuro, questo non è più vero e in realtà non lo è mai stato. Gli utenti devono capire che HTTPS significa solo che il contenuto è protetto durante la consegna, ma che il contenuto protetto può essere ancora dannoso. Ma ancora, questo è un problema sociologico e di usabilità e non un problema di protocollo.

    
risposta data 01.06.2018 - 00:37
fonte

Leggi altre domande sui tag