Desidero certificati SMIME affidabili per terze parti. È una configurazione ragionevole?

9

Desidero inviare certificati SMIME con le mie e-mail e voglio implementare la seguente PKI

Root01  (All EKU, All Constrants, No Restrictions)

PolicyInt01 (Internal applications, not trusted by 3rd parties...)
PolicyExt01 (Name constraints = domain.com, EKU=Message signing) 

IssueExt01 (Issues certificates for PolicyExt01)

Il mio intento è di chiedere alle parti esterne di considerare PolicyExt01 e aggiungerlo all'archivio principale attendibile. Dal momento che è limitato e limitato nell'uso, penso che le terze parti più intelligenti non abbiano problemi con questo.

Domanda

  • Questa è una configurazione accettabile per la distribuzione di certificati SMIME affidabili all'esterno della nostra organizzazione?

  • Quali modifiche faresti per te, te stesso come amministratore della sicurezza, in questo processo?

  • Esiste il rischio che questo certificato pkipolext01 cross-firga / concateni un altro certificato, causando un'escalation imprevista dei diritti? (nome vincoli / EKU)

posta random65537 02.03.2015 - 19:22
fonte

2 risposte

4

Suggerirei di utilizzare una radice completamente separata per i certificati interni ed esterni, per evitare qualsiasi perdita di informazioni sugli host interni o sugli utenti, tramite Root01, ma anche per impedire qualsiasi trust implicito da parte di software non funzionante. Utilizzando 2 root separati per l'uso esterno e interno, non è possibile che nessun trust provenga da certificati esterni a interni, indipendentemente da come è danneggiato il software.

Normalmente, se abbiamo percorsi di certificazione che assomigliano a questo:

Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02

E SubCA02 è importato come affidabile. In un'implementazione PKI valida, Cert01 non dovrebbe essere considerato attendibile. Ma come sapete con codifica pigra, software rotto e analisi hacky dei certificati, è possibile che la fiducia trapeli da subCA02 a Root01 e quindi trapelare causando a Cert01 la fiducia di qualcuno che non dovrebbe fidarsi di quel certificato, se il L'implementazione di PKI è molto spezzata e, ad esempio, presuppone che ogni cert più alto sia considerato attendibile automaticamente. Sì, è molto estrapolato, ma è meglio tenere conto di eventuali software danneggiati usando invece radici completamente separate.

Vorrei anche aggiungere un vincolo di base PathLength = 0, che impedisce al certificato CA di essere utilizzato per firmare altri certificati CA, oltre al vincolo del nome.

Come forse saprai, c'è un sacco di software rotto là fuori, e un attacco di escalation di privilegi (come lo chiami quando qualcuno riesce a firmare un certificato in violazione con i vincoli) può accadere, per esempio se il suddetto certificato PolicyExt01 è usato per firmare una CA subordinata, che a sua volta sta firmando un certificato S / MIME.

Alcuni software rotti controllano solo i vincoli di denominazione di esempio "1 livello Deep" e l'aggiunta di un vincolo Pathlength causerebbe il fallimento di catene più lunghe invece di essere accettate come attendibili.

Quindi vorrei fare così:

Root01 (Name constraints = [email protected], PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)

E quindi condividere il certificato Root01 con quelle terze parti che dovrebbero fidarsi di esso, mentre installa Root01 e Root02 in tutti i computer interni all'azienda.

Sia Root01 che Root02 sono quindi certificati CA radice autofirmati.

Quando si utilizza Namingconstraint, inserirei solo un vincolo di denominazione [email protected] e quindi inserire tutti gli altri vincoli di denominazione (IP, DNS, UPN, URI) come caratteri jolly esclusi, per impedire l'utilizzo di un certificato come per esempio un certificato SSL di un sito Web, se un browser o un'implementazione SSL non fosse in grado di analizzare i flag di utilizzo della chiave.

Una buona idea è anche testare la tua configurazione, preferibile esportando il certificato della CA radice e la chiave privata in un computer sicuro, e poi provare a firmare certificati "non validi" con questo. Quindi prova i certificati "non validi" con il software client comune per assicurarti che i vincoli si stiano verificando e contrassegnando il certificato come non attendibile.

Personalmente non conosco alcuna configurazione esplicita che possa causare un tale attacco di "escalation di privilegi", ma come sai, ci sono molte implementazioni SSL e software PKI danneggiati, quindi è meglio prevenire che curare e limitare i certificati come il più possibile, e usa anche radici separate per evitare qualsiasi perdita di fiducia tra i certificati da parte del software MOLTO danneggiato.

    
risposta data 10.03.2015 - 04:06
fonte
0

Lo scopo dei certificati S / MIME è di firmare e crittografare i messaggi di posta elettronica. Dato il tuo caso d'uso, ciò che stai proponendo non è appropriato. Per l'e-mail si desidera che i destinatari siano in grado di verificare i messaggi e-mail senza dover scaricare e installare la chiave principale dell'organizzazione. Pertanto, per le e-mail, si desidera veramente utilizzare certificati emessi da un provider di certificati S / MIME riconosciuto a livello globale, come Comodo, VeriSign o StartCom. È possibile rilasciare questi certificati in loco se si acquista il sistema appropriato da questi fornitori.

Se le tue parti relying hanno rimosso tutti i loro certificati dai loro archivi root, allora puoi, ovviamente, fornire loro il tuo certificato di root e applicarlo come hai descritto. Tuttavia, ancora una volta, non è necessario disporre di una PKI separata per uso interno ed esterno. Sarà quasi impossibile da gestire e non vi è alcuna sicurezza aggiuntiva nel farlo. Basta usare una singola radice.

    
risposta data 31.10.2015 - 05:06
fonte