Bonjour à tous,

Il y a plusieurs mois, j’avais fait un article sur le protocole ESNI et je vous invite à aller le lire si ce n’est déjà fait !

Aujourd’hui, nous allons nous attarder protocole OCSP, je me suis entre autres inspiré des explications fournies sur Wikipédia.

Pour comprendre cet article, il n’est pas nécessaire d’avoir des connaissances poussées mais uniquement d’avoir des bases sur le chiffrement par clé. Par simplicité et parce que c’est un des protocoles les plus courants pour le grand public, les exemples seront souvent basés sur le HTTPS, mais cela ne veut pas dire que le protocole OCSP (et tout ce qu’on verra autour) est propre au HTTPS.

Les certificats numériques

Avant de voir le protocole OCSP, il faut tout d’abord comprendre ce qu’est un certificat numérique.

Un certificat numérique est utilisé pour identifier ou authentifier une personne (qu’elle soit physique ou morale) mais également pour chiffrer des échanges. Et c’est cette partie qui nous intéresse particulièrement aujourd’hui.

Le certificat est signé par un tiers de confiance (nous allons voir ce que c’est un peu plus tard) pour attester du lien entre l’identité physique ou morale et l’entité numérique. Le standard le plus utilisé pour les certificats numériques est le X.509.

Les tiers de confiance

Un tiers de confiance est habilité à effectuer des opérations de sécurité juridique d’authentification et de transmission.

On peut citer plusieurs exemples:

• La protection sur les paiements comme Paypal, etc.
• La protection (avec un certificat numérique donc) des échanges sur internet.

C’est ce dernier point sur lequel nous allons nous attarder aujourd’hui.

Dans le monde de la sécurité, il existe 3 principaux tiers de confiance:

• L’autorité de certification (abrégé CA en anglais): elle définit une politique de certification et est porteuse de la confiance des utilisateurs.
• L’autorité d’enregistrement: elle vérifie l’identité du demandeur.
• L’opérateur de certification: il assure la fourniture et la gestion des certificats électroniques.

Le certificat HTTPS présent sur ce site est par exemple fourni par l’autorité de certification Let’s Encrypt qui, du fait de sa gratuité, a énormément contribué à la démocratisation du HTTPS au profit du HTTP.

Le X.509

Revenons à nos moutons sur les certificats numériques.

Le X.509 est donc une norme sur les certificats numériques qui spécifie les formats pour:

• Les certificats à clé publique.
• Les listes de révocation de certificat.
• Les attributs de certificat.
• Un algorithme de validation du chemin de certification.

X.509 est donc une norme se reposant sur les autorités de certification (qu’on abrégera CA dans le reste de cet article) et dont le certificat associé comporte toute une liste d’informations comme des identifiants ou la date de validité du certificat. Le protocole HTTPS utilise ainsi un certificat se basant sur cette norme, certificat qui est donc validé par une CA qui le chiffre. Il faut savoir que cette norme est très répandue et est également utilisée par d’autres protocoles tels que SSH, S/MIME, IPSec …

Enfin, il est également nécessaire de parler de la révocation d’un certificat. Un certificat révoqué est un certificat caduc qui n’est donc plus valable.

Les raisons de révocation sont principalement:

• L’expiration du délai de validité (s’il n’a pas été renouvelé par exemple).
• La clé privée associée au certificat est compromise.
• L’identité du demandeur ne peut plus être garantie.

Le rôle de la CA est également de fournir la liste des certificats qui ne sont plus valides. On le voit, les autorités de certification ont donc un rôle majeur notamment sur le Web avec le HTTPS car chaque visite sur un site implique la vérification de la validité de son certificat.

La validation des certificats

Maintenant que nous avons vu le principe des certificats numériques, intéressons-nous au protocole OCSP dont le but est justement de valider ces certificats.

OCSP signifie Online Certificate Status Protocol en anglais, ce qui se traduit par Protocole de Vérification de Certificat en Ligne. C’est un protocole standardisé dans la RFC 6960. Bien qu’inconnu du grand public et invisible aux yeux de tous, ce protocole possède un rôle majeur dans le fonctionnement notamment d’internet (avec les fameux certificats derrière le protocole HTTPS). Comme son nom l’indique, ce protocole permet donc la vérification des certificats, pour vérifier s’ils ne sont pas révoqués par exemple.

La CRL

Anciennement, il y avait uniquement la CRL pour Certificate Révocation List. Chaque CA possédait alors une liste des certificats révoqués. À chaque visite sur un site en HTTPS, la CA renvoie alors cette liste (CRL) au navigateur et vérifie que le certificat n’est pas dedans.

L’inconvénient majeur est que ce mode de fonctionnement génère un trafic important vers les autorités de certification puisque la totalité de la liste est systématiquement retournée. Si ces dernières ne pouvaient répondre (trop de demandes par exemple), le navigateur n’avait alors pas la liste et supposait que le certificat n’était pas révoqué.

L’OCSP

À contrario du CRL qui se base sur une liste noire à chaque demande, l’OCSP fonctionne plutôt sur liste blanche où n’est envoyé que des informations sur le certificat à vérifier. La CA renvoie en effet le statut du certificat demandé.

À juste titre, vous allez me dire que ce fonctionnement génère tout de même du trafic à chaque demande comme avec les CRL. Cependant, le trafic généré est bien moins important car ce n’est plus la totalité de la liste qui est retournée. Si la CA ne répond pas ou n’est pas disponible, le navigateur bloquera alors l’accès au site.

Un point positif concernant l’OCSP est qu’il apporte une amélioration la sécurité dans le sens où la liste des certificats révoqués n’est pas directement retournée. Cela complique légèrement la tâche des personnes mal intentionnées qui souhaiteraient exploiter des certificats révoqués en grande quantité par exemple.

Un point négatif sur ce protocole est que les requêtes se font le plus souvent en HTTP, et donc sont en clair et non chiffrées, elles peuvent donc être lues par n’importe qui. Cependant, les échanges peuvent également se faire en HTTPS, même si ce n’est pas encore courant. En revanche, un pirate qui voudrait se faire passer pour une CA ne pourrait pas car la réponse des CA est toujours chiffrée pour garantir son authenticité.

Exemple d’utilisation de l’OCSP

Je reprends tel quel l’exemple présent sur la page Wikipédia car sa clarté me semble parfaite pour comprendre le fonctionnement de l’OCSP.

1. Alice et Bob sont des clients d’Ivan, la CA. Ils possèdent le certificat de clé publique d’Ivan.
2. Alice et Bob possèdent chacun un certificat de clé publique émis par Ivan.
3. Alice veut effectuer une transaction avec Bob. Elle lui envoie donc son certificat contenant sa clé publique.
4. Bob veut s’assurer que le certificat d’Alice n’a pas été révoqué. Il crée une requête OCSP contenant l’empreinte du certificat d’Alice et l’envoie à Ivan.
5. Le répondeur OCSP d’Ivan vérifie le statut du certificat d’Alice dans la base de données de la CA.
6. Le répondeur OCSP confirme la validité du certificat d’Alice en envoyant une réponse OCSP positive signée à Bob.
7. Bob vérifie la signature cryptographique de la réponse.
8. Bob effectue sa transaction avec Alice.

L’OCSP Stapling

Comme on vient de le voir avec l’OCSP simple, l’autorité de certification reste un SPOF (pour Single Point of Failure), c’est-à-dire que si elle tombe, les clients de cette autorité ne pourront pas voir leurs certificats vérifiés et les sites seront alors bloqués par défaut par les navigateurs.

L’OCSP Stapling (pour agrafage OCSP, on comprendra plus tard la raison de son nom) a pour but de résoudre à cette problématique. En effet, plutôt que ce soit le navigateur qui fasse la requête OCSP pour vérifier le certificat d’un site, ce sera directement le site qui fera la requête.

Lorsqu’un site communique son certificat, il ajoutera alors un petit appendice agrafé correspondant à la réponse OCSP qui aura été chiffrée et horodatée par la CA.

Sur un site très fréquenté, la CA est n’est donc sollicitée que par le site en question et à intervalles beaucoup moins fréquents (environ tous les 7 jours) qu’à chaque requête d’un client. De façon générale, on économise alors de la bande passante et la vitesse d’accès au site se trouve de fait améliorée car on supprime les échanges entre le navigateur et la CA.

Conclusion

Dans cet article, nous avons vu les évolutions qui ont pu avoir lieu sur la validation des certificats avec la CRL puis l’OCSP. C’est en effet un mécanisme invisible toutefois indispensable sans lequel le HTTPS (entre autres) ne fonctionnerait pas.