In passato i certificati spesso scadevano perché dovevano essere rinnovati manualmente. Le persone semplicemente si dimenticavano di farlo. Con l'avvento di Let's Encrypt e della procedura di aggiornamento automatico, sembra che il problema dovrebbe essere risolto. Ma recente Storia di Firefox dimostra che, in effetti, è ancora rilevante. Sfortunatamente, i certificati continuano a scadere.

Nel caso in cui ti fossi perso la storia, a mezzanotte del 4 maggio 2019, quasi tutte le estensioni di Firefox hanno smesso improvvisamente di funzionare.

Come si è scoperto, il massiccio fallimento è avvenuto a causa del fatto che Mozilla il certificato è scaduto, che veniva utilizzato per firmare le estensioni. Pertanto, sono stati contrassegnati come "non validi" e non sono stati verificati (dettagli tecnici). Sui forum, come soluzione alternativa, è stato consigliato di disabilitare la verifica della firma dell'estensione in about: config o cambiare l'orologio del sistema.

Mozilla ha rilasciato rapidamente la patch Firefox 66.0.4, che risolve il problema con un certificato non valido e tutte le estensioni tornano alla normalità. Gli sviluppatori consigliano di installarlo e non usare nessuna soluzione alternativa per aggirare la verifica della firma perché potrebbero entrare in conflitto con la patch.

Tuttavia, questa storia dimostra ancora una volta che la scadenza dei certificati rimane una questione urgente anche oggi.

A questo proposito, è interessante osservare il modo piuttosto originale in cui gli sviluppatori del protocollo hanno affrontato questo compito DNSCrypt. La loro soluzione può essere divisa in due parti. Innanzitutto, si tratta di certificati a breve termine. In secondo luogo, avvisare gli utenti della scadenza di quelli a lungo termine.

DNSCrypt

DNSCrypt è un protocollo di crittografia del traffico DNS. Protegge le comunicazioni DNS da intercettazioni e MiTM e consente inoltre di aggirare il blocco a livello di query DNS.

Il protocollo avvolge il traffico DNS tra client e server in un costrutto crittografico, operando sui protocolli di trasporto UDP e TCP. Per utilizzarlo, sia il client che il risolutore DNS devono supportare DNSCrypt. Ad esempio, da marzo 2016 è abilitato sui suoi server DNS e nel browser Yandex. Anche diversi altri fornitori hanno annunciato il supporto, tra cui Google e Cloudflare. Sfortunatamente non ce ne sono molti (sul sito ufficiale sono elencati 152 server DNS pubblici). Ma il programma dnscrypt-proxy può essere installato manualmente su client Linux, Windows e MacOS. Ci sono anche implementazioni del server.

Come funziona DNSCrypt? In breve, il client prende la chiave pubblica del provider selezionato e la utilizza per verificare i propri certificati. Le chiavi pubbliche a breve termine per la sessione e l'identificatore della suite di crittografia sono già presenti. I client sono incoraggiati a generare una nuova chiave per ogni richiesta e i server sono incoraggiati a modificare le chiavi ogni 24 ore. Quando si scambiano chiavi, viene utilizzato l'algoritmo X25519, per la firma - EdDSA, per la crittografia a blocchi - XSalsa20-Poly1305 o XChaCha20-Poly1305.

Uno degli sviluppatori del protocollo Frank Denis scrivequella sostituzione automatica ogni 24 ore ha risolto il problema dei certificati scaduti. In linea di principio, il client di riferimento dnscrypt-proxy accetta certificati con qualsiasi periodo di validità, ma emette un avviso "Il periodo della chiave dnscrypt-proxy per questo server è troppo lungo" se è valido per più di 24 ore. Contestualmente è stata rilasciata un'immagine Docker nella quale è stato implementato il cambio rapido delle chiavi (e dei certificati).

Innanzitutto è estremamente utile per la sicurezza: se il server viene compromesso o la chiave viene divulgata, il traffico di ieri non potrà essere decrittografato. La chiave è già cambiata. Ciò probabilmente rappresenterà un problema per l’attuazione della legge Yarovaya, che obbliga i fornitori a archiviare tutto il traffico, compreso quello crittografato. L'implicazione è che potrà essere successivamente decifrato, se necessario, richiedendo la chiave al sito. Ma in questo caso il sito semplicemente non può fornirlo, perché utilizza chiavi a breve termine, cancellando quelle vecchie.

Ma la cosa più importante, scrive Denis, è che le chiavi a breve termine costringono i server a impostare l’automazione fin dal primo giorno. Se il server si connette alla rete e gli script di modifica della chiave non sono configurati o non funzionano, ciò verrà rilevato immediatamente.

Quando l'automazione cambia le chiavi ogni pochi anni, non è possibile fare affidamento su di essa e le persone possono dimenticarsi della scadenza del certificato. Se cambi le chiavi ogni giorno, questo verrà rilevato immediatamente.

Allo stesso tempo, se l'automazione è configurata normalmente, non importa quanto spesso vengono cambiate le chiavi: ogni anno, ogni trimestre o tre volte al giorno. Se tutto funziona per più di 24 ore, funzionerà per sempre, scrive Frank Denis. Secondo lui, la raccomandazione della rotazione giornaliera delle chiavi nella seconda versione del protocollo, insieme a un'immagine Docker già pronta che la implementa, ha effettivamente ridotto il numero di server con certificati scaduti, migliorando allo stesso tempo la sicurezza.

Tuttavia, alcuni fornitori hanno deciso, per motivi tecnici, di fissare il periodo di validità del certificato a più di 24 ore. Questo problema è stato in gran parte risolto con poche righe di codice in dnscrypt-proxy: gli utenti ricevono un avviso informativo 30 giorni prima della scadenza del certificato, un altro messaggio con un livello di gravità più elevato 7 giorni prima della scadenza e un messaggio critico se il certificato ha residui validità inferiore a 24 ore. Questo vale solo per i certificati che inizialmente hanno un lungo periodo di validità.

Questi messaggi offrono agli utenti la possibilità di avvisare gli operatori DNS dell'imminente scadenza del certificato prima che sia troppo tardi.

Forse se tutti gli utenti di Firefox ricevessero un messaggio del genere, qualcuno probabilmente informerebbe gli sviluppatori e non permetterebbero la scadenza del certificato. "Non ricordo un solo server DNSCrypt nell'elenco dei server DNS pubblici il cui certificato sia scaduto negli ultimi due o tre anni", scrive Frank Denis. In ogni caso, probabilmente è meglio avvisare prima gli utenti piuttosto che disattivare le estensioni senza preavviso.

Fonte: habr.com