Gestione dei certificati SSL sui prodotti

19

Stiamo sviluppando un prodotto (dispositivo / sistema) che verrà installato sui siti dei clienti. Molti dei nostri clienti (dovrebbero) dovrebbero preoccuparsi della sicurezza e dovrebbero pensarci seriamente.

Il nostro prodotto fornisce un'API via HTTPS, che viene utilizzata dall'interfaccia utente integrata ed è anche aperta ai clienti.

Sto cercando informazioni e consigli su come gestire i certificati SSL installati nel nostro prodotto quando escono dalla fabbrica.

Gradirei qualsiasi input: abbiamo trascurato o perso qualcosa?

As It Stands Today

Attualmente (il sistema è in fase di sviluppo) stiamo installando lo stesso certificato autofirmato in ogni unità di sviluppo e prototipo. Questo chiaramente non ha alcuna catena di fiducia e l'utente vedrà un avvertimento.

Credo che questo sia lo stesso approccio adottato da altri produttori (ad esempio Cisco, Ubiquiti), ma la conferma sarebbe apprezzata.

Opzioni

  1. Iclientisarannoingradodifornireipropricertificati,firmatiinqualsiasimododesiderio(pubblicamenteoprivatamente).Questodaràlorolacatenadellafiduciaepermetteràlorodiesseresicurichesistianodavveroconnettendoa*that*system.

  2. Installazione di un certificato autofirmato diverso su ciascuna unità . Non sono sicuro che vi sia alcun vantaggio nel fare ciò condividendo un singolo certificato autofirmato su tutte le unità, poiché il certificato non è ancora valido.

  3. Installazione di un certificato firmato pubblicamente su ogni unità che lascia la fabbrica. Per quanto posso dire, questo non funzionerà . I certificati sono legati a un FQDN (eventualmente con un carattere jolly) e pertanto non è possibile generare e firmare un certificato per il cliente.

posta Attie 31.03.2017 - 15:54
fonte

4 risposte

30

We are installing the same self-signed certificate into every development and prototype unit.

Installare lo stesso certificato in ogni unità è la peggiore pratica di sicurezza che si possa immaginare quando si ha a che fare con i certificati. Ora sappiamo di non rilasciare prodotti con le credenziali amministrative con codifica hard predefinita. Evitiamo le credenziali di default perché tali credenziali potrebbero essere estratte una volta e utilizzate per compromettere tutti i dispositivi che le implementano. Questa è una situazione molto simile: il certificato predefinito indica che la chiave privata potrebbe essere estratta una sola volta e utilizzata per compromettere tutti i dispositivi che si basano su questo certificato.

Crittograficamente, i certificati di terze parti autofirmati e attendibili funzionano allo stesso modo. Ogni certificato è associato a una coppia di chiavi costituita da una chiave privata segreta e una chiave pubblica non segreta. Se conosci la chiave privata, puoi eseguire tutte le azioni associate alla chiave pubblica e al certificato.

Il compromesso dei certificati predefiniti ha ulteriori implicazioni rispetto alla semplice compromissione dell'autenticazione. Per TLS, a seconda del codice utilizzato, il certificato potrebbe essere utilizzato per stabilire un segreto condiviso. In questi casi, un intercettatore passivo sarebbe in grado di decifrare il traffico TLS dopo aver visto l'iniziale stretta di mano.

Certo, gli amministratori competenti risolveranno questo problema caricando i propri certificati univoci, ma quanti si fermerebbero effettivamente alla fase "basta farlo funzionare" affidandosi al certificato predefinito? Quello che dovresti fare invece è generare una nuova coppia di chiavi all'avvio iniziale o al reset di fabbrica. Questo è il modo in cui operano i dispositivi di rete sicuri. Quando si genera un nuovo certificato, è necessario assicurarsi di disporre di sufficiente entropia nel sistema e di non generare generatori di fattori fattorizzabili.

    
risposta data 31.03.2017 - 16:13
fonte
5

Potresti fare qualcosa come offrire un certificato unico per

product-serial-number.product-name.company-name.com

e farlo emettere da qualcosa che ha qualcosa di fidato nel percorso di certificazione. Il certificato non sarebbe stato ancora considerato attendibile a tale scopo, ma qualcuno potrebbe verificare il certificato con un adesivo sulla scatola (e opzionalmente installarlo nell'archivio dei certificati). Purtroppo, Chrome e Edge non semplificano la visualizzazione dei dettagli dei certificati nelle pagine HTTPS, quindi sarà difficile.

    
risposta data 02.04.2017 - 04:26
fonte
4

Sono stato esattamente nella stessa situazione, essendo stato responsabile dello sviluppo di un server HTTPS (e del contenuto associato, API REST e così via) incorporato in un dispositivo consumer.

Come già indicato nella domanda, l'installazione di un certificato firmato CA (Certificate Authority) non è purtroppo un'opzione, perché il certificato deve essere legato a un dominio.

Nella mia esperienza, il meglio che puoi fare è generare una coppia di chiavi e un certificato univoci in ogni dispositivo. Nel mio dispositivo questo avviene durante il primo avvio dopo che il firmware è stato caricato nel dispositivo e anche se viene eseguito un reset di fabbrica. Il microcontrollore in uso ha un RNG hardware utilizzato per questo scopo.

Utilizzare la stessa coppia di chiavi e il medesimo certificato su tutti i dispositivi sarebbe particolarmente pericoloso se si considera che un utente malintenzionato potrebbe semplicemente ottenere uno dei propri dispositivi ed estrarre la chiave privata da esso, a quel punto tutti i dispositivi sarebbero stati compromessi.

Quindi, secondo la mia esperienza, il meglio che si possa davvero fare (poiché nessuna soluzione ideale sembra esistere) è informare i propri clienti sul perché devono riconoscere l'avviso di sicurezza del proprio browser sul certificato autofirmato nei manuali del prodotto e, almeno, assicurati che ogni dispositivo crei la sua chiave privata e il suo certificato univoci.

    
risposta data 01.04.2017 - 00:41
fonte
4

Customers will be able to provide their own certificates, signed in whatever manner they wish (publicly, or privately). This will give them the chain of trust, and will allow them to be sure that they really are connecting to that system.

Questo suggerisce che A ) un'installazione tipica avrà un nome di dominio "reale", visibile sull'internet pubblico (al contrario di un nome di dominio intranet o di un indirizzo IP privato) o B ) un cliente tipico avrà le conoscenze tecniche necessarie per utilizzare la propria autorità di certificazione interna.

Se (A) è true, il tuo prodotto potrebbe chiamare Let's Encrypt e ottenere in tal modo un certificato firmato. Ciò richiede che il servizio abbia entrambi un nome di dominio "reale" e che sia completamente visibile per l'Internet pubblica (ad esempio non è protetto da firewall sulle porte 80 e / o 443). Let's Encrypt i certificati possono essere acquisiti in modo completamente automatizzato e non richiedono alcuna procedura manuale, a condizione che entrambi conoscano e controllino (possono servire al traffico web) il FQDN. Naturalmente, dovresti interagire con il servizio in modo ragionevolmente "educato", soprattutto considerando che è gratuito (cioè non inviarlo un gran numero di richieste contemporaneamente, implementare il backoff di ripetizione esponenziale, ecc.).

Se (B) è vero, allora dovresti assolutamente andare con l'opzione che descrivi (cioè lasciare che il cliente fornisca un certificato), perché i tuoi clienti sono in una posizione migliore per risolvere questo problema rispetto a te. Tuttavia, nella maggior parte dei settori, (B) non è vero. Tuttavia, un cliente sufficientemente avventuroso potrebbe volere l'opzione di farlo, quindi dovresti fornirlo comunque.

Se né (A) né (B) sono veri, allora dovresti seguire una delle altre risposte. In questo caso, un cliente tipico non ha la possibilità di fornire un buon certificato, quindi non dovresti renderlo responsabile di farlo. Potresti comunque voler fornire un'opzione per l'utilizzo di un certificato personalizzato, ma non dovresti renderlo predefinito.

    
risposta data 01.04.2017 - 02:38
fonte

Leggi altre domande sui tag