Any website secured using TLS can be impersonated using a rogue certificate issued by a rogue CA. This is irrespective of which CA issued the website’s true certificate and of any property of that certificate.
— Marc Stevens et al. 2009
È ancora vero?
Capisco che uno scopo della Trasparenza dei certificati sia di individuare eventuali CA rogue a lungo termine. Ma c'è qualche protezione contro l'attacco immediato?
Esiste una potenziale protezione sotto forma di blocco dei certificati. Questo può essere fatto in un'applicazione, e alcuni browser (si spera tutto in futuro) lo supportano sotto forma di pinning del certificato. Il blocco dei certificati può assumere due forme, in primo luogo è possibile inviare l'impronta digitale del certificato ai fornitori di browser (Google e Mozilla, attualmente) da includere nel browser stesso. In secondo luogo, puoi aggiungere i pin a un'intestazione HSTS, che indicherà ai browser che hanno visitato il tuo sito in passato se il certificato che stanno visualizzando è kosher o no.
Poiché il blocco dei certificati avviene a livello di singolo certificato, attenua la minaccia dei certificati firmati da root dannosi o compromessi.
Ironia della sorte, i certificati X.509 possono teoricamente essere ambiti a domini specifici e sub -dominio, tramite l'estensione Limitazioni nome : se un certificato CA contiene un'estensione Name Constraints con un campo permittedSubtrees contenente un dNSName del valore example.com può emettere certificati solo se i nomi host che compaiono nelle estensioni Subject Alt Names di questi certificati provengono dal dominio example.com o da un sottodominio di questi. Questo vincolo si propaga lungo la catena, quindi anche i certificati emessi dalla CA secondaria devono essere conformi.
Sfortunatamente, questo schema fallisce nella pratica, per due motivi:
Quando il certificato del server non include affatto un'estensione Subject Alt Name , i client SSL hanno l'abitudine di usare il nome comune da subjectDN come sostituto. Secondo le regole X.509, il Common Name è non coperto da Name Constraints di tipo dNSName . L'utilizzo del nome comune è esplicitamente consentito da RFC 2818 .
Nessuno implementa il supporto per Name Constraints . Se non si contrassegna l'estensione come critica, i client la ignoreranno. Se si contrassegna l'estensione come critica, i client rifiuteranno il certificato. Pertanto, non puoi davvero usarli.
La mancanza di supporto implica che nessuno cerchi di eseguire l'analisi dei certificati con Name Constraints . Poiché nessuno ci prova, gli implementatori non hanno alcun incentivo a implementare realmente il supporto.
La conseguenza generale è che, al momento, le CA non hanno ambito. Pertanto, qualsiasi CA radice attendibile dai client SSL e qualsiasi CA intermedia emessa (direttamente o meno) da una di queste CA radice, sarà tecnicamente attendibile per la convalida dei certificati server SSL per ogni possibile nome di dominio.
Tuttavia, CA canaglia sono un evento abbastanza raro. Il motivo è che un certificato contraffatto, con un nome falso, indica anche chiaramente la CA che lo ha emesso. I certificati falsi sono molto rischiosi per una CA; c'è quasi la certezza di essere scoperti dopo il fatto. La CA principale viene inclusa nel sistema operativo e nei browser firmando contratti che impongono severe sanzioni in caso di comportamento scorretto; quando la CA radice emette certificati di sub-CA, impongono nuovamente lo stesso tipo di penalità contrattualmente. Stiamo parlando di milioni di dollari qui.
I casi reali di certificati falsi sono per lo più dovuti a compromessi, di natura transitoria e accadono circa una volta all'anno.
Tutto ciò che un sito deve fare è presentare un certificato firmato da una CA affidabile. Attualmente non esiste un modo per le CA di "ambito" (limitare le origini per le quali possono firmare i certificati) né esiste un modo per un sito di specificare quali CA sono valide per esso. (E anche se ci fosse, questo è un problema di pollo e uova, come sapresti che l'informazione è valida?)
Quindi, la risposta è fondamentalmente: sì, qualsiasi CA può firmare un certificato per qualsiasi sito.
Leggi altre domande sui tag tls certificate-authority