Perché non ci fidiamo di un certificato SSL scaduto di recente?

Quando un certificato è scaduto, il suo stato di revoca non viene più pubblicato. Cioè, il certificato potrebbe essere stato revocato molto tempo fa, ma non sarà più incluso nel CRL. La data di scadenza del certificato è la data limite per l'inclusione CRL. Questo è il motivo ufficiale per cui i certificati scadono: mantenere le dimensioni del CRL limitate.

(La ragione non ufficiale è far pagare ai proprietari dei certificati una tariffa annuale.)

Quindi non puoi fidarti di un certificato scaduto perché non puoi controllare lo stato di revoca . Potrebbe essere stato revocato mesi fa e tu non lo sapresti.

Una buona domanda. La risposta più semplice è che avere una data di scadenza garantisce di avere un "controllo" ogni tanto. Se non ci fosse data di scadenza e qualcuno smettesse di usare un certificato (e proteggendo la chiave privata), nessuno lo saprebbe mai. Tuttavia, avendo una data di scadenza, si assicura che l'utente ritorni alla società che ha venduto loro il certificato SSL e paga molti più soldi, intendo, ha un controllo e viene riconvalidato come la persona o il servizio che rivendicano essere (proverò a lasciare in sospeso le dichiarazioni sull'attuale modello di sicurezza di Internet).

Il problema diventa allora: se hai un periodo di prova in cui ignori i certificati scaduti, quanto dura? Un giorno? Una settimana? Un mese? Ad un certo punto devi semplicemente smettere di fidarti del certificato; se fai quel punto un giorno dopo la scadenza, puoi ancora chiederti: "Cosa potrebbe essere successo tra oggi e ieri?" E tu cadi in un ciclo.

In sostanza, hai ragione: le persone non smettono magicamente di proteggere le proprie chiavi private non appena scade la data di scadenza (o potrebbero aver smesso di proteggerle molto tempo fa e nessuno lo sa perché non le hanno revocate e non sono ancora scaduti). La data di scadenza non dice nulla sulla sicurezza del certificato, ma se non hai un taglio ti mai sapere che un certificato può essere dimenticato mentre con uno almeno lo sai più di tanto .

Se ci fosse un periodo di grazia universale di cinque giorni, nessuno noterebbe la scadenza dei certificati fino a cinque giorni dopo, lasciandoti con un effetto netto identico a rifiutare immediatamente un certificato scaduto. È il fatto che le connessioni SSL smettono di funzionare e questo crea pressione.

Ho il sospetto che sarebbe più produttivo per le applicazioni client SSL avvertire a voce alta di una scadenza imminente del certificato, in modo che gli utenti di tali applicazioni possano fare pressione sui loro fornitori di servizi in anticipo.

Sono d'accordo sul fatto che il sistema attuale sia subottimale.

Un sistema di certificati migliore potrebbe avere un periodo di validità "giallo" per i certificati che stanno per scadere ("verde" è un certificato valido e "rosso" è un certificato scaduto), con scadenza entro 1 mese. Ogni certificato N-year scadrà dopo N anni + 1 mese, anche se idealmente verrebbero aggiornati entro il periodo N. Tuttavia, durante l'ultimo mese, ogni applicazione che utilizza un certificato dovrebbe presentare una lieve segnalazione di avvertimento all'utente. Per la navigazione web, potresti fare qualcosa come colorare l'URL in giallo invece che in verde - con un messaggio di hover / clic sull'effetto:

This website's certificate will expire on Mar 25, 2013 and should be updated by the domain owner before they expire. The certificate is still perfectly valid and should be fully trusted at this date, but applications that rely on this certificate will stop working on Mar 25, 2013 if the certificate is not updated by then.

Sarebbe perfetto? Probabilmente no, poiché alcune applicazioni potrebbero non trasmettere questi messaggi all'utente e la data di scadenza sarà comunque raggiunta. Inoltre, ci deve essere un accordo codificato in uno standard per quanto tempo prima che i certificati scadano che dovrebbero essere aggiornati (un giorno? Una settimana? Due settimane? Un mese?). Ma sicuramente sembra essere un miglioramento.

(Concesso, sono d'accordo che Microsoft abbia davvero abbandonato la palla quando hanno lasciato scadere il loro certificato Azure - questo è un segno di incompetenza per una piattaforma che tenta di supportare le applicazioni aziendali).

La risposta è semplice come il business: "Il conto non viene pagato"

L'autorità di certificazione reclama per un periodo di tempo distinto che questo certificato è valido. Ma questo non dice molto sulla fiducia dell'autorità di certificazione e sui processi da parte del proprietario del certificato.

Ha a che fare con la percezione e le pratiche di sicurezza appropriate.

Quando crei un certificato con, diciamo, una scadenza di un anno, stai sostanzialmente dicendo "Non possiamo garantire l'integrità del certificato per più di un anno, quindi prima di allora pubblicheremo un nuovo certificato ".

Quindi un sito con un certificato scaduto è un segno che gli amministratori non hanno mantenuto la promessa di rinnovare entro il tempo stabilito per loro stessi, il che suggerisce scarse pratiche di sicurezza.

È lo stesso motivo per cui prendi l'inferno per aver perso un'ispezione dell'automobile anche se la tua auto sembra funzionare bene o perché i prodotti hanno una data di scadenza.

La shelf-life potrebbe essere una cosa interessante per alcuni prodotti: il produttore dichiara che garantisce che il prodotto sarà valido durante un certo periodo di tempo, ma non può garantire che le proprietà originali siano presenti se si consuma il prodotto dopo tale periodo.

Un certificato ha la stessa cosa: ha un periodo in cui l'emittente afferma che è valido. Durante quel periodo il certificato dovrebbe essere ok. E se non lo è, ci sarà qualche ricordo su di esso: una lista di revoche da parte dell'emittente dirà al mondo intero "non fidarti ancora di quel certificato, perché in qualche modo potrebbe essere compromesso".

Dopo la data di scadenza, l'emittente non terrà più traccia di quel certificato: ha passato la data in cui era buono, quindi chiunque ne abbia ancora fiducia dovrebbe farlo basandosi solo sulla sua convinzione, non sull'emittente (o chiunque altro) altro).

Dopo la data di scadenza, il certificato non è male, rotto, puzzolente ... non è più garantito che sia stato revocato. E perché non ci fidiamo di un certificato SSL scaduto di recente perché vogliamo la sicurezza e usiamo i certificati per garantire qualcosa. Se non possiamo essere sicuri che fosse (o sarebbe) revocato , non puoi essere sicuro che sia stato compromesso e non hai alcuna sicurezza che lo usi ...

Oltre alle cose già menzionate (è buona prassi cambiare tali chiavi su base regolare, le CA vogliono essere pagate, ri-audire l'identità ecc.), c'è anche un motivo tecnico. I browser ti informano che non possono verificare la validità del certificato.

I certificati possono essere revocati, ovvero contrassegnati come non validi, nel caso in cui le chiavi vengano compromesse, la CA si accorga di essere stati omessi, ecc. Queste informazioni di revoca sono garantite per essere fornite durante il periodo di validità, ma non dopo. Ciò consente di mantenere piccole le dimensioni CRL (Certificate Revocation List). Sebbene i CRL siano usati raramente oggi in SSL basato su browser, questo potrebbe influenzare anche altri mezzi di verifica della validità.

Per questo motivo, far rispettare la data di validità ha un senso tecnico e non viene fatto solo perché "i certificati devono essere rinnovati per garantire il riconoscimento" e "le CA vogliono essere pagate".

L'impostazione della data di scadenza per i certificati viene eseguita per lo stesso motivo per cui è necessario modificare la password di volta in volta e disporre di una politica che consenta agli utenti di modificarla di volta in volta. Non sempre necessario , ma potrebbe essere utile a volte.

Ad esempio il tuo ex-dipendente che ha il tuo posto di lavoro (interno) CA potrebbe firmare il suo sito web phising e non noterai alcuna differenza tra il suo sito e il tuo sito bancario (compreso il browser che dice che la connessione è sicura). Avere una data di scadenza almeno sulla CA interna ti fa cambiare di tanto in tanto ed evitarlo.

Puoi ancora dire "Non mi interessa" e impostare la data del certificato ad es. 2300 (se sei il proprietario di CA). Ovviamente le autorità commerciali e esterne potrebbero voler impostare la data di scadenza della licenza; -).

Dipende da cosa stai assicurando. È relativamente sicuro. Si tratta di un giorno zero, l'uomo nel mezzo dell'attacco. Un utente malintenzionato dovrebbe conoscere il certificato scaduto, sapere che si utilizza quel certificato e inserirsi tra l'utente e il server nell'arco di pochi giorni. Se stai custodendo segreti nucleari, è troppo rischioso fidarsi. Se si invia il numero di carta di credito, sarebbe ok per alcuni giorni o settimane (non che tu sia comunque responsabile). Se pubblichi un blog sui dittatori in Iran, mentre sei in Iran, stai mettendo a rischio la tua vita, e potrebbe non valerne la pena.