Domanda:
Devo cambiare la chiave privata quando rinnovo un certificato?
Commander Keen
2013-01-10 14:17:23 UTC
view on stackexchange narkive permalink

Il mio dipartimento di sicurezza insiste che io (l'amministratore di sistema) crei una nuova chiave privata quando desidero rinnovare un certificato SSL per i nostri server web. Affermano che è la migliore pratica, ma i miei tentativi di googling non sono riusciti a verificare la loro affermazione. Qual è il modo corretto?

Il più vicino che ho trovato è Devo rigenerare una nuova chiave privata SSL ogni anno?, ma non spiega davvero perché sarebbe necessario cambiare le chiavi.

So che non è un grosso problema cambiare le chiavi mentre ci sono, ma non sono mai stato uno che fa quello che mi viene detto senza una ragione adeguata o spiegazione :)

Personalmente sono rimasto davvero sorpreso dal fatto che le CA consentano anche il rinnovo con la stessa chiave.
È interessante notare che, come menziona di seguito @Thomas Pornin, lo stesso dipartimento di sicurezza `` non insisterà nel generare nuove chiavi ogni anno per i propri server SSH, anche se la situazione è simile, dal punto di vista della sicurezza. '' ... è scomodo poiché si rompe i file .ssh / known_hosts dei client
Dieci risposte:
#1
+65
Polynomial
2013-01-10 15:07:39 UTC
view on stackexchange narkive permalink

Direi che il loro suggerimento non è molto concreto, a meno che tu non stia utilizzando chiavi di dimensioni orribilmente piccole, nel qual caso hai un problema completamente diverso.

Una chiave a 2048 bit, secondo la maggior parte delle stime, ti manterrà al sicuro almeno fino al 2020, se non più a lungo. Se utilizzi chiavi a 1024 bit o meno, sei al di sotto dello standard e ti consiglio di aggiornare immediatamente a 2048 bit. Se attualmente stai utilizzando chiavi a 1536 bit, dovresti essere al sicuro per un anno o due.

Ovviamente, questo è tutto accademicamente parlando. La probabilità che qualcuno sia in grado (o incline) a decifrare la tua chiave SSL a 1024 bit entro un anno è estremamente bassa.

Come menzionato nella domanda che hai collegato, ci sono vantaggi e svantaggi.

  • Dà meno tempo a un attaccante per decifrare la chiave. Un po 'un punto controverso se utilizzi comunque chiavi di dimensioni ragionevoli.
  • Blocca i malvagi che potrebbero aver compromesso la tua chiave privata. Improbabile, ma sconosciuto.
  • Ti offre la possibilità di aumentare la dimensione della tua chiave per essere davanti alla curva.

Svantaggi

  • In realtà non ti offre alcuna protezione concreta contro il cracking delle chiavi a meno che tu non stia utilizzando chiavi terribilmente piccole.
  • I plugin di controllo SSL / anti-MitM per i browser potrebbero avvisare l'utente che il la chiave è cambiata. Questo è, a mio parere, un debole svantaggio: la maggior parte degli utenti non lo utilizzerà.
  • Potrebbe causare avvisi temporanei in relazione a politiche e implementazioni HSTS più rigide.
  • Richiede lavoro. Potresti fare qualcos'altro.

Quindi su entrambi i lati ci sono alcune ragioni deboli e alcuni casi d'angolo che potresti dover considerare. Mi inclino leggermente verso l'angolo "non farlo a meno che non sia necessario", purché utilizzi chiavi a 2048 bit o superiore.

La cosa più importante è chiedere a loro perché pensano che sia necessario: potrebbe essere che tu abbia una ragione relativa all'infrastruttura per aggiornare le chiavi di cui non siamo a conoscenza. Se non riescono a trovare un argomento solido ("perché no?" Non è veramente valido), allora dovrebbero probabilmente rivalutare il loro consiglio.

Perché l'utilizzo di una nuova coppia di chiavi nel certificato richiede molto più lavoro rispetto a un rinnovo con la stessa chiave?
@CodesInChaos Non lo fa, ma aggiornare i certificati client associati è sicuramente molto più faticoso. Se ricordo bene, quando aggiorni il certificato del server senza cambiare la chiave, puoi mantenere tutti i certificati del client senza problemi. Ma se cambi la chiave, devi rinnovare anche tutti i certificati del cliente.
Inoltre avrai spesso bisogno di un riavvio completo del tuo server web (facendo riferimento ad Apache, ma supponendo che altri richiedano lo stesso) se cambi la tua chiave, ma puoi fare un riavvio regolare (nessun tempo di inattività) se stai solo cambiando il certificato . Ovviamente tutto ciò potrebbe essere mitigato avendo un ambiente HA, ma comunque ...
@SteelCityHacker Questo diventa un problema solo se gestisci un sito con migliaia di visite al minuto. Nella maggior parte dei casi potresti essere sfortunato e ricevere una singola richiesta durante il riavvio del servizio Apache, poiché è così veloce.
È importante notare che la perdita silenziosa del controllo della chiave è un altro rischio. Sei sicuro che nessuno abbia gestito male un server negli ultimi anni in un modo che potrebbe aver fatto trapelare una chiave? Che nessuno ha qualche copia in giro? Nuovo certificato, nuova chiave. Ricominciare da capo quell'orologio di solito conta ** più ** del rischio che qualcuno prenda in considerazione la tua chiave, indipendentemente dalla dimensione della chiave.
Nella maggior parte dei casi a nessuno importa se riavvii il tuo server nel cuore della notte
#2
+46
Thomas Pornin
2013-01-10 18:10:13 UTC
view on stackexchange narkive permalink

Cambiare la chiave privata non è una best pratica, è una pratica diffusa ; ha infatti poco a che fare con la sicurezza, e molto con il modo in cui le comuni CA gestiscono i rinnovi dei certificati, ovvero il più delle volte come un nuovo certificato, con una nuova generazione di chiavi private. È più semplice, dal lato CA , non fare nulla di speciale per un rinnovo. Da qui l'abitudine di cambiare le chiavi.

Gli stessi amministratori di sistema non insisteranno nel generare nuove chiavi ogni anno per i loro server SSH, anche se la situazione è simile, dal punto di vista della sicurezza Visualizza. O, più precisamente, cambiare una chiave del server SSH è un po 'scomodo poiché interrompe i file .ssh / known_hosts dei client. Pertanto è consuetudine evitare di modificare le chiavi del server SSH. Pertanto, le chiavi del server SSH sono di lunga durata. Nessuno salta davvero un battito di cuore su questo. Perché dovrebbero preoccuparsi di chiavi SSL di analoga forza crittografica?

La migliore pratica è cambiare la chiave quando i progressi tecnologici hanno reso la tua chiave un po 'vulnerabile, tenendo conto della paranoia generale (spesso chiamato "per motivi di conformità"); quindi potresti considerare che in questo momento, nel 2013, una chiave RSA a 1024 bit dovrebbe essere sostituita con una più lunga, anche se siamo ancora lontani dall'essere in grado di rompere tale chiave. Se la tua chiave RSA è 1536 bit o più ampia, non c'è alcun motivo crittografico per crearne una nuova (ma, anche in questo caso, forse è solo più conveniente cambiarla, sul lato CA).

Il rinnovo di un certificato CA (rispetto alla creazione di uno nuovo) complica la costruzione o la convalida del percorso?
Qui stiamo parlando del certificato del server, cioè un certificato dell'entità finale, non un certificato CA. Il rinnovo di un certificato _CA_ mantenendo la stessa chiave ha il vantaggio di renderlo immediatamente applicabile ai certificati emessi con il precedente certificato CA, quindi è nominalmente _ buono_ e rende le transizioni più agevoli. _Fa_ rende la costruzione del percorso un po 'più complessa, ma le implementazioni di solito la affrontano senza problemi (tuttavia _de_ confonde alcuni amministratori di rete).
@ThomasPornin SSH ha scambi di chiavi interamente segreti in avanti, ma SSL no.Pensi che questo faccia la differenza in questo argomento?
@AlexWebr Questo non dovrebbe fare la differenza.Nelle reti moderne, gli aggressori che possono origliare sono in una buona posizione per effettuare anche un attacco MitM, rendendo il vantaggio della segretezza in avanti piuttosto minore.
#3
+20
Bob Jones
2013-01-11 21:08:51 UTC
view on stackexchange narkive permalink

La risposta non è tecnica o crittografica, riguarda le persone. Con cose come i cambiamenti di lavoro (sentito di amministratori scontenti?), Le migrazioni dei server, i test DR, i backup e simili le chiavi private possono diventare un po 'esposte.

Dato quanto sopra, il rinnovo delle chiavi è una best practice per la sicurezza.

Questo è effettivamente un buon punto, non sollevato in nessun'altra risposta. Molte persone hanno accesso alla chiave nel tempo, chi non la cambia? Ti piace cambiare il codice di una porta quando un dipendente lascia? (Lo fai, vero?)
#4
+10
CodesInChaos
2013-01-10 15:33:19 UTC
view on stackexchange narkive permalink

Non preoccuparti che qualcuno prenda in considerazione la tua chiave RSA. Il factoring di una chiave RSA a 1024 bit potrebbe essere possibile per gli avversari a livello statale, ma anche per loro probabilmente non è conveniente. Il factoring di chiavi a 2048 bit probabilmente non sarà possibile per alcuni decenni.

Mi preoccuperei principalmente che la tua chiave privata venga rubata a causa di una compromissione del server. Il vantaggio in caso di compromissioni passate è un po 'poco chiaro, poiché l'aggressore potrebbe avere malware persistente sul tuo server. Quindi dovresti reinstallare il server per proteggere la nuova chiave.

Un altro problema è che alcune suite SSL deboli (principalmente la famiglia basata sulla crittografia RSA ) usano il tuo lungo termine chiave per la riservatezza e non solo per l'autenticazione. Con questi, una compromissione della chiave del server consente la decrittazione di tutte le comunicazioni SSL passate con il server che utilizzava una suite così debole. L'uso di una nuova chiave e l'eliminazione sicura di quella vecchia limita l'impatto di un tale attacco.

Quindi, se il tuo server ha ancora quelle suite abilitate, ti consiglio vivamente di cambiare la chiave regolarmente.

Sebbene non utilizzerei chiavi RSA a 1024 bit, questo punto è esattamente corretto.Il vero pericolo non è nella debolezza crittografica degli algoritmi standard, ma nelle vulnerabilità del software sfruttabile e nelle persone che gestiscono il server.
#5
+8
jorfus
2016-02-17 01:50:38 UTC
view on stackexchange narkive permalink
  • Hai cambiato le chiavi dopo HeartBleed?
  • Cosa fanno i tecnici del tuo data center con i dischi rigidi danneggiati?
  • Qualcuno ha lasciato l'organizzazione operativa nell'ultimo anno ?
  • Quando è stata l'ultima volta che hai ruotato le password dell'amministratore e le chiavi ssh?

Tutte queste domande dovrebbero farti pensare all'integrità delle tue chiavi. Non sto dicendo che sia probabile che siano compromessi o che qualcuno possa abusarne. Sto cercando di farti pensare al motivo per cui potresti volerle ruotare.

Ruotare le chiavi dovrebbe essere semplicissimo ed è una buona igiene di sicurezza. Se non lo fai perché è difficile, è un problema serio. Crea gli strumenti e i processi per renderlo facile. Se non lo fai, finirai per non riuscire a ruotare cose molto più importanti.

#6
+7
Dinu
2013-01-10 14:55:57 UTC
view on stackexchange narkive permalink

Più usi una chiave, più tempo dedichi a un aggressore. Anche se rompere 2048 bit non è considerato possibile con la tecnologia attuale, essere molto cauti e sostituire la chiave non è affatto una cosa negativa.

Inoltre, qualcuno potrebbe essere riuscito a ottenere la tua chiave privata, senza che tu fossi in grado di rilevarla. Se non può ripetere l'azione, il vantaggio del rinnovo è molto chiaro.

#7
+4
Tim X
2013-01-11 13:00:10 UTC
view on stackexchange narkive permalink

Anche se sono d'accordo sul fatto che ci siano poche ragioni tecniche per generare nuove chiavi ogni volta che rinnovi un certificato, non vorrei sfidare immediatamente il tuo team / i tuoi responsabili della sicurezza e chiamarli sulla questione.

ragioni non tecniche che sono altrettanto valide per generare nuove chiavi. Ad esempio, in una grande organizzazione in cui sono presenti diversi livelli di centralizzazione IT, competenze, procedure e buone pratiche, un'area di gestione della sicurezza centralizzata può richiedere tali pratiche per aiutare a mitigare alcuni dei rischi. Questo può anche aiutare a mantenere le procedure più piccole e più gestibile. Sebbene procedure più complesse possano essere più corrette da un punto di vista tecnico, sono più difficili da documentare e rendono più difficile per il personale sapere che le stanno seguendo correttamente. A condizione che la pratica non crei un sovraccarico significativo, potrebbe essere più facile adottare e mantenere l'approccio più semplice fai sempre X.

Pensaci da un'altra prospettiva. Tutti nella tua organizzazione che hanno la responsabilità della gestione dei certificati hanno la tua stessa consapevolezza e comprensione dei problemi e sono così approfonditi / dedicati? Qual è il livello di rotazione del personale e in che misura è necessario essere preoccupati per la quantità di dati sensibili a cui gli ex dipendenti possono avere accesso, ecc.

Ogni volta che si considera la sicurezza, il fattore umano è quasi sempre importanti o più importanti dei soli aspetti tecnici. Le politiche e le procedure devono considerare l'elemento umano e cercare di garantire che queste politiche e procedure siano strutturate in modo tale da consentire al personale di fare la cosa giusta, anche quando potrebbe non comprendere appieno il motivo per cui è necessario che lo faccia.

#8
+4
Jason
2017-11-16 23:27:03 UTC
view on stackexchange narkive permalink

SP 800-57 Parte 1 Rivista, Raccomandazione per la gestione delle chiavi

Le raccomandazioni del NIST sui cryptoperiodi RSA sembrano essere di 1-2 anni.

Nel caso in cui per persone future, nella 4a revisione si può trovare un'elegante tabella a pagina 45 (o sezione 5.3.6) con varie informazioni sui cryptoperiodi
#9
+2
Luc
2013-01-10 14:48:23 UTC
view on stackexchange narkive permalink

In realtà è come cambiare le password. Se qualcuno sta per violare la tua password quando la modifichi, dovrà ricominciare da capo. Oppure, se la password, o la chiave privata, è stata rubata, il rinnovo invaliderebbe la chiave rubata (supponendo che non possano rubarla di nuovo facilmente).

Potrebbe essere una buona abitudine cambiare la chiave privata ogni anno o ogni pochi anni solo per sapere che non si romperà nulla quando è necessario modificarlo, ma non è necessario per la sicurezza del certificato di per sé.

Ci sono ragioni * non * per farlo, però.
#10
+2
jorfus
2016-02-18 07:19:43 UTC
view on stackexchange narkive permalink

Diverse persone hanno sollevato il fatto che le chiavi host ssh vengono raramente ruotate come argomento per non ruotare le chiavi ssl. Sembra solo un altro problema da risolvere. (Mi scuso per una risposta leggermente fuori tema, ma molte persone qui l'hanno menzionata, quindi sembra appropriata)

Vedi la mia risposta sopra per il perché si potrebbe desiderare di ruotare le chiavi.

Quanto segue sarà particolarmente utile per tutti coloro che, per motivi di conformità, devono ruotare le chiavi host ssh, ma che si preoccupano dell'impatto dell'usabilità sugli utenti finali.

1) Distribuire un ssh_ca (Istruzioni straordinariamente complete in man ssh-keygen)

  ssh-keygen -f ssh_ca -b 4096  

2) Distribuisci il certificato ai tuoi utenti: Aggiungi la riga dell'autorità di certificazione a ~ / .ssh / known_hosts

  @ cert-authority * .domain.name ssh-rsa AAAAB3 [...] == Comment  

3) Firma le chiavi dell'host (assicurati di limitare ciascuna a un singolo host)

  ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain .name -V + 52w /etc/ssh/ssh_host_rsa_key.pub  

4) Configura i server per presentare il certificato (/ etc / ssh / sshd_config):

  HostCertificate / etc / ss h / ssh_host_rsa_key-cert.pub  

Ogni chiave host firmata dalla CA è ora considerata attendibile dal client (non più accettare ciecamente una sigla chiave la prima volta che ti connetti)

Ora è possibile eseguire il rollio della chiave host senza interrompere i client. La firma della chiave può essere inserita nel processo di creazione / orchestrazione dell'host.

Questo è un buon riferimento. Questo progetto ha creato alcuni strumenti utili sull'utilizzo di ssh_ca per l'accesso utente a scadenza automatica.

Se ho capito bene, stai ruotando le chiavi host, ma non la CA ...?Che cosa sta risolvendo esattamente?
Questo crea una catena di fiducia in base alla quale l'utente non deve più semplicemente fidarsi ciecamente delle nuove chiavi host.In un ambiente in cui gli host vengono continuamente spostati su e giù, la verifica della chiave host è inutile perché gli utenti sono addestrati a ignorare semplicemente l'avviso.Questa soluzione consente a un gestore di configurazione di firmare le chiavi di nuovi host autorizzati consentendo all'utente di considerare attendibili le chiavi firmate dalla CA.Un host canaglia presenterà un avvertimento utilizzabile.Se è necessario sostituire la CA o ruotare la chiave, è necessario aggiornare l'identità della CA firmataria su ogni client.(forse con il tuo MDM)


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...