Si je consulte un site disposant d'un certificat SSL non signé ou auto-signé, mon navigateur me donne un avertissement. Pourtant, le même navigateur n'a aucun problème à autoriser l'envoi d'informations d'identification sur des pages non sécurisées.
Pourquoi le certificat auto-signé est-il pire que de ne pas avoir de certificat?
Réponses:
Il y a beaucoup de gens qui pensent que ce système est en panne.
Voici la logique derrière la raison pour laquelle votre navigateur vous donnera un tel avertissement alarmant lorsqu'un certificat SSL n'est pas valide:
L'un des objectifs de conception d'origine de l'infrastructure SSL était de fournir l'authentification des serveurs Web. En gros, si vous allez sur www.bank.com, SSL permet au serveur web qui répond de prouver qu'il appartient bien à votre banque. Cela empêche un imposteur de manipuler le DNS ou d'utiliser une autre méthode pour qu'un serveur malveillant réponde.
La «confiance» dans SSL est fournie en faisant signer un certificat par un tiers de confiance (des sociétés comme VeriSign et Thawte Consulting), indiquant qu'ils ont vérifié qu'il appartient à qui il prétend être (en théorie, en visitant l'administrateur informatique en personne ou une autre méthode qui crée une confiance directe, bien que les preuves montrent qu'ils sont en fait plutôt laxistes à ce sujet - tout ce qu'il faut pour obtenir un certificat SSL signé est souvent un numéro 800 et un peu de compétence d'acteur).
Donc, si vous vous connectez à un serveur Web qui fournit un certificat SSL, mais qu'il n'est pas signé par un tiers de confiance, cela pourrait en théorie signifier que vous communiquez avec un imposteur qui prétend être un serveur appartenant à une autre organisation .
Dans la pratique, un certificat auto-signé signifie généralement que l'organisation qui exécute le serveur a choisi de ne pas payer pour un certificat signé (ils peuvent être assez chers, selon les fonctionnalités que vous souhaitez), ou manquait de l'expertise technique pour en configurer un ( certaines solutions pour petites entreprises offrent un mécanisme en un clic pour un certificat auto-signé, mais l'obtention d'un certificat de confiance nécessite des étapes plus techniques).
Je crois personnellement que ce système est en panne et que communiquer avec un serveur n'offrant aucun cryptage est beaucoup plus dangereux que de communiquer avec un serveur proposant SSL avec un certificat auto-signé. il y a trois raisons pour lesquelles les navigateurs n'agissent pas comme c'est le cas:
L'envoi des informations d'identification d'une page à l'autre fait essentiellement HTTP POST. L'envoi d'informations d'identification n'a rien de spécial par rapport à l'envoi de termes de recherche via POST, par exemple.
L'utilisation d'un canal sécurisé indique l'intention du programmeur de sécuriser le transfert. Dans ce cas, l'utilisation d'un avertissement de certificat auto-signé est une très bonne chose à faire.
Je ne peux pas commenter, donc je publierai ces informations qui complètent les informations correctes de user40350.
Pourtant, le même navigateur n'a aucun problème à autoriser l'envoi d'informations d'identification sur des pages non sécurisées.
Ce n'est même pas vrai. La plupart des navigateurs affichent un avertissement indiquant que vous êtes sur le point de soumettre des données via une connexion non sécurisée lorsque vous essayez pour la première fois, mais vous pouvez le désactiver pour qu'il ne s'affiche plus jamais, et je parie que c'est exactement ce que vous avez fait ...
Miro A a écrit:
L'envoi des informations d'identification d'une page à l'autre fait essentiellement HTTP POST. L'envoi des informations d'identification n'a rien de spécial par rapport à l'envoi, par exemple les termes de recherche via POST
C'est également incorrect, car les champs de mot de passe sont des balises html spéciales par exemple. En plus de cela, les étiquettes comme "nom d'utilisateur" et "mot de passe" trahissent également beaucoup de leur sensibilité. Il serait parfaitement possible pour les navigateurs de prendre en compte ce type d'informations.
Les connexions sécurisées par le protocole https: // sont indiquées par le navigateur comme "sécurisées". Par exemple, un petit cadenas est affiché ou des parties de l'URL sont marquées en vert.
L'utilisateur est donc censé avoir confiance que les pages qu'il visite proviennent bien de l'URL qu'il a saisie et ne proviennent pas de quelqu'un d'autre.
S'il n'utilise pas https: //, l'utilisateur est censé savoir que les données saisies ne sont pas protégées et le site sur lequel il surfe pourrait être importé.
Un certificat auto-signé ne garantit pas - encore une fois, l'attente que la page consultée ne soit pas impostée, donc il ne donne aucune sécurité supplémentaire.
Une distinction doit être faite entre un certificat de confiance (signé par une autorité de confiance) et un certificat non approuvé. Sinon, quelqu'un pourrait usurper l'identité de votre banque (par exemple) en utilisant un certificat auto-signé avec une relative impunité.
Un avertissement en face à face est préférable à un avertissement subtil dans ce cas, car le risque potentiel est relativement élevé. Les gens peuvent cliquer sur un lien https et ne même pas penser que quelqu'un pourrait être assis au milieu pour surveiller la connexion. Si l'indication que le certificat n'est pas approuvé est subtile (disons une icône rouge au lieu d'une icône verte, etc.), alors les gens pourraient être facilement trompés, supprimant les avantages de SSL.
De nombreuses bonnes raisons ont été énumérées. En voici encore un:
Pensez aux cas où une page Web sécurisée intègre des éléments d'une autre. Un attaquant pourrait détecter quelles requêtes concernent la page Web externe (par exemple, en regardant le timing, elle doit venir en premier) et lesquelles concernent les éléments internes. Il pouvait s'injecter en tant que MITM dans les seuls éléments internes, utiliser un certificat auto-signé et contrôler des parties de la page. À moins qu'un avertissement ne soit présenté pour les éléments internes utilisant SSL mais n'utilisant pas de certificat de confiance, la sécurité de la page externe serait compromise.
Voici un exemple réaliste. Supposons que je suis un fournisseur et que j'ai un lien "payer avec PayPal". Vous cliquez dessus, et je sais. Je vous redirige vers PayPal et vous laisse accéder à la page PayPal légitime et sécurisée. Si je regarde votre réseau, je sais que ce sera votre première demande de PayPal, et peu de temps après, vous soumettrez votre mot de passe. J'ai donc MITM submitcontenant votre adresse e-mail et votre mot de passe, en remplaçant mon certificat auto-signé par PayPal.
Vous voyez comment la sécurité de la page externe est compromise en ne vous avertissant pas si le certificat de la page interne est auto-signé? Il doit donc mettre en garde contre les certificats auto-signés provenant de liens.
Et, bien sûr, si vous entrez httpsmanuellement, il doit vous avertir. Parce que vous vous attendez à ce qu'il soit sécurisé.
Lorsque l'homme dans l'attaque du milieu est exécuté dans https: // site Web, l'avertissement n'est qu'une indication de quelque chose de mal à l'utilisateur moyen. C'est donc une partie très importante de la sécurité HTTPS.
La bonne question est pourquoi le chiffrement partiellement dangereux n'est pas un exemple possible sur HTTP.