Introduction
Lorsqu'un utilisateur visite votre site Web HTTPS, il doit répondre par un Clé publiqueet un certificat SSL valide associant la clé à votre identité, que ce soit en tant que personne, entreprise ou organisation. Les certificats sont toujours émis avec une date d'expiration prédéfinie qui est incluse dans le certificat signé lui-même, et les navigateurs vérifient toujours la date d'expiration et rejetteront tout certificat expiré.
Cependant, dans certains cas, un certificat doit être marqué comme invalide (et la confiance à ces certificats doit être révoqué) before il expire. Des exemples courants incluent un propriétaire de serveur ayant des preuves (ou soupçonnant simplement) que sa clé privée a été compromise (c'est-à-dire qu'elle a été perdue, volée ou détruite), car un tiers détenant cette clé privée peut essentiellement contourner tous les contrôles de sécurité du réseau du navigateur.
En conséquence, les fournisseurs de navigateurs requis confiance du public autorités de certification (CA) pour implémenter au moins une méthode permettant à la fois de révoquer des certificats problématiques et de notifier aux navigateurs de rejeter ces certificats révoqués.
Un bref historique de (les problèmes de) vérification de révocation
Dans les premiers jours de SSL, la méthode utilisée par les autorités de certification consistait à publier l'état de révocation de leur certificat dans des documents accessibles au public appelés listes de révocation de certificats (CRL). Une liste de révocation de certificats est simplement une liste de tous les certificats qu'une autorité de certification a révoqués avant l'expiration. Les autorités de certification ont périodiquement publié la dernière version de leurs listes de révocation de certificats, que les navigateurs devaient consulter before chaque connexion HTTPS.
Naturellement, comme HTTPS (et SSL /TLS) a augmenté au fil des ans, tout comme la taille des LCR publiées. La nécessité de devoir télécharger et analyser une grande liste CRL avant chaque connexion imposait une surcharge réseau toujours croissante. Il est rapidement devenu évident que la méthode CRL ne fonctionnait pas bien.
Pour atténuer ces problèmes de mise à l'échelle, les navigateurs et les autorités de certification ont conçu et mis en œuvre le Protocole de statut de certificat en ligne (OCSP). Autorités de certification de confiance publique, telles que SSL.com, maintenant gérer des serveurs HTTP simples appelés Répondeurs OCSP. Les navigateurs pouvaient désormais contacter un répondeur pour demander le statut de révocation d'un seul certificat émis par l'autorité de certification, au lieu d'avoir à acquérir et traiter l'intégralité de la liste de révocation de certificats.
Les répondeurs OCSP signent leurs réponses avec la clé de signature privée de l'autorité de certification et les navigateurs peuvent vérifier que l'état de révocation qu'ils ont reçu a bien été généré par l'autorité de certification réelle.
Malheureusement, même si OCSP semblait être une solution efficace au début, le nouveau protocole s'est avéré présenter des problèmes pratiques de performances, de sécurité et de confidentialité.
Les problèmes de performance
Contacter un répondeur pour chaque certificat rencontré par le navigateur signifie que les navigateurs doivent effectuer une demande HTTP supplémentaire pour chaque nouvelle connexion HTTPS. Cette surcharge du réseau était perceptible par les utilisateurs, en particulier dans les pages contenant du contenu tiers stocké dans des serveurs de distribution de contenu distants (qui pouvaient chacun avoir un ou plusieurs certificats en place).
Réactivité est un principe essentiel d'une bonne conception d'interface utilisateur. Les longs retards peuvent être une cause majeure de frustration des utilisateurs et peuvent conduire les utilisateurs à croire que votre site Web ne fonctionne pas ou que leur geste de saisie a été ignoré.
De plus, beaucoup et le cannabis dans le passé, ont lié la vitesse de chargement de page rapide et la réactivité à un référencement amélioré et à des taux de conversion accrus. En fait, Amazon a calculé qu'un retard d'une seconde peut leur coûter environ $1.6 milliard annuel.
(Pour plus de détails sur la façon dont la vitesse de chargement des pages affecte votre site Web et les optimisations suggérées, veuillez consulter notre article décrivant comment la suppression du contenu mixte de votre site Web améliorera ses performances.)
Les questions de sécurité
Il y a également des problèmes de sécurité importants avec OCSP. Le fait que la majorité des implémentations OCSP pratiques n'étaient pas suffisamment fiables (soit en raison d'un retard du réseau, soit d'erreurs de configuration ou d'application) a motivé les navigateurs et autres logiciels clients à implémenter la vérification OCSP. échec progressif mode.
Cela signifie que si un serveur OCSP ne peut pas être atteint ou expire pendant la réponse, les navigateurs considérer le certificat comme valide et procédez à la connexion HTTPS de toute façon.
Le raisonnement derrière cela est que, comme un serveur OCSP peut potentiellement servir des millions de sites Web et qu'il est possible qu'un serveur OCSP échoue à tout moment, la suppression de la connexion à chaque échec OCSP perturberait l'expérience de navigation de millions d'utilisateurs. Même si le serveur OCSP fonctionne mais met beaucoup de temps à répondre, cela ajoute au décalage perçu et à la frustration des utilisateurs.
Homme au milieu (MITM) les attaquants sont connus pour exploiter ce comportement en bloquant TOUTE les connexions aux répondeurs OCSP, ce qui signifie qu'ils peuvent utiliser un certificat et une paire de clés volés pour un site malveillant, quel que soit l'état de révocation du certificat.
Problèmes de confidentialité
Enfin, comme un certificat est lié à une clé et un nom de domaine et que les navigateurs demandent l'état de révocation avant chaque nouvelle connexion HTTPS, cela signifie que les navigateurs divulguent une partie importante de l'historique Web de leurs utilisateurs aux répondeurs OCSP.
Bien sûr, les autorités de certification de confiance publique ne sont pas des organisations malveillantes qui cherchent à compromettre la confidentialité des utilisateurs. (Les CA réputées essaient toujours activement de protéger la sécurité et la confidentialité de leurs utilisateurs.) Cependant, en cas de compromission du répondeur OCSP d'une autorité de certification, les données échangées avec ce serveur non fiable pourraient entraîner la divulgation d'informations sensibles et privées.
OCSP Stapling à la rescousse
Pour atténuer ces problèmes, les navigateurs et les autorités de certification ont proposé une nouvelle méthode de détermination de l'état d'un certificat, appelée Agrafage OCSP. L'agrafage OCSP permet aux serveurs Web (au lieu des navigateurs) d'obtenir des réponses OCSP signées pour leurs certificats, qui peuvent être mises en cache jusqu'à 7 jours.
Les serveurs incluent (ou agrafe) la réponse OCSP mise en cache dans leurs réponses HTTPS à côté du certificat SSL lui-même. De cette façon, les navigateurs peuvent vérifier la signature des autorités de certification sur la réponse OCSP et être assurés que le certificat n'a pas été révoqué, avant que la connexion sécurisée ne soit établie et sans avoir à effectuer eux-mêmes la demande supplémentaire coûteuse au serveur OCSP.
L'agrafage OCSP est une solution simple mais très efficace aux problèmes mentionnés ci-dessus. Les serveurs peuvent récupérer les réponses OCSP mises en cache dans leur propre temps, ce qui supprime la surcharge de performances imposée par les listes de révocation de certificats et OCSP, ainsi que les problèmes de confidentialité associés.
Cependant, l'agrafage OCSP en lui-même ne résout pas complètement le problème de sécurité de défaillance logicielle d'OCSP. L'agrafage étant implémenté dans le serveur, les navigateurs ne peuvent pas savoir si un serveur prend réellement en charge l'agrafage ou non.
En conséquence, les attaquants MITM avec un certificat volé (mais révoqué) peuvent effectuer une attaque de rétrogradation en servant le certificat sans agrafage OCSP. Le navigateur d'une victime n'est pas en mesure de vérifier si le serveur prend réellement en charge l'agrafage, et continuez à interroger le répondeur OCSP comme il le ferait normalement.
Les attaquants MITM peuvent alors simplement bloquer cette requête OCSP et forcer efficacement les navigateurs à accepter le certificat comme valide.
OCSP Indispensable
Cette attaque a incité les autorités de certification et les fournisseurs de navigateurs à introduire une extension pour les certificats SSL, définie dans RFC 7633, communément appelé OCSP Incontournable (bien que la RFC elle-même ne mentionne pas ce nom, ce qui peut causer une certaine confusion.) Cela oblige simplement l'agrafage OCSP pour le certificat. Si un navigateur rencontre un certificat avec cette extension qui est utilisé sans OCSP Stapling, il sera rejeté. OCSP Must-Staple atténue l'attaque de déclassement susmentionnée et réduit également le trafic inutile vers les répondeurs OCSP de l'AC, ce qui peut également aider à améliorer les performances globales de l'OCSP.
Si vous souhaitez activer l'extension OCSP Must-Staple dans vos certificats, contactez l'un de nos agents d'assistance au support@ssl.com pour plus de détails.
Activer l'agrafage OCSP sur votre serveur
Pour vous éviter d'avoir à le rechercher, les sections suivantes contiennent des instructions sur la façon d'activer l'agrafage OCSP dans votre Apache et Nginx environnements:
Apache
Pour activer l'agrafage OCSP dans votre Apache serveur, veuillez ajouter les lignes suivantes dans le fichier de configuration de votre serveur.
# OCSP Stapling, uniquement dans httpd 2.3.3 et versions ultérieures SSLUseStapling sur SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
Nginx
Pour activer l'agrafage OCSP dans votre Nginx serveur, veuillez ajouter le texte suivant dans le fichier de configuration de votre serveur.
# OCSP Stapling --- # récupère les enregistrements OCSP de l'URL dans ssl_certificate et les cache ssl_stapling on; ssl_stapling_verify activé;
Conclusion
Le Web est un réseau complexe de composants interdépendants, tous (généralement) travaillant en harmonie pour offrir une expérience de navigation transparente. Cependant, la complexité toujours croissante de ce système crée une surface d'attaque toujours plus large et permet de concevoir et d'exécuter de nouvelles attaques réseau.
Le nombre considérable de composants augmente naturellement la latence et entraîne des retards, ce qui signifie que les entreprises doivent trouver des moyens d'améliorer la sécurité sans affecter l'expérience utilisateur. L'activation de l'agrafage OCSP vous donnera cette rare opportunité d'améliorer la sécurité et performances de votre site Web en même temps.
Comme toujours, nous sommes heureux de répondre à vos questions concernant l'agrafage OCSP ou d'autres problèmes - envoyez-nous un e-mail à support@ssl.com.
