Dopo aver perso il cuore, come puoi distribuire in sicurezza nuovi certificati?

2

È passato un po 'di tempo da quando ho studiato la distribuzione delle chiavi, quindi potrei avere qualche malinteso fondamentale ...

Da quello che ricordo, gli attacchi man in the middle non possono verificarsi durante la distribuzione di cert perché il certificato che viene distribuito è protetto da una chiave di livello superiore. Le chiavi di root sono distribuite su cd con il sistema operativo, il che rende molto improbabile che vengano forgiate. Ma con il cuore, non è possibile che anche le chiavi private a livello di root siano state compromesse? Come puoi distribuire in modo sicuro nuove chiavi elettronicamente in queste circostanze?

    
posta ConditionRacer 11.04.2014 - 01:34
fonte

2 risposte

5

Le CA radice normali e serie sono offline. Sono ospitati su macchine che sono mai collegate a qualsiasi tipo di rete. Questo tende a renderli immuni agli attacchi remoti, e questo è il punto.

Tecnicamente, i motivi che hanno giustificato il rinnovo della chiave ("il bug era lì, quindi potrebbe essere stato un compromesso che non conosciamo") sono ancora validi: sarebbe assurdo per affermare che abbiamo trovato e rimosso l'ultimo bug in OpenSSL, o, per quella materia, in Apache (OpenSSL è una libreria, viene caricato nello spazio degli indirizzi del server Apache, quindi qualsiasi bug simile in Apache stesso sarebbe ugualmente devastante). Quindi ci devono essere alcuni bug rimanenti e la tua nuova chiave è "potenzialmente compromessa" come la precedente. Quindi non preoccuparti ...

O detto diversamente: l'intero panico di fondo è basato sul sospetto di una possibile violazione, che si applica ancora logicamente e si è sempre applicato sin dai primi giorni di reti. Il bug "heartbleed" non è qualitativamente nuovo; bug di quel livello di serietà si trovano più volte all'anno in qualsiasi pezzo di software significativo. Possiamo concludere che "non possiamo essere sicuri di nulla" e che sarebbe matematicamente vero, ma poco pratico. Se vogliamo aggrapparci all'idea che computer e reti sono ancora utilizzabili, allora dobbiamo accettare l'esistenza di bug, alcuni dei quali sono vulnerabilità e le solite strategie (applicare le correzioni di sicurezza non appena i produttori pubblicano loro) è una strategia valida che consentirà ai nostri server di rimanere illesi per la maggior parte del tempo.

Come mi ha detto ieri un mio collega: gruppo di pesci in sciami (tecnicamente chiamati scuole e scuole ) per proteggersi dai predatori. Quando un delfino afferra un pesce, quel pesce specifico probabilmente pensa "perché io?" e ha una sensazione di ingiustizia; ma la strategia di shoaling è ancora mediamente .

In larga misura, questo è ciò che facciamo con il meccanismo di pubblicazione delle vulnerabilità e le patch di sicurezza. Si può trovare una vulnerabilità perché è stato osservato che è usato da un predatore, e questo è un peccato per la vittima, ma almeno il resto dei benefici dello sciame per l'esperienza. Ci piacerebbe essere più proattivi e sviluppare codice senza bug, ma purtroppo Science non ha trovato un modo per evitare in modo affidabile i bug nel software (anche se i linguaggi con una strong tipizzazione e controlli sistematici sugli array possono essere di grande aiuto).

    
risposta data 11.04.2014 - 15:20
fonte
1

Esistono vari modi per esaminare la tua domanda.

  1. Applica la patch per l'errore heartbleed e usa openssl
  2. Utilizza Opzioni per bypassare heartbleed o versioni di openssl che non hanno problemi di heartbleed. più qui
  3. Utilizza qualche altra libreria crittografica (non gaurentee non sanguina più tardi)

Fondamentalmente, non esiste un metodo infallibile o un modo ideale per distribuire chiavi o crypto. la complessità del software sarebbe sempre soggetta a errori di vario grado. dobbiamo solo continuare a testare, convalidare ed essere resilienti a tali cambiamenti

    
risposta data 11.04.2014 - 04:00
fonte

Leggi altre domande sui tag