Un certificato solo CN può ignorare un vincolo di nome se la CA diventa canaglia?

3

Sto provando a certificare in modo incrociato un certificato di emittente interno, aggiungendo un vincolo di nome per il nostro dominio.

Tuttavia, sembra che un utente malintenzionato possa ignorare questa protezione inserendo il nome host desiderato in un attributo CN del soggetto e non aggiungendo un'estensione di nome alternativa del soggetto. Lo scenario è un operatore per la CA interna che diventa canaglia e crea certificati illegittimi per eseguire attacchi MITM.

In breve, sembra che il vincolo del nome sia inutile, a meno che non contenga un vincolo del nome della directory fino a un CN per un host specifico (nel qual caso è sicuro, ma comunque inutile).

Questo attacco funzionerebbe nella pratica? I browser adottano misure per prevenirlo?

    
posta erickson 09.03.2016 - 19:47
fonte

2 risposte

5

La posizione "ufficiale" di X.509 su CA canaglia è che CA canaglia sono fuori portata da X.509. Ci vuole un certo sforzo per accettare che ... L'idea è che tutta la struttura della CA non riguarda realmente gli attacchi di prevenzione , ma piuttosto la possibilità di puntare le dita contro i colpevoli. Se una CA diventa canaglia, la catena di certificati fraudolenta consentirà di individuare quale CA ha sbagliato, quindi indirizzare la colpa dove è dovuta.

La maggior parte dei browser affronta il problema dei vincoli di nome non supportando i vincoli di nome, il che significa che provare a limitare una CA secondaria a un dominio specifico è, per ora, una ricerca pazza.

SE il supporto dei vincoli di nome era molto diffuso, allora si poteva limitare una CA secondaria all'emissione di SSL / TLS per un dominio specifico aggiungendo un vincolo di nome che costringe il DN soggetto a un prefisso che definisce il CN a un valore che non può essere un FQDN per una macchina. Pertanto, qualsiasi certificato "SSL aware" necessiterebbe necessariamente di un'estensione SAN, evitando così il problema a cui si allude. Ma questo continua a fare supposizioni sul comportamento delle implementazioni che incontrano un certificato il cui DN soggetto contiene più campi "CN"; se la SAN vincola il DN a "CN = INVALID FOR DOMAIN" e la sub-CA anomala emette un certificato con, come DN: "CN = NON VALIDO PER DOMAIN, CN = www.google.com", come reagirà il software del client ?

Per riassumere, i vincoli dei nomi non funzionano bene o affatto nella pratica, per mancanza di supporto diffuso, ma anche se fossero supportati, se funzionano effettivamente rimarrebbe un gioco "hit-and-miss".

    
risposta data 09.03.2016 - 20:01
fonte
2

Mi piacerebbe espandere l'eccellente primo paragrafo di Tom Leek in cui diceva:

The "official" X.509 stance on rogue CA is that rogue CA are out of scope of X.509. It takes some effort to accept that...

L'intero ecosistema CA funziona sull'idea che la CA radice di una catena sia assolutamente affidabile, quindi Autorità del certificato: non mettere in dubbio un'autorità!

Inserendo un certificato di root nel tuo negozio di fiducia stai dicendo "Credo che quei ragazzi siano affidabili e affidabili e non pubblicheranno mai un certificato fraudolento". Se viene rilevata una CA intermedia emettendo certificati fraudolenti, (speriamo) che la CA radice sopra di essi revochi il certificato, rendendo immediatamente non validi tutti i certificati che hanno emesso, consentendo agli amministratori di iniziare la pulizia e la nuova emissione di certificati validi . Se una CA root viene mai sorpresa a rilasciare certificati fraudolenti, la loro fiducia pubblica sarà eliminata, verranno strappati dai browser, perderanno tutti i loro clienti e cesseranno l'attività - quasi durante la notte (vedi: DigiNotar ).

Nel bene o nel male, l'intero sistema dipende dalla fiducia che le CA pubbliche agiscono in buona fede per paura della bancarotta se vengono catturate (e con la quantità di auditing che devono affrontare, speriamo che lo faranno essere).

Come ha detto Tom,

It takes some effort to accept that...

    
risposta data 09.03.2016 - 23:10
fonte