Perché le autorità di certificazione radice sono autorizzate a emettere certificati per qualsiasi dominio?

5

Perché le autorità di certificazione sono autorizzate a rilasciare certificati attendibili dai browser per qualsiasi nome di dominio?

Ciò non implica che un'autorità di certificazione radice dirottata possa rilasciare certificati falsi attendibili di cui ogni browser si fida. Questo non è molto sicuro dal punto di vista dell'utente finale.

Non sarebbe più sicuro che tu decida quali autorità di certificazione root sono consentite & si fidano di firmare i certificati per i record dei nomi di dominio, ad esempio tramite DNS SEC? Esempi DNS simili sono anche record SPF di posta in cui dici quali server di posta sono autorizzati a inviare posta dal tuo dominio.

Perché è progettato per fare in modo che tutta la CA radice emetta certificati per qualsiasi nome di dominio?

    
posta Christian 22.01.2016 - 22:37
fonte

3 risposte

6

Why is it designed to trust all root CA to issue certs for any domain name?

Questo ha ragioni storiche e forse per motivi di promozione della concorrenza. All'inizio si aveva solo un CA root con prezzi molto alti. Ora i prezzi sono bassi perché tutta la CA può rilasciare un certificato per chiunque. Se ciascuna CA fosse in grado di firmare certificati per una parte specifica di Internet, questa competizione non sarebbe possibile.

Un tale insicuro progetto iniziale che hai in varie parti dei protocolli Internet e di solito viene aggirato aggiungendo sicurezza opzionale, vale a dire blocco dei certificati, politica di sicurezza dei contenuti contro lo scripting cross-site ecc. Naturalmente, tutto questo è solo aggiunto sicurezza opzionale e quindi usato raramente. Il pensiero generale è che funziona senza così perché preoccuparsi.

Would it not be more secure that you designate which root certificate authorities are allowed & trusted to sign certificates for your domain name records for example via DNS SEC?

Ci sono idee per usarlo e nell'area della sicurezza della posta DANE sta lentamente guadagnando seguaci e ci sono anche proposte per memorizzare SSH o altre chiavi e certificati (o impronte digitali) in DNS. Il problema principale è che è necessario prima avere DNSSec disponibile ovunque prima di poter contare su DNSSec per fornire tutti questi certificati. Ma per ora solo una piccola parte di Internet è protetta da DNSSec. Inoltre, molti risolutori DNS non gestiscono affatto DNSSec o non correttamente e a livello di applicazione di solito non si ha accesso allo stato di protezione di una risposta DNS.

Similar DNS examples are also mail SPF records where you say which mail servers are allowed to send mail from your domain.

I record SPF o DKIM non sono considerati rilevanti per la sicurezza e quindi la consegna di questi record con DNS semplice non protetto è considerata accettabile. Questo non sarebbe il caso dei certificati in cui avresti bisogno di una risposta di cui puoi fidarti completamente.

    
risposta data 23.01.2016 - 07:25
fonte
4

Affidarsi a DNSSEC equivarrebbe sostanzialmente a trasferire la nostra fiducia dalle CA ai registrar (ad esempio aziende come GoDaddy), i TLD (ad esempio VeriSign) e la radice (ad esempio ICANN). Non sono sicuro che possiamo fidarci di queste entità più di quanto possiamo fidarci delle CA. Vedi il post sul blog di Moxie Marlinspike per un ottimo articolo su questo argomento: link

    
risposta data 22.01.2016 - 23:07
fonte
0

Hai riscontrato uno dei problemi fondamentali con i certificati. Sono una forma di autenticazione, ma sono poveri in fase di autorizzazione. So chi sei, ma cosa ti è permesso firmare? E tu ed io siamo d'accordo comunque sulle definizioni?

Nel corso del tempo, vari bit sono stati violati in X.509. I bit indicano se è possibile firmare il codice, crittografare su TLS, ecc. Ma non esiste la nozione di "ambito". Non è come "Sono un CA, ma posso solo firmare i certificati per il dominio example.com". Anche allora, ci sono differenze di implementazione e differenze di interpretazione.

Uno dei grandi problemi è che X.509 confondeva autenticazione e autorizzazione. Il set di operazioni che si possono fare (firmare dati, crittografare dati, emettere certificati, revocare certificati, ecc.) È mal definito. Le possibili restrizioni (sempre, mai, a volte, con approvazione, ecc.) Non sono definite. Lo scopo delle operazioni (limitato a un dominio, un sottodominio, ecc.) È mal definito.

È un sistema vecchio di 20-30 anni che mostra la sua età. Ma non c'è una soluzione facile.

    
risposta data 24.01.2016 - 22:59
fonte

Leggi altre domande sui tag