Pourquoi les navigateurs utilisent-ils par défaut http: et non https: pour les URL saisies?
Quand je tape example.com sans aucun schéma dans la barre du navigateur et appuyez sur Entrée, il est interprété comme HTTP://example.com, ne pas HTTPS://example.com. Pourquoi? Et où sont les plans pour résoudre ce problème?
(Pour être clair, je parle seulement sur les adresses tapées/collées provenant d'un utilisateur "paresseux", pas sur les actions définies par logiciel telles que les URL relatives au schéma, window.location = "url" etc. Et évidemment en tapant/collant HTTP://example.com doit encore fonctionner.)
[~ # ~] modifier [~ # ~] : Comme certaines réponses soulignent que les sites peuvent déjà surtout atteindre cet objectif avec redirections + HSTS. Le gain technique central serait de réduire le problème de première connexion (également résolu par la précharge HSTS mais qui ne peut pas être étendu à tous les sites). Je peux voir comment c'est une faible justification pour casser des choses maintenant; ce qui m'intéresse le plus, c'est de savoir si c'est une fin de jeu évidente dans 5 ans? dix? 20?
Je peux voir plusieurs problèmes sur la façon de passer à l'interprétation https:
Expérience utilisateur avec des sites qui ne fonctionnent que sur http. La valeur par défaut de https afficherait une erreur mais l'utilisateur n'a généralement aucune idée si cela fonctionne - devrait, c'est-à-dire si ce site n'a tout simplement jamais fonctionné sur https ou s'il s'agit d'une attaque de rétrogradation.
Si la page d'erreur pour cette situation contiendra un simple "vouliez-vous dire http: ...?" lien (*), les utilisateurs s'habitueront à cliquer sur n'importe quel site qui ne fonctionne pas et nous n'avons pas beaucoup gagné (?). Et si ce n'est pas facile (par exemple, l'utilisateur doit modifier
https->http, les utilisateurs n'utiliseront pas ce navigateur.[~ # ~] modifier [~ # ~] : j'aurais dû préciser que l'indication d'erreur doit être différente de la mention explicite d'une adresse HTTPS qui a échoué - ce scénario n'est pas tant un "échec" que "l'interprétation sûre n'a pas fonctionné". Et pour commencer, même "soft failing" automatiquement sur HTTP avec une barre d'avertissement en haut serait OK.
Mais je pense que nous gagnons encore 3 choses: aller sur un site non sécurisé est une action consciente, nous éduquons les utilisateurs que HTTP non sécurisé est pas normal , et nous mettons la pression sur les sites pour implémenter https.
Inconvénient d'avoir à taper
http://dans certains cas. L'OMI est complètement compensée par la commodité de ne pas avoir à taperhttps://dans plus de cas."Compatibilité" avec la valeur par défaut historique. Je ne sais pas si elle est inscrite dans une norme, mais IMO, il est clair que nous devrons la changer un jour, donc ce n'est pas un showstopper.
Politique/économie: le système d'AC a ses problèmes et les navigateurs peuvent être réticents à faire pression sur les administrateurs de sites pour les payer (s'ils n'y voient pas de valeur autrement). Ignorons l'argent pendant un moment et faisons semblant Let's Encrypt free CA est arrivé.
Je peux voir pourquoi faire le changement en ce moment peut être controversé; ce qui me déroute, c'est pourquoi il n'est pas largement discuté comme l'objectif évident à long terme, avec un plan par étapes à la la suppression des certificats SHA-2 bien que peut-être plus lent. Ce que je vois semble supposer que http restera par défaut pratiquement pour toujours:
Passage de Chrome à la dissimulation
http://dans la barre d'URL est un pas en arrière. La première étape vers https par défaut aurait dû afficher http en rouge; à un moment ultérieur, finissent par se cacherhttps://(affichant uniquement le cadenas vert) ...HSTS évolue dans la bonne direction mais avec une opt-in prudente par site. C'est à la fois plus faible et plus fort - les sites optent pour forcer https même pour les URL http explicites, sans recours de l'utilisateur pour les erreurs - mais le RFC ne mentionne même pas l'idée que https pourrait être un global par défaut, ou que le schéma par défaut du navigateur est à blâmer pour bootsrap MITM problème.
J'ai vu DNSSEC mentionné comme futur vecteur pour l'opt-in de type HSTS mais encore une fois je n'ai jamais vu de propositions pour l'opt-out ...
Existe-t-il également des navigateurs (ou des extensions) offrant cela en option?
Eh bien, je peux présumer qu'il existe plusieurs raisons:
- La prise en charge HTTPS n'est pas configurée automatiquement sur les sites Web. Par conséquent, pourquoi les navigateurs devraient-ils supposer que c'est le cas?
- Dire qu'un site Web n'est pas accessible à moins d'utiliser un système spécifique serait au-dessus des têtes d'un nombre important d'utilisateurs.
- Passer à HTTPS n'est pas aussi simple qu'il y paraît dans certains cas. Prenez Stack Exchange par exemple.
Quant à montrer les sites Web non sécurisés en rouge, qui est déjà en cours .
Google Chrome a le calendrier suivant pour signaler des erreurs sur des sites Web non sécurisés:
- Chrome 46
Chrome marquera l'état "HTTPS avec des erreurs mineures" en utilisant la même icône de page neutre que les pages HTTP.
- Chrome 56
marquer les pages HTTP qui collectent des mots de passe ou des cartes de crédit comme non sécurisées
- Chrome 62
Chrome affiche l'avertissement "Non sécurisé" dans deux situations supplémentaires: lorsque les utilisateurs saisissent des données sur une page HTTP et sur toutes les pages HTTP visitées en mode navigation privée.
- Chrome 68
l'omnibox affichera "Non sécurisé" pour toutes les pages HTTP.
- Chrome 79
Chrome passera progressivement au blocage de tout le contenu mixte par défaut. Pour minimiser les ruptures, nous mettrons à niveau automatiquement les ressources mixtes vers https: //, afin que les sites continuent de fonctionner si leurs sous-ressources sont déjà disponibles sur https: //.
- Chrome 81
Chrome affichera un message d'avertissement sur tous les téléchargements de contenu mixte.
- Chrome 82
Chrome avertit des téléchargements de contenu mixte d'exécutables (par exemple .exe).
Chrome bloquera les exécutables à contenu mixte
Chrome avertira les archives de contenu mixte (.Zip) et les images de disque (.iso).
Chrome bloquera les exécutables, les archives et les images de disque à contenu mixte
Chrome avertit de tous les autres téléchargements de contenu mixte, à l'exception des formats d'image, audio, vidéo et texte.
Chrome avertit des téléchargements de contenu mixte d'images, d'audio, de vidéo et de texte
Chrome bloquera tous les autres téléchargements de contenu mixte
- Chrome 86
Chrome bloquera tous les téléchargements de contenu mixte.
Les navigateurs sont des applications pour les utilisateurs finaux. Bien que la majorité des sites soient disponibles par http (même s'ils redirigent simplement vers https), une partie importante n'est pas disponible par https. Ainsi, votre proposition briserait la navigation sur le Web pour une très grande partie des utilisateurs. Cela se briserait d'une manière qu'ils ne comprennent pas. La rétrogradation automatique vers http en cas d'échec de https n'aurait pas de sens car un attaquant pourrait alors simplement causer des ravages avec les connexions au port 443 pour appliquer les rétrogradations.
Une fois tous les sites insignifiants passés à https, à l'exception de quelques-uns, on pourrait passer à une valeur par défaut plus sécurisée, mais pas encore. Les utilisateurs finaux ne comprendraient pas ce qui s'est passé et devraient probablement simplement basculer vers un autre navigateur ou obtenir des conseils quelque part sur Internet pour récupérer l'ancien comportement.
Les décisions de sécurité doivent être prises avec et non contre les utilisateurs.
Il y a un problème plus important en jeu ici qui empêcherait votre suggestion. La façon dont de nombreux serveurs Web sont actuellement configurés, vous pourriez en fait vous retrouver sur le mauvais site Web si vous avez opté par défaut pour https. Ce n'est pas vrai si vous utilisez par défaut http.
Par exemple, supposons que vous ayez 3 sites tous sur la même adresse IP:
http://site.a.com
http://site.b.com
https://site.c.com
Sur de nombreux serveurs, si vous tentez d'accéder à https://site.a.com, (au lieu de http), vous regarderez réellement le site C, mais avec une erreur de certificat.
Je pense qu'il y a un réel danger de confondre beaucoup d'utilisateurs, ce qui aggraverait la situation. Essayer HTTPS partout n'est pas nécessairement une mauvaise idée, mais il doit y avoir une sorte de plan de secours pour l'utilisateur lorsque HTTPS n'est pas disponible.
De nombreux utilisateurs ne sont pas intéressés par les panneaux d'avertissement, ils veulent juste leur contenu. Dans de nombreux cas, la protection du trafic que vous obtenez contre les écoutes ou les attaques MITM n'est pas strictement nécessaire, ou du moins le risque et les conséquences sont bien inférieurs à un certificat incorrect sur votre banque.
Essentiellement, si les utilisateurs reçoivent un signe d'avertissement lorsqu'ils essaient d'accéder à leur site HTTP uniquement préféré (par exemple, un journal ou un blog), vous devrez leur apprendre à ignorer l'avertissement, car il peut toujours être OK dans ce cas. Dire aux utilisateurs d'ignorer les avertissements est généralement une idée terrible, à moins que vous ne vous assuriez vraiment qu'ils comprennent vraiment que ignorer cet avertissement est OK, mais ignorer les autres ne l'est pas.
Les avertissements sont bons, mais de nombreux avertissements pour des problèmes à risque relativement faible sont contre-efficaces, car les utilisateurs sont alors susceptibles d'ignorer tous les avertissements (surtout s'ils ne les comprennent pas complètement).
Peu d'utilisateurs non techniques essaient de comprendre les implications de l'avertissement Firefox pour un mauvais certificat, par exemple:
Cette connexion n'est pas approuvée
Vous avez demandé à Firefox de se connecter en toute sécurité à some.site.example, mais nous ne pouvons pas confirmer que votre connexion est sécurisée.
Normalement, lorsque vous essayez de vous connecter en toute sécurité, les sites présenteront une identification fiable pour prouver que vous allez au bon endroit. Cependant, l'identité de ce site ne peut pas être vérifiée. Que devrais-je faire?
Si vous vous connectez généralement à ce site sans problème, cette erreur peut signifier que quelqu'un essaie de se faire passer pour le site, et vous ne devez pas continuer.
C'est trois paragraphes que de nombreux utilisateurs ne prendront pas la peine de lire, du moins pas à chaque fois qu'ils le rencontrent, si cela se produit trop souvent.
La principale différence avec un site HTTP ordinaire est que le site HTTP ordinaire ne prétend pas offrir une connexion sécurisée. En supposant que vous pouvez expliquer cela dans un autre message de trois paragraphes de la même manière. Il serait assez courant, même pour les utilisateurs avertis d'être distraits et de ne pas lire ces explications en entier avant de choisir de continuer.
De nombreux sites utilisent http:// à https:// redirections, parfois avec un code d'état 301 (permanent) ou avec HSTS. Le HSTS préchargé est excellent mais rare, le HSTS sur la première connexion est un bon compromis.
À la fin de la journée, il appartiendra toujours à l'utilisateur de s'attendre à ce que la connexion soit sécurisée le cas échéant. Le navigateur ne peut pas faire grand-chose, mais il appartient à l'utilisateur de vérifier que HTTPS est utilisé lorsque cela est logique et avec le site auquel il s'attend. Ce n'est pas particulièrement différent de la vie réelle: vous n'avez pas besoin de vérifier le passeport de tous ceux à qui vous parlez, mais quand les choses comptent, vous le faites.
Il y a un problème d'amorçage qui ne peut pas être transmis dans le domaine de la technologie. Si les utilisateurs accèdent à http://www.gmail.com/, ils doivent être redirigés vers https://www.gmail.com/ ou peut-être https://mail.google.com/ ou https://accounts.google.com/. Ce sont les connaissances hors bande qui leur indiquent qu'ils doivent s'attendre à HTTPS sur Gmail et que Gmail est géré par Google. (La même connaissance hors bande qui leur dit que HTTPS existe même ...)
S'ils ne sont pas redirigés vers un site HTTPS géré par Google (Gmail ou login), c'est ce qui devrait sonner avec eux. Alors qu'un mécanisme automatisé pourrait fonctionner pour un nombre limité de sites bien connus, il est difficile d'imaginer un système qui fonctionnerait en général. A défaut, l'utilisateur a toujours la responsabilité de: (a) savoir quand s'attendre à HTTPS, (b) vérifier que HTTPS est utilisé et (c) vérifier qu'il est bien sur le site qu'il souhaite. (Malheureusement, certains navigateurs, en particulier sur les appareils mobiles, rendent ces informations un peu moins visibles.)
À mon avis, il est plus facile d'enseigner à un utilisateur ces trois points que de lui apprendre à lire les détails des avertissements qu'il peut choisir d'ignorer de toute façon.
Bien sûr, vous pourriez imaginer à l'avenir un monde où tous les sites utiliseraient HTTPS. Je ne suis pas encore entièrement convaincu que cela soit nécessaire. Les sites incorrects peuvent également obtenir un certificat, de sorte que les utilisateurs devront toujours assumer la responsabilité de vérifier qu'ils se trouvent sur le site qu'ils avaient l'intention de visiter de toute façon.
Essayer d'enseigner que le HTTP simple n'est "pas normal" ne fait que pousser le problème au niveau supérieur. Un site Web entièrement HTTPS peut être un fardeau pour les fournisseurs de services, tout en n'offrant pas nécessairement les avantages que vous attendez.
L'EFF a un plugin pour Firefox (y compris Android), Chrome et Opera. Il s'appelle HTTPS Everywhere et il utilise des règles pour vous assurer de vous retrouver sur le bon site. Par exemple, il va réécrire example.com to https://secure.example.com/ s'il sait que la version https ne vit que sur secure.example.com. Il remplace même les URL dans les liens, etc.
À l'heure actuelle, les navigateurs utilisent HTTP par défaut, car c'est ce qui a été fait pendant des décennies. Il n'est pas de la responsabilité du navigateur de s'assurer que le site Web est sécurisé. Il s'appuie sur le site Web pour effectuer la redirection appropriée et prendre en charge HTTPS. Taper google.com redirigera très bien vers la version HTTPS. Si un site Web prend en charge HTTPS, il doit mettre en place la redirection appropriée. Le navigateur doit être robuste.
Si le site prend en charge les deux, c'est comme dire que votre porte dérobée reste ouverte, mais votre porte d'entrée est verrouillée.
Parce que les ordinateurs étaient faibles et que le cryptage était gourmand en CPU et en bande passante Internet et considéré comme inégalé dans les balbutiements d'Internet. Cette couche supplémentaire doit faire son propre tango cérémoniel pour fonctionner, ce qui signifie un processeur supplémentaire, des allers-retours supplémentaires, une largeur de bande supplémentaire. Mais les choses changent, par exemple les versions récentes de chrome par défaut essaiera https de nos jours. Côté serveur, cependant, vous devez configurer une redirection en tant que seul contenu Web servi sur ledit domaine qui pointe le navigateur vers la saveur https du site.
Tout site Web nécessitant une sécurité doit rediriger automatiquement de http: // vers https: //. Cela rendrait l'exigence que le navigateur affiche automatiquement https: // redondant, et est une solution plus simple que d'avoir à rediriger de https vers http pour les sites sans certificats.
C'est quelque chose qui ne devrait pas vraiment être fait de toute façon, ce qui signifie que le navigateur devrait mettre des avertissements de sécurité, gênant inutilement l'utilisateur comme ces avertissements de cookies ennuyeux, etc.