SSL / TLS a une légère surcharge. Lorsque Google a basculé Gmail vers HTTPS (d'une fonctionnalité facultative 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 + 2%; voir ce texte pour plus de détails. Cependant, c'est pour Gmail, qui se compose de données privées, dynamiques, non partagées et hébergées sur les systèmes de Google, qui sont accessibles de partout avec une très faible latence. Les principaux effets de HTTPS, par rapport à HTTP, sont:

• L'initiation de connexion nécessite des allers-retours réseau supplémentaires. Puisque de telles connexions sont «maintenues en vie» et réutilisées chaque fois que 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 du contenu statique peuvent trouver que la surcharge du réseau n'est pas 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 sont extrêmement friands de la mise en cache car la bande passante du réseau est leur force vitale.

• HTTPS est HTTP dans SSL / TLS. Au cours de la négociation TLS, le serveur affiche son certificat, qui doit désigner le nom de serveur prévu - et cela se produit avant que la requête HTTP elle-même ne soit envoyée au serveur. Cela empêche l'hébergement virtuel, sauf si une extension TLS appelée 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 de serveur sous Windows XP (IE 7.0 et les versions ultérieures la prennent en charge, mais uniquement sous Vista et Win7). Compte tenu de 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 d'IPv6 et la pénurie d'adresses IPv4 en font 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. C'est 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, donc la confidentialité est de peu d'importance 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 l'identification physique du propriétaire du certificat par l'autorité de certification (je ne dis pas que l'autorité de certification commerciale prix leurs certificats équitablement; mais même la plus juste des autorités de certification, gérée par le Bouddha lui-même, doivent encore facturer des frais pour un certificat). Une autorité de certification commerciale aimerait que HTTPS soit "la valeur par défaut". De plus, il n'est pas clair si le modèle PKI incarné par les certificats X.509 est vraiment ce qui est vraiment 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 lorsque le domaine est créé).

• 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 inclut tous types 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.

Toutes ces raisons expliquent pourquoi HTTPS n'est pas nécessairement une bonne idée comme 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 a été négligé jusqu'à présent.

La voici: HTTP simple est le protocole par défaut pour le Web, car la majorité des informations sur le Web n'a pas besoin de sécurité.

Je ne veux pas minimiser la question ou les problèmes de sécurité de certains sites / applications Web. Mais nous pouvons parfois oublier le trafic Web:

• contient uniquement des informations entièrement publiques
• ou a peu ou pas de valeur
• ou où en avoir plus les visiteurs sont considérés comme augmentant la valeur du site (médias d'information, sites à effet de réseau)

Quelques exemples rapides, je suis sûr que vous pouvez rapidement en faire plus dans votre esprit:

• Presque tous les sites Web d'entreprise, parfois appelés "sites de brochures", répertoriant des informations publiques sur une entreprise.
• Presque tous les médias d'information, les blogs , Les chaînes de télévision, etc. qui ont choisi le support publicitaire comme principale stratégie de monétisation.
• Services qui peuvent offrir des connexions et une personnalisation supplémentaire, mais qui donnent également leur contenu gratuitement à quiconque navigation anonyme (YouTube fx).

• Cela met beaucoup plus de charge CPU sur le serveur, en particulier pour le contenu statique.
• Il est plus difficile de déboguer avec des captures de paquets
• Il ne prend pas en charge les serveurs virtuels basés sur les noms

Http était toujours la valeur par défaut. Au départ, https n'était pas nécessaire pour quoi que ce soit, 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 qu'il n'est toujours pas un argument convaincant pour remplacer entièrement http.

Avec des mécanismes de plus en plus efficaces pour exécuter des connexions sécurisées TLS, la surcharge du processeur devient beaucoup moins problématique.

Personne n'a signalé de problème clair résultant 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é à diverses fins.

Prenons l'exemple de gmail, lorsque les utilisateurs visitent gmail.com , ils consultent 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 le code HTML de la requête https et de le faire pointer vers http.

Si https était en fait le protocole par défaut, vos sessions sur les sites Web auraient été protégées.

question 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 chiffrement.

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 le renouvellement des 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 ce 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 depuis la prise en charge de 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 en utilisant SSL sur un serveur et un port particuliers. Cela a interféré avec la possibilité de faire de l'hébergement basé sur le nom (hébergement virtuel) - une pratique largement utilisée permettant d'héberger de nombreux domaines différents à partir de la même adresse IP. Avec HTTPS, l'hébergement classique basé sur le nom ne fonctionne pas car le serveur aurait besoin de savoir quel nom d'hôte présenter dans la couche de validation SSL / TLS avant la requête HTTP, contenant le hostname, peut être déchiffré.

  L'identification du nom du serveur (SNI), qui implémente efficacement l'hébergement basé sur le nom au niveau de la couche SSL / TLS, supprime cette limitation.

• Rythme lent du changement

  HTTPS était une modification d'un protocole existant, HTTP, qui était déjà bien ancré avant que de nombreuses personnes ne commencent à penser à la sécurité. Une fois qu'une technologie est établie et aussi omniprésente que l'était HTTP, le monde peut mettre très longtemps à passer à 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 HTTPS n'est pas plus largement utilisé ...

• Non nécessaire . Comme la réponse de Jesper le souligne avec perspicacité, "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 de publicité, 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 quelques travaux intéressants de CloudFlare contribuent à changer cela.

• 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 elles ne reçoivent pas autant de publicité (vous ne savez pas pourquoi?).

• Prix des adresses IP . Tant que l'IPv6 ne se généralisera pas, les sites Web seront confrontés à la raréfaction (et donc au coût) croissante des adresses IPv4. SNI permet d'utiliser plusieurs certificats sur une seule adresse IP, mais sans prise en charge SNI dans Windows XP ou IE 6, la plupart des sites ont encore 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ûteuse 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épare pas.

La vraie réponse est que les certificats SSL dans leur forme actuelle sont difficiles à utiliser. Ils sont tellement inutilisables que cela menace 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 le SSL bidirectionnel (certificats PKI), les incompatibilités de la 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) qui sont appelés "TLS".

Voir la montée 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 gens utilisent des expirations très courtes car les renouvellements sont automatisés.