Cosa c'è di sbagliato nello scambio fisico dei certificati invece dell'handshake?

4

L'organizzazione XYZ preferisce non fidarsi di nessuna CA ma solo di se stessa. Ha una serie di certificati che sono fisicamente memorizzati su ogni client e server che sono di nuovo attendibili solo dalla loro CA Enterprise. Tutti i browser interni sono impostati per fidarsi di questa CA Enterprise. Quindi, naturalmente, tutti gli altri siti web (come Google) non sono affidabili, come indicato dal browser.

Tutti gli altri programmi (Java, Node.js, .NET, ecc.) mantengono il sottoinsieme dei certificati richiesti e li usano per collegarsi tra loro.

Cosa c'è di sbagliato in questa immagine? Quali argomenti dovrebbero essere usati per convincere la direzione a usare la pratica comune?

Dopo che tutti i dirigenti dicono - ci fidiamo l'un l'altro e chi vuole lavorare con noi dovrebbe fidarsi di noi. Non c'è altro modo di comunicare per noi.

Chiarificazione delle domande: Forse mi sbaglio, ma sento che la soluzione spiegata è sbagliata. Non riesco a convincere il management che questo è sbagliato e ho chiesto alla community di darmi alcuni argomenti.

Personalmente (tenendo conto descritto nelle risposte costo aggiuntivo) Vedo solo un problema - dal momento che tutti i siti esterni sono già contrassegnati come utente privato / pericoloso normale non presterà attenzione a tale avviso. Non è diventato un avvertimento, ma è risaputo che il web è pericoloso e il surf è il tuo rischio. La parte peggiore: ci fidiamo solo della rete interna, ma dal momento che i singoli computer sono più vulnerabili, qualsiasi interruzione su qualsiasi computer esporrà l'intera rete interna dal momento che si fida di se stessa.

In realtà, ad essere onesti, non è affatto un mio problema. Il mio problema è che quando provo a utilizzare altri approcci o programmi standard (come ad esempio Node.js tenta di raggiungere la web api interna), esso (come programma onesto) dice - "certificato autofirmato in catena locale" e si rifiuta di accedere a questa connessione . Quindi, per me è un incubo (o in realtà un costo) trovare una soluzione per ogni programma (Node.js, Java, VuGen, QTP, .NET, ecc.) Ottenere i certificati e tenerli sincronizzati.

La mia domanda è quali sono gli argomenti che posso utilizzare per convincere il management che questa soluzione è sbagliata.

    
posta Alex 15.12.2016 - 03:43
fonte

3 risposte

5

Organization XYZ prefers not to trust any CA but only itself.... All inside Browsers are set to trust this Enterprise CA. So, naturally, all other web sites (like Google) are not trustworthy which is indicated by browser.

What is wrong with this picture?

Ciò che è sbagliato è che l'organizzazione XYZ è che utilizza il punto di applicazione sbagliato .

Se non si fidano del mondo esterno, devono rimuovere i proxy Web in uscita e assicurarsi che le regole del firewall non consentano tutti gli accessi in uscita sulle porte 80/443.

Oppure potrebbero implementare un proxy draconiano con TLS MITM che limita l'accesso solo a quei siti esterni che considerano legittimi. (E se lo fanno, ovviamente, dovrebbero fidarsi ancora delle autorità di certificazione esterne, poiché l'accesso ai siti approvati viene applicato dal proxy, non dal livello del certificato TLS.)

Se l'Organizzazione XYZ non è disposta a prendere questi - certamente abbastanza drastici - passi, allora devono seriamente riconsiderare perché stanno stigmatizzando ciò che è - per loro stessa ammissione - un accesso accettabile. Poiché diffidando di tutte le altre CA, stanno posizionando i certificati di convalida estesa allo stesso livello dei certificati Snakeoil autofirmati. Se hai intenzione di buttarli via, dovresti semplicemente bloccare ogni ... . oh, aspetta, quello era il passaggio 1.

    
risposta data 15.12.2016 - 04:24
fonte
3

Ci sono due parti nella tua domanda:

È sbagliato utilizzare una CA interna all'interno di un'organizzazione?

Qui non c'è niente di sbagliato, a condizione che il processo di consegna dei certificati sia corretto. Ciò suppone che i certificati di macchina vengano stabiliti solo al livello amministrativo appropriato e che vengano installati sulla macchina solo dagli amministratori e che nessun altro possa rubarli. Ciò suppone anche che se i certificati vengono consegnati a dipendenti o partner, ci sono alcune informazioni sui loro usi e il processo garantisce che possano essere utilizzati solo dalla persona corretta.

Risparmia un po 'di denaro a costo di non fidarsi dei certificati nel mondo esterno. Sarebbe problematico per i processi Business to Client, ma va bene per gli scambi interni o gli scambi con un numero limitato di partner noti

È sbagliato rimuovere tutti i certificati predefiniti dai browser interni?

È strano a meno che le macchine interne non possano accedere a Internet globale. Se la rete interna se fisicamente isolata dagli accessi a Internet o se un proxy blocca tutto tranne un numero limitato di macchine, gli altri certificati sono solo inutili e possono essere rimossi ... anche se non fornisce alcuna sicurezza aggiuntiva.

Se ai dipendenti è consentito accedere a Internet rimuovendo i certificati è possibile evitare l'installazione automatica di plug-in firmati da fonti ben note, ma a costo di un numero elevato di falsi positivi. Il rischio qui è di istruire gli utenti ad accettare qualsiasi nuovo certificato senza nemmeno leggere il messaggio, il che può essere peggio. Quindi IMHO ha senso solo se gli utenti non possono bypassare lo stato non attendibile dei certificati esterni.

Ma fintanto che le macchine appartengono al datore di lavoro, può scegliere cosa può essere installato o meno su di esse e per cosa possono essere utilizzate ... anche se la rimozione del certificato predefinito potrebbe non essere il modo migliore e non può essere il solo uno.

Limiti del certificato privato

I certificati privati vanno bene per l'autenticazione o per la criptazione degli scambi di dati. In genere, sono perfettamente adatti per HTTPS.

Ma non puoi usarli per non ripudiarli, almeno con le smartcard (*). Se emetti e consegni un certificato, non sarai mai in grado di dimostrare di non aver mai tenuto una copia della chiave privata. Nessun tribunale accetterà questo perché hai un interesse qui. Questo è il motivo per cui il ripudio non è meglio convalidato da un emittente di terze parti .

(*) Come detto da @ AndréBorie, questo non si applica se è stata scambiata solo una CSR, ma solo se fornisci una smartcard

    
risposta data 15.12.2016 - 10:40
fonte
1

Se ho letto correttamente, direi che la cosa sbagliata è che il personale sta perdendo tempo manualmente applicando il certificato di fiducia invece di lasciare che il browser e le infrastrutture Public Key esterne facciano il loro lavoro.

Anche se è vero che il modello di affidabilità del certificato è gravemente danneggiato, funziona principalmente. Almeno finché è necessario il browser per verificare la validità e l'estensione del certificato mantenere aggiornato il browser (in modo che i trust della CA radice possano essere rapidamente aggiornati).

Vuoi davvero affidarti al personale per fare ciò che il browser può fare? Quali spese generali portano? Questi costi generali si traducono in costo , il che significa come convincere la "gestione" a cambiare idea.

    
risposta data 15.12.2016 - 21:38
fonte

Leggi altre domande sui tag