La sicurezza TLS per server Web è affidabile o presenta gravi difetti di progettazione

Is there any plan to replace this protocol with something more reliable, or is it that most problems are implementation-based and all those best practices/RFCs are there to mitigate possible human error?

Qui non c'è una risposta semplice, quindi farei "sì e no a tutti i precedenti". Ci sono molti fattori in gioco.

TLS è difettoso?

Proprio come qualsiasi altro protocollo (ad esempio, HTTP o HTML) SSL / TLS è uno standard in evoluzione. Come ogni altro protocollo, si evolve per includere:

• nuove funzionalità (ad esempio DNS CAA o OCSP che offrono maggiore sicurezza)
• miglioramenti delle prestazioni (ad esempio la graffatura OCSP e molte delle funzionalità di TLS 1.3 per migliorare la velocità e l'utilizzo della larghezza di banda)
• nuovi casi d'uso che riflettono il modo in cui viene costruita Internet (ad esempio, wildcard vs multi-dominio e più certificati in un contesto di server cloud con bilanciamento del carico).

A differenza di altri protocolli, TLS deve anche tenere il passo con l'aumento della potenza della CPU disponibile per gli hacker e la ricerca crittografica (sia la ricerca su nuovi algoritmi, sia la ricerca per rompere gli algoritmi esistenti). Questo è il motivo per cui vengono aggiunti nuovi cipher, quelli vecchi vengono eliminati e le dimensioni delle chiavi aumentano gradualmente.

Non direi che TLS è difettoso, ma piuttosto che, come qualsiasi altro software, TLS viene migliorato nel tempo per riflettere il cambiamento di Internet.

Errori di implementazione

Hai ragione a sottolineare che la maggior parte delle vulnerabilità di rilievo in TLS non è dovuta a un problema con la specifica TLS, ma a causa della mancata corretta osservanza da parte dei programmatori. Mi vengono in mente due esempi:

Estrazione di Ps e Q

[Paper]

Il problema qui è con (principalmente) piccoli dispositivi incorporati (pensate ai router domestici o alle webcam abilitate per Internet) che devono generare le chiavi del server TLS al primo avvio. Risulta che questi dispositivi escono tutti dalla fabbrica quasi identici, il che significa che i tasti che generano al primo avvio non sono molto casuali.

Questa è certamente una vulnerabilità TLS, ma non è colpa della specifica TLS.

ROBOT

[Home page del progetto]

Qui, la specifica TLS ( RFC 5246 sezione 7.4.7.1 ) fornisce istruzioni molto chiare per come evitare gli attacchi in stile Bleichenbacher:

As described by Klima [KPR03], these vulnerabilities can be avoided
by treating incorrectly formatted message blocks and/or mismatched
version numbers in a manner indistinguishable from correctly
formatted RSA blocks.  In other words:

  1. Generate a string R of 46 random bytes

  2. Decrypt the message to recover the plaintext M

  3. If the PKCS#1 padding is not correct, or the length of message
     M is not exactly 48 bytes:
        pre_master_secret = ClientHello.client_version || R
     else If ClientHello.client_version <= TLS 1.0, and version
     number check is explicitly disabled:
        pre_master_secret = M
     else:
        pre_master_secret = ClientHello.client_version || M[2..47]

Ecco 3 passaggi abbastanza semplici. Si scopre che gli sviluppatori di software che stanno dietro a un gran numero di implementazioni TLS là fuori non hanno eseguito correttamente questi passaggi, portando a vulnerabilità.

Ancora una volta, la sua è certamente una vulnerabilità TLS, ma non è colpa della specifica TLS.

Are these "enhancements" the result of SSL/TLS being fundamentally flawed?

OCSP stapling

La pinzatura OCSP è solo OCSP con prestazioni migliori e minore impatto sulla privacy. Questo non risolve un problema in TLS di per sé.

Do not use wildcard use multidomain certificates

Non conosco questa "best practice". Se i caratteri jolly o multidominio dovrebbero essere utilizzati dipende dal caso d'uso. Non è un problema con TLS.

Do not use this cipher suite it's too old (still very hard to break but too old)

Che i computer diventino più veloci e otteniamo progressi nella crittografia e che quindi i cifrari abbiano un tempo limitato in cui forniscono sicurezza è normale. Anche questo non è un difetto in TLS. Al contrario, TLS è flessibile in quanto consente di utilizzare i codici più recenti, se necessario. Ancora TLS 1.3 proibisce esplicitamente alcuni dei vecchi cifrari.

increase DHGroup

La stessa cosa che usare i cifrari aggiornati.

put a DNSCAA record in your DNS

Questo consente alla CA di verificare se è consentito emettere certificati per il dominio specifico. Non risolve un problema di TLS ma migliora la gestione della PKI che viene utilizzata nel contesto di TLS per convalidare i certificati.

and the list can goes on

Finora nessun problema di TLS stesso menzionato. Ma c'erano effettivamente problemi negli standard SSL / TLS precedenti ed è per questo che hai le versioni TLS più recenti. E lo sviluppo di TLS non è stato interrotto, ma sono in sviluppo nuove versioni.

Questo di nuovo non significa che ci sia un difetto fondamentale . Se questo fosse il caso, abbandoneremo TLS e non continueremo a svilupparlo.