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.

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).

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.

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.

• 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.

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.

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.

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.

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é.

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.