Pourquoi HTTPS n'est-il pas le protocole par défaut?
Pourquoi HTTP est-il encore couramment utilisé, au lieu de cela, je pense que HTTPS est beaucoup plus sécurisé?
SSL/TLS a une légère surcharge. Lorsque Google est passé de Gmail à HTTPS (d'une fonctionnalité optionnelle au paramètre par défaut), ils ont découvert que la surcharge du processeur était d'environ +1% et la surcharge du réseau de 2%; voir ce texte pour plus de détails. Cependant, c'est pour Gmail, qui se compose de données privées, dynamiques et non partagées, et hébergées sur les systèmes de Google, qui sont accessibles de partout avec une latence très faible. Les principaux effets de HTTPS, par rapport à HTTP, sont:
L'initiation de la connexion nécessite des allers-retours réseau supplémentaires. Étant donné que ces connexions sont "maintenues en vie" et réutilisées dans la mesure du possible, cette latence supplémentaire est négligeable lorsqu'un site donné est utilisé avec des interactions répétées (comme c'est généralement le cas avec Gmail); les systèmes qui servent principalement des contenus statiques peuvent trouver la surcharge du réseau non négligeable.
Les serveurs proxy ne peuvent pas mettre en cache les pages servies avec HTTPS (car ils ne voient même pas ces pages). Là encore, il n'y a rien de statique à mettre en cache avec Gmail, mais c'est un contexte très spécifique. Les FAI aiment beaucoup la mise en cache car la bande passante réseau est leur force vitale.
HTTPS est HTTP dans SSL/TLS. Pendant la prise de contact TLS, le serveur affiche son certificat, qui doit désigner le nom de serveur prévu - et cela se produit avant la requête HTTP elle-même est envoyée au serveur. Cela empêche l'hébergement virtuel, sauf si une extension TLS connue sous le nom Indication du nom du serveur est utilisée; cela nécessite le soutien du client. En particulier, Internet Explorer ne prend pas en charge l'indication du nom du serveur sous Windows XP (IE 7.0 et versions ultérieures le prennent en charge, mais uniquement sur Vista et Win7). Étant donné la part de marché actuelle des systèmes de bureau utilisant WinXP, on ne peut pas supposer que "tout le monde" prend en charge l'indication du nom du serveur. Au lieu de cela, les serveurs HTTPS doivent utiliser une adresse IP par nom de serveur; l'état actuel du déploiement IPv6 et IPv4 la pénurie d’adresses en fait un problème.
HTTPS est "plus sécurisé" que HTTP dans le sens suivant: les données sont authentifiées comme provenant d'un serveur nommé, et le transfert est confidentiel vis-à-vis de quiconque peut espionner la ligne. Il s'agit d'un modèle de sécurité qui n'a pas de sens dans de nombreuses situations: par exemple, lorsque vous regardez une vidéo de Youtube, vous ne vous souciez pas vraiment de savoir si la vidéo provient vraiment de youtube.com ou d'un pirate informatique qui (courtoisement) envoie vous la vidéo que vous souhaitez voir; et cette vidéo est de toute façon des données publiques, la confidentialité est donc peu pertinente ici. De plus, l'authentification n'est effectuée que par rapport au certificat du serveur, qui provient d'une autorité de certification connue du navigateur client. Les certificats ne sont pas gratuits, car le but des certificats est qu'ils impliquent une identification physique du propriétaire du certificat par l'AC (je ne dis pas que les AC commerciaux évaluent leurs certificats équitablement; mais même le plus équitable des AC, opéré par le Bouddha lui-même, le ferait doivent encore facturer des frais pour un certificat). L'autorité de certification commerciale aimerait aimer HTTPS pour être "la valeur par défaut". En outre, il n'est pas clair si le modèle PKI incarné par les certificats X.509 est vraiment ce qui est nécessaire "par défaut" pour Internet dans son ensemble (en particulier en ce qui concerne les relations entre les certificats et le DNS - certains affirment qu'un le certificat de serveur doit être émis par le bureau d'enregistrement lors de la création du domaine).
Dans de nombreux réseaux d'entreprise, HTTPS signifie que les données ne peuvent pas être vues par les écoutes indiscrètes, et cette catégorie comprend toutes sortes de filtres de contenu et de logiciels antivirus. Faire de HTTPS la valeur par défaut rendrait de nombreux administrateurs système très mécontents.
Ce sont toutes des raisons pour lesquelles HTTPS n'est pas nécessairement une bonne idée en tant que protocole par défaut pour le Web. Cependant, ils ne sont pas la raison pour laquelle HTTPS n'est pas, actuellement, le protocole par défaut pour le Web; HTTPS n'est pas la valeur par défaut simplement parce que HTTP était là en premier.
Bien qu'il y ait déjà d'excellentes réponses, je pense qu'un aspect est ignoré jusqu'à présent.
Le voici: HTTP simple est le protocole par défaut pour le Web car la majorité des informations sur le Web n'ont pas besoin de sécurité.
Je ne veux pas minimiser la question ou les problèmes de sécurité de certains sites Web/applications. Mais nous pouvons parfois oublier le trafic Web:
- ne contient que des informations entièrement publiques
- ou a peu ou pas de valeur
- ou où avoir plus de visiteurs est considéré comme augmentant la valeur du site (médias d'information, effet de résea sites)
Quelques exemples rapides, je suis sûr que vous pouvez rapidement en faire plus dans votre esprit:
- Presque tous les sites Web d'entreprises, parfois appelés "sites de brochures", répertorient les informations publiques sur une entreprise.
- Presque tous les médias d'information, blogs, chaînes de télévision, etc. qui ont choisi le support publicitaire comme stratégie principale de monétisation.
- Services qui peuvent offrir identifiants et personnalisation supplémentaire, mais qui donnent également leur contenu gratuitement à toute personne naviguant anonymement (YouTube fx).
- Il met beaucoup plus de charge CPU sur le serveur, en particulier pour le contenu statique.
- Il est plus difficile de déboguer avec les captures de paquets
- Il ne prend pas en charge les serveurs virtuels basés sur le nom
Http a toujours été la valeur par défaut. Au départ, https n'était nécessaire pour rien, c'était à peu près un ajout car il devenait évident que la sécurité était nécessaire dans certaines circonstances.
Même maintenant, il y a tellement de sites Web qui n'ont pas besoin de https que ce n'est toujours pas un argument convaincant pour remplacer complètement http.
Avec des mécanismes toujours plus efficaces pour exécuter des connexions sécurisées TLS, la surcharge du processeur devient de moins en moins un problème.
Personne n'a signalé un problème clair qui résulte de l'utilisation de http par défaut, plutôt que de https.
Presque personne ne prend la peine d'écrire l'URI complet lors de la demande d'une ressource qui doit être chiffrée et/ou signée à diverses fins.
Prenons l'exemple de gmail, lorsque les utilisateurs visitent gmail.com, ils visitent en fait le protocole par défaut de http, plutôt que https. À ce stade, la sécurité a échoué dans les scénarios où l'adversaire intercepte le trafic. Pourquoi? Parce qu'il est possible de supprimer html de la demande https et de les pointer vers http.
Si https était en fait le protocole par défaut, vos sessions vers des sites Web auraient été protégées.
À la question de savoir pourquoi http est choisi sur https, les différentes réponses ci-dessus s'appliquent. Le monde n'est tout simplement pas encore prêt pour une utilisation généralisée du cryptage.
En plus des raisons que d'autres ont déjà données:
Travail supplémentaire requis pour configurer HTTPS sur le serveur
L'administrateur du serveur doit configurer des certificats pour chaque domaine. Cela implique d'interagir avec une autorité de certification pour prouver que vous êtes le véritable propriétaire du domaine et obtenir des renouvellements de certificats. Cela peut signifier générer manuellement des demandes de signature de certificat et acheter des renouvellements, ou mettre en place un processus automatisé pour le faire (tel que certbot utilisant Let's Encrypt). Dans les deux cas, c'est plus de travail que de ne pas utiliser HTTPS.
Adresses IP supplémentaires requises
Ce n'est pas vraiment un problème car la prise en charge SNI (Server Name Identification) s'est généralisée dans les navigateurs et les bibliothèques client SSL.
Traditionnellement, cependant, il était nécessaire d'utiliser une adresse IP différente pour chaque site distinct utilisant SSL sur un serveur et un port particuliers. Cela interférait avec la possibilité de faire de l'hébergement basé sur un nom (hébergement virtuel) - une pratique largement utilisée permettant à de nombreux domaines différents d'être hébergés à partir de la même adresse IP. Avec HTTPS, l'hébergement basé sur un nom normal ne fonctionne pas car le serveur devrait savoir quel nom d'hôte présenter dans la couche de validation SSL/TLS avant la requête HTTP, contenant le nom d'hôte, peut être déchiffrée.
L'identification du nom de serveur (SNI), qui implémente efficacement l'hébergement basé sur le nom au niveau de la couche SSL/TLS, supprime cette limitation.
Ralentissement du changement
HTTPS était une modification d'un protocole existant, HTTP, qui était déjà bien ancré avant que beaucoup de gens ne commencent à penser à la sécurité. Une fois qu'une technologie est établie et aussi omniprésente que HTTP, il peut s'écouler très longtemps avant que le monde ne passe à son successeur, même si les raisons du changement sont convaincantes.
Thomas a déjà écrit une excellente réponse, mais je pensais offrir quelques autres raisons pour lesquelles le HTTPS n'est pas plus largement utilisé ...
Pas nécessaire. Comme l'indique avec perspicacité la réponse de Jesper, "la majorité des informations sur le Web n'ont pas besoin de sécurité". Cependant, avec le nombre croissant de suivis effectués par les moteurs de recherche, les sociétés publicitaires, les filtres Internet au niveau des pays et d'autres programmes "Big Brother" (par exemple, NSA); cela augmente le besoin de mesures de confidentialité plus strictes.
Vitesse. Cela semble souvent lent en raison des allers-retours supplémentaires et des demandes supplémentaires de listes de révocation de certificats ( OCSP etc.). Heureusement SPDY (créé par Google et désormais pris en charge dans tous les principaux navigateurs), et certains travaux intéressants de CloudFlare aident à changer cette .
Prix des certificats. La plupart des autorités de certification facturent des sommes exorbitantes (des centaines de dollars) pour un certificat. Heureusement il existe des options gratuites , mais celles-ci ne reçoivent pas autant de publicité (vous ne savez pas pourquoi?).
Prix des adresses IP. Jusqu'à ce qu'IPv6 se généralise, les sites Web seront confrontés à la rareté croissante (et donc au coût) des adresses IPv4. SNI permet d'utiliser plusieurs certificats sur une seule adresse IP, mais sans prise en charge SNI sous Windows XP ou IE 6, la plupart des sites ont toujours besoin d'une adresse IP dédiée pour fournir SSL.
Augmentation de l'utilisation du processeur du serveur.C'est une croyance courante, mais selon Google " SSL/TLS n'est plus coûteux en calcul ".
L'explication la plus simple et la plus raisonnable que j'ai trouvée parmi mes collègues est que cela a toujours été fait avec HTTP, pourquoi le changer maintenant.
S'il n'est pas cassé, ne le réparez pas.
La vraie réponse est que les certificats SSL dans leur forme actuelle sont très difficiles à utiliser. Ils sont tellement inutilisables qu'ils menacent la sécurité des certificats, car les gens prennent des raccourcis pour simplement faire avancer les choses. Je dis cela en tant que personne qui traite régulièrement avec SSL bidirectionnel (certificats PKI), les incompatibilités de pile TLS qui sont créées par la complexité de la spécification et le nombre fou de combinaisons de configurations (limites de chiffrement, options, bogues de bibliothèque spécifiques à la langue) , etc.) appelés "TLS".
Voyez l'essor de LetsEncrypt comme preuve que cela est vrai.
Caddy est un projet de proxy inverse qui utilise LetsEncrypt. Il peut renouveler les certificats pendant que le serveur fonctionne et les utilisateurs utilisent des expirations très courtes car les renouvellements sont automatisés.