Est-il sûr de consommer des services via HTTPS qui n'est pas signé par une autorité de certification de confiance?
Je crée une application client qui consommera une application de service Web fournie par un fournisseur de services tiers. Le service est exposé avec une URL HTTPS qui est pas signée par une autorité de certification approuvée.
Est-il sûr de consommer leurs services avec la situation actuelle? Notez que la société prestataire de services nous est connue et que nous avons un accord commercial avec elle.
Vous pouvez l'utiliser en toute sécurité si vous épinglez leur certificat . Cela ajoute de la complexité à la maintenance et au déploiement, mais améliore réellement la sécurité.
Si vous ne le faites pas, cela dépend de la façon dont ils ont construit leur chaîne de confiance: s'ils n'utilisent que des certificats auto-signés, alors vous n'avez pas de chance et ne pouvez pas utiliser leurs services en toute sécurité. S'ils utilisent simplement une autorité de certification privée, vous pouvez toujours importer leur autorité de certification et lui faire confiance.
Dans l'ensemble, je vous recommande d'implémenter l'épinglage de certificat (ou racine).
Modifier @LieRyan a fait un bon commentaire que j'aimerais approfondir.
Dans certaines configurations, l'épinglage d'un certificat nécessite que vous l'ajoutiez à la liste des ancres racine de la machine. Par exemple, cela est nécessaire si vous utilisez IIS sous Windows pour héberger votre application.
Maintenant, selon la façon dont le certificat a été généré, cela peut être ou non un problème. Plus précisément: si le certificat a une propriété "utilisation des clés" et si cette propriété ne répertorie PAS la "signature de certificat", alors il peut être utilisé en toute sécurité car il ne peut pas être utilisé pour signer d'autres certificats (les détails sont un peu plus complexes mais c'est le plus important).
Si le certificat N'A PAS de propriété "d'utilisation de clé" ou si cette propriété a une "signature de certificat", cela pourrait potentiellement conduire à d'autres certificats signés par ce certificat pour être approuvés par le système d'exploitation. Si vous avez implémenté l'épinglage de certificat, cela ne devrait pas être un problème pour votre application (car l'épinglage empêchera même l'utilisation de certificats valides), mais cela pourrait l'être pour une autre partie du système d'exploitation.
Est-il sûr de consommer leurs services avec la situation actuelle?
Voilà une question chargée. Permettez-moi de le décomposer:
Puis-je communiquer avec eux en toute sécurité, d'une manière qui ne peut être interceptée par un tiers?
Oui, vous pouvez. Cependant, vous devrez effectuer la cérémonie d'échange de clés et la vérification d'identité manuellement au lieu de dépendre de l'autorité de certification pour le faire. Cela peut être fait, par exemple, en faisant en sorte que des représentants de confiance de chaque entreprise se réunissent régulièrement pour échanger des informations d'identification et pour échanger des clés (certificats). La sécurité de votre connexion dépend de la sécurité de cet échange, vous devez donc vous assurer de sécuriser cet échange avec le bon niveau de sécurité.
Puis-je faire confiance à cette entreprise pour ne pas m'escroquer?
C'est un problème juridique. Notez que même l'autorité de certification publique ne fait pas cette affirmation. Tout ce qu'une autorité de certification publique fait est d'affirmer qu'une clé appartient à une organisation spécifique, elle n'affirme pas la moralité de l'entreprise qu'elle certifie. Vous voudrez peut-être vous assurer que vous avez des contrats sur le type de services que vous allez vous fournir, et si vous avez besoin de paiements à régler, et ce qui se passe si une partie rompt unilatéralement le contrat.
Puis-je faire confiance à cette entreprise pour être compétente dans la gestion de leur sécurité, pour éviter des pertes indues?
C'est aussi une question difficile. Vous voudriez vous assurer que votre contrat spécifie ce qui se passe si l'autre partie n'est pas en mesure de respecter ses exigences de sécurité et a causé des pertes à l'autre d'entre vous. Vous pouvez également demander à l'autre société de produire un certificat d'audit par un auditeur financier et/ou de sécurité indépendant.
Comme toujours, il s'agit de faire confiance au fournisseur de ce service.
Dans ce cas, vous ne pouvez pas relayer sur une AC (autorité de certification) mondialement connue pour garantir la confiance, ce qui est de toute façon discutable.
Vous devez, comme toujours, lors de la connexion, vérifier l'émetteur du certificat (l'autorité de certification) et si vous faites confiance à cette autorité de certification via votre magasin local. Si vous faites confiance au certificat de l'autorité de certification stockée localement, cela n'est pas moins sûr (ou même plus sûr que) d'utiliser une autorité de certification tierce.
Le risque d'utiliser un certificat auto-signé est pour le client. Les certificats SSL sont utilisés par le client pour connaître la clé publique du serveur qui est ensuite utilisée pour le chiffrement. L'utilisation d'un certificat signé par une autorité de certification de confiance garantit au client que la clé appartient au serveur prévu.
Lorsqu'un client accepte un certificat qui n'est pas signé par une autorité de certification de confiance, il existe un risque que le client parle à un faux serveur (l'attaque de l'homme du milieu vient ici). Si le client confirme que le certificat est authentique pour une fois, le navigateur se souviendra du certificat et n'affichera pas d'avertissement pour la prochaine visite.
Il convient de noter qu'un certificat auto-signé n'étant pas "géré" par une autorité de certification, il n'y a pas de révocation possible. Si un attaquant vole votre clé privée, vous perdez définitivement, alors que les certificats émis par l'AC ont toujours le filet de sécurité théorique de la révocation (un moyen pour l'AC de déclarer qu'un certificat donné est pourri).
Il est donc recommandé d'utiliser des certificats signés par une autorité de certification de confiance. Si vous ne pouvez pas vous permettre d'obtenir un certificat de CA, il vaut mieux opter pour l'épinglage de certificat, comme suggéré dans la réponse de Stéphane.
Votre question peut se terminer par puis-je faire confiance à une URL HTTPS qui n'est pas signée par une autorité de certification de confiance?
À mon humble avis, ce n'est pas exactement la bonne question. Je préfère Qu'est-ce qui peut garantir que je consulte le bon service? La différence n'est pas simplement une formulation. C'est dans ce que vous pouvez et voulez faire confiance. La réponse à la première question est immédiatement le service doit utiliser un certificat d'une autorité de certification bien connue . La réponse à la seconde est Je dois connaître le certificat ou l'autorité de certificat du service , mais ce certificat peut être auto-signé à condition que le service donne par un canal alternatif. Ensuite, vous déclarez simplement ce certificat ou tout certificat auto-signé qui le validerait dans la configuration de l'application et vous pouvez faire confiance.
Ce n'est pas la consommation du service qui vous donne la sécurité (authenticité), c'est plutôt la prise de conscience de la façon dont vous vérifiez le certificat reçu du serveur qui vous assure de l'authenticité.
Le fait que vous posiez la question montre le niveau de sécurité dont vous disposez: un utilisateur passif qui souhaite monter en sécurité.
L'utilisation d'une autorité de certification connue (par le système d'exploitation) sécurise la consommation d'un certificat signé pour tout utilisateur passif, car le système de confiance peut avertir avec des informations précises de tout signe de non authenticité possible (expliquant le "possible" dans un état bien compris). ), ou aucun avertissement si tout va bien (ou si l'ensemble du système est compromis, ce qui est hors de portée).
Vous avez dit que vous "construisez une application" malgré le fait que l'application elle-même puisse techniquement contenir n'importe quelle clé publique à des fins de comparaison et se comporter en toute sécurité (être capable de vérifier l'authenticité). En tant que développeur, je remarque une tendance récente à faire obstacle au processus d'approbation de la bibliothèque et des applications publiques fourni, encore plus que nécessaire, une AC auto-signée (où soi est bien défini), par exemple cela émerge dans https://stackoverflow.com/questions/30337322/how-do-i-register-my-own-root-certificate-authority-in-Swift