Réponses:
Question intéressante, cela dépend de l'utilisation à mon avis. Vous êtes toujours protégé en termes de session cryptée, mais vous n'avez aucun moyen de savoir s'il s'agit du certificat SSL correct qui vous est présenté, sauf si vous distribuez votre certificat racine CA aux utilisateurs / clients. Pour les projets de test / développement internes, cela fonctionnerait très bien, vous générez un certificat d'autorité de certification racine que vous utilisez pour distribuer à vos utilisateurs (peut être effectué via la stratégie de groupe dans Windows et via la ligne de commande openssl sous Linux / BSD), puis utilisez ce certificat racine pour signer vos CSR. Les utilisateurs ne verront aucun avertissement ni rien et vous savez que le certificat est signé par votre autorité de certification interne.
Pour les sites externes où vous ne pouvez pas garantir cela, je dirais quand même qu'un certificat auto-signé vaut mieux que pas de SSL du tout si vous envoyez des mots de passe ou d'autres informations sensibles via la connexion.
Cependant, du côté positif, il existe de nombreux émetteurs de certificats "commerciaux" très bon marché, GoDaddy étant l'un d'entre eux. Vous pouvez obtenir un certificat pour environ 40 euros par an. GoDaddy offre même des certificats gratuits aux sites Web des projets OpenSource.
Je vais être en désaccord, une fois pour des raisons techniques étroites et une fois pour des raisons générales.
Le fondement technique étroit est que le PO a posé des questions sur les certificats auto-signés, et plusieurs autres réponses se réfèrent aux certificats signés par des autorités de certification privées, ce qui est un problème légèrement différent. Mais pas très différent, donc ce n'est vraiment qu'une note en passant.
L'objection principale est que je pense que tant que les certificats signés commercialement coûtent plus que des dépenses insignifiantes - et 40 $ par an ne sont pas une dépense insignifiante pour beaucoup de gens sur cette planète - les certificats auto-signés ont un rôle majeur à jouer en sécurité Internet, à condition que leurs limites soient reconnues .
Un certificat auto-signé est comme une clé ssh de mon known_hostsfichier. Sans vérification indépendante, il ne peut pas m'assurer que je parle au système que je crois être; mais cela peut m'assurer que le système auquel je parle maintenant est le même que celui auquel j'ai parlé la dernière fois que je pensais avoir une conversation avec lui. Nous mettons en cache les clés ssh tout le temps, et je n'ai encore jamais rencontré d'administrateur système qui ait indépendamment vérifié plus d'une fraction des clés publiques de son known_hostsfichier.
Les certificats auto-signés (et, d'ailleurs, les certificats signés par des autorités de certification non généralement valides) sont bien meilleurs que pas de SSL du tout, tant que les gens se rendent compte qu'à moins de les vérifier, ils sécurisent uniquement la communication pour eux-mêmes, le serveur à l'autre extrémité de l'enregistrement DNS, et tous les hommes du milieu actuellement sur la ligne. S'ils vérifient indépendamment le certificat, l'authentification et le chiffrement sont au moins aussi solides que ceux fournis par un certificat signé par une autorité de certification reconnue.
De plus, ceux qui souhaitent présenter l'utilisation des certificats signés par une autorité de certification reconnue comme l'une et unique panacée de sécurité Internet peut avoir besoin de réfléchir à des questions telles que l'inclusion du CA de la signature du gouvernement chinois dans le paquet norme Mozilla , et le certificats SSL frauduleux signés par Comodo .
known_hosts@MadHatter fait référence.
Pour les sites externes, où les utilisateurs n'ont pas votre certificat CA installé (ce qui est le cas le plus courant), oui, un certificat auto-signé donne un faux sentiment de sécurité , et donc c'est pire qu'inutile:
Tout d'abord, sans certificat CA préinstallé, comment l'utilisateur vérifie-t-il que le certificat provient bien de vous et non d'un attaquant? En faisant correspondre les champs du certificat (CN, empreintes digitales, etc.), bien sûr - mais contre quoi? Alors maintenant, vous avez besoin d'un canal latéral pour vérifier le certificat - et dans les rares cas que j'ai vus, les opérateurs de ligne de support (qui auraient dû servir de canal latéral pour la vérification) n'ont aucune idée de ce que cela est censé signifier; En outre, l'exploitation d'un tel canal latéral coûte beaucoup plus cher que l'obtention d'un certificat signé par une autorité de certification, de sorte que l'utilisateur doit vous faire aveuglément confiance.
Deuxièmement, l'alerte effrayante que l'utilisateur reçoit est effrayante pour une bonne raison: puisque l'utilisateur ne peut pas / ne vérifiera pas le certificat présenté, il peut transmettre en toute sécurité des données à Elbonian Haxx0r D00dz.
Troisièmement, et pire que tout, vous désensibilisez les utilisateurs : "eh bien, ils m'ont dit que je devrais ignorer cet avertissement sur https://mysite.example.com/ , et une enclume ne m'a pas tombé sur la tête, et mon le poisson rouge n'est pas mort non plus; sooooo, cela signifie que c'est juste une autre boîte d'alerte sans aucune signification réelle, donc je peux ignorer cette boîte chaque fois que je la rencontre - je reçois quand même cette jolie icône de verrou, et c'est important. "
En d'autres termes, le niveau de protection est comparable à HTTP standard (sauf pour le reniflement sur le fil: bien que les données soient cryptées en transit, c'est une caractéristique plutôt anémique sans vérification des points finaux), mais le sentiment de protection est déraisonnablement élevé . Mauvaise analogie avec la voiture: "J'ai de l'ABS, donc je peux désormais conduire en toute sécurité dans de mauvaises conditions" - sauf que l'ABS n'existe que dans la brochure de vente de la voiture, sans être réellement présent dans la voiture.
Lecture suggérée: OWASP SSL Best practices
TL; DR: En utilisant des certificats auto-signés sur des sites accessibles au public, vous faites du Net un endroit pire, un utilisateur désemparé à la fois.
Dépend. Si vous pensez que cela vous rend plus sûr, cela augmente vos risques lorsque vous choisissez de faire des choses plus risquées avec votre faux sentiment de sécurité. Si vous le traitez fonctionnellement équivalent à HTTP, alors je dirais que vous êtes légèrement plus sûr.
Sans SSL / HTTPS, toute personne disposant de wirehark sur votre réseau (ou le réseau local de toute personne se connectant) peut écouter et capturer de manière triviale le nom d'utilisateur / les mots de passe envoyés en texte brut.
Avec SSL auto-signé, ils ne peuvent pas simplement écouter, mais doivent maintenant truquer votre site, potentiellement modifier le DNS pour attaquer un homme au milieu (MITM). C'est toujours une menace, mais beaucoup plus difficile à réaliser.
L'autre problème avec l'utilisation de SSL auto-signé est que de nombreux navigateurs traitent les certificats auto-signés comme une menace de sécurité majeure et vous avertissent avant d'entrer (par exemple, chrome) avec une page rouge géante. http://www.sslshopper.com/article-ssl-certificates-in-google-chrome.html Cela pourrait être un inconvénient majeur.
Donc, l'essentiel est: si vous exécutez quelque chose qui n'a pas besoin d'être particulièrement sécurisé (par exemple, pas de données de carte de crédit, pas de numéros de sécurité sociale) et ne peut pas vous permettre un certificat approprié, un certificat auto-signé pourrait avoir un sens (pour empêcher les autres utilisateurs du réseau de renifler facilement leurs informations de connexion).
Cela dépend de ce que vous entendez par «sécurité» et de son ampleur.
Par exemple, votre navigateur est livré avec un ensemble d'autorités de certification acceptées par défaut. Cela signifie que tout certificat émis par cette autorité de certification est accepté par votre navigateur (jusqu'à ce qu'il corresponde au nom DNS). Maintenant, imaginez qu'un gouvernement maléfique possède une autorité de certification ou peut l'obliger à émettre un certificat pour le site que vous visitez. Ensuite, faire un MITM est très facile: ils peuvent proxy votre connexion, en envoyant à votre navigateur le certificat dont ils disposent, et votre navigateur l'acceptera, car il provient d'une autorité de certification "de confiance". Tant qu'ils ne sont pas DNS-transparents (qui est la base de MITM), c'est correct.
Ainsi, la "liste des AC acceptées" est fondamentalement un gros trou de sécurité, jusqu'à ce que l'un de ces AC coopère avec un gouvernement maléfique. Avoir son propre CA est bien mieux.
Bien sûr, vous pouvez le faire dans votre entreprise ou sur votre serveur domestique, car vous pouvez installer votre propre certificat CA sur le client, que vous contrôlez également. Dans un serveur public, vous ne pouvez pas traiter avec un utilisateur, lui demandant d'ajouter une exception ou d'ajouter votre certificat.
Cela dépend donc de ce que vous entendez par «sécurité» et de la portée. SI vous possédez les clients, SÛR, l'auto-signature est plus sûre, jusqu'à ce que vous installiez sur le client lui-même le certificat de votre propre autorité de certification.
Bien sûr, vous ne pouvez pas le faire sur un site Web public car vous ne possédez pas tous les clients. Ainsi, vous aurez un risque de différents comportements, ce qui n'est pas sûr.