Introduction
HTTPS (via SSL /TLS) les usages cryptage à clé publique pour protéger les communications du navigateur contre la lecture ou la modification en transit sur Internet. Les serveurs fournissent aux navigateurs visiteurs une clé publique qui est utilisée pour établir une connexion cryptée pour tous les échanges de données ultérieurs.
Cependant, juste recevoir un de travail la clé publique seule ne garantit pas qu'elle (et par extension le serveur) est bien détenue par la bonne télécommande sujet (c.-à-d. personne, entreprise ou organisation). Man-in-the-middle les attaquants peuvent manipuler les réseaux pour servir leurs propres clés, compromettant ainsi toute communication.
Les navigateurs empêchent cela en authentifier Serveurs HTTPS utilisant certificats, qui sont des documents numériques lier une clé publique d'un sujet individuel. La liaison est affirmée en ayant une confiance Autorité de certification (CA) comme SSL.com vérifier l'identité des propriétaires de certificats potentiels, via des vérifications automatiques et manuelles par rapport à des bases de données qualifiées.
Cette relation de confiance signifie que la sécurité des utilisateurs Web n'est pas absolue; elle oblige plutôt les utilisateurs à faire confiance aux navigateurs et aux autorités de certification pour protéger leur sécurité. Par conséquent, nous pensons qu'il est dans l'intérêt de chaque utilisateur d'avoir une compréhension de base du fonctionnement de la validation des certificats.
Notez que le processus de validation du certificat (décrit en détail dans le document standard RFC 5280) est assez alambiqué. Dans cet article, nous allons essayer de vous guider sur un chemin (un navigateur validant le SSL /TLS certificat) et parcourez les détails complexes qui sont sans conséquence pour la plupart des utilisateurs.
Certificats et format X.509
Les certificats sont des fichiers numériques à tous égards, ce qui signifie qu'ils doivent suivre un format de fichier pour stocker des informations (par exemple, signatures, clés, émetteurs, etc.). En privé PKI les configurations peuvent implémenter n'importe quel format pour leurs certificats, de confiance PKIs (c'est-à-dire ceux auxquels les navigateurs font confiance) doivent être conformes à la RFC 5280, qui nécessite l'utilisation du X.509 v3 le format.
X.509 v3 permet aux certificats d'inclure des données supplémentaires, telles que des contraintes d'utilisation ou des informations de stratégie, comme extensions, chaque extension étant soit critique or non critique. Les navigateurs peuvent ignorer les extensions non critiques non valides ou non reconnues, mais elles sont nécessaires pour traiter et valider toutes les extensions critiques.
Chemins de certification et traitement des chemins
Les autorités de certification utilisent une clé privée pour signer cryptographiquement tous les certificats émis. De telles signatures peuvent prouver irrévocablement qu'un certificat a été délivré par une autorité de certification spécifique et qu'il n'a pas été modifié après sa signature.
Les AC établissent la propriété de leur clé de signature en détenant un certificat auto-émis (appelé racine) pour la clé publique correspondante. Les autorités de certification doivent observer des procédures étroitement contrôlées et auditées pour créer, gérer et utiliser une racine, et pour minimiser l'exposition, elles utilisent normalement une racine pour émettre intermédiaire certificats. Ces intermédiaires peuvent ensuite être utilisés pour émettre les certificats de leurs clients.
Les navigateurs sont livrés avec une liste intégrée de racines de confiance. (Ce sont des racines d'autorités de certification qui ont passé les critères d'inclusion stricts du navigateur.) Pour vérifier un certificat, un navigateur obtiendra une séquence de certificats, chacun ayant signé le certificat suivant dans la séquence, connectant la racine de l'autorité de certification signataire au serveur du serveur. certificat.
Cette séquence de certificats est appelée chemin de certification. La racine du chemin s'appelle un ancre de confiance et le certificat du serveur s'appelle le feuille or entité finale certificat.
Construction de chemin
Souvent, les navigateurs doivent considérer plusieurs chemins de certification jusqu'à ce qu'ils puissent en trouver un valide pour un certificat donné. Même si un chemin peut contenir des certificats qui «s'enchaînent» correctement à une ancre connue, le chemin lui-même peut être rejeté en raison de restrictions sur la longueur du chemin, le nom de domaine, l'utilisation du certificat ou la politique.
La construction et l'évaluation de tous les chemins possibles est un processus coûteux effectué pour chaque nouveau certificat qu'un navigateur rencontre. Les navigateurs ont implémenté diverses optimisations pour minimiser le nombre de chemins candidats rejetés, mais approfondir ces détails dépasse largement le cadre de cet article.
Validation du chemin
Une fois qu'un chemin de certification candidat est construit, les navigateurs le valident à l'aide des informations contenues dans les certificats. Un chemin est valide si les navigateurs peuvent prouver par cryptographie qu'à partir d'un certificat directement signé par une ancre de confiance, la clé privée correspondante de chaque certificat a été utilisée pour émettre la suivante dans le chemin, jusqu'au certificat feuille.
Algorithme de validation du chemin de certification
RFC 5280 décrit un algorithme standard que les navigateurs suivent pour valider un chemin de certification des certificats X.509.
Fondamentalement, les navigateurs parcourent tous les certificats du chemin en commençant par l'ancre de confiance (c'est-à-dire le certificat racine), validant les informations de base et les extensions critiques de chaque certificat.
Si la procédure se termine par le dernier certificat du chemin sans erreur, le chemin est accepté comme valide. Si des erreurs se produisent, le chemin est marqué comme non valide.
Traitement de base des certificats
Quelles que soient les extensions, les navigateurs doivent toujours vérifier les informations de base du certificat telles que la signature ou l'émetteur. Les sections suivantes présentent la séquence de vérifications effectuées par les navigateurs.
1. Le navigateur vérifie l'intégrité du certificat
La Signature sur le certificat peut être vérifié en utilisant la cryptographie à clé publique normale. Si la signature n'est pas valide, le certificat est considéré comme modifié après sa délivrance et est donc rejeté.
2. Le navigateur vérifie la validité du certificat
Un certificat période de validité est l'intervalle de temps pendant lequel l'autorité de certification signataire garantit qu'elle conservera des informations sur son statut. Les navigateurs rejettent tous les certificats dont la période de validité se termine avant ou après la date et l'heure du contrôle de validation.
3. Le navigateur vérifie l'état de révocation du certificat
Lorsqu'un certificat est délivré, il devrait être utilisé pendant toute sa période de validité. Bien entendu, diverses circonstances peuvent rendre un certificat invalide avant son expiration naturelle.
De telles circonstances peuvent inclure un sujet changeant de nom ou une compromission présumée de sa clé privée. Dans de tels cas, une autorité de certification doit révoquer le certificat correspondant, et les utilisateurs font également confiance à une autorité de certification pour informer les navigateurs de l'état de révocation de leurs certificats.
RFC 5280 recommande aux autorités de certification d'utiliser des listes de révocation à cette fin.
Listes de révocation de certificats (CRL)
Les autorités de certification émettent périodiquement une liste signée et horodatée des certificats révoqués appelée liste de révocation de certificats (CRL). Les CRL sont distribuées dans des référentiels accessibles au public et les navigateurs peuvent acquérir et consulter la dernière CRL de l'autorité de certification lors de la validation d'un certificat.
Un défaut de cette méthode est que la granularité temporelle de la révocation est limitée à la période d'émission de la CRL. Un navigateur ne sera informé d'une révocation qu'après la mise à jour de toutes les CRL actuellement émises. Selon la politique de l'autorité de certification signataire, cela peut prendre une heure, une journée ou même jusqu'à une semaine.
OCSP (Online Certificate Status Protocol)
Il existe d'autres méthodes alternatives pour acquérir des informations sur le statut de révocation, la plus populaire étant Protocole de statut de certificat en ligne (OCSP).
Décrit dans le document standard RFC6960, OCSP permet à un navigateur de demander l'état de révocation d'un certificat spécifique à un serveur OCSP en ligne (également appelé répondeur). Lorsqu'il est correctement configuré, OCSP est beaucoup plus immédiat et évite le problème de latence de mise à jour CRL mentionné ci-dessus. En outre, Agrafage OCSP améliore les performances et la vitesse.
4. Le navigateur vérifie l'émetteur
Les certificats sont normalement associés à deux entités:
- La émetteur, qui est l'entité détenant la clé de signature et
- La sujet, qui fait référence au propriétaire de la clé publique que le certificat authentifie.
Les navigateurs vérifient qu'un certificat émetteur champ est le même que le sujet champ du certificat précédent dans le chemin. Pour plus de sécurité, la plupart PKI Les implémentations vérifient également que la clé de l'émetteur est la même que la clé qui a signé le certificat actuel. (Notez que ce n'est pas vrai pour l'ancre de confiance, car les racines sont auto-émises - c'est-à-dire qu'elles ont le même émetteur et le même sujet.)
Traitement des contraintes
Le format X.509 v3 permet à une autorité de certification de définir des contraintes ou des restrictions sur la façon dont chaque certificat est validé et utilisé comme extensions critiques. Chaque certificat du chemin peut imposer des contraintes supplémentaires auxquelles tous les certificats suivants doivent obéir.
Les contraintes de certificat affectent rarement l'utilisateur Internet moyen, bien qu'elles soient assez courantes dans les solutions SSL d'entreprise. Les contraintes fonctionnelles peuvent servir plusieurs objectifs opérationnels, mais leur utilisation la plus importante est d'atténuer les problèmes de sécurité connus.
5. Le navigateur vérifie les contraintes de nom
Une autorité de certification intermédiaire privée (mais de confiance publique) avec les contraintes de nom peut fournir à une organisation un contrôle précis sur la gestion et l'émission des certificats. Les certificats peuvent être limités à un domaine ou à une arborescence de domaines spécifique (c'est-à-dire y compris des sous-domaines) pour le nom de domaine d'une entreprise ou d'une organisation. Les contraintes de nom sont souvent utilisées pour les certificats d'autorité de certification intermédiaires achetés auprès d'une autorité de certification de confiance publique afin d'empêcher l'autorité de certification intermédiaire d'émettre des certificats parfaitement valides pour des domaines tiers (par exemple google.com).
6. Le navigateur vérifie les contraintes de politique
Une politique de certification est un document juridique publié par une autorité de certification, détaillant officiellement les procédures suivies pour émettre et gérer ses certificats. Les autorités de certification peuvent émettre un certificat sous une ou plusieurs stratégies, et des liens vers celles-ci sont inclus dans chaque certificat émis afin que les parties utilisatrices puissent évaluer ces stratégies avant de décider d'approuver ce certificat.
Pour des raisons juridiques et opérationnelles, les certificats peuvent imposer des restrictions sur les politiques auxquelles ils peuvent être soumis. S'il s'avère qu'un certificat contient des contraintes de stratégie critiques, les navigateurs doivent les valider avant de continuer. (Cependant, des contraintes politiques critiques sont rarement rencontrées dans le monde réel et ne seront donc pas prises en compte pour le reste de cet article.)
7. Le navigateur vérifie les contraintes de base (aka longueur du chemin)
Le format X.509 v3 permet aux émetteurs de définir la longueur de chemin maximale qu'un certificat peut prendre en charge. Cela permet de contrôler dans quelle mesure chaque certificat peut être placé dans un chemin de certification. C'est en fait important - les navigateurs utilisés pour ignorer la longueur du chemin de certification jusqu'à ce qu'un chercheur démontre, dans un 2009 présentation, comment il a utilisé le certificat feuille de son site Web pour forger un certificat valide pour un grand site Web de commerce électronique.
8. Le navigateur vérifie l'utilisation des clés
L'extension «utilisation de la clé» indique le but de la clé contenue dans le certificat. Des exemples de telles fins comprennent le chiffrement, les signatures, la signature de certificats, etc. Les navigateurs rejettent les certificats qui enfreignent leurs contraintes d'utilisation de clé, telles que la rencontre d'un certificat de serveur avec une clé destinée uniquement à la signature CRL.
9. Le navigateur continue de traiter toutes les extensions critiques restantes
Après avoir traité les extensions mentionnées ci-dessus, les navigateurs procèdent à la validation de toutes les extensions restantes que le certificat actuel désigne comme critiques, avant de passer à la suivante. Si un navigateur atteint le certificat feuille d'un chemin sans erreur, le chemin est accepté comme valide. Si des erreurs se produisent, le chemin est marqué comme non valide et une connexion sécurisée n'est pas établie.
Conclusion
Le World Wide Web est un système complexe de pièces mobiles interconnectées et en constante évolution. La sécurité du navigateur n'est donc pas un problème résolu, et nous espérons que cet article a fourni un aperçu de la complexité même du seul composant que nous avons examiné ici. La confiance joue un rôle majeur dans votre sécurité en ligne, c'est pourquoi nous vous invitons à vous renseigner davantage sur la politique de certification de votre autorité de certification. (N'hésitez pas à revoir Les politiques de SSL.com ici, En réalité.)
Merci d'avoir choisi SSL.com, où nous croyons plus sûre Internet est un mieux Internet.
