La sicurezza riguarda l'emissione di certificati jolly per singoli dipendenti

Question

La sicurezza riguarda l'emissione di certificati jolly per singoli dipendenti

#1 da (48 voti)
#2 da (3 voti)
#3 da (0 voti)
#4 da (0 voti)

15

Di recente abbiamo impostato un'autorità di certificazione interna a due livelli. Inoltre, diffondiamo le CA root tramite Active Directory in modo che i certificati della nostra CA interna siano automaticamente considerati affidabili da ogni sistema (Windows) della nostra rete.

I nostri sviluppatori hanno bisogno di certificati SSL per le loro workstation locali. Un'opzione sarebbe quella di generare un certificato con caratteri jolly come *.foo.bar.com .

I vantaggi sono la facilità di implementazione e la dimostrazione futura (se creiamo nuovi sottodomini in futuro, li copra automaticamente).

Tuttavia, il rovescio della medaglia è se dovessimo emettere un certificato con caratteri jolly, come puoi essere certo che un dipendente malintenzionato non lo abuserà?

Immagina una situazione in cui un dev dannoso installa un sito Web sulla workstation locale (mail.foo.bar.com) e può in qualche modo anche avvelenare DNS o modificare il file host locale di un utente. Tale certificato con caratteri jolly presta credibilità al loro sito Web dannoso, rendendolo più autentico.

Sono troppo paranoico? Dovremmo rilasciare i caratteri jolly e rendere più semplice la manutenzione dei certificati o dovremmo generare certificati unici per ogni nome DNS per limitare l'ambito di utilizzo?

Qualcuno ha qualche pensiero? Esperienze?

Modifica

A me sembra che ci siano due ottime soluzioni pubblicate qui:

Separa dev / test e produzione in CA indipendenti come consigliato da @Kotzu. Per noi personalmente Non posso giustificare la creazione di una seconda CA solo per quello scopo. È troppo sforzo per il numero di certificati che abbiamo (40 in totale di cui 10-20 sono dev). Detto questo, penso che sia la risposta migliore.
Modifica la struttura dei nomi DNS come raccomandato da @immbis in modo che la parte "dev" del nome sia il sottodominio e non il sottodominio secondario. Rendendo così il jolly più evidentemente un dominio dev. Ciò allevierebbe le mie preoccupazioni sull'emissione di certificati con caratteri jolly in larga misura. Quindi la rappresentazione può avvenire solo per *.dev.ourdomain.com - con cui sto bene. Detto questo, abbiamo semplicemente programmato troppi posti per renderlo pratico.

Penso che quello che finiremo per fare è continuare a rilasciare certificati SSL completi per ogni dev. Ciò sembra più sicuro poiché lascia molto meno spazio per una persona malintenzionata ad abusare / impersonare una risorsa legittima. Comunque, questa intera situazione è un po 'un caso di croce. Spero che i nostri sviluppatori non stiano agendo maliziosamente e provando a creare siti fasulli. Non voglio solo distribuire cerattivi di caratteri jolly attendibili come caramelle gratis solo per poi averli usati in qualche modo inaspettato.

Se avessimo bisogno di sempre più certificati e l'emissione di singoli certificati diventasse ingestibile, prenderemo in considerazione la possibilità di creare una seconda CA che è ritenuta affidabile solo dalle workstation di sviluppo (non dall'intera azienda) e che emette nuovi certificati jolly.

public-key-infrastructure tls wildcard

posta Brad 01.06.2017 - 22:21

fonte

4 risposte

3

Suppongo che i tuoi sviluppatori abbiano bisogno di certificati SSL localmente affidabili. Come accennato in precedenza, potrebbe valere la pena di prenderlo in considerazione se hanno davvero bisogno di quelli in primo luogo.

Un certificato con caratteri jolly fa riferimento a un certificato con CN o SAN nel formato *.something.example.com .

Il * si espande in una sola etichetta; non si espande su più etichette. Pertanto, quanto sopra corrisponderebbe a foo.something.example.com ( * che si espande su una singola etichetta) ma non a foo.bar.something.example.com (due etichette) e tanto meno a foo.example.com (etichetta mancante).

Tieni presente che se richiamo correttamente, più etichette * sono specificatamente non consentite nei campi SAN e CN certificati. Pertanto non è possibile creare un certificato valido per es. %codice%; sarebbe rifiutato perché ha più *.*.something.example.com in un singolo nome. (Penso che questo sia stato uno dei problemi in cui si è verificato lo Stack Exchange in cui si è verificata l'azienda quando si lavorava per configurare HTTPS su tutta la rete.)

Presumibilmente, ciascuna workstation di sviluppo ha un nome diverso. Quindi potresti avere workstation di sviluppo come * , dev033.internal.example.com o cosa hai.

Assegna quindi a ogni sviluppatore un singolo certificato per una singola SAN jolly con il nome completo del proprio host oltre al nome completo del proprio host. Configuralo per non poterlo utilizzare per firmare altri certificati (certificato foglia).

Ad esempio, assegna allo sviluppatore che utilizza dev7g-vm2.example.com un certificato valido per solo dev033.internal.example.com e dev033.internal.example.com .

In questo modo, lo sviluppatore è libero di impostare alias al proprio host (ad esempio, *.dev033.internal.example.com e api.dev033.internal.example.com funzionerebbero entrambi con tale certificato) ma non è possibile impostare alcun SSL per qualsiasi cosa non sotto il loro il nome host della propria workstation. Supponendo che non esporti web.dev033.internal.example.com a nessun host esterno, al di fuori della tua rete lo sviluppatore non può davvero fare nulla con il certificato che non potrebbero fare con un certificato autofirmato.

Per i punti bonus, ma non realmente necessari: firmali con una CA interna che viene utilizzata solo per tali certificati di sviluppo (o test, o simili).

risposta data 02.06.2017 - 12:00

fonte

0

Dati i tuoi vincoli, direi che dovresti impostare uno script che usi Let's Encrypt (o il tuo generatore di certificati, qualunque cosa funzioni) per generare automaticamente tutti i certificati di sottodominio richiesti per qualsiasi sviluppatore sulla tua rete, con il vincolo critico che < strong> il suffisso del nome di dominio è abbastanza odioso .

Ad esempio, chiunque nella tua coporation crei sottodomini arbitrari come X-untrustworthy-danger-danger-danger.company.com dove X è quello che vogliono (solo ASCII, preferibilmente). Questo dovrebbe essere sufficiente per testare senza ingannare nessuno.

risposta data 02.06.2017 - 13:18

fonte

0

Considerare la possibilità di limitare i certificati rilasciati agli sviluppatori con il campo extendedKeyUsage solo a ciò che è assolutamente necessario. Se non esiste uno scopo di Autenticazione server, verrà rifiutato se presentato da un server Web.

Prendi in considerazione l'utilizzo delle estensioni. Ad esempio, l'estensione basicConstraints distinguerà tra i certificati che possono firmare certificati aggiuntivi ( CA:TRUE ) e quelli che non possono ( CA:FALSE ). In questo modo, se un altro certificato viene emesso da un datore di lavoro dannoso usando il loro certificato, verrà rifiutato ovunque che supporti questa estensione (quindi qualsiasi X509v3).

In questo modo se hai un dipendente malintenzionato con un certificato limitato nel modo seguente non sarà in grado di utilizzarlo in molti modi diversi:

X509v3 Basic Constraints: 
    CA:FALSE
X509v3 Key Usage: 
    Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement

risposta data 02.06.2017 - 18:43

fonte

Leggi altre domande sui tag public-key-infrastructure tls wildcard

Come fare in modo che le persone segnalino incidenti? Password mostrata sullo schermo dopo un crash su Linux, qualche idea del perché?

score 48 · Accepted Answer

Penso che dovresti separare il tuo ambiente. Solo i certificati di produzione dovrebbero essere considerati attendibili su tutta la rete. I certificati di sviluppo e di test devono essere considerati affidabili solo nei computer in cui gli sviluppatori lavorano. In un ambiente più sicuro non si potrebbe nemmeno utilizzare la stessa CA radice per gli ambienti di produzione e sviluppo.