SSL unidirezionale può proteggere un dispositivo IoT?

9

Sto considerando un dispositivo IoT collegato alla mia rete locale (impostazioni predefinite, nessuna VPN, nessun NAT, nessuna DMZ) con o senza accesso a Internet. Il mio dispositivo funzionerà come un server HTTP che offre un meccanismo RPC con autenticazione e autorizzazione. Si fa pubblicità con mDNS e ci parlo usando la mia app mobile o il mio RaspberryPi.

Sembra che la norma nello sviluppo dell'IoT sia quella di avere un reciproco (bidirezionale) SSL. Ciò significa che SSL unidirezionale non può proteggere il mio traffico? Perché?

Appunti:

Comprendo le differenze tecniche tra SSL a una e due vie, non capisco perché la modalità a senso unico (quasi) non sia mai stata considerata nella produzione IoT.
Capisco che avere SSL reciproco per un dispositivo locale sia difficile: è necessario condividere la chiave pubblica del server e certificare il client e viceversa. Unidirezionale, d'altra parte, sembra più semplice (non richiede l'intervento dell'utente).
Alcuni dispositivi prodotti in serie come Philips Hue preferirebbero avere un endpoint http locale aperto e non protetto rispetto a una crittografia SSL unidirezionale. Perché uno dovrebbe fare questa scelta?
Mi aspetto che questa domanda non sia basata sull'opinione. Mi scuso se questo è il caso.

— valentin
fonte

8

SSL / TLS funziona bene quando il "server" si trova in una posizione nota (un nome host fisso) che può corrispondere al CN del certificato che presenta.

Questo non funziona bene per i dispositivi su reti domestiche (ad esempio la maggior parte dei dispositivi IoT) perché tendono a ottenere indirizzi IP emessi da blocchi RFC1918 e non dispongono di voci DNS. Ciò significa che non possono essere emessi con certificati (ma possono farlo, ma la maggior parte dei browser li rifiuterà). Questo è il motivo per cui dispositivi come Philips Hue utilizzano endpoint HTTP non sicuri del dispositivo, fondamentalmente si basano sull'accesso alla rete da proteggere per proteggere il dispositivo.

Quando viene utilizzato il TLS reciproco, è quando il dispositivo si connette a un servizio centrale, il client dispone della propria chiave cert / privata per autenticare che è in grado di agire per conto del proprietario con quel server centrale.

Per chiarire la tua domanda, non è necessario distribuire i certificati cert / key a tutti i client, è necessario solo il certificato della CA che ha emesso il certificato per dimostrare che il certificato è attendibile.

MODIFICARE:

Un buon esempio di una connessione di dispositivo locale protetta è l'illuminazione Tradfri di IKEA che utilizza COAP su DTLS con una chiave pre-condivisa (in un codice QR) sul dispositivo che viene utilizzata per generare una chiave per client. Ciò garantisce l'accesso fisico all'installazione di un nuovo client e protegge i dati in volo sulla rete locale.

— hardillb
fonte

Se l'host non ha un nome DNS o indirizzo IP fisso, la normale verifica del certificato ha esito negativo, poiché il certificato afferma che il dispositivo a quell'indirizzo è chi dice di essere (normale "single-side" SSL). Per SSL con autenticazione reciproca non dovresti usare la stessa chiave / certificato per entrambe le parti. Il server e il client devono raggiungere il proprio certificato / chiave firmati da una CA reciprocamente affidabile

— hardillb

Grazie per la risposta e scusa per il lungo silenzio @hardillb. "Ciò significa che non possono essere emessi con certificati (ma possono farlo, ma la maggior parte dei browser li rifiuterà)." Considerando una comunicazione con il mio dispositivo IoT, non vedo quando userò un browser per farlo ... "non è necessario distribuire il server cert / key a tutti i client, solo il certificato della CA" Questo è per TLS a senso unico, giusto? Perché per mutuo credo che tu debba dare la certezza e la chiave, il che rende le cose molto più difficili. Per quanto riguarda Tradfri, la chiave pre-condivisa è per l'autenticazione, non per la crittografia.

— valentin,

No, la chiave precondivisa tradrfi è quella di eseguire la stretta di mano e creare una chiave per dispositivo per la crittografia

— hardillb

1

Generalmente, TLS è buono per molto più di x.509, ma molte implementazioni lo limitano a solo x.509.

x.509 è una tecnica per un trust indiretto sicuro. "A" si fida di "B", se "B" ha un certificato, che è firmato da "C" e "C" è considerato attendibile da "A". Funziona anche nella vita reale; ti fidi di qualcuno che non conosci, se una lettera viene presentata firmata da una persona di cui ti fidi. Forse vedi la trappola: se la lettera dice, ti preghiamo di dare una tazza di caffè che non darai la tua auto. Pertanto, anche le informazioni aggiuntive nel certificato sono rilevanti ai fini dell'ambito del trust. Ecco perché un server di solito ha il suo nome DNS o indirizzo IP nel suo certificato. Generalmente puoi includere informazioni diverse (ad es. "Lampada da soggiorno"), ma molte implementazioni sono almeno preconfigurate per usare / controllare le cose DNS / IP. E tutto ciò funziona solo se a qualcuno interessa il fidato "

Se puoi passare del tempo, controlla la tua implementazione, se offre anche suite di crittografia PSK. In caso contrario, forse è possibile regolare il "controllo di convalida" del certificato del server. Ma richiede molta lettura per trovare una buona soluzione. E a volte l'implementazione TLS usata non lo offre.

— Achim Kraus
fonte