Quelles sont les différences entre vérifier un certificat auto-signé et l'ignorer?
Je fais une intégration avec un système qui a un certificat auto-signé. Pour le développement initial, nous choisissons d'ignorer la vérification du certificat pour contourner certaines erreurs:
Exception dans le thread "principal" javax.net.ssl.SSLHandshakeException: Sun.security.validator.ValidatorException: échec de la création du chemin PKIX: Sun.security.provider.certpath.SunCertPathBuilderException: impossible de trouver un chemin de certification valide vers la cible demandée
car nous devons d'abord comprendre comment ajouter le certificat à l'aide de Java keytool sur un environnement de docker.
Mais, ma question est: quel est l'avantage dans ce cas d'importer un certificat auto-signé en tant que "certificat de confiance" alors que je pourrais simplement l'ignorer?
Si c'est un service officiel que vous intégrez avec le fournisseur, vous devez vraiment avoir un certificat valide et signé publiquement installé pour des raisons de sécurité.
En supposant que vous devez continuer avec votre fournisseur à l'aide d'un certificat auto-signé, la grande différence entre ignorer le certificat et l'ajouter comme approuvé est le scénario suivant. Cela utilise l'empoisonnement DNS comme exemple d'un homme au milieu de l'attaque.
Prenons l'exemple suivant:
api.example.compossède un certificat auto-signé avec empreinte numérique XXX écoutant sur l'IP5.5.5.5.- En l'ajoutant à votre magasin de confiance, votre système s'attend à ce que l'empreinte numérique soit XXX lors de la connexion
- Si quelqu'un a réussi à empoisonner votre DNS - faites
api.example.comdécidez de6.6.6.6- l'empreinte numérique serait YYY. - En ajoutant le certificat à votre boutique, votre produit refuserait de se connecter au site malveillant.
- En désactivant complètement la vérification, votre produit se connecterait volontiers au
api.example.comà6.6.6.6.
En important un bon certificat auto-signé connu dont la clé privée est unique et non compromise, la connexion est tout aussi sûre qu'un certificat global CA PKI signé. Après tout, ils sont également simplement stockés et approuvés à un moment donné.
La raison pour laquelle un certificat PKI CA est signé est d'ordre pratique plus que de sécurité; si vous devez faire confiance à un certificat auto-signé sur de nombreux clients, cela peut représenter beaucoup de travail. Et faire une rotation des touches augmente presque exponentiellement ce travail.
Si vous contrôlez le serveur et le client, comme lors du développement, et que vous n'avez pas les compétences ou les ressources pour configurer une autorité de certification privée, l'ajout d'un certificat auto-signé spécifique à un magasin de clés de confiance n'est pas si mal. Accepter tout le certificat est mauvais, ne faites jamais ça.
Si vous ignorez la vérification du certificat, toute personne qui peut obtenir la position d'homme au milieu (avec la possibilité de modifier le trafic) entre vous et l'autre système peut lire/modifier le trafic en texte brut. Un attaquant va simplement casser le tunnel TLS/SSL en démarrant son propre serveur TLS en utilisant son certificat auto-signé, acheminer votre trafic vers celui-ci, le déchiffrer et le proxyer vers le vrai serveur. Il existe de nombreux outils qui rendent cette attaque assez facile, par exemple, mitmproxy pour HTTPS ou stunnel en général pour TLS/SSL.
Une attaque peut entrer dans la position de l'homme au milieu de de nombreuses façons différentes . Ainsi, il est difficile d'exclure complètement qu'il n'y a aucun moyen pour un attaquant de gagner cette position même si vous êtes un expert en sécurité réseau.
S'il n'y a aucun moyen de remplacer le certificat auto-signé par un certificat signé publiquement, vous pouvez approuver le certificat auto-signé manuellement en l'ajoutant à un magasin de clés Java utilisant keytool et faites confiance à ce magasin. Ceci est parfois appelé Épinglage de certificat ou de clé publique
Les certificats sont la façon dont le signataire peut se porter garant du signataire. Si vous faites confiance au signataire, vous pouvez faire confiance au certificat et à la clé publique signée. Si vous faites confiance au signataire, vous pouvez ignorer le certificat.
En termes plus réels:
Exemple 1: Cindy Certificateauthority est très bien connu. Tout le monde connaît Cindy. Cindy a une très bonne réputation pour vérifier qui sont vraiment les gens avant de les présenter à d'autres personnes. Quelqu'un prétend être Pablo Pubkey - un vendeur bien connu et digne de confiance - veut vous vendre quelque chose. Cindy vous présente cette personne et dit qu'il est Pablo. Vous faites confiance à Cindy, vous pensez donc que la personne est Pablo, et vous décidez donc de lui donner votre numéro de carte de crédit et d'acheter des trucs.
Exemple 2: Vous avez grandi avec Freddy Friend depuis votre enfance. Vous savez qui est Freddy - vous l'avez rencontré à la maternelle et l'avez vu devenir un adulte à vos côtés. Freddy est également vendeur. Si vous voulez parler à Freddy, vous allez simplement trouver Freddy - vous n'avez besoin de personne pour vous le présenter.
Dans le premier exemple, vous vous êtes appuyé sur une autorité de certification en qui vous avez confiance pour vous dire à qui appartient une clé publique particulière. Dans le deuxième exemple, vous aviez une confiance directe dans la clé publique et vous n'avez pas eu besoin d'un tiers pour vous dire à qui elle appartient - par exemple, votre logiciel peut émettre des clés publiques à ses utilisateurs et associer ces clés publiques dans la base de données de votre logiciel. Ce deuxième exemple est exactement le même lorsque vous avez un certificat auto-signé et un certificat non signé.