Qu'est-ce qui m'empêche d'acheter un certificat SSL pour un domaine que je ne contrôle pas?
Puis-je simplement créer un serveur Web, faire son nom d'hôte "google.com ", créer une CSR sur ce serveur et l'envoyer à une autorité de certification pour signature? Disons que je choisis la tenue la moins chère et la plus douteuse que je puisse trouver.
Ça marchera? Quels mécanismes sont en place pour empêcher les gens de faire cela?
Je suis bien conscient que je ne recevrai aucun trafic destiné à google.com en raison des enregistrements DNS pointant vers le vrai Google, mais je pourrais attaquer MitM tout trafic Google en utilisant cette méthode. Je pourrais également rediriger le trafic local vers mon propre serveur sans que les utilisateurs ne sachent mieux.
C'est plus un problème que vous ne le pensez, en particulier pour une entreprise comme Google, car ils sont une cible fréquente pour ce type de manigances. Mais il existe plusieurs couches de garanties, et notre protection s'améliore avec le temps.
Votre première ligne de défense est l'autorité de certification.
Ils ne devraient pas laisser les certificats être signés de manière inappropriée. Chaque autorité de certification dispose de son propre mécanisme pour vérifier votre droit à acheter un certificat pour un domaine donné, mais il comprend généralement que vous effectuez une ou plusieurs des opérations suivantes:
- Vérifiez la propriété de l'adresse e-mail répertoriée dans les informations WHOIS du domaine.
- Vérifiez la propriété d'une adresse e-mail qui suit l'un des nombreux modèles prédéterminés sur le domaine (par exemple, "administrateur @ {domaine}")
- Créer un enregistrement DNS spécifique sur le domaine
- Apportez une modification spécifique au site Web hébergé sur ce domaine
Mais avec autant d'autorités de certification que nous en avons, un nombre surprenant de certificats inappropriés est émis. Ceci est un cas de "vous aviez littéralement UN travail" mais nous devons accepter que des erreurs se produisent.
La transparence du certificat a été créée pour aider à l'audit des autorités de certification
Il y a un manque surprenant de responsabilité et de transparence de la part des autorités de certification, alors Google a décidé de faire quelque chose avec Transparence du certificat .
Il s'agit d'un journal public de chaque certificat que l'AC signe; si un certificat n'apparaît pas dans le journal, il n'est pas valide et le journal est uniquement en annexe; vous ne pouvez pas revenir en arrière et nettoyer votre histoire. C'est encore relativement nouveau, mais Chrome l'exige déjà sur certaines autorités de certification, y compris toutes les autorités de certification EV. L'idée est que vous pouvez suivre le journal et voir si votre domaine apparaît quand il ne devrait pas. Les outils évoluent toujours pour simplifier les choses, mais c'est une technologie très prometteuse.
Votre dernière ligne de défense est l'épinglage des clés
Les navigateurs les plus sécurisés permettront aux propriétaires de domaine de "verrouiller" une ou plusieurs clés publiques à leur domaine. Il s'agit d'une fin autour de l'ensemble du système PKI et injecte la confiance directement dans le navigateur. Les propriétaires de domaine peuvent, via l'en-tête HTTP, dire au navigateur d'autoriser uniquement les certificats avec des clés publiques spécifiques, et peuvent en fait expédier cette assertion préinstallée sur le navigateur lui-même. Cela empêche l'utilisation d'un certificat non autorisé, même s'il possède une signature CA valide.
DNSSEC et DANE est où cela va finalement aller
Probablement. Avec DNSSEC, vous pouvez signer vos enregistrements DNS, ce qui signifie que vous pouvez placer votre signature de clé publique directement dans DNS. Ce qui signifie que vous n'avez pas besoin d'une autorité de certification tierce pour signer vos clés. C'est une solution assez élégante, mais DNSSEC est encore loin; vous ne pouvez pas l'utiliser avec un certain nombre de systèmes d'exploitation, et l'adoption est glaciale.
Vous devez prouver la propriété DNS avant que quelqu'un ne signe un certificat pour un nom de domaine donné.
Créer un CSR avec le domaine de Google ne sera pas suffisant.
Si une autorité de certification vous fournissait réellement un Cert valide pour un domaine dont vous n'avez pas prouvé la propriété, cette autorité de certification serait immédiatement méfiée par les gens et leurs certificats racine seraient supprimés des magasins de confiance.
En théorie, cela est possible pour les autorités de certification actuelles. Mais il existe de nombreuses garanties en place. Mais cela a déjà été répondu.
Cependant, cela n'est pas possible avec l'autorité de certification letsencrypt . Parce qu'il utilise le protocole ACME pour prouver la propriété du nom de domaine.
Fondamentalement, vous exécutez le client letsencrypt qui communique avec les serveurs de l'autorité de certification letsencrypt en utilisant le protocole ACME pour prouver que vous possédez le nom de domaine que vous revendiquez. Une fois que cela est prouvé, un nouveau certificat vous est délivré, gratuitement et automatiquement.
Réponse courte; OUI, cela pourrait fonctionner
Étant donné le fonctionnement des certificats, si vous pouviez trouver une autorité de certification suffisamment merdique pour le faire, vous pourriez vous retrouver avec un certificat indiquant votre Google. com.
Le problème est que les autorités de certification sont censées vérifier votre identité. C'est tout leur but. Celui qui fait un mauvais travail ne va pas durer longtemps.
Habituellement, ces autorités de certification moins dignes de confiance sont de 4ème et 5ème niveau dans une chaîne de confiance, et généralement elles sont identifiées et retirées de la chaîne de confiance rapidement.
Cela dit, lorsque vous examinez uniquement les certificats, l'AC est la dernière ligne de défense, donc si vous pouvez en trouver un qui certifiera que vous êtes google.com sans les recherches appropriées, vous vous retrouverez avec un certificat prouvant que vous êtes google .com. (encore une fois probablement pour une très courte période)
Il est important de noter qu'il s'agit d'un sérieux vecteur d'attaque et d'un problème pour les serveurs de plus grande taille. C'est également un vecteur d'attaque possible (mais moins utilisé) si vous pouvez ajouter un certificat racine à un client via un code malveillant.
Il y a quelques "correctifs" dans les travaux, comme DNSSEC, mais il faudra un certain temps avant que cela ne soit largement utilisé.
Aujourd'hui, la meilleure protection consiste à s'assurer que les certificats racine de vos clients sont sains et à ne pas les ajouter.