Una volta che un certificato è stato convalidato, è sicuro eseguire una corrispondenza stringa sul campo dell'emittente?

2

In primo luogo, alcuni sfondi della domanda:

Ho un'appliance Secure VPN Pulse Connect in un ambiente multi-tenant e mi è stato chiesto di supportare l'autenticazione dei certificati (utilizzando specificamente le smartcard, ma non credo che i dettagli siano rilevanti per la domanda). Ogni cliente ha la propria autorità di certificazione che emette certificati client per gli utenti finali.

Sfortunatamente, sul dispositivo Pulse Connect Secure VPN, è possibile configurare solo CA attendibili a livello globale per l'intero dispositivo. Non è possibile definirlo al livello Authentication Server o al livello User Realm .

Questo va bene se non hai bisogno di segmentare la fiducia per CA differenti: s a seconda dei client che stai servendo, ma in realtà non supporta molto un ambiente multi-tenant.

La minaccia specifica che sto cercando di mettere in sicurezza è che se una CA di un cliente dovesse essere compromessa, potrebbero emettere certificati VPN con soggetti appartenenti a un altro cliente. Pertanto, solo la CA del cliente può essere considerata attendibile per firmare i certificati client per la propria organizzazione, non per i certificati che concedono l'accesso ad altre organizzazioni.

Dopo la comunicazione con il dipartimento di supporto di Pulse Secure, mi hanno offerto un work-around, in cui avrei configurato più Realtà di autenticazione (ciascuna collegata a una specifica norma di accesso e un URL di accesso specifico, che va bene, perché è così che segmentiamo i nostri inquilini oggi).

L'autenticazione verrebbe eseguita indipendentemente dal certificato del cliente. Per quanto riguarda la fase di mappatura dei ruoli (autorizzazione), nella parte superiore viene inserita una regola, che fondamentalmente fa una corrispondenza stringa sul campo "Emittente" della CA.

La regola sarebbe qualcosa sulla falsariga di questo screenshot (questo non è stato testato per funzionare esattamente come scritto, il nome attributo dell'emittente potrebbe essere sbagliato ecc.):

Laregolaverrebbeinseritaincimaesarebbelaprimaregoladaabbinare.Corrispondenzastringadelnomeemittentenelcertificatoe,senoncorrispondealnomedell'emittenteprevisto,nonassegnerebbealcunruoloecontrollandolacasellaInterrompiregoledielaborazionequandoquestaregolacorrisponde,lafasedimappaturadeiruoliterminerebbesenzaassegnareruoli,equindiiltentativodiaccessofallirebbeacausadell'assenzadiruoli.

Imieiragionamenti/ipotesi:

ÈundatodifattocheleCAfidate:saggiuntealdispositivoPulseConnectSecuresianocontrollatepercontenerenomiduplicatisolosetaliCAappartengonoallastessaorganizzazione.Ciòsignificacheilnomedell'emittentepuòessereconsideratounivocoperunospecificodominiosicuro.

Èancheundatodifattocheassegnareruolizeroaunutentechehasuperatol'autenticazionegarantiscechenonavrannoaccessoanessunsistemaprotetto.

Tuttiitentatividiaccessofinoallamappaturadeiruolihannosuperatolaconvalidadelcertificatoesonoquindi"validi", il che implicherebbe che il campo emittente possa essere considerato attendibile per contenere dati validi. Suppongo che un certificato emesso da un'autorità di certificazione valida, ma in cui il nome dell'emittente sia qualcosa di diverso dal previsto, fallirebbe la convalida del certificato prima ancora che raggiungesse la fase di mappatura dei ruoli.

Pertanto, la corrispondenza delle stringhe nel campo dell'emittente in queste circostanze dovrebbe essere un modo sicuro per applicare il fatto che solo l'accesso ai certificati emessi da una CA specifica.

Rischi noti:

Durante l'accesso, un elenco di CA valide: s viene inviato al client allo scopo di filtrare la loro visualizzazione dei certificati di accesso validi in un processo noto come negoziazione del certificato. Questo può potenzialmente far trapelare un elenco di clienti che utilizzano quella particolare appliance, oltre a causare un problema di usabilità per gli utenti che fanno parte di più organizzazioni. Di fronte a non avere un modo alternativo per risolvere questo, trovo che questo rischio è gestibile.

Limite di ambito:

Vorrei porre questa domanda alla sola sicurezza dell'autenticazione e dell'autorizzazione, piuttosto che a domande più ampie sulla progettazione della rete dietro l'appliance VPN.

La mia domanda:

Quindi, dopo aver spiegato tutto questo, penso che la mia domanda nella riga dell'oggetto abbia più senso:

Once a certificate has been validated, is it safe to string-match on the issuer field?

(O mi morderà il culo in un modo che non avevo considerato.)

    
posta Per von Zweigbergk 04.07.2018 - 14:49
fonte

1 risposta

5

Se si considera la CA compromessa, la CA potrebbe emettere anche certificati intermedi con l'oggetto della CA intermedia uguale o simile all'oggetto di una CA radice di cui ci si fida. Questa CA intermedia "mimikri" può quindi essere utilizzata per emettere il certificato foglia, a meno che la CA radice non abbia un set di pathlen che impedisce questo e il pathlen viene effettivamente verificato nell'applicazione.

Il client può quindi autenticarsi con il certificato foglia e il certificato intermedio mimikri e l'autenticazione verrà accettata poiché il certificato foglia è emesso (indirettamente) da una CA attendibile. Ma se poi l'emittente del certificato foglia è controllato vedrà i dati dell'emittente falsi.

O come immagine:

   compromised CA "Bad"                trusted CA "Good"
        |                                    |
   intermediate CA "Good"              real good leaf certificate
   issuer "Bad"                        issuer "Good"
        |
   fake good leaf cert
   issuer "Good"                   

Se è necessario distinguere quale CA radice è stata utilizzata nella creazione del certificato foglia, è quindi necessario verificare l'oggetto della CA radice e non l'emittente del certificato foglia. Non ho idea se l'applicazione specifica supporta questo.

    
risposta data 04.07.2018 - 15:07
fonte

Leggi altre domande sui tag