Pouvoirs délégués pour TLS

Mettre fin à un TLS la connexion nécessite l'utilisation de la clé privée d'un certificat. Par conséquent, la clé privée doit être stockée sur chaque serveur utilisé par un service. La protection du secret de cette clé privée est primordiale pour le bon fonctionnement d'un système d'infrastructure à clé publique. Une entité en possession de la clé privée peut effectuer des attaques de type man-in-the-middle pendant le reste de la validité du certificat. Généralement, lorsqu'un attaquant compromet une clé privée, le certificat associé à cette clé est révoqué et un nouveau est émis. Cependant, pour les entreprises qui utilisent plusieurs serveurs, comme Facebook ou Réseaux de diffusion de contenu, les principaux compromis, en particulier dans les serveurs de périphérie, ne sont pas faciles à détecter, mettant ainsi en danger l'ensemble du réseau. Les informations d'identification déléguées permettent aux serveurs d'effectuer TLS poignées de main, tandis que la clé privée du certificat est stockée dans un emplacement sécurisé.

SSL.com fournit une grande variété de SSL /TLS certificats de serveur pour les sites Web HTTPS.

COMPARER SSL /TLS CERTIFICATS

Les informations d'identification déléguées sont des structures de données signées numériquement comprenant deux parties : un intervalle de validité et une clé publique (avec son algorithme de signature associé). Ils servent de "procuration» pour les serveurs indiquant qu'ils sont autorisés à mettre fin au TLS connexion. Le processus de délivrance des pouvoirs délégués est actuellement en cours de normalisation et défini dans ce Brouillon de l'IEFT. Le projet définit l'utilisation des pouvoirs délégués comme suit :

« Un mécanisme de délégation limité qui permet à un TLS homologue pour émettre ses propres informations d'identification dans le cadre d'un certificat émis par une autorité de certification externe. Ces informations d'identification permettent uniquement au destinataire de la délégation de parler pour les noms que l'autorité de certification a autorisés.

Les informations d'identification déléguées sont conçues dans le but d'augmenter la sécurité. Par conséquent, ils possèdent certains traits, tels que définis dans le projet de l'IEFT.

• La période de validité maximale d'un justificatif délégué est de sept (7) jours pour minimiser l'exposition si la clé privée est compromise. La courte période de validité ne signifie pas que la sécurité des informations d'identification déléguées doit être prise à la légère. Les mesures prises pour protéger la clé privée du certificat d'entité finale devraient également s'appliquer à la protection des DC. Ceux-ci incluent les contrôles du système de fichiers, la sécurité physique et les modules de sécurité matérielle, entre autres. De plus, les informations d'identification déléguées ne doivent être utilisées qu'entre des parties qui partagent une relation de confiance entre elles.
• Les pouvoirs délégués sont lié cryptographiquement au certificat d'entité finale. Plus précisément, la clé privée du certificat d'entité finale est utilisée pour calculer la signature du DC via un algorithme spécifié par les informations d'identification. La signature lie effectivement le contrôleur de domaine aux noms du certificat d'entité finale.
• Les informations d'identification déléguées sont émises par le client, ce qui est beaucoup plus simple que de créer un certificat signé par une autorité de certification. Les certificats émis par le client sont également utiles pour maintenir le service opérationnel même si l'autorité de certification a un temps d'arrêt. En outre, les organisations peuvent expérimenter des algorithmes non officiellement pris en charge par l'autorité de certification sans compromettre la sécurité du certificat d'entité finale. 
• Les pouvoirs délégués ont par définition de courtes périodes de validité. Lors de la définition de la durée de vie des informations d'identification déléguées, les serveurs doivent prendre en compte le décalage d'horloge du client pour éviter le rejet des certificats. Le décalage de l'horloge client est également important pour le certificat d'origine, mais est crucial pour la clé privée déléguée de courte durée. Le décalage de l'horloge client doit être pris en compte à la fois au début et à la fin des périodes de validité.
• Il n'y a pas de mécanisme de révocation pour les informations d'identification déléguées. Ils sont rendus invalides une fois la période de validité expirée. Cependant, la révocation de la clé privée du certificat d'entité finale (qui est utilisé pour signer les informations d'identification déléguées) révoque implicitement les informations d'identification déléguées. 
• Les informations d'identification déléguées sont conçues pour être utilisées dans TLS 1.3 ou plus tard. Il existe une vulnérabilité connue lorsque TLS Les serveurs 1.2 prennent en charge l'échange de clés RSA, permettant la falsification d'une signature RSA sur un message arbitraire. Supposons qu'un attaquant soit capable de contrefaire une signature. Dans ce cas, ils peuvent créer des informations d'identification déléguées falsifiées pour toute la période de validité du certificat d'entité finale. Cette vulnérabilité n'est pas présente dans les implémentations de TLS 1.3 ou version ultérieure. De plus, la vulnérabilité n'affecte pas les certificats avec cryptographie à courbe elliptique, qui SSL.com offre. 
• Les organisations peuvent utiliser les API d'émission automatisées existantes comme ACME pour fournir des informations d'identification déléguées. Dans ce cas, les algorithmes utilisés sont uniquement ceux supportés par l'AC, mais cette pratique réduit la possibilité de compromis de clés. SSL.com approuve cette pratique. 
• Les informations d'identification déléguées ne peuvent pas être réutilisées dans plusieurs contextes. Les parties émettrices calculent la signature à l'aide d'une chaîne de contexte unique au rôle prévu (client ou serveur), rendant ainsi impossible l'utilisation des mêmes informations d'identification déléguées pour l'authentification client et serveur. 

SSL.com prend en charge l'utilisation d'informations d'identification déléguées pour tous les clients. L'émission de certificats capables d'informations d'identification déléguées peut être effectuée via l'utilisation d'API pour l'automatisation à l'aide du protocole ACME. Puisque SSL.com utilise ECDSA pour mettre en œuvre le PKI offert à clients, les informations d'identification déléguées émises par nos clients ne sont pas vulnérables aux attaques de falsification de signature, comme décrit ci-dessus.     

Avec la mise en œuvre par SSL.com de ACME, tous nos clients peuvent prendre avantage de ce protocole populaire pour automatiser facilement SSL/TLS émission et renouvellement de certificat de site Web.

En savoir plus sur ACME SSL/TLS Automation

SSL.com fournit une grande variété de SSL /TLS certificats de serveur pour les sites Web HTTPS.

COMPARER SSL /TLS CERTIFICATS