en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Ottimizzazione del caricamento della pagina: pinzatura OCSP

Introduzione

Quando un utente visita il tuo sito HTTPS, deve rispondere con un funzionamento Chiave pubblicae un certificato SSL valido che associ la chiave alla tua identità, come persona, azienda o organizzazione. I certificati vengono sempre emessi con una data di scadenza predefinita inclusa nel certificato firmato stesso ei browser controllano sempre la data di scadenza e rifiuteranno qualsiasi certificato scaduto.

Tuttavia, in alcuni casi, un certificato deve essere contrassegnato come non valido (e la fiducia in tali certificati deve essere revocato) prima scade. Esempi comuni includono un proprietario del server che ha prove (o semplicemente sospetta) che la sua chiave privata sia stata compromessa (ovvero che sia stata persa, rubata o distrutta), poiché una terza parte che detiene questa chiave privata può essenzialmente ignorare tutti i controlli di sicurezza della rete del browser.

Di conseguenza, sono richiesti i fornitori di browser pubblicamente fidato autorità di certificazione (CA) per implementare almeno un metodo sia per revocare i certificati problematici sia per avvisare i browser di rifiutare questi certificati revocati.

Per esempi di messaggi di errore del browser risultanti da certificati revocati, fare riferimento a questa guida. Puoi controllare lo stato di revoca di un certificato su certificate.revocationcheck.com.

Una breve storia di (i problemi di) controllo di revoca

Agli albori di SSL, il metodo utilizzato dalle CA era quello di pubblicare lo stato di revoca del certificato in documenti accessibili pubblicamente chiamati elenchi di revoca dei certificati (CRL). Un CRL è semplicemente un elenco di tutti i certificati che una CA ha mai revocato prima della scadenza. Le autorità di certificazione pubblicavano periodicamente l'ultima versione dei loro elenchi CRL, che i browser dovevano consultare prima ogni connessione HTTPS.

Naturalmente, poiché HTTPS (e SSL /TLS) l'adozione è aumentata nel corso degli anni, così come la dimensione delle CRL pubblicate. Il requisito di dover scaricare e analizzare un CRL di grandi dimensioni prima di ogni connessione imponeva un sovraccarico di rete sempre maggiore. È diventato subito evidente che il metodo CRL non si adattava bene.

Per mitigare questi problemi di ridimensionamento, i browser e le CA hanno progettato e implementato Protocollo di stato del certificato online (OCSP). CA pubblicamente attendibili, come SSL.com, ora mantiene semplici server HTTP chiamati Responder OCSP. I browser ora potrebbero contattare un risponditore per richiedere lo stato di revoca di un singolo certificato emesso dalla CA, invece di dover acquisire ed elaborare l'intero CRL.

I risponditori OCSP firmano le loro risposte con la chiave di firma privata della CA ei browser possono verificare che lo stato di revoca ricevuto sia stato effettivamente generato dalla CA effettiva.

Sfortunatamente, anche se all'inizio OCSP sembrava una soluzione efficace, il nuovo protocollo ha dimostrato di avere alcuni problemi pratici di prestazioni, sicurezza e privacy.

Problemi di prestazione

Contattare un risponditore per ogni certificato rilevato dal browser significa che i browser devono eseguire una richiesta HTTP aggiuntiva per ogni nuova connessione HTTPS. Questo sovraccarico della rete era percepibile dagli utenti, specialmente nelle pagine che contenevano contenuti di terze parti archiviate in server di distribuzione di contenuti remoti (che ciascuno poteva avere uno o più certificati in atto).

Reattività è un principio essenziale per una buona progettazione dell'interfaccia utente. I ritardi prolungati possono essere una delle principali cause di frustrazione degli utenti e possono indurre gli utenti a credere che il sito Web non funzioni o che il loro gesto di input sia stato ignorato.

Inoltre, molti studi in passato hanno collegato la velocità di caricamento della pagina veloce e la reattività con SEO ottimizzato e tassi di conversione più elevati. In effetti, Amazon ha calcolato che può costare un ritardo di un solo secondo $ 1.6 miliardo annuale.

(Per maggiori dettagli su come la velocità di caricamento della pagina influenza il tuo sito web e le ottimizzazioni suggerite, dai un'occhiata al nostro articolo descrivendo come la rimozione di contenuti misti dal tuo sito web migliorerà le sue prestazioni.)

Le questioni di sicurezza

Ci sono anche importanti problemi di sicurezza con OCSP. Il fatto che la maggior parte delle implementazioni pratiche di OCSP non fosse sufficientemente affidabile (a causa di un ritardo della rete, o errori di configurazione o dell'applicazione) ha motivato i browser e altri software client per implementare il controllo OCSP soft-fail modalità.

Ciò significa che se un server OCSP non può essere raggiunto o timeout durante la risposta, i browser lo faranno considera valido il certificato e procedere comunque con la connessione HTTPS.

Il ragionamento alla base di ciò è che dal momento che un server OCSP può potenzialmente servire milioni di siti Web ed è possibile che un server OCSP fallisca in qualsiasi momento, interrompere la connessione ad ogni errore OCSP comprometterebbe l'esperienza di navigazione di milioni di utenti. Anche se il server OCSP è in funzione ma richiede molto tempo per rispondere, ciò aumenta il ritardo percepito e la frustrazione dell'utente.

Man-in-the-middle (MITM) gli aggressori sono noti per sfruttare questo comportamento bloccando per tutti i nostri marchi storici connessioni ai risponditori OCSP, il che significa effettivamente che possono utilizzare un certificato rubato e una coppia di chiavi per un sito dannoso, indipendentemente dallo stato di revoca del certificato.

Problemi di privacy

Infine, poiché un certificato è collegato a una chiave e a un nome di dominio ei browser richiedono lo stato di revoca prima di ogni nuova connessione HTTPS, ciò significa che i browser perdono una parte significativa della cronologia web dei loro utenti ai risponditori OCSP.

Naturalmente, le autorità di certificazione pubbliche non sono organizzazioni maligne che cercano di compromettere la privacy degli utenti. (Le CA affidabili ci provano sempre attivamente protegge la sicurezza e la privacy dei loro utenti.) Tuttavia, in caso di compromissione del risponditore OCSP di una CA, i dati scambiati con quel server non attendibile potrebbero portare alla divulgazione di informazioni sensibili e private.

Pinzatura OCSP in soccorso

Per mitigare questi problemi, i browser e le CA hanno escogitato un nuovo metodo per determinare lo stato di un certificato, chiamato Pinzatura OCSP. La pinzatura OCSP consente ai server Web (anziché ai browser) di ottenere risposte OCSP firmate per i loro certificati, che possono essere memorizzati nella cache per un massimo di 7 giorni.

I server includono (o di base) la risposta OCSP memorizzata nella cache nelle risposte HTTPS insieme al certificato SSL stesso. In questo modo, i browser possono verificare la firma della CA sulla risposta OCSP ed essere certi che il certificato non sia stato revocato, prima che venga stabilita la connessione sicura e senza dover eseguire la costosa richiesta aggiuntiva al server OCSP stesso.

La pinzatura OCSP è una soluzione semplice ma molto efficace ai problemi sopra menzionati. I server possono recuperare le risposte OCSP memorizzate nella cache nel proprio tempo, eliminando il sovraccarico di prestazioni imposto da CRL e OCSP, nonché i relativi problemi di privacy.

Tuttavia, la cucitura OCSP da sola non risolve completamente il problema di sicurezza soft-fail di OCSP. Poiché la pinzatura è implementata nel server, i browser non possono sapere se un server supporta effettivamente la pinzatura o meno.

Di conseguenza, gli aggressori MITM con un certificato rubato (ma revocato) possono eseguire un attacco di downgrade servendo il certificato senza pinzatura OCSP. Il browser di una vittima non è in grado di confermare se il server supporta effettivamente la pinzatura e procede all'interrogazione del risponditore OCSP come farebbe normalmente.

Gli aggressori MITM possono quindi semplicemente bloccare questa query OCSP e forzare efficacemente i browser ad accettare il certificato come valido.

OCSP Must-Staple

Questo attacco ha motivato le CA e i fornitori di browser a introdurre un'estensione per i certificati SSL, definita in RFC 7633, comunemente chiamato OCSP Must-Fiocco (anche se la stessa RFC non menziona questo nome, il che può causare un po 'di confusione.) Questo richiede semplicemente la pinzatura OCSP per il certificato. Se un browser rileva un certificato con questa estensione utilizzato senza OCSP Stapling, verrà rifiutato. OCSP Must-Staple mitiga il suddetto attacco di downgrade e riduce anche il traffico non necessario ai risponditori OCSP della CA, il che può anche aiutare a migliorare le prestazioni OCSP complessive.

Se sei interessato ad abilitare l'estensione OCSP Must-Staple nei tuoi certificati, contatta uno dei nostri agenti dell'assistenza all'indirizzo support@ssl.com per ulteriori dettagli.

Abilita pinzatura OCSP nel server

Per evitare il problema di cercare questo, le seguenti sezioni contengono istruzioni su come abilitare la pinzatura OCSP nel proprio Apache che collaborano con noi, attingono direttamente dalla storia e dalla tradizione veneziana Nginx ambienti:

Apache

Per abilitare la pinzatura OCSP nel proprio Apache server, aggiungi le seguenti righe nel file di configurazione del tuo server.

# OCSP Stapling, solo in httpd 2.3.3 e versioni successive SSLUseStapling su SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)

Nginx

Per abilitare la pinzatura OCSP nel proprio Nginx server, aggiungi il seguente testo nel file di configurazione del tuo server.

# OCSP Stapling --- # recupera i record OCSP dall'URL in ssl_certificate e li memorizza nella cache ssl_stapling su; ssl_stapling_verify su;

Conclusione

Il web è una complessa rete di componenti interdipendenti, tutti (di solito) che lavorano in armonia per offrire un'esperienza di navigazione senza soluzione di continuità. La complessità sempre crescente di questo sistema, tuttavia, crea una superficie di attacco sempre più ampia e consente di ideare ed eseguire nuovi attacchi alla rete.

Il semplice numero di componenti aumenta naturalmente la latenza e comporta ritardi, il che significa che le aziende devono trovare modi per migliorare la sicurezza senza influire sull'esperienza dell'utente. Abilitare la pinzatura OCSP ti darà quella rara opportunità di migliorare la sicurezza che collaborano con noi, attingono direttamente dalla storia e dalla tradizione veneziana prestazioni per il tuo sito web allo stesso tempo.

Come sempre, siamo lieti di rispondere alle vostre domande relative alla pinzatura OCSP o ad altri problemi, basta inviarci e-mail all'indirizzo support@ssl.com.

Articoli Correlati

Iscriviti alla Newsletter di SSL.com

Cos'è SSL /TLS?

Riproduci video

Iscriviti alla Newsletter di SSL.com

Non perdere nuovi articoli e aggiornamenti da SSL.com