Qual è lo scopo di rotazione frequente dei certificati TLS senza modificare le chiavi sottostanti?

25

Ho letto nel foglio cheat OWASP relativo al certificato / blocco di chiave pubblica che "Google ruota il suo certificati ... circa una volta al mese ... [ma] le chiavi pubbliche sottostanti ... rimangono statiche ".

Aumentare la frequenza della rotazione delle chiavi ha senso per me, nel caso in cui una chiave venga compromessa senza rilevamento, il tempo per i danni continui viene ridotto.

Qual è il vantaggio dei certificati di rotazione così frequenti? È per consentire loro di usare SHA1 (per la compatibilità con i vecchi browser) limitando allo stesso tempo l'ambito di un avversario per trovare una firma corrispondente? O c'è qualcos'altro che mi manca?

    
posta Arran Schlosberg 14.04.2015 - 06:53
fonte

3 risposte

36

Un grande vantaggio è la rimozione della necessità di revoca in caso di compromissione.

Il modo "tipico" per farlo è pubblicare un elenco di revoche di certificati (CRL) o utilizzare Protocollo OSCP in caso di compromissione della revoca dei certificati. Tuttavia, il controllo CRL o OSCP è incredibilmente facile da ignorare. Un utente malintenzionato in grado di eseguire un attacco MITM può semplicemente impedire a un client di comunicare con il server su cui è ospitato il CRL e il cliente si limiterà a svolgere con piacere la propria attività. Ciò è necessario a causa di situazioni comuni come i portali in cattività che funzionano su HTTPS e bloccano tutto il resto del traffico, incluso il traffico verso i server CRL.

I certificati di breve durata hanno il vantaggio che, in caso di compromissione, il certificato compromesso funzionerà solo per un periodo di tempo molto limitato fino alla scadenza del certificato, limitando quindi il danno che può essere causato.

Adam Langley ha scritto estesamente sull'argomento se sono richieste ulteriori letture.

    
risposta data 14.04.2015 - 07:28
fonte
8

Terry Chia ha risposto alla domanda "Qual è il vantaggio dei certificati rotanti così frequentemente?" completamente corretto, quindi non c'è niente da aggiungere.

Tuttavia, vorrei aggiungere una nota che Google cambia spesso anche le proprie chiavi pubbliche, quindi l'ipotesi del cheat sheet non è valida. Questo aggiunge molta confusione e potrebbe essere parte della ragione della domanda originale.

Solo dai miei x509-archivi personali:

$ openssl x509 -in google-oct.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Sep 24 10:48:54 2014 GMT
notAfter=Dec 23 00:00:00 2014 GMT
Modulus=AF384ED52C86FBDCD4F3117AD63652874889E442C80B4B112B3AEFA978607B33758927E75F92838D1A42B19F1DB59BC55322068FB197D38BBCB68984CAB4F0328E10A1B0D98DA794AAA379AB7C3CAFF177663127EC5069872F801E925AEDB76C865209A00A55618A2D1BB91F368D5739A1DE88C9FE66F5E0108C1FF1025D62DEE3BFBFB9BCFD3E71EC9C6E91A05AECD9833AE32B89B432DCD4C489D69C2BEC7E325C621184A8E8658CD3B755E62E65E19A2649ADC668E5C2705280884FC5D3B9D5914AC27D22B050F819233A0DDFF4194F55BDE358AABA6376567087BA69407B17EA364DB3A842A1972199B9B5632088F0E1C45B50DD1AD123F49573094051F3


$ openssl x509 -in google-nov.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Oct 22 12:57:51 2014 GMT
notAfter=Jan 20 00:00:00 2015 GMT
Modulus=C15236913979042DF078DF5B73AF463A636F98CE32A2AABAC378180566A87C382BB3A82A6808D4103D626A37CA4FBF8ABEA5939DD6C9874A8D318593F5481F59756E76817CBD38B73A5C703438BB9A824FD054B168ED3C9E5CD0445F744ED2A4EAA6327A94813A98C941BD60F3B19C5DC8CDFB34DE9293C53D41A234B4499A4F19C6AF193084F61C6636D7E89AEA86110231E6EE03F4C853841B0FB46122E6D73E7EF08D058665C7297B1A329F16F0EEB856E7614EB16B23CB4B6BBC5B567685F02638B52ECEBC71B06A1503776C0945A75E3227F71FE2956FC48533A6529066C840433A6705E94523843D10C45A8BC9CD58FCA6A6AABD79F2FFFEE6CB254AB9

[...]
$ openssl x509 -in google-apr.pem -noout -subject -dates -modulus
Modulus=924D62DDCD6B012D33F6CF12A5FD6291B490867ABB1E4F7F356FA8BBD424400C283EE7BB14DA8D1268239814A490F7D88EBA5EA3A9ED8DFEE6B6FF841405A964D47B1F76DB6F39A6990FD024060248FA889580271D6DDA6A7ADEB1538425268FAA8C2D824865DA3F30F78D48887D4C90D86F0A8A95F0A9CC951B7562FC98EC91D132C1C9418182045652BF510D357F1792201126DF230CD76BCA58B367A30088E6606FE7B80265582BD9A235F36AC60A2A6C266775979B52501355C51C7927ABA5DD0FFAFA39DFA240B3F21826188A9818B5E9761D38E15ACA980EF12BA14BEE00CA3D8C7F66112B56CEDCE2CA8BE67DD8ACA8B594D906CAE752217F67419E59

Le chiavi effettive sono completamente diverse e questo è perfettamente soddisfacente dal punto di vista della sicurezza.

Supponendo che il tempo e le risorse siano sufficienti, si può per es. tentare di calcolare la forza bruta una chiave privata per abbinare una chiave pubblica nota. O qualcosa di simile a heartbleed accade ancora una volta, con conseguente compromissione delle chiavi private. Un modo semplice per mitigare entrambi i tipi di minacce è modificare periodicamente le chiavi.

Dalle mie osservazioni, i certificati di Google sono validi per tre mesi, ma vengono scambiati una volta al mese. Ciò va bene da un punto di vista operativo: non si desidera ricaricare i nuovi certificati esattamente nello stesso secondo, ma probabilmente avviare la distribuzione dei nuovi certificati su 1% dei server interessati e aumentare fino alla piena flotta di server. Se qualcosa va storto, è comunque possibile ripristinare il vecchio certificato ancora valido e disporre di altri due mesi per correggere i nuovi certificati, la configurazione del server, il software del server o qualsiasi altra cosa che possa causare il problema associato al nuovo (interrotto) certificato.

    
risposta data 14.04.2015 - 19:09
fonte
0

Alla risposta di Ayrx , Steve Sether nota che:

  1. Esiste una corrispondenza uno a uno tra la chiave pubblica e la chiave privata - formano una cosiddetta coppia di chiavi . La chiave privata cambia se e solo se la chiave pubblica cambia. Quindi dobbiamo prima capire, dato che la chiave privata non cambia durante l'aggiornamento del certificato, nemmeno la chiave pubblica. Viene aggiornato solo il certificato, in particolare la data di scadenza.
  2. Consideriamo lo scenario in cui la nostra chiave privata è compromessa - diciamo che un avversario ha rubato la nostra chiave privata. Passare a un nuovo certificato non aiuterà, perché il certificato è pubblico, l'avversario può continuare a ottenere i nuovi certificati e mascherarsi come noi.

Sono d'accordo con i punti di Steve. Quindi a cosa serve cambiare in un nuovo certificato?

Il punto cruciale qui non sta cambiando in un nuovo certificato, ma piuttosto la validità limitata o la scadenza del vecchio certificato. Se il compromesso della chiave privata non viene rilevato (n. 2 qui sopra), allora questa scadenza non sarà d'aiuto - tuttavia, se sappiamo del compromesso (come spesso accade), possiamo provare a revocare il certificato (citato da Ayrx) - indipendentemente e indipendentemente dalla revoca, sappiamo che dobbiamo usare una nuova chiave privata. La scadenza del nostro vecchio certificato indica che anche la nostra chiave privata scadrà allo stesso tempo, in quanto coppia chiave.

Potrebbero esserci altri attacchi che possono aiutare l'aggiornamento della certificazione, ma ritengo che il caso di utilizzo sopra riportato sia di rilievo.

    
risposta data 21.11.2018 - 08:14
fonte

Leggi altre domande sui tag