Come verificare che la patch Heartbleed di OpenSSL sia quella corretta?

Question

Come verificare che la patch Heartbleed di OpenSSL sia quella corretta?

#1 da (2 voti)

2

Nel sentire la vulnerabilità Heartbleed, sono andato a https://www.openssl.org/source/ per scaricare la patch più recente, ma sono rimasto piuttosto sorpreso nel constatare che il certificato di sicurezza per quel sito non è stato aggiornato da quando l'exploit è stato scoperto ("non valido prima" la data è martedì 30 agosto 2011 alle 5.30.50 CT).

Quindi, come posso essere sicuro di quello che sto guardando è il vero sito OpenSSL e non un impostore che ha rubato il loro certificato (anche prima che l'exploit fosse rivelato).

In altre parole, ho scaricato https://www.openssl.org/source/openssl-1.0.1g.tar.gz , che lo stesso sito afferma di avere un MD5 di de62b43dfcd858e66a74bee1c834e959 , che fa, ma è la giusta impronta digitale per quella patch? Oppure sto scaricando qualcosa di malizioso che ha una nuova backdoor codificata in esso?

UPDATE: Seguendo il suggerimento di @Lekensteyn, ho verificato che la firma PGP fornita per quel download era valida e firmata dalla chiave 0xFA40E9E2 , che sembra essere la chiave di Dr Stephen N Henson <[email protected]> (che il il sito web è d'accordo). Ma per essere super-sicuro, sto assumendo che non posso fidarmi del sito web in questo momento. In quali altri modi posso avere fiducia che la chiave 0xFA40E9E2 sia quella che dovrebbe firmare quella release?

Qualcuno ha un download OpenSSL dal ramo 0.9.8 (che non è stato compromesso da Heartbleed e sarebbe stato abbastanza vecchio da essere distribuito prima dell'exploit), che è possibile verificare è firmato dalla stessa chiave?

Preoccupazione: ho trovato questo avviso di un aggiornamento al sito Web di OpenSSL, poco prima che l'exploit fosse rivelato (2 aprile), e la modifica al sito era di contrassegnare la chiave della Dr. Henson come scaduta e aggiungere 0xFA40E9E2 come sua nuova chiave, ma quella chiave è stato creato nel 2005? Quindi è una nuova chiave per identificare Dr. Henson, ma questa è la chiave che hanno scelto di firmare questa patch super-importante per Heartbleed? Sembra strano a tutti?

openssl heartbleed

posta MidnightLightning 11.04.2014 - 13:15

fonte

1 risposta

Leggi altre domande sui tag openssl heartbleed

configurazione PHP e max_input_vars Quanto è difficile risolvere un sale se si conoscono i dati originali e l'output hash che utilizza l'algoritmo SHA-2

score 2 · Answer 1

La tua domanda è in realtà:

How can I be sure of the authenticity of the downloaded file?

Iniziamo con i dettagli che hai menzionato. Il checksum (MD5, SHA1, qualunque sia) è un'impronta digitale del file che consente di controllare l' integrità del file. Cioè, se i dati sono cambiati da quando è stata presa l'impronta digitale. Se si ottiene il checksum da una fonte affidabile, è possibile presumere che il file scaricato sia valido.

Se non ti fidi del checksum e vuoi autenticare il file, usa la firma GPG se disponibile. Per il file nella tua domanda, questo è disponibile all'indirizzo link . Se ti fidi del firmatario e la firma corrisponde al file, allora puoi presumere che il file scaricato sia valido. Se non conosci nessuno nel suo portachiavi, puoi cercare gli altri che lo credono. Ad esempio, Debian ha una copia della chiave di firma su link . Questo script Tor contenente un'impronta digitale GPG di La posta privata del dott. Stephen Henson che ha firmato il openssl.org indirizzo.

Se sei veramente paranoico e hai a disposizione fonti precedenti, puoi scaricare il file, estrarlo e confrontare i sorgenti:

# Assume openssl-1.0.1f to be a known good source
tar xf openssl-1.0.1g.tar.gz
diff -Nur openssl-1.0.1f/ openssl-1.0.1g/

Ciò richiede una certa conoscenza della lingua in cui è stato scritto il programma (C per OpenSSL). Se qualcuno inserisce una backdoor, probabilmente non sarebbe così ovvio come // backdoor requested by the NSA .

Un'altra alternativa è quella di evitare completamente il download singolo e recuperare i sorgenti dal repository del codice sorgente al link . Alcuni file potrebbero essere diversi tra il rilascio tarball e il repository git (come lo script configure ), ma le fonti stesse dovrebbero essere uguali.