Dovrei testare il mio certificato SSL per "Primi condivisi RSA" prima di usarlo?

6

Ci sono diversi documenti del 2012 che dicono che è è possibile calcolare diversi moduli prendendo in considerazione i numeri primi condivisi. Il link sopra include codice sorgente python per verificare e verificare questo fatto.

Data questa conoscenza, cosa devo fare come professionista della sicurezza IT per quanto riguarda tutti i certificati SSL di tutti i miei server e altri artefatti di crittografia che potrebbero o meno essere vulnerabili.

Domanda

  • Se SSL è vulnerabile, è una buona idea per me testare e riemettere i certificati interessati? O dovrei semplicemente cambiare i codici utilizzati dal mio server web?

  • I dati crittografati precedenti dalle sessioni basate su RSA o DHE sono vulnerabili?

posta random65537 30.06.2013 - 20:08
fonte

2 risposte

2

Se è abbastanza semplice da testare, si potrebbe anche farlo. Non conosco alcun servizio o altro meccanismo che faccia questo test per te, ma se lo fai allora. La probabilità di un attacco è probabilmente piuttosto sottile, ma la gravità è piuttosto estrema. Vale certamente la pena ripararlo se lo rilevi.

Sì, eventuali sessioni precedenti, se acquisite, possono essere decodificate se è possibile derivare la chiave privata. A meno che non usi Diffie-Hellman per generare la tua chiave di sessione effimera (attualmente estremamente rara); cerca semplicemente "Perfect Forward Secrecy" per informazioni sulla protezione delle sessioni di oggi contro gli attacchi di domani.

Tieni presente che i tuoi numeri primi vengono determinati quando generi la chiave , non il tuo certificato . Generare una chiave non costa nulla (ma il tuo tempo) e può essere fatto tutte le volte che vuoi. Quindi, se stai per testare, potresti anche generare il test in anticipo (o forse in un colpo solo) prima di generare una CSR basata solo su una chiave "strong". Un computer con un buon TRNG (come i recenti Linux e BSD) è utile qui, poiché un PRNG errato è tipicamente la tua fonte di chiavi sbagliate.

Inoltre, diverse CA ti permetteranno di "ridigitare" un certificato, che in sostanza significa emetterne uno nuovo con la data di scadenza originale. Quindi, se in qualsiasi momento la tua chiave è sospetta, questa potrebbe essere un'opzione.

    
risposta data 01.07.2013 - 05:25
fonte
2

Se hai appena creato una nuova chiave, non preoccuparti di testarla. Invece, è meglio assicurarsi che quando si crea una nuova chiave, si usi una buona casualità. Questa è una situazione in cui la prevenzione è molto più facile del rilevamento.

I ricercatori hanno scoperto che il problema a cui ti riferisci si pone principalmente con chiavi private generate su dispositivi embedded (ad es. access point wireless consumer, router DSL, ecc.). Questi dispositivi tendono ad avere PRNG scadenti e (spesso) codice di generazione della chiave sciatto. Al contrario, se hai generato la tua chiave su un server utilizzando software affidabile (ad es. OpenSSL), probabilmente stai bene.

(Eccezione: l'errore di Debian ha colpito alcune persone, ma è successo un po 'di tempo fa e non dovrebbe riguardare le chiavi generate negli ultimi due anni.)

    
risposta data 01.07.2013 - 09:27
fonte

Leggi altre domande sui tag