Les certificats sont-ils utiles pour l'intranet SSL?
J'ai été chargé de développer une interface intranet pour un logiciel de ligne de commande, et maintenant je recherche des options de sécurité. Notre application en ligne de commande est terminée, mais je n'ai pas commencé à écrire l'interface Web. Je ne sais pas exactement quelles sont les exigences de sécurité pour les clients potentiels, bien que je pense que ssh est généralement acceptable pour l'interface de ligne de commande. Dans cet esprit, je demande de l'aide pour développer un menu de choix avec leurs avantages/inconvénients associés. Un jour, nous pourrions envisager de publier notre interface Web sur Internet, donc je suis prêt à envisager plus de sécurité que nécessaire actuellement si c'est facile et/ou gratuit.
J'ai fait beaucoup de lecture, et ma conclusion provisoire est que la sécurité SSL sans certificat est la meilleure approche, non pas parce que moins de sécurité est inacceptable, mais parce que SSL est la norme et parce qu'il ne semble pas difficile à installer. Moi, un non-expert en sécurité, je n'aurais pas besoin d'expliquer pourquoi moins de sécurité est acceptable pour les non-experts en sécurité. Je pourrais mettre à niveau mon application pour utiliser un certificat à l'avenir si nécessaire.
Voici une liste de choix de sécurité liés à SSL, triés par ma perception du niveau de sécurité avec mes commentaires. De quel niveau de protection ai-je besoin?
Pas de SSL. Cela peut être acceptable si nos clients ne s'inquiètent pas que leurs employés voient/changent les données des autres. Leurs employés pourraient vouloir partager les résultats entre eux de toute façon, et je pourrais utiliser un contrôle d'accès basé sur IP et/ou des mots de passe pour la sécurité.
Effectuez SSL sans certificat. Cela crypte la communication, ce qui protège au moins les données contre la lecture par des employés non autorisés. En utilisant un mot de passe, c'est le même niveau de sécurité que
sshsur la ligne de commande, non? Je n'ai pas besoin de m'inquiéter des attaques de l'homme du milieu dans un intranet, non? Un inconvénient de cette approche serait s'il y avait beaucoup de messages d'avertissement du navigateur.SSL avec un certificat auto-signé. Qu'est-ce que cela me donne qu'aucun certificat ne me donne? Si le DNS peut être modifié de manière inappropriée, alors le client, alors ma demande est la moindre de leurs préoccupations. Autrement dit, si le DNS peut changer, je pense que
sshserait également vulnérable.Faites SSL avec une autorité de certification locale. OpenSSL me permet de créer ma propre autorité de certification. Qu'est-ce que cela me donne qu'un certificat auto-signé ne fait pas? Je suppose que sur un réseau local, il est moins important de vérifier le serveur.
Faites SSL avec une autorité de certification externe. Y a-t-il jamais une raison d'aller dans cette voie pour un intranet? J'ai trouvé des "certificats intranet" à vendre en ligne - mais ce n'est pas clair ce qu'ils offrent, je ne peux pas le faire moi-même.
Pour référence, cette page peut être utile pour comparer des certificats:
http://httpd.Apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts
[mise à jour]
Voici un article sur les risques et les règles d'obtention d'un certificat interne d'une autorité de certification publique.
Oui, les certificats sont toujours utiles pour SSL intranet.
Il existe une différence importante entre SSH et SSL sans certificat: lorsque vous vous connectez pour la première fois à un serveur avec SSH, votre SSH stocke l'empreinte digitale du serveur. Si vous essayez ensuite de vous connecter à ce que le client SSH pense être la même machine mais récupère une empreinte digitale différente, il vous avertit que quelqu'un peut intercepter vos communications.
SSL-without-a-certificate, d'autre part, ne stocke pas l'empreinte digitale du serveur. Vos communications seront toujours cryptées, mais si quelqu'un détourne d'une manière ou d'une autre le serveur DNS comme vous l'avez mentionné, ou, comme le note Rushyo , l'empoisonnement ARP ou quelque chose de similaire, il pourrait effectuer un man-in l'attaque du milieu. SSH, comme mentionné précédemment, remarquera (en supposant que vous vous êtes connecté au bon serveur dans le passé) que l'empreinte digitale a changé et vous alerte.
Un certificat auto-signé serait comparable en sécurité à SSH. Un homme au milieu pourrait générer son propre certificat auto-signé, mais tant que vos applications sont configurées pour n'accepter que certificat auto-signé, vous devrait recevoir une alerte similaire à celle que SSH vous enverra.
Une autorité de certification locale vous offre une sécurité similaire aux certificats auto-signés, mais peut être plus évolutive. Si vous avez plusieurs serveurs, chacun peut avoir son propre certificat, mais un client n'a besoin que du niveau supérieur pour tous les faire confiance. Si un serveur est compromis, vous pouvez révoquer son certificat plutôt que de devoir changer le certificat de chaque serveur.
Je ne pense pas qu'une autorité de certification externe présente des avantages, si ce n'est éventuellement moins de configuration si vos machines ont déjà l'autorité de certification approuvée.
Enfin, je ne connais pas suffisamment l'authentification à deux facteurs pour l'évaluer, mais pour la plupart des applications, SSL devrait être suffisant.
Avertissement: je ne suis pas un expert en sécurité.
- Faites SSL avec une autorité de certification externe. Y a-t-il jamais une raison d'aller dans cette voie pour un intranet? J'ai trouvé des "certificats intranet" à vendre en ligne - mais ce n'est pas clair ce qu'ils offrent, je ne peux pas le faire moi-même.
L'avantage est que vous n'avez pas besoin d'apprendre à configurer votre propre autorité de certification si vous devez gérer un nombre décent de certificats et/ou de machines. Un tel certificat serait déjà approuvé par tous les navigateurs sans que vous ayez besoin d'installer vos propres certificats dans le magasin de confiance.
Cependant , cela est en fait moins sûr car quelqu'un pourrait acheter un certificat pour un autre intranet et l'utiliser sur votre réseau. Pour cette raison, les fournisseurs SSL n'offrent plus ce service. Pour plus d'informations, voir: https://www.godaddy.com/help/phasing-out-intranet-names-and-ip-addresses-in-ssls-6935
Si vous ne disposez que d'un très petit intranet, je vous recommande d'utiliser un certificat auto-signé, puis d'ajouter simplement chaque certificat auto-signé au magasin de confiance de chaque ordinateur.
Cependant, il devient rapidement impossible d'installer un nouveau certificat sur chaque ordinateur de votre intranet chaque fois que vous souhaitez ajouter un nouvel ordinateur. À ce stade, vous souhaitez configurer votre propre autorité de certification afin que vous n'ayez besoin d'installer qu'un seul certificat CA dans le magasin de confiance de chaque ordinateur.