Quelles vulnérabilités pourraient être causées par un certificat SSL générique?
Dans un commentaire sur cette réponse , AviD dit:
"Il existe de nombreux problèmes de sécurité avec les certificats SSL génériques."
Alors, quels sont les problèmes? Je comprends que la même clé privée est utilisée dans plusieurs contextes, mais étant donné que je pourrais héberger toutes mes applications sous le même nom d'hôte, je ne vois pas cela comme un `` nouveau '' problème introduit par les certificats génériques.
Un "certificat générique" est un certificat qui contient, comme nom de serveur possible, un nom qui contient un "* "caractère. Les détails sont dans RFC 2818, section 3.1 . La ligne de fond: lorsque le certificat de serveur contient *.example.com, il sera accepté par les clients comme certificat valide pour tout serveur dont le nom apparent correspond ce nom.
Dans le domaine de la certification de sites Web, il existe quatre principaux acteurs:
- Le serveur SSL lui-même.
- Le fournisseur du navigateur Web que le client utilisera.
- L'utilisateur humain, qui contrôle dans une certaine mesure ce que fera le navigateur client.
- Autorité de certification qui a délivré le certificat au serveur.
Les certificats génériques n'impliquent pas de vulnérabilités supplémentaires pour le serveur SSL; en effet, le serveur SSL n'a aucun intérêt à consulter son propre certificat. Ce certificat est au bénéfice des clients, pour les convaincre que la clé publique contenue dans le certificat est bien la clé publique du véritable serveur SSL. Le serveur SSL connaît sa propre paire de clés publique/privée et n'a pas besoin d'en être convaincu.
L'utilisateur humain n'a aucune idée de ce qu'est une clé publique. Ce qu'il voit est une icône de cadenas et, plus important encore, le nom de serveur prévu : c'est le nom à droite de "https:// "et avant le prochain" / ". Le navigateur Web est supposé pour gérer les détails techniques de la vérification du bon nom, c'est-à-dire la validation du certificat du serveur, et la vérification que le nom correspond à celui qui est écrit dans ledit certificat. Si le navigateur ne fait pas ce travail, il sera considéré comme bâclé et n'assumant pas son rôle, ce qui peut avoir des conséquences commerciales graves, voire juridiques. De même, l'AC est contractuellement tenue de suivre des procédures définies pour identifier les propriétaires de serveurs SSL afin que les faux certificats soient difficiles à obtenir pour les attaquants (le contrat est récursif entre l'autorité de certification et son über-CA, jusqu'à l'autorité de certification racine qui est elle-même liée par un pacte avec le fournisseur du système d'exploitation ou du navigateur, qui accepté d'inclure la clé de l'autorité de certification racine dans le système d'exploitation ou le navigateur dans des conditions définies).
Cela signifie que le navigateur et le [~ # ~] ca [~ # ~] doivent, en pratique , chouchoutez l'utilisateur tout au long du processus de vérification. Ils sont plus ou moins tenus (par la loi ou, encore plus sévèrement, par des considérations commerciales) d'empêcher l'utilisateur d'être escroqué par le biais de faux sites qui semblent légitimes. La frontière entre le travail de l'utilisateur et le travail du navigateur/CA n'est pas clairement définie et s'est historiquement déplacée. Dans Days of Yore, je veux dire il y a une dizaine d'années, les navigateurs venaient d'imprimer l'URL brute, et c'était à l'utilisateur humain de trouver le nom du serveur. Cela a incité les opérateurs de sites falsifiés (c'est-à-dire les "sites de phishing") à utiliser des URL techniquement valides, mais trompeuses, comme celle-ci:
https://www.Paypal.com:[email protected]/confirm.html
Étant donné que les utilisateurs humains sont, bien, humains , et que la plupart d'entre eux lisent de gauche à droite (les cibles d'escroquerie les plus riches et crédules sont toujours dans les pays occidentaux), ils commenceront le à gauche, voir www.Paypal.com, arrêtez-vous au signe deux-points ("trop technique") et faites-vous arnaquer.
En réaction, les fournisseurs de navigateurs ont reconnu que les capacités d'analyse d'URL des utilisateurs humains n'étaient pas aussi bonnes que ce qui était initialement supposé, et donc les navigateurs récents mettent en évidence la partie domaine. Dans le cas ci-dessus, ce serait xcvhjvb.com, et certainement rien avec Paypal.com dedans. Vient maintenant la partie où les certificats génériques entrent en jeu. Si le propriétaire de xcvhjvb.com achète un certificat générique contenant "*.xcvhjvb.com ", il peut alors configurer un site de phishing appelé:
https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html
qui sera accepté par le navigateur (il correspond au nom générique), et est toujours susceptible d'attraper les utilisateurs imprudents (et il y en a beaucoup ...). Ce nom aurait pu avoir été acheté par l'attaquant sans recourir à des caractères génériques, mais alors les employés de l'AC auraient vu le nom avec une tentative frauduleuse évidente (bonne AC une validation humaine de chaque demande de certificats, ou au moins déclencher des alertes pour les noms qui sont très longs et/ou contiennent des noms de banque connus).
Par conséquent, les certificats génériques diminuent l'efficacité des mesures de limitation de la fraude du côté de l'AC . C'est comme une signature vierge de l'AC. Si les tentatives de phishing basées sur des caractères génériques deviennent plus courantes, on peut s'attendre à ce qu'une ou plusieurs des mesures suivantes se concrétisent:
- Les navigateurs ne mettent en évidence que les parties du nom de domaine qui correspondent aux éléments non génériques du certificat.
- Les CA nécessitent des formalités administratives et des contrats plus lourds pour les certificats génériques (et ceux-ci seront plus chers).
- Les navigateurs désactivent complètement la prise en charge des certificats génériques.
Je m'attends en fait à ce que les trois mesures soient appliquées au cours des prochaines années. Je peux me tromper complètement (c'est le problème avec la prévision de l'avenir) mais c'est toujours mon instinct.
Nitpickingly, nous pouvons également souligner que les certificats génériques sont utiles pour partager la même paire de clés entre différents noms de serveur , ce qui rend plus probable que la clé privée sera partagée entre différents serveurs machines . Voyager avec des clés privées représente un risque de sécurité en soi; plus une clé privée se promène, moins elle reste "privée".
C'est une mauvaise pratique de répartir la même clé privée sur plusieurs serveurs fournissant un service différent: tout problème de sécurité exploité dans n'importe quel service révélera la clé privée utilisée pour tout.
Mais il est courant d'utiliser des certificats génériques pour isoler le contenu Web fourni par l'utilisateur dans des sous-domaines spécifiques à l'utilisateur afin de tirer parti de la même politique d'origine. La même approche est couramment utilisée pour rendre les portlets non approuvés. Cela fait partie du Open Social "standard".
Sur mon lieu de travail, nous développons un logiciel qui contient une implémentation sociale ouverte et utilise la configuration générique. Les installations des clients ont été soumises à des tests de pénétration. La configuration des caractères génériques n'a pas été critiquée.
En fin de compte, bon nombre des vulnérabilités notées dans ces réponses proviennent du mélange des niveaux de confiance. Mais si vous comprenez comment fonctionnent les certificats génériques, vous pouvez atténuer ces vulnérabilités pour des cas d'utilisation particuliers. Je pense que l'expliquer plus en détail améliorera l'utilité de cette question et de ses réponses.
À moins que tous les systèmes de votre domaine aient le même niveau de confiance, l'utilisation d'une certification générique pour couvrir tous les systèmes sous votre contrôle est une mauvaise idée. Mais vous pouvez utiliser les sous-domaines DNS comme outil de segmentation. Comme l'a dit Hendrik, puisque les caractères génériques ne traversent pas les sous-domaines, vous pouvez restreindre un certificat générique à un espace de noms spécifique. Par exemple, si vous aviez une batterie de serveurs CDN, vous pouvez simplement utiliser le caractère générique *.cdn.example.com. Cela maintient les hôtes dans example.com lui-même (comme www.example.com) distinct, et vous pouvez émettre un certificat distinct pour www.example.com.
Comme AviD l'a mentionné de l'OWASP: les postes de travail internes, les systèmes de développement, etc. appartiennent à des niveaux de confiance inférieurs. Cependant, les hôtes comme ceux-ci devraient de toute façon être dans leur propre espace de domaine interne (comme prv.example.com). Étant donné que les caractères génériques ne traversent pas les sous-domaines, un *.example.com cert ne peut pas être appliqué à prv.example.com hôtes. (Cela garderait les propriétés publiques et privées séparées, mais ne séparerait évidemment pas les propriétés privées les unes des autres. D'autres caractères génériques de sous-domaine pourraient être utilisés, mappés aux niveaux de confiance appropriés).
Alors que cet article eWeek note que la clé privée peut être partagée entre plusieurs hôtes, cette réfutation SSLShopper dit que certains émetteurs (comme DigiCert) vous permettent de générer des clés privées distinctes pour chaque Hôte générique. Cela réduit une partie de l'utilité des certificats génériques, mais atténue définitivement le problème des clés privées partagées et peut être utile dans certaines circonstances. Sinon, cet article Entrust et le livre blanc PDF auquel il fait référence discuter des meilleures pratiques de gestion des clés privées lorsqu'il est utilisé avec des certificats génériques.
Enfin, en recourant à l'argument par autorité ... si Google utilise des certificats génériques pour certaines de leurs propriétés , ils ne doivent pas être universellement mauvais:
:-)
Idéalement, la liste des services qu'un certificat/clé peut être utilisé pour emprunter l'identité devrait être la même que la liste des services pour lesquels le certificat/clé est destiné à être utilisé.
Disons que vous avez un domaine example.com. Vous configurez différents noms d'hôtes sous ce domaine www.example.com catpictures.example.com users.example.com. Tous sont hébergés sur le même serveur, vous obtenez donc un certificat pour tous les couvrir.
Supposons maintenant que vous configuriez secure.example.com sur un serveur plus hautement sécurisé. Disons que vous obtenez un certificat séparé pour ce serveur.
Considérez maintenant ce qui se passe si la clé privée correspondant au certificat sur le premier serveur est volée.
S'il s'agissait d'un certificat pour * .example.com (un certificat générique), les attaquants peuvent l'utiliser pour se faire passer pour secure.example.com
S'il s'agissait d'un certificat pour www.example.com catpictures.example.com et users.example.com, les attaquants ne peuvent pas l'utiliser pour usurper l'identité de secure.example.com