Qual è la differenza esatta tra la normale cucitura OCSP e OCSP?

La pinzatura OCSP è più efficiente del normale OCSP e offre una migliore privacy.

Il protocollo OCSP viene utilizzato per determinare se un certificato è ancora valido o è stato revocato. Di ', vuoi connetterti in modo sicuro a un sito web tramite TLS. Per essere certi che il certificato non sia stato revocato o scaduto, il browser può inviare una richiesta OCSP all'autorità di certificazione corrispondente. Dopo aver ricevuto una conferma firmata della validità del certificato, prosegui con l'handshake TLS.

Questo processo ha alcuni aspetti negativi: contattare la CA costa tempo e rallenta la tua esperienza di navigazione. Potrebbe anche creare un volume di traffico elevato per la CA, rivelare alla CA quale sito web stai visitando e devi sempre fare affidamento sulla disponibilità del risponditore OCSP poiché altrimenti non è possibile alcuna conferma - e dovresti decidere tra l'accettazione della certificato nonostante la mancanza di conferma o interrompere la connessione. Per questi motivi, Google Chrome ha abbandonato il supporto per OCSP regolare.

La pinzatura OCSP evita questi problemi facendo in modo che il server esegua periodicamente le interrogazioni OCSP. Invece di fare in modo che l'utente esegua il controllo di validità, il server Web ti presenterà la risposta OCSP durante l'handshake TLS. Non è un problema di sicurezza che il server esegua la query OCSP stessa in quanto la risposta è stata firmata dalla CA e include un timestamp, impedendo così la manomissione. Dal momento che il server memorizza nella cache la risposta, le CA non sono piene di richieste OCSP e come utente non è necessario contattare una terza parte per avere un certificato verificato a vantaggio della tua privacy.

Qualcosa da aggiungere alla risposta di @Arminius:

La richiesta OCSP avviata dal client e la pinzatura OCSP condividono ancora un problema: i risponditori OCSP non reattivi. Sia che si tratti del client o del server che si sta certificando, si ottiene la risposta OCSP, il risponditore è lo stesso. Se il rispondente non funziona, tutte le garanzie di sicurezza cadono a pezzi.

L'assenza di una risposta OCSP valida viene gestita in due modi:

1. Hard Fail: un browser può visualizzare un avviso nella pagina che indica che la connessione potrebbe essere compromessa e richiede all'utente di fare clic sugli avvisi per poter esplorare il server in questione.

2. Soft Fail: il browser tenta di ottenere una risposta OCSP valida (dal risponditore o dal certificato inviato dal server in caso di graffatura OCSP), ma in caso di errore continua con la connessione e ignora l'assenza di una risposta OCSP valida.

Per mantenere la disponibilità, i browser di solito preferiscono il secondo approccio.

È difficile dire che un modo è più sicuro dell'altro. La graffetta OCSP riduce il carico sul risponditore riducendo le possibilità che sia DOS-d da richieste autentiche. Le risposte memorizzate nella cache sul lato server accelerano un po 'le cose e riducono il carico sui browser per eseguire il sollevamento pesante di OCSP. Detto questo, un utente malintenzionato può potenzialmente ancora DDOS un risponditore OCSP e impedire persino ai veri server di ottenere una graffetta OCSP valida.

La pinzatura OCSP ha tuttavia comportato un aumento delle prestazioni, come spiegato da questo breve ma brillante post di Nick Sullivan da Cloudflare nel suo blog. Se riusciamo ad aggirare il problema dei risponditori OCSP non rispondenti, e possiamo trovare un modo per essere certi che una risposta ocsp sarà sempre presentata, i certificati possono essere generati con ocsp-must-staple estensione. QUESTO, se sul posto, significherebbe garanzie di sicurezza più forti rispetto a nessun fiocco di ocsp.