HTTPS pour l'ensemble du site


10

Je travaille sur un site Web assez standard avec un contenu public plus un contenu personnel / personnalisé pour les utilisateurs enregistrés. Je sais que je dois utiliser HTTPS lorsque les utilisateurs se connectent ou envoient des informations de carte de crédit. Y a-t-il une raison pour laquelle je ne devrais pas simplement utiliser HTTPS pour l'ensemble du site?

Réponses:


12

Oui, il y a une raison pour laquelle vous ne devriez pas l'utiliser pour l'ensemble du site. Certains navigateurs (selon la marque et la version) ne mettent pas en cache le contenu des demandes HTTPS sur le disque, ce qui peut sérieusement ralentir l'expérience de navigation pour les utilisateurs, car les actifs statiques seront chargés avec chaque demande de page (feuilles de style, javascript, images d'en-tête, etc.) . Par exemple, Mozilla déclare que:

"La mise en cache sur disque enregistre des copies des fichiers téléchargés sur le disque dur afin qu'ils n'aient pas besoin d'être téléchargés pour être réaffichés. Ces pages peuvent être consultées par toute personne autorisée à accéder au dossier de cache. Les pages transmises avec le cryptage SSL contiennent souvent des informations sensibles et la mise en cache de ces pages sur le disque peut présenter un risque de confidentialité. Cette préférence contrôle s'il faut mettre en cache sur le disque les pages qui ont été transmises avec le cryptage SSL. "

La façon dont les navigateurs individuels mettent en cache HTTPS est quelque peu contestée, mais il reste encore de bonnes chances que de nombreux utilisateurs verront la mise en cache du disque désactivée pour les demandes HTTPS.

Deuxièmement, HTTPS nécessite une " poignée de main " pour chaque demande et cela s'accompagne de frais généraux, ce qui affectera les performances et augmentera les demandes (généralement de quelques Ko seulement - mais c'est pour chaque demande et cela s'ajoute). HTTP KeepAlive peut limiter cela, mais c'est toujours une surcharge dont vous n'avez pas besoin pour le contenu non sécurisé.


2
Tout ici est vrai. Cependant, nous exploitons un site Web SSL complet depuis environ 5 ans maintenant et nous n'avons jamais reçu de plainte de nos utilisateurs. La plupart d'entre eux sont des sociétés ainsi sur IE6 et IE7 avec quelques-uns sur Firefox ces jours-ci. La mise en cache semblait bien fonctionner, mais nous avions des règles explicites d'expiration de contenu définies sur beaucoup d'images, je ne sais pas si cela faisait une différence.
Mark Henderson

5
Ne devinez pas: test :-). Une façon simple (quoique approximative et non complète à 100%) de vérifier si la mise en cache fonctionne est de vérifier les journaux de votre serveur pour les demandes des utilisateurs. Demandent-ils toutes les images / fichiers ou seulement le contenu non mis en cache? Les utilisateurs individuels sont de mauvais juges de la latence, mais lorsqu'ils sont agrégés, les millisecondes peuvent être visibles, donc je m'assurerais certainement que la vitesse est vraiment acceptable.
John Mueller

10

Si vous prévoyez d'exécuter SSL complet, assurez-vous que tous les services tiers hébergés que vous utilisez (serveur publicitaire, analytique, outils de partage, etc.) disposent de versions SSL, ou vous obtiendrez des avertissements de contenu mixtes sur certains navigateurs.


5

Un autre problème est que tout ce que vous servez à partir de n'importe quelle page doit alors passer par SSL, y compris les ressources tierces. Nous avons constaté que c'est un vrai problème avec quelque chose comme YouTube, par exemple. Étant donné que Google ne fait pas des vidéos YouTube disponible via SSL, cela signifie que toute vidéo YouTube vous ne souhaitez intégrer dans une page sur votre site fera l'avertissement « cette page contient du contenu sécurisé et non sécurisé ». Bien que cela soit subtil dans la plupart des navigateurs, il s'agit d'une énorme boîte de dialogue dans IE et peut amener certains utilisateurs à abandonner votre site assez rapidement, collant leurs données à leur poitrine de peur.


2

Vous devez également penser à la croissance. Une fois que vous avez plus d'un serveur Web, vous devrez décider: voulez-vous fournir HTTPS sur chaque serveur individuel, et si oui, utiliserez-vous le même certificat ou un certificat par serveur comme il est souvent recommandé. J'ai vu des configurations plus courantes où il y a moins de serveurs HTTPS car ils ne sont généralement utilisés que pour le traitement des détails sensibles et plus de serveurs HTTP car ceux-ci ont tendance à recevoir la majeure partie du trafic. HTTPS ajoute un peu plus de complexité à chacune de vos configurations. Juste quelque chose à garder à l'esprit.


1

À mon avis, la seule raison de ne pas utiliser HTTPS sur l'ensemble de votre site est que cela ralentira votre serveur et que les visiteurs auront une expérience de navigation légèrement plus lente. Cela étant dit, il y a des avantages. Plus précisément:

  1. Vous n'aurez jamais à vous soucier de mettre les données que vous souhaitez sécuriser sur n'importe quelle page de votre site. Tu ne peux pas oublier.
  2. Les utilisateurs remarqueront que votre site est entièrement crypté et peuvent se sentir plus en sécurité pour vous fournir leurs informations.
  3. Les utilisateurs savent que votre site Web appartient à votre entreprise et n'a pas été repris.

En plus de permettre à vos développeurs de ne pas se soucier d'afficher des données sécurisées sur une page non chiffrée, il n'y a vraiment aucune raison technique d'utiliser HTTPS sur chaque page. Par le même raisonnement, il y a très peu de raisons de ne pas le faire.


Autre raison de ne pas utiliser HTTPS sur l'ensemble du site ... plus de bande passante sera utilisée car les pages ne seront pas mises en cache côté client (théoriquement).
MrWhite

"Vous n'aurez jamais à vous soucier de mettre les données que vous souhaitez sécuriser sur n'importe quelle page de votre site." - Je ne sais pas si c'est vrai. Google indexera _et cache_ (!) Ces pages par défaut. Et si demandé, semble servir la version mise en cache en tant que HTTP simple.
MrWhite

0

Enfin et surtout, plusieurs employeurs n'aiment pas que leurs employés naviguent sur des sites https "chiffrés". C'est le cas des entreprises et des organisations de défense / sécurité, donc si vous avez un site Web «https uniquement», vous risquez de perdre certains de ces visiteurs / clients, car leur réseau ne les laissera tout simplement pas naviguer sur votre site.


En avez-vous des preuves? Pouvez-vous créer un lien vers des articles qui soutiennent cette affirmation?
Andrew Lott

J'ai mon expérience personnelle avec ce sujet. Je gère un grand site Web militaire et pendant que nous testions la configuration HTTPS, nous avons découvert que cela poserait un problème pour une grande partie de nos utilisateurs, simplement parce que leurs employeurs n'autorisent pas la navigation https depuis leur réseau (même les banques d'accès, wikipedia et d'autres sites via https est impossible). J'ai lancé un autre fil sur la façon d'aborder ce problème, lorsque Google est obligé de passer à https - ce n'est pas un problème que tout le monde connaît, mais cela pourrait arriver et les gens pourraient avoir besoin de le considérer.
Radek

Je m'explique que certains outils de surveillance doivent surveiller le "contenu" des paquets sur le proxy ou tout "homme du milieu" entre ces utilisateurs et sites Web, pour pouvoir surveiller les problèmes de sécurité, le secret ou autre, et utiliser les interdictions SSL cette surveillance. Ainsi, https n'est pas autorisé dans ces entreprises (je ne dis pas dans toutes, mais évidemment au moins dans certaines d'entre elles, oui)
Radek
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.