Casi d'uso dei certificati

Transport Layer Security (TLS)

Quali sono le due domande che un client deve porsi quando riceve un certificato da un server?

1. Il certificato è valido e attendibile? Il client deve verificare che il certificato sia stato emesso da un'autorità di certificazione (CA) attendibile e che non sia scaduto né revocato. Questo comporta il controllo del periodo di validità del certificato e la verifica che sia firmato da una CA di cui il client si fida.
2. Il certificato corrisponde all'identità del server? Il client deve accertare che i dati del certificato, come il Common Name (CN) o il Subject Alternative Name (SAN), corrispondano al nome di dominio del server. Questo aiuta a confermare che il certificato sia effettivamente destinato al server a cui il client sta tentando di connettersi.

Come verifica il client che un certificato sia affidabile?

1. Controllo della catena di fiducia del certificato: il client verifica la catena di certificati, che comprende il certificato del server, gli eventuali certificati intermedi e il certificato radice. Ogni certificato della catena deve essere firmato dall'autorità immediatamente superiore, fino ad arrivare a un certificato radice attendibile.
2. Verifica del periodo di validità del certificato: il client controlla il periodo di validità del certificato per accertare che non sia scaduto e che sia già valido. Questo comporta il controllo delle date "Not Before" e "Not After" presenti nel certificato.
3. Corrispondenza tra certificato e identità del server: il client verifica che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. In questo modo si conferma che il certificato è destinato al server a cui il client si sta connettendo.
4. Controllo della revoca: il client verifica se il certificato è stato revocato interrogando la Certificate Revocation List (CRL) oppure utilizzando l'Online Certificate Status Protocol (OCSP). Un certificato revocato non è più attendibile.
5. Verifica della firma digitale: il client verifica la firma digitale presente sul certificato per accertare che non sia stato manomesso. Questo comporta il controllo della firma crittografica rispetto alla chiave pubblica della CA emittente.

Come verifica il client che il server sia il reale proprietario di un certificato?

1. Verifica della catena di certificati: il client verifica la catena di certificati, accertando che ogni certificato della catena sia firmato da un'autorità di certificazione (CA) attendibile. La catena parte dal certificato del server e termina in un certificato radice attendibile.
2. Corrispondenza del nome di dominio: il client controlla che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. Questo garantisce che il certificato sia destinato al server a cui il client si sta connettendo.
3. Verifica della firma digitale: il client verifica la firma digitale presente sul certificato utilizzando la chiave pubblica della CA emittente. Questo garantisce che il certificato non sia stato manomesso e sia stato effettivamente emesso da una CA attendibile.
4. Periodo di validità del certificato: il client controlla il periodo di validità del certificato per accertare che sia attualmente valido e non scaduto.
5. Controllo dello stato di revoca: il client verifica se il certificato è stato revocato interrogando la Certificate Revocation List (CRL) oppure utilizzando l'Online Certificate Status Protocol (OCSP). Un certificato revocato non è più attendibile.

Perché la proprietà è importante se si è già verificato che il certificato è attendibile?

Validità e affidabilità del certificato: questo passaggio accerta che il certificato sia stato emesso da un'autorità di certificazione (CA) attendibile, che rientri nel proprio periodo di validità e che non sia stato revocato. Conferma che il certificato è legittimo e non è stato manomesso.

Verifica dell'identità del server: anche se un certificato è valido e attendibile, occorre confermare che appartenga al server a cui ci si sta connettendo. Questo comporta la verifica che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server. Il passaggio garantisce che il certificato sia destinato a quel server specifico e previene gli attacchi man-in-the-middle, in cui un attaccante potrebbe presentare un certificato valido per un dominio diverso.

Con quali due metodi il client risponde a questa domanda? Quali sono i due esiti possibili per ciascun metodo?

1. Verifica tramite Domain Name System (DNS): il client controlla che il Common Name (CN) o il Subject Alternative Name (SAN) del certificato corrisponda al nome di dominio del server.
   Esito:
   • Corrispondenza: se i nomi coincidono, il client può proseguire con la connessione, certo che il certificato sia destinato a quel server.
   • Mancata corrispondenza: se i nomi non coincidono, il client con ogni probabilità interrompe la connessione o mostra un avviso, segnalando un potenziale rischio per la sicurezza.
2. Verifica tramite Public Key Infrastructure (PKI): il client verifica la firma digitale presente sul certificato utilizzando la chiave pubblica dell'autorità di certificazione (CA) emittente.
   Esito:
   • Firma valida: se la firma è valida, si conferma che il certificato non è stato manomesso ed è stato emesso da una CA attendibile.
   • Firma non valida: se la firma non è valida, il client interrompe la connessione o mostra un avviso, segnalando che il certificato potrebbe essere compromesso o fraudolento.

Che cosa determina quale metodo viene utilizzato?

Verifica tramite Domain Name System (DNS):

• Utilizzo: questo metodo viene sempre impiegato nell'ambito dell'handshake TLS. Il client confronta il Common Name (CN) o il Subject Alternative Name (SAN) del certificato con il nome di dominio del server per verificarne la corrispondenza.
• Fattori determinanti: si tratta di una parte standard del protocollo TLS, eseguita automaticamente dal client quando stabilisce una connessione sicura.

Verifica tramite Public Key Infrastructure (PKI):

• Utilizzo: anche questo metodo viene sempre impiegato durante l'handshake TLS. Il client verifica la firma digitale presente sul certificato utilizzando la chiave pubblica dell'autorità di certificazione (CA) emittente.
• Fattori determinanti: si tratta di un'altra parte standard del protocollo TLS. Il client esegue automaticamente questo controllo per accertare che il certificato sia valido e non sia stato manomesso.

Quali certificati deve inviare il server al client?

Durante l'handshake TLS il server dovrebbe inviare al client i certificati seguenti:

• Certificato di entità finale: è il certificato del server stesso, che ne dimostra l'identità al client.
• Certificati intermedi: questi certificati collegano il certificato di entità finale al certificato radice attendibile. Contribuiscono a costruire una catena di fiducia dal certificato del server fino a un certificato radice attendibile.

Che cosa sono i certificati Domain Validation ed Extended Validation?

I certificati Domain Validation (DV) sono un tipo di certificato TLS per il quale l'autorità di certificazione (CA) verifica che il richiedente abbia il controllo del dominio. Di norma questo avviene:

• Rispondendo a un'email inviata al contatto amministrativo del dominio.
• Aggiungendo un record DNS TXT.
• Caricando un file sul server web.

Caratteristiche principali:

• Emissione rapida: possono essere emessi rapidamente, spesso nel giro di pochi minuti, perché richiedono una verifica minima.
• Sicurezza di base: forniscono la cifratura e una garanzia di base che il dominio sia controllato dal soggetto che richiede il certificato.
• Convenienza: spesso sono più economici o persino gratuiti, il che li rende accessibili per siti web di piccole dimensioni e progetti personali.

I certificati Extended Validation (EV) sono certificati TLS di livello superiore, che richiedono un processo di verifica più rigoroso. La CA verifica l'esistenza legale, fisica e operativa del soggetto che richiede il certificato. Questo comprende:

• La conferma dell'identità e dello stato giuridico del soggetto.
• La verifica della presenza fisica e operativa del soggetto.
• L'accertamento che il soggetto abbia il diritto esclusivo di utilizzare il dominio.

Caratteristiche principali:

• Garanzia elevata: offre agli utenti il massimo livello di fiducia e garanzia, perché comporta controlli approfonditi.
• Indicatori visibili: in alcuni browser i certificati EV mostravano il nome dell'organizzazione nella barra degli indirizzi, anche se oggi è meno comune.
• Fiducia rafforzata: ideali per i siti web che trattano informazioni sensibili, come gli istituti finanziari e i siti di e-commerce.

Quali sono più sicuri?

I certificati Extended Validation (EV) sono generalmente considerati più sicuri dei certificati Domain Validation (DV), per via del rigoroso processo di verifica a cui sono sottoposti. Ecco un confronto:

Certificati Domain Validation (DV)

• Livello di verifica: viene verificato solo il controllo del dominio.
• Sicurezza: forniscono cifratura e garanzie di base.
• Caso d'uso: adatti a siti web personali, blog e piccole imprese.

Certificati Extended Validation (EV)

• Livello di verifica: viene verificata l'esistenza legale, fisica e operativa del soggetto.
• Sicurezza: offrono un livello più elevato di fiducia e garanzia, grazie ai controlli approfonditi.
• Caso d'uso: ideali per istituti finanziari, siti di e-commerce e qualsiasi sito web che tratti informazioni sensibili.

Perché i certificati EV sono più sicuri:

• Controlli approfonditi: i certificati EV richiedono una verifica estesa, che rende più difficile ottenerli a soggetti malintenzionati.
• Indicatori di fiducia: benché oggi sia meno comune, i certificati EV mostravano il nome dell'organizzazione nella barra degli indirizzi del browser, offrendo agli utenti una garanzia visibile.
• Garanzia più elevata: il processo di verifica dettagliato assicura che il soggetto dietro il certificato sia legittimo, riducendo il rischio di phishing e di altri attacchi.

Come funziona la revoca con l'OCSP stapling

L'OCSP stapling migliora il processo OCSP standard riducendo la latenza e aumentando la riservatezza. Ecco come funziona:

1. Il server richiede una risposta OCSP: il server web richiede periodicamente lo stato di revoca del proprio certificato all'OCSP responder, un server gestito dall'autorità di certificazione (CA). La richiesta avviene in background e non a ogni connessione del client.
2. L'OCSP responder fornisce la risposta: l'OCSP responder restituisce una risposta OCSP firmata e con marca temporale che indica lo stato del certificato, ad esempio "good", "revoked" oppure "unknown". Il server mette la risposta in cache.
3. Handshake TLS con risposta allegata: quando un client, ad esempio un browser web, avvia una connessione verso il server, il server include la risposta OCSP memorizzata in cache nell'handshake TLS. Questo è ciò che si intende per "stapling" della risposta all'handshake.
4. Il client verifica la risposta OCSP: il client verifica la risposta OCSP allegata. Poiché la risposta è firmata dalla CA, il client può fidarsi della sua validità. Se la risposta indica che il certificato è revocato, il client non stabilisce una connessione sicura.
5. Aggiornamenti periodici: il server continua ad aggiornare periodicamente la risposta OCSP in cache, così da avere sempre a disposizione uno stato aggiornato da fornire durante l'handshake TLS.

Questo processo riduce la necessità per i client di effettuare richieste OCSP separate, migliorando così prestazioni e riservatezza.