Secondo lo screenshot seguente, preso da firefox-3.6.17-1.fc14.i686, Firefox ha un'opzione per fallire quando non è possibile connettersi ai server OCSP.
Qualcuno può spiegare perché questo non è abilitato di default?
Secondo lo screenshot seguente, preso da firefox-3.6.17-1.fc14.i686, Firefox ha un'opzione per fallire quando non è possibile connettersi ai server OCSP.
Qualcuno può spiegare perché questo non è abilitato di default?
Ci sono diversi problemi con OCSP. Alcuni di loro:
Alcune CA non offrono un server OCSP, basandosi invece su CRL (in particolare, l'OCSP completo con supporto per client nonces è piuttosto costoso per la CA). E tra coloro che implementano OCSP, molti bocciano il lavoro, risultando in risposte OCSP che non sono, per se , verificabili (ad esempio la risposta OCSP è firmata con un certificato di risponditore OCSP dedicato per il quale lo stato di revoca non può essere ottenuto). Quindi, fare in modo che OCSP controlli i mezzi obbligatori, in questo momento, rifiuta di parlare con una percentuale non trascurabile di siti Web SSL esistenti. Il mondo è semplicemente "non pronto" per l'ampia accettazione di OCSP.
Il grande - IMO - è la velocità. Ho usato un paio di plug e configurazioni diversi per abilitare OCSP nei browser, e anche in un ambiente di laboratorio in cui il server OCSP è alleggerito e un hop in un ambiente con larghezza di banda elevata, il controllo OCSP può essere un grave ritardo nella creazione della sessione. Ho persino ricevuto molti reclami da parte degli utenti, anche quando gli utenti sono altri ingegneri che capiscono esattamente cosa sta succedendo.
In un browser pubblico come Firefox, non vorranno avere le impostazioni predefinite che rendono il tuo browser dolorosamente lento quando fai acquisti online.
Inoltre - c'è una certa quantità di configurazione nei controlli OCSP - hai un server OCSP locale che preferisce la configurazione nel certificato? In che modo, esattamente, il certificato è configurato: non esiste un modo perfetto per impostare un URL per i controlli OCSP. Il tuo browser sarà tenuto a firmare le richieste OCSP? Richiederà un nonce? E per un sistema sicuro, non è un controllo OCSP, è un controllo per ogni certificato nella catena tranne per il root autofirmato.
E quante volte il browser riproverà una richiesta senza risposta? E quanto a lungo aspettare per decidere che non ha ricevuto una risposta?
Queste non sono domande a cui un utente medio può rispondere, e i browser sono assolutamente costruiti per il minimo comune denominatore.
Non sono d'accordo con alcune delle posizioni che è perché è troppo gravoso per la CA. Generalmente i server OCSP sono separati dalla CA. La CA firma il CRL e passa questo CRL a un risponditore OCSP. Una suite di responder OCSP con bilanciamento del carico può essere gestita per gestire il traffico. OCSP, da solo, non è un carico pesante. È una transazione piuttosto piccola, con dati abbastanza semplici. Le prestazioni sono in genere correlate alla dimensione del CRL e all'eventuale impostazione della connessione / impatto di teardown. Questo tipo di servizio è assolutamente fattibile se la spinta è lì per averlo. Il problema più grande è che il servizio stesso è ancora abbastanza complicato da non essere facile da configurare o universale. E non è il tipo di cosa che gli utenti medi apprezzano abbastanza per avere ritardato le loro sessioni SSL.
Perché OCSP mette troppo a dura prova la CA. Immagina di essere una CA di fiducia. Ora immagina l'infrastruttura che devi mettere in atto per gestire milioni di richieste OCSP sul tuo server ogni secondo. Buoni affari?
Leggi altre domande sui tag cryptography web-browser public-key-infrastructure certificates certificate-revocation