Perché i certificati radice CA sono tutti firmati SHA-1 (poiché SHA-1 è obsoleto)?

67

Comprendo che i certificati SSL non possono più essere firmati utilizzando SHA-1. Tuttavia, tutti i certificati radice CA sono firmati SHA-1 (principalmente). Significa che lo stesso algoritmo che non è più attendibile per "il tuo negozio SSL nonna" va bene per il certificato più sicuro al mondo?

Mi sto perdendo qualcosa? (utilizzo chiave? dimensione chiave?)

ssl ssl-certificate certificate-authority

— 131
fonte

9

Non è vero che "tutti" i certificati radice CA sono SHA1.

— Greg Askew,

5

I certificati di root sono come iniziare ipotesi in una visione del mondo. Ci vuole fede per fidarsi di loro.

— Roy Tinker,

@RoyTinker ad eccezione del cogito ergo sum (vedi il dubbio radicale, ed è la risposta: scetticismo cartesiano )?

— Nick T

1

Cross-stack: security.stackexchange.com/questions/120301/… e superuser.com/questions/1122069/…

— dave_thompson_085

6

@NickT: gioca sicuro - cogito ergo cogito ;-)

— tonysdg

106

La firma dei certificati della CA principale non ha alcuna importanza, poiché non è necessario verificarli. Sono tutti autofirmati.

Se ti fidi di un certificato CA radice, non è necessario verificarne la firma. Se non ti fidi, la sua firma è inutile per te.

Modifica: di seguito sono riportati alcuni commenti molto pertinenti. Non mi sento a mio agio nel copiarli o riformularli e prendermi il merito per loro invece che per i loro autori. Ma accolgo con favore le persone per aggiungere spiegazioni a questa risposta.

— user2233709
fonte

3

Pone la domanda sul perché siano firmati

— Richard Tingle,

42

Perché il sistema non supporta i certificati che non sono firmati.

— Smetti di fare del male a Monica il

Mi sembra che la preoccupazione per un certificato di root crackabile non sia "non sai da dove hai ottenuto il certificato di root", ma piuttosto "non sai chi altro è stato in grado di decifrare questo certificato e usarlo per firmare quello che vogliono ". E dalla tua risposta sembra che i due (cert e cert-signing) siano preoccupazioni separate e che il cert stesso sia adeguatamente sicuro e non crackabile?

— Dewi Morgan,

20

Andrei anche oltre "non è necessario verificarli". Lo scopo della firma in una catena di certificati è che un'autorità superiore certifica un'autorità inferiore. Per un'autorità di certificazione radice, non esiste un'autorità superiore per definizione (questo è ciò che significa "radice"), quindi non c'è nessuno che possa firmare il certificato . Poiché, come detto, i certificati devono essere firmati, le CA principali sono firmate con una firma "fittizia" e il modo più semplice per farlo è l'auto-firma. Pertanto, non solo non è necessario verificarlo, ma l' idea stessa di verificare la firma di una CA principale non è sensata.

— Jörg W Mittag,

13

@DewiMorgan Non puoi "rompere" un certificato root con una collisione hash, perché il client si fida del certificato stesso , non della sua (auto) firma. Dovresti recuperare la chiave privata, che è un attacco a RSA, non all'algoritmo hash.

— zwol,

46

Alla fine della giornata, un certificato radice è autofirmato. Non è mai firmato da un'altra entità tranne se stesso. Il certificato radice ottiene la sua fiducia attraverso processi fuori banda come l'invio a un elenco di editori attendibili del browser o l'accettazione da parte di Microsoft per l'inserimento nell'elenco predefinito degli editori attendibili di Windows.

Questi certificati (e le aziende che li hanno autofirmati) sono (presumibilmente, si spera) controllati accuratamente con altri mezzi oltre alle loro firme.

— Mark Henderson
fonte

2

Per non parlare del fatto che l'aggiornamento di un certificato radice richiede di nuovo il processo fuori banda.

— Kaithar,

4

+1 per il "presumibilmente, si spera"

— Nathan Osman,

6

L'unico caso in cui ciò è importante è che se la radice è firmata da SHA-1, può essere revocata da SHA-1. Cioè, qualcuno che può attaccare SHA-1 può costruire una revoca per il root. E sono assolutamente sicuro che il browser non sappia come persistere, quindi il vandalo non ha fatto altro che abbandonare le connessioni SSL. Che zoppo.

— joshudson
fonte

1

Questo è un pensiero interessante ma dubito che funzionerebbe in questo modo. La mia ipotesi è che ogni agente avrebbe il suo comportamento unico, ma dubito che qualsiasi sviluppatore abbia avuto l'idea che l'elenco di revoca sarebbe stato usato per gestire la revoca dei certificati di root. Per lo meno, se in alcuni casi funzionasse, ciò sarebbe dovuto all'astrazione della revoca del software e non intenzionalmente da parte degli sviluppatori.

— Peter Oehlert,

1

Come nota al riguardo, ALCUNE CA hanno già aggiornato i loro certificati root e intermedi a SHA256 comunque.

So che l'anno scorso GlobalSign stava aggiornando i loro certificati mentre stavamo aggiornando i nostri certificati di firma del codice, quindi ho dovuto aggiungere anche la loro nuova catena a quelli.

Puoi verificare quali certificati specifici sono stati aggiornati e quali sono stati aggiornati ma hanno anche lasciato un certificato SHA1 legacy per qui => 1

Spero che aiuti.

— B.Kaatz
fonte

0

Per la CA principale, ti dai la fiducia alla chiave pubblica della CA raggruppata nel CRT, indipendentemente dalla sua firma personale.

Descrivere la CA usando il formato di file .CRT invece di una chiave pubblica non elaborata .PEM consente di raggruppare più dettagli al suo interno - ad esempio il nome della CA - (ancora una volta, la firma non ha valore)

— 131
fonte

-1

Esistono già certificati radice SHA1 bloccati molto vecchi, per lo più del 2006 o precedenti, che i browser accettano, ma non quelli più recenti. Ricordi quando Firefox e Chrome sono stati sottoposti a versione utilizzando cifre singole?

I certificati falliscono se la CA principale utilizza i certificati SHA1 con Not Before impostato su qualcosa dopo il 2014. Le restrizioni sulla data effettiva dipendono dal browser o da altra applicazione. Il cabforum WebCA lo ha chiarito diversi anni fa. Provalo tu stesso:

Creare un'infrastruttura dell'autorità di certificazione radice privata firmata con un SHA1, chiamarla rootSHA1
Chiedi a rootSHA1 di creare una CA "di emissione" o CA "intermedia" che emette certificati con un certificato incatenato alla radice. Chiamalo intermedio SA256.
Fare in modo che la CA di emissione intermediaSHA256 generi un certificato firmato con un hash sha256 o superiore. Chiamalo webServerSHA256.
Installa webServerSHA256 in webServerSHA56.mydomain.com.
Installa i certificati rootSHA1, intermediaSHA256 e webServerSHA256 in posizioni appropriate in Google Chrome. Installare la radice su Autorità di certificazione radice attendibili e le altre con una catena di certificati.
Passare a Google Chrome su https://webServerSHA256.mydomain.com/ e verificare che non sia presente un lucchetto verde per webServerSHA256. Il test fallisce.

— RJT
fonte

Questo è abbastanza sbagliato. Certs intermedi (e EE./leaf certs) richiedono SHA2, ma le radici no. La stessa certs di Google passa attraverso la sua CA privata (Google Internet Authority G3) alla radice GlobalSign CA R2 - che è SHA1 - e (nessuna sorpresa) sono accettate da Chrome.

— dave_thompson_085

Sì, tali certificati SHA1 bloccati sono accettati, ma non i nuovi certificati radice SHA1 anche se lo si aggiunge al proprio archivio certificati radice attendibile. Aggiunto un test case alla mia risposta.

— rjt