Domande riguardanti i CRL (prodottiAt e non modificati)

3

Ho due domande sulla sicurezza della richiesta di CRL.

  1. La mia prima domanda è: i CRL non dovrebbero contenere un campo producedAt proprio come le risposte OCSP? Ciò assicurerebbe che un hacker non invii un CRL vecchio (ma non ancora scaduto) al client, giusto? Perché non è fatto? Perché i CRL sono più grandi e firmarli ogni volta costerebbe troppo tempo? Oppure perché i CRL sono visti come file statici (il che non sarebbe una buona ragione)?

  2. Quindi la mia seconda domanda. Ho visto il mio browser ha richiesto un CRL con un'intestazione If-Modified-Since HTTP. Il server ha risposto con un codice 304 - Not Modified . Questo non sarebbe anche un modo semplice per gli hacker di trattenere gli aggiornamenti di un CRL (purché il vecchio sia ancora valido)?

posta SWdV 07.01.2016 - 22:43
fonte

1 risposta

3
  1. [...] is it because CRL's are seen as static files [...]?

  2. Wouldn't this also be an easy way for hackers to withhold updates to a CRL (as long as the old one's still valid)?

Yup. Entrambe le limitazioni sono note. E da come leggo la RFC, entrambe sono scelte progettuali intenzionali.

Da RFC 5280, sezione 3.3 Revoca : (sottolineatura mia)

An advantage of this revocation method is that CRLs may be distributed by exactly the same means as certificates themselves, namely, via untrusted servers and untrusted communications.

One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until all currently issued CRLs are scheduled to be updated -- this may be up to one hour, one day, or one week depending on the frequency that CRLs are issued.

Ulteriori letture

risposta data 08.01.2016 - 08:27
fonte

Leggi altre domande sui tag