Rischi di fidarsi esplicitamente del certificato SSL e affidarsi alla catena di certificati per la convalida?

What are the risks of not relying on the certificate chain for SSL certificate validation and instead manually importing the certificate as trusted?

Uno è legato al fatto che la catena di convalida in genere include un servizio CRL e / o OCSP per interrogare per certificati invalidati, ma altrimenti legittimi. In altre parole, un certificato può essere tecnicamente valido, ma è stato invalidato perché la sua chiave privata è stata compromessa - CRL e OCSP sono metodi standardizzati per gestire la revoca, che in genere non è il caso della gestione manuale dei certificati.

Tenderei anche a pensare che questo sia uno spreco di risorse: perché spendere ulteriori sforzi per soddisfare un bisogno che ha una soluzione migliore, e più precisamente, standardizzata?

Soprattutto su qualsiasi scala, sicuramente questo è anche inefficiente: rispetto a una radice (o ad es. 5 root + CA intermedie) che dovresti fidarti, dovresti distribuire i certificati X end-entity, e in aggiunta, sarebbe legato al ciclo di vita della CA di emissione per i certificati in termini di necessità di ridistribuire nuovi certificati.

What additional risks, if any, are there for not keeping the list of trusted root CAs updated?

Come accennato, la revoca è una delle aree che mi viene in mente: in assenza di un efficace meccanismo di revoca, una CA attendibile indica semplicemente che qualcosa era, a un certo punto, attendibile. Non ha un chiaro significato se questo stesso 'qualcosa' è ora fidato.

Senza mantenere le tue radici attendibili, tenderei a pensare che tu stia rendendo molto più importante lo scopo di x509: la fiducia è una proprietà transitiva e ogni ipotesi contraria tende a essere sfruttata per scopi dannosi.

Sembra che tu stia parlando di una connessione one-to-one, in cui il sistema client si connette solo sempre al tuo sistema (e forse a pochi altri).

In tal caso, l'approccio del cliente potrebbe effettivamente migliorare la sicurezza, purché allo stesso tempo eliminino tutte le CA attendibili esistenti dal loro sistema.

In sostanza, ciò che stanno facendo è il blocco dei certificati. Si fidano del tuo certificato SSL, invece di tutti i certificati emessi dalla tua CA. I certificati Rogue, cioè i certificati emessi senza conoscenza del proprietario del dominio, sono una realtà oggi. Affidandosi solo al tuo certificato, i certificati rogue non funzioneranno anche se fossero emessi dalla stessa CA.

Ovviamente, funziona solo se non si fidano ancora di alcuna CA.

Se il pinning del certificato è davvero l'obiettivo principale del tuo cliente, allora la revoca del certificato non è un problema: se un certificato ha bisogno di essere revocato, devi semplicemente comunicarlo direttamente al cliente.

L'installazione di un certificato radice affidabile garantisce un'immensa potenza su una macchina. Un certificato di origine può convalidare il codice firmato o intercettare il traffico web crittografato falsificando i certificati. (Questo è il modo in cui https ispezionano i proxy.) Se l'organizzazione non sta seguendo tutte le politiche e le regole di una CA attendibile come definito da CA Security Council, il certificato CA radice semplicemente non è affidabile.

È interessante notare che non dovresti volere che la tua CA radice sia attendibile anche dai tuoi clienti. Perchè no? Perché potresti diventare responsabile nel caso in cui vengano violati. Un utente malintenzionato potrebbe entrare nella tua CA e utilizzarlo per firmare malware da eseguire sui computer dei tuoi clienti.

Ciò non significa che il certificato dell'applicazione o del server non può essere considerato attendibile per fare qualsiasi servizio tu fornisca, ma una root attendibile ha un livello di potenza inopportunamente più alto.

Abbiamo avuto team clienti che ci chiedono informazioni sull'installazione dei certificati dei fornitori nei loro negozi root attendibili e dobbiamo sempre dire loro "non permetterlo mai!"