it-swarm.dev

Esiste un certificato SSL senza scadenza?

Esiste un certificato SSL senza scadenza? Il nostro scenario è che sviluppiamo e vendiamo dispositivi embedded (pensate a "internet delle cose"). Su questi dispositivi sono in esecuzione piccoli server Web che consentono determinate funzioni amministrative (come un router domestico Cisco consente azioni amministrative). Vorremmo avere una buona sicurezza su questi piccoli server Web, cioè non passare password di testo chiaro. L'approccio più semplice è utilizzare SSL per passare la password in una sessione SSL crittografata. Tuttavia, questi piccoli server Web non sono sotto il nostro controllo una volta che li vendiamo ai nostri clienti. Come gestiamo i certificati SSL in scadenza in questi dispositivi? L'aggiornamento di certificati SSL su sistemi non sotto il nostro controllo non sarebbe facile. È meglio fornire un'esperienza di accesso sicuro per questo tipo di dispositivo? Se l '"Internet delle cose" decolla davvero, devo credere che questo diventerà un problema comune.

16
Keith Hill

In effetti, sì: potresti generare il tuo certificato di root (ovvero diventare la tua autorità di certificazione) e quindi firmare ogni CSR certificato SSL con la chiave di root. Quindi sarai in grado di impostare la data di scadenza nel futuro (ad esempio, utilizzare una stima della durata del prodotto molto ottimistica) sul certificato SSL installato su ciascun dispositivo. L'unico aspetto positivo dell'unguento è che il certificato radice dovrà essere installato come radice attendibile in ciascun browser Web client che accede alle funzioni di amministrazione. Se questo è troppo complicato per i tuoi utenti, potrebbero semplicemente fidarsi di ogni certificato individualmente che potrebbe essere più facile. In realtà, dopo aver pensato un po 'di più a questo proposito, ogni singolo certificato dovrebbe essere comunque associato a un determinato nome host o indirizzo IP per evitare altri avvisi del browser (ad esempio, il nome host del certificato non corrisponde al nome host effettivo nel browser), quindi il nome host dovrebbe essere "hard coded" nel dispositivo. Poiché ciò non è pratico, ogni utente dovrebbe fare clic oltre l'avviso del browser per accedere al dispositivo. La soluzione alternativa è che dovrai farlo in modo che possano aggiornare il certificato da soli per rimuovere completamente gli avvisi del browser o potresti far sì che il dispositivo generi il proprio certificato.

My ZyXel NAS offre la funzionalità per generare il proprio e consente di impostare nome comune per il certificato:

enter image description here

La generazione dei propri certificati avrà gli stessi vantaggi di crittografia dell'utilizzo delle autorità di certificazione pubbliche e poiché i singoli dispositivi avranno comunque i propri nomi di host privati, questa soluzione potrebbe essere più appropriata rispetto all'utilizzo di una CA pubblica. Certificati Intranet sono disponibili ( ma vengono eliminati gradualmente ), ma poiché richiedono un nome di dominio completo o un indirizzo IP, i clienti dovrebbero aggiornarli sul dispositivo.

Si prega di vedere questo articolo per i dettagli completi su come funziona.

5
SilverlightFox

No, e ci sono diverse ragioni per questo:

  • Un certificato contiene non solo informazioni sul proprietario, ma contiene la sua chiave pubblica. La chiave privata corrispondente è nota solo al proprietario del certificato e, utilizzando la crittografia a chiave pubblica, è possibile verificare che l'endpoint della connessione SSL sia realmente il proprietario (o almeno quello che possiede la chiave privata). Il certificato stesso è firmato da un'agenzia di certificazione attendibile dal browser (tutto è semplificato). Ma la forza crittografica di tutto ciò dipende dalla dimensione delle chiavi e dagli algoritmi utilizzati. L'aumento delle dimensioni rende tutto più lento, meno dimensioni rende tutto meno sicuro. E poiché i computer diventano più veloci e gli esperti di crittografia solo meglio e trovando nuovi modi per decifrare un algoritmo, la protezione crittografica del certificato si indebolisce con il tempo. Pertanto, ogni certificato deve scadere prima che la protezione diventi debole.

  • Un certificato potrebbe essere compromesso, ad es. alcuni cattivi o agenzie potrebbero ottenere la chiave privata e quindi identificarsi come proprietario o decifrare tutto il traffico. In questo caso il certificato viene revocato e le informazioni sulla revoca sono rese accessibili al pubblico. Se il certificato non dovesse mai scadere, queste informazioni dovrebbero essere conservate per sempre e la memoria necessaria e il tempo necessario per controllare un certificato per la revoca aumenterebbero. In questo modo i certificati per utenti finali più economici hanno un tempo di scadenza più breve rispetto a certificati più costosi, perché gli utenti finali a basso costo probabilmente non proteggono anche la loro chiave privata, quindi è bene che le loro revoche possano essere gettate via dopo la data di scadenza.

5
Steffen Ullrich

RFC 5280, Sezione 4.1.2.5 ("Validità") non risponde alla tua domanda tecnicamente esattamente.

In breve, un certificato con una data di scadenza di 99991231235959Z (23:59 GMT del 31 dicembre 9999) soddisfa i tuoi requisiti esatti, ma RFC 5280 richiede anche che tu debba essere in grado di revocare quel certificato per interrompere il percorso di certificazione ( cioè revocando il certificato) prima di questa data.

La data di scadenza è anche considerata come una data in cui l'utente deve verificare se le misure tecniche in atto soddisfano ancora gli standard attuali (ad esempio se devono passare da un modulo lungo 1024 bit a un modulo lungo 2048 bit o aggiornare il loro server da DES in AES).

Per lo stesso motivo, le CA commerciali si impegnano a non emettere certificati per più di 3 anni in futuro e richiedono nomi DNS risolvibili pubblicamente su spazio IP pubblico; molto probabilmente, entrambi questi requisiti sono bloccanti per te.

Quindi, alla fine, ci sono solo due opzioni:

  • diventa la tua CA principale e rilascia automaticamente tali certificati. Un criterio per emettere i certificati "per sempre" non soddisfa le considerazioni sulla sicurezza dei fornitori di browser e SO, quindi ciò richiederà agli utenti di importare manualmente la CA principale. Consigliare agli utenti di fidarsi della propria CA principale è un'operazione delicata e potrebbe non essere accettabile da parte degli utenti. La CA potrebbe utilizzare le restrizioni del nome x509 (quindi i certificati emessi sono validi solo per alcuni domini o sottoreti IP), ma tutti quelli che hanno un po 'di sicurezza in mente si chiederanno comunque se è una buona idea andare in quel modo. In breve: questo può diventare molto complesso, complicato e rischioso - non farlo.

  • in fase di fabbricazione o "ripristino delle impostazioni di fabbrica", genera una chiave privata individuale su e/o per ogni dispositivo ed emette un certificato autofirmato con una data di scadenza, ad es. 10 anni nel futuro (o la data speciale sopra menzionata). La documentazione deve chiedere agli utenti di rimuovere i certificati precedentemente installati dopo il "ripristino delle impostazioni di fabbrica" ​​e di importare quel certificato specifico al fine di evitare l'avvertimento del browser. Karma extra per spiegare all'utente perché questo deve essere fatto :)

Tieni presente che quando stai utilizzando la data "per sempre", il certificato potrebbe comunque diventare "meno sicuro" o "non valido". Ad esempio, i browser e i sistemi operativi impongono una lunghezza minima della chiave o algoritmi (non funzionanti) per rifiutare e aggiornare tali requisiti di conseguenza. Quindi in questo momento 1024 bit potrebbero "funzionare", ma i browser iniziano a visualizzare le connessioni utilizzando meno 2048 bit per essere "non sicuri" o come "non validi". E gli algoritmi si rompono anche al punto in cui i browser non si fidano più di loro. Se il tuo certificato autofirmato lo utilizza, dovrai aggiornarlo di conseguenza.

3