Desidero sapere se i miei vari provider hanno cambiato il certificato a causa di Heartbleed o se stanno utilizzando un vecchio certificato vulnerabile. Come posso saperlo? La data "valida da" è anche la data di creazione?
Desidero sapere se i miei vari provider hanno cambiato il certificato a causa di Heartbleed o se stanno utilizzando un vecchio certificato vulnerabile. Come posso saperlo? La data "valida da" è anche la data di creazione?
Heartbleed ha una relazione piuttosto scarsa con i certificati. L'unico collegamento è che una conseguenza potenziale di un heartbleed sfruttato con successo è una rivelazione della chiave privata del server SSL. Pertanto potrebbe voler andare alla modalità paranoia completa e considerare che qualsiasi chiave privata che è stata utilizzata in un server vulnerabile è toast e deve essere sostituita. Questo è abbastanza estremista, e in qualche modo manca il punto perché lo stesso argomento si applica a ogni singolo overflow del buffer sfruttabile da remoto mai scoperto nel server, e ce ne sono diversi ogni anno; individuare il bug "heartbleed" è ingiustificato.
Ora un certificato contiene due "date di validità", chiamate notBefore
e notAfter
. Normalmente , la data notBefore
è vicina alla data in cui il certificato è stato effettivamente emesso, vale a dire quando la CA lo ha firmato. Normalmente, la data notBefore
è leggermente passata perché la CA vuole produrre un certificato che il proprietario può utilizzare immediatamente anche se gli orologi delle sue macchine non sono precisi. Ad esempio, la CA di Microsoft ("Servizi certificati"), per impostazione predefinita, scriverà "14:35" come notBefore
di tempo se il certificato è stato effettivamente emesso alle 14:45. Altre CA possono andare oltre; Conosco una CA che ha utilizzato sistematicamente la mezzanotte (dalla notte precedente) come notBefore
di tempo.
Ma devi notare che questa data qualifica la data di emissione del certificato , non del tasto . È relativamente comune "rinnovare" un certificato emettendo un nuovo certificato (con nuove date di validità) contenente la chiave pubblica e l'identità stessa di un certificato precedente. Per lo scenario "exploble heartbleed" sopra, ti preoccupi se la chiave privata potenzialmente trapelata sia stata scartata e rigenerata o meno. Nulla nel contenuto del certificato ti dirà nulla sull'ora in cui è stata creata la chiave privata (beh, la chiave privata esisteva prima del certificato, ma forse lungo prima, o forse no, il contenuto del certificato ha vinto lo dico).
Diventiamo un po 'più reali qui. Heartbleed è solo un altro bug potenzialmente sfruttabile in un'implementazione; questo non è il primo, e non l'ultimo. Probabilità che un determinato server sia stato sfruttato tra il momento in cui il bug è stato scoperto e il tempo in cui il codice del server è stato corretto, è estremamente basso in media. L'insetto è diventato di gran moda tutta la notte, ma non è stato osservato in natura prima.
Secondo la pagina di Wikipedia e specifiche un certificato non contiene informazioni sulla data di creazione.
Prendi il mio chrome come esempio, nella url, c'è un blocco verde:
quandofaiclicsullucchettoverde,vedrai:
quando fai clic su "informazioni sul certificato", vedrai il certificato, i dettagli del clic, puoi vedere:
il"non valido prima" è quando il certificato viene creato. In realtà in questo caso, dal momento che Yahoo è interessato, quindi il suo certificato è rilasciato solo oggi.
Nel frattempo puoi trovare qualsiasi sito interessato qui , ho provato alcuni di questi, alcuni dei certificati vengono aggiornati, mentre altri non lo sono ancora.
Leggi altre domande sui tag certificates heartbleed