come implementare TLS tra server Web e dispositivi incorporati

I requisiti di progettazione del tuo sistema non mi sono completamente chiari. Ma supporrò che tu abbia il pieno controllo sulla configurazione e che questa configurazione abbia solo i seguenti requisiti:

• connessione protetta tra dispositivi e server di gestione centrale
• la gestione centrale deve essere in grado di inviare comandi ai dispositivi in qualsiasi momento
• L'indirizzo IP per i dispositivi è dinamico e non è noto al server di gestione in primo piano, vale a dire che il dispositivo deve in qualche modo annunciarsi sul server inizialmente.

Ci sono diverse opzioni per implementarlo, come

• Crea una VPN tra i dispositivi e il sistema di gestione. Questo può essere fatto ad esempio con IPSec o OpenVPN e con alcune varianti anche con SSH. All'interno di questa VPN i dispositivi possono avere un indirizzo IP privato fisso, quindi l'indirizzamento di un dispositivo dal server non è un problema. E TLS non è necessario in quanto la VPN protegge già le connessioni contro gli aggressori al di fuori della VPN.
• Creare una connessione TLS dal dispositivo al sistema di gestione che richiede solo un certificato sul lato del sistema di gestione. Questa connessione TLS può quindi essere utilizzata con un protocollo personalizzato per comunicare tra server e client. A seconda della configurazione e delle restrizioni a causa dei firewall, potrebbe essere utile non creare una semplice connessione TLS direttamente su TCP ma utilizzare WebSockets sicuri per la connessione bidirezionale. Tuttavia, è necessario solo un certificato sul lato server che sia considerato affidabile dal client.

Queste impostazioni sono simili in quanto la connessione protetta (ad es. tunnel VPN o TLS) viene avviata dal client, poiché l'indirizzo IP del client è dinamico e il sistema di gestione ha un IP statico o almeno un nome host statico. Potrebbe essere utile aggiungere dell'autenticazione del client a questo perché non vuoi che qualche attacker si connetta al tuo sistema di gestione.

Un modo sarebbe creare il proprio PKI con la propria CA e rilasciare un certificato univoco per ciascun dispositivo. L'oggetto di questo certificato può essere un ID dispositivo che è possibile utilizzare per identificare il dispositivo. Questi certificati lato client possono essere utilizzati per l'autenticazione nella VPN o come certificati client nella connessione TLS. Inoltre, se un certificato viene compromesso (ad esempio, qualcuno ha hackerato il dispositivo), puoi semplicemente bloccare centralmente l'accesso con questo certificato nel tuo sistema di gestione.

There are hundreds of such devices not having host-name and their IP is not static. So SSL certificates may not be possible here???

Ricorda: prima di provare a capire le soluzioni di sicurezza, inizia a determinare il profilo della tua minaccia. Quali attacchi stai cercando di prevenire?

Direi che uno dei principali è impedire a un utente malintenzionato di fingere di essere il server di controllo e di inviare con successo comandi ai controller. Per questo, quindi, vuoi che i dispositivi siano in grado di autenticare il server, e che richiede un certificato sul lato server , non sui dispositivi - un HTTPS tradizionale (o simile a HTTPS, se stai utilizzando un protocollo diverso), se i client avviano una connessione al server o un certificato sul lato client se il server sta iniziando una connessione con i dispositivi.

There are hundreds of such devices not having host-name and their IP is not static. So SSL certificates may not be possible here???.

I certificati di autenticazione client SSL possono essere emessi senza un nome risolvibile DNS o indirizzi IP fissi. Il server non deve essere configurato per utilizzare DNS per verificarli.

Come ha suggerito Stephan, alzare il proprio PKI per questo sistema sembra l'approccio giusto. A meno che la tua organizzazione non disponga già di una propria PKI, questo può essere * semplice come utilizzare OpenSSL per generare il proprio certificato autofirmato, quindi utilizzare tale certificato CA per firmare tutti i certificati server e client. Dovrai installare il certificato CA personalizzato come certificato di radice affidabile in ciascuno dei server e dei client. (Se questi fanno parte di un ecosistema chiuso, prendi in considerazione la possibilità di rimuovere i certificati di root attendibili di cui i client non hanno bisogno.)

Probabilmente avrai un inventario dei dispositivi come parte della tua organizzazione. Qualunque sia l'ID che viene loro assegnato, sarebbe probabilmente appropriato impostare il DN dei certificati. Ma certamente non devi farlo neanche, soprattutto se non vuoi mettere il tuo nome interno sui tuoi certificati. Invece, è possibile pre-generare una grande pila di certificati in anticipo e consegnarli a nuovi clienti quando si registrano con te. Quindi tenere traccia dell'ID del certificato e dell'ID client al quale è stato rilasciato e utilizzare tale relazione per concedere le autorizzazioni del client. Ciò mantiene la CA di emissione in modalità sicura dal sistema che registra i tuoi clienti.

Se la tua organizzazione ha già una PKI, consultati con loro. Dovrebbero assegnare un'unità organizzativa riservata esclusivamente ai tuoi dispositivi. È quindi possibile fare in modo che il server verifichi che i certificati client abbiano la OU valida solo per i propri dispositivi. In questo modo, altri gruppi della tua organizzazione non potranno emettere certificati su dispositivi non autorizzati o rogue.

Ricorda che una volta che i dispositivi sono fuori sul campo possono essere rubati, manomessi e / o smontati. Non mettere più fiducia nei certificati client di quanto necessario. Non consentire a questi stessi certificati di dispositivo di concedere autorizzazioni amministrative sul server. E se un dispositivo scompare, invalida rapidamente il suo certificato.

* Mi scuso per aver usato la parola "semplice" insieme a PKI.