La potenza di un certificato NON è nel certificato. È nella chiave privata. Quando un server "usa un certificato", utilizza realmente la chiave privata; e il server mostra il certificato (che contiene solo la chiave pubblica) al client. Il certificato è una prova che una determinata chiave pubblica appartiene a un'entità specificatamente denominata. Ad esempio, il certificato utilizzato dal server SSL www.google.com contiene quel nome ( www.google.com ) e la chiave pubblica di Google. Ovviamente Google non ti mostrerà la chiave privata!
Un certificato non è accettato come prova semplicemente perché esiste; un client deve eseguire convalida del certificato , un processo complesso e complesso che comporta la creazione di catene di certificati e la verifica di molte firme, poiché un certificato è firmato da un'autorità dotata del potere di firmare il certificato , ed è quindi denominato un'autorità di certificazione (o CA in breve).
I certificati sono descritti in X.509 , che è meglio descritto come "Il diavolo del capolavoro della confusione". Per far fronte praticamente alla pura complessità di X.509, le implementazioni, in particolare i browser Web e altre applicazioni client SSL, tendono a "prendere scorciatoie" che consentono di completare l'intera procedura di convalida entro un tempo ragionevole, ma hanno anche un effetto deleterio sull'intero la sicurezza.
Il blocco dei certificati è un metodo con cui alcune implementazioni cercano di ripristinare un po 'di sicurezza pur restando praticabili. Tutto X.509 è context-free : un client dovrebbe essere in grado di convalidare un certificato del server senza memoria o stato mantenuto da precedenti convalide. Il blocco del certificato è la negazione di tale nozione: il client "pin" un certificato con ricordando che un determinato certificato è stato utilizzato da alcuni server e quindi utilizzando tali informazioni per "convalidare" quel certificato in modo efficiente, il client si connette di nuovo allo stesso server. Il blocco aggiunge anche rifiuta un certificato server se non è uguale a quello utilizzato dal server durante una precedente connessione a quello stesso server.
L'idea è che se un utente malintenzionato tenta di mostrarti un server falso, non sarà in grado di mostrare il certificato del server originale - ovviamente, l'autore dell'attacco potrebbe mostrare una copia del certificato vero (questo è pubblico dati, il server lo invia a tutti i client di connessione), ma l'utente malintenzionato non sarebbe in grado di utilizzare la chiave privata corrispondente, poiché non ce l'ha (la chiave privata, come dice il nome, è privata). Invece, per essere in grado di posare come server falso in grado di eseguire un handshake SSL completo, l'utente malintenzionato deve fornire al client un certificato falso che contiene la chiave pubblica dell'aggressore, distinta da quella del server. Con il pinning del certificato, il client sospetto noterà che il server ha apparentemente cambiato i certificati, e lo troverà peschioso, e si lamenterà con l'utente, che farà quindi clic sul popup di avvertimento dannato e procederà all'invio del suo numero di carta di credito all'attaccante perché gli utenti sono così.
Si noti che il blocco dei certificati è utile solo nei casi in cui l'autore dell'attacco possa ottenere un certificato accettato da ciò che passa per il codice di convalida del certificato nelle applicazioni client. Ci sono stati alcuni casi altamente pubblicizzati di una CA che viene corrotta o compromessa nell'emettere certificati falsi; tuttavia, questo è ancora raro. Inoltre, il blocco dei certificati non può essere davvero assoluto perché i certificati hanno date di validità, per un sacco di motivi (alcuni dei quali sono persino accettabili razionalmente), quindi ci devono essere alcune situazioni in cui un client con il blocco dei certificati accetterà ancora che il server abbia cambiato il suo certificato .
Un esempio di protocollo, simile a SSL, e l'utilizzo di coppie di chiavi pubbliche / private (non i certificati X.509, però) in un modello "full pinning", è SSH. Quando ci si connette a un server SSH per la prima volta, il client chiede conferma se la chiave pubblica inviata dal server è quella giusta (l'utente umano dovrebbe controllare l'hash di quella chiave con qualche fonte autorevole); quindi, il client ricorda quella chiave (nel file .ssh/known_hosts per i client SSH basati su Unix) e griderà ad alta voce se il server dovesse mai cambiare la sua chiave.