In che modo i certificati di breve durata aumentano la sicurezza?

4

Dopo aver letto un post sul blog sul nuovo protocollo Roughtime, non sono convinto della premessa originale che il certificato più breve le vite aumentano la sicurezza. L'affermazione è che un tempo più breve riduce in qualche modo l'esposizione se una chiave segreta viene compromessa. Ma quanto è realistico questo scenario?

Se il protocollo crittografico è debole e questo è il modo in cui la chiave è stata compromessa, cambiare la chiave per una nuova ugualmente debole non ha senso. Viceversa, se il protocollo è valido, un utente malintenzionato sarà solo in grado di compromettere la chiave segreta dal violare il sistema (o sfruttando le persone deboli). E sappiamo dalla lunga esperienza con le violazioni che la prima cosa che un aggressore fa è aprire un back door per mantenere l'accesso se la vulnerabilità originariamente sfruttata è chiusa. La quantità di tempo tra una violazione e il processo di backdoor è di solito misurata in secondi o minuti, il che una politica di rotazione probabilmente non aiuterà.

Finalmente abbiamo iniziato ad accettare con le password che la rotazione frequente è inutile (e rischiosa). Le raccomandazioni del NIST sono la prova di quel cambiamento. Credere nelle frequenti rotazioni per i certificati sembra un superstizioso retaggio delle idee di sicurezza degli anni '80.

Quindi sto chiedendo prove. Esistono studi sull'efficacia dei certificati a vita breve come misura di sicurezza? C'è qualche prova che le frequenti rotazioni dei certificati migliorino la sicurezza invece di causare semplicemente inconvenienti frustranti (e tempi di inattività significativi alla scadenza dei certificati) per tutti gli interessati? Un altro modo per porre la domanda è quali sono i benefici effettivi forniti da un breve periodo di rotazione del certificato?

    
posta John Deters 22.09.2018 - 20:51
fonte

2 risposte

2

Un documento a cui non posso resistere dal mostrarti qui è draft-nir-saag-star di Yoav Nir (presidente del gruppo di lavoro ACME ) e la discussione successiva su % mailing list% .

Un problema importante che sorge è che né i soccorritori OCSP né i punti di distribuzione CRL sono ampiamente riconosciuti come parti di rete affidabili. Voglio dire, non c'è ovviamente alcuna prova che siano costantemente in calo, ma, dato l'approccio soft-fail attualmente in uso, non è necessario che l'attuale infrastruttura dell'autorità di certificazione sia disponibile e monitorata 24/7, il che rende la transizione a fallire (con simili a Must-Staple, ecc.) molto più difficile.

E, comunque, CRL e OCSP costituiscono entrambi un singolo punto di errore aggiuntivo, mentre un servizio Internet di oggi fa del suo meglio per evitarlo.

Di fatto, un certificato di breve durata è valido solo se la rotazione è automatizzata; tuttavia, per un servizio di rete sufficientemente scalabile, distribuito da decine a centinaia a migliaia di istanze fisiche e / o virtuali, ciò è vero.

Anche alcune brevi osservazioni sul resto della domanda,

Conversely, if the protocol is good, an attacker will only be able to compromise the secret key from breaching the system

- Ma non necessariamente il sistema in cui vengono distribuiti il certificato e la chiave privata per gestire il traffico di produzione. Potrebbe anche essere il server Ansible centrale, o la sua memoria di rete, o un server utilizzato per il rinnovo del certificato, o qualunque altra cosa. Potrebbe anche essere solo una piccola parte dei server di produzione, nemmeno in uso (ad esempio quando un servizio di rete viene distribuito su alcuni fornitori di servizi cloud e uno di questi ha consentito una violazione). In alcuni (più obsoleti?) Modelli di minacce potrebbe anche essere stato un laptop personale (rubato) di un dipendente responsabile del rinnovo del certificato.

In tutti i casi di cui sopra non ci sarà alcun vantaggio immediato per un attaccante per l'installazione di una backdoor, mentre possono ancora facilmente andare via con la chiave privata e usarlo per MitM, ecc.

We’ve finally begun to accept with passwords that frequent rotation is pointless (and risky)

Bene, non esattamente . Per esempio. NIST SP 800-63B suggerisce che i "verificatori NON DEVONO richiedere segreti memorizzati da modificare arbitrariamente (ad esempio, periodicamente) ", dove un segreto memorizzato è " un tipo di autenticatore composto da una stringa di caratteri destinata ad essere memorizzata o memorabile dal sottoscrittore, consentendo all'abbonato di dimostrare qualcosa che sanno come parte di un processo di autenticazione ".

Tuttavia, questo non si applica a una chiave privata che non dovrebbe mai essere memorizzata o memorizzata in qualsiasi scenario di utilizzo contemporaneo sano di mente. In realtà, ci sono anche degli svantaggi di una rotazione frequente dei certificati (come la necessità di automatizzare correttamente le cose), ma questi non sono nemmeno vicini agli svantaggi di una rotazione frequente delle password memorabili.

    
risposta data 24.09.2018 - 00:24
fonte
1

La revoca è più facile.

Se non fai nulla, il certificato diventerà invalido da solo dopo un breve periodo di tempo, rendendolo meno pericoloso di uno con una lunga durata.

Quando impieghi effettivamente un'infrastruttura di revoca, ottieni enormi elenchi di revoche di certificati (CRL) e molto traffico sui server OCSP per verificare se un certificato è revocato. Questo è un notevole dispendio di gestione e costi infrastrutturali, ad es. potrebbe aver impedito la cifratura.
Quindi utilizzano una vita breve per i certificati, in modo tale che i loro elenchi di revoche siano sempre molto brevi, in quanto possono eliminare i certificati scaduti dagli elenchi.

    
risposta data 24.09.2018 - 15:43
fonte

Leggi altre domande sui tag