Y a-t-il une raison de ne pas appliquer HTTPS sur un site Web?


49

Un site Web que je fréquente a finalement décidé d'activer TLS sur leurs serveurs, sans toutefois l'exiger de la même manière que beaucoup de sites Web. Le responsable affirme que TLS doit être facultatif. Pourquoi?

Sur mon propre site Web, j'ai depuis longtemps mis en place des TLS et HSTS obligatoires avec de longues périodes, et les suites de chiffrement plus faibles sont désactivées. L’accès au texte en clair est garanti contre un mur HTTP 301 vers la version protégée par TLS. Est-ce que cela affecte mon site web négativement?


12
Ils peuvent craindre que HSTS ne leur pose problème, si tout se passe bien (par exemple, leur autorité de certification gratuite cesse de délivrer des certificats ou est supprimée des magasins de confiance du navigateur en raison d'un problème). Avec l'écosystème TLS actuel, vous créez des dépendances aux autorités de certification approuvées / aux fournisseurs de navigateurs. Il est actuellement difficile à éviter et en vaut la peine, mais vous pouvez toujours voir cela comme un problème et ne pas appliquer HTTPS comme une solution pour rester indépendant au cas où quelque chose se produirait.
allo

quiconque veut mentionner l'exigence de TLS pour H2, qui est beaucoup plus rapide que http1.1. bon pour vous faire hsts, j'ai récemment envoyé mon site pour la liste de précharge hsts, j'espère que je peux simplement désactiver le port 80 tous ensemble
Jacob Evans


4
@gerrit Cet argument ne tient pas devant les autorités de certification gratuites et peu coûteuses telles que Let's Encrypt.
Maxthon Chan

1
Let's Encrypt ne fonctionne pas avec tous les hôtes et ce n'est pas aussi simple que d'utiliser un meilleur hôte. J'utilise App Engine qui n'est pas (directement) pris en charge pour des raisons techniques.
Carl Smith

Réponses:


8

Il y a plusieurs bonnes raisons d'utiliser TLS

(et seulement quelques raisons marginales de ne pas le faire).

  • Si le site est authentifié, utilisez HTTP exposer pour voler des sessions et des mots de passe.
  • Même sur des sites statiques, purement informatifs, l’utilisation de TLS garantit que personne n’a altéré les données.

  • Depuis Google I / O 2014 , Google a pris plusieurs mesures pour encourager tous les sites à utiliser HTTPS:

  • Le blog de sécurité de Mozilla a également annoncé l' élimination de HTTP non sécurisé en rendant toutes les nouvelles fonctionnalités disponibles uniquement pour les sites Web sécurisés et en supprimant progressivement l'accès aux fonctionnalités de navigateur pour les sites Web non sécurisés, en particulier les fonctionnalités présentant des risques pour la sécurité et la confidentialité des utilisateurs .

Il existe également plusieurs bonnes raisons pour appliquer TLS

Si vous avez déjà un certificat largement approuvé, pourquoi ne pas toujours l'utiliser? Pratiquement tous les navigateurs actuels prennent en charge TLS et disposent de certificats racine. Les seuls problèmes de compatibilité que je connaisse depuis des années concernent les appareils Android et une autorité de certification intermédiaire manquante car Android ne fait confiance que directement aux autorités de certification racines. Cela peut facilement être évité en configurant le serveur pour renvoyer la chaîne de certificats à l'autorité de certification racine.

Si votre responsable souhaite toujours autoriser les connexions HTTP sans connexion directe 301 Moved Permanently, par exemple pour assurer l'accès depuis des navigateurs ou des appareils mobiles très anciens, le navigateur n'a aucun moyen de savoir que vous avez même configuré HTTPS . De plus, vous ne devez pas déployer de sécurité HTTP HSTS (Transport Strict Transport) sans 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Le problème des différents sites configurés pour les deux protocoles est reconnu par le projet Tor et l’ Electronic Frontier Foundation et est traité par une extension multi-navigateur HTTPS Everywhere :

De nombreux sites Web offrent une prise en charge limitée du cryptage sur HTTPS, mais rendent son utilisation difficile. Par exemple, ils peuvent utiliser par défaut HTTP non crypté ou remplir les pages cryptées avec des liens renvoyant au site non crypté.

Le contenu mixte constituait également un énorme problème en raison d'attaques XSS possibles sur des sites HTTPS via la modification de JavaScript ou de CSS chargés via une connexion HTTP non sécurisée. C'est pourquoi tous les navigateurs traditionnels avertissent les utilisateurs des pages avec un contenu mixte et refusent de le charger automatiquement. Cela rend difficile la maintenance d'un site sans les 301redirections sur HTTP: vous devez vous assurer que chaque page HTTP ne charge que le contenu HTTP (CSS, JS, images, etc.) et que chaque page HTTPS ne charge que le contenu HTTPS. C'est extrêmement difficile à réaliser avec le même contenu sur les deux.


If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, HSTS is the correct choise as it only enforces HTTPS when it is clear that the browser supports itmais dans ce cas, le client (même compatible HTTPS) ne saura jamais de la version HTTPS, car ils chargent HTTP initialement.
Cthulhu le

Concernant votre dernier paragraphe: l’en-tête HSTS est ignoré lors d’une connexion non HTTPS.
Cthulhu

1
HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-14.txt
Cthulhu le

Merci d'avoir signalé mon faux indice, Cthulhu! Inspiré de cela, j'ai apporté des améliorations majeures à ma réponse. S'il vous plaît soyez bienvenu pour être également critique envers le nouveau contenu. :)
Esa Jokinen

62

De nos jours, TLS + HSTS indiquent que votre site est géré par des professionnels à qui on peut faire confiance pour savoir ce qu'ils font. Il s’agit d’une norme minimale émergente en matière de fiabilité, comme en témoigne Google indiquant qu’elle fournira un classement positif pour les sites qui le font.

De l'autre côté est la compatibilité maximale. Il existe encore des clients plus âgés, en particulier dans des régions du monde autres que les États-Unis, l'Europe et la Chine. Un simple HTTP fonctionnera toujours (mais pas toujours bien ; c'est une autre histoire).

TLS + HSTS: optimise le classement dans les moteurs de recherche
. HTTP simple: optimise la compatibilité.

Cela dépend de ce qui compte le plus pour vous.


16
C'est peut-être moi qui suis difficile, mais cette première phrase semble un peu exagérée: un site https ne dit rien sur le professionnalisme ou la fiabilité des personnes en charge. Un site peut être https et toujours être développé / géré par des personnes qui ne nettoient pas les entrées, ce qui rend le site vulnérable à l'injection SQL ou XSS; ou il peut s'agir de https et être invalide, inaccessible ou non utilisable.
Alvaro Montoro

34
L'utilisation de HTTPS n'est pas une garantie de professionnalisme, mais son absence indique certainement le contraire.
Esa Jokinen

8
L'utilisation de TLS et de HSTS sont des signaux, faisant partie d'un ensemble beaucoup plus vaste, que le site peut valoir d'être lus. Contrairement à d'autres solutions, il est très facile de tester la présence de , ce qui explique pourquoi Google l'utilise comme proxy pour le reste.
sysadmin1138

3
@Braiam Stack Exchange est en cours de migration vers https uniquement et commencera à utiliser hsts sous peu. Le protocole HTTP est toujours disponible, non pas pour des raisons de compatibilité, mais parce qu'ils sont lents et prudents et qu'il est techniquement difficile de migrer.
captncraig

4
@esajohnson - le manque de https ne montre pas le manque de professionnalisme. Cela montre qu'il n'y a pas de "besoin" pour cela. Par exemple, un miroir CentOS.
Warren

30

Il existe une bonne raison pour que les sites Web en lecture seule n'utilisent pas HTTPS.

  • Les caches Web ne peuvent pas mettre en cache les images transportées via HTTPS.
  • Certaines régions du monde ont des connexions internationales à très basse vitesse, alors dépendez des caches.
  • L'hébergement d'images d'un autre domaine requiert des compétences que vous ne pouvez pas attendre des opérateurs de sites Web en lecture seule .

1
Le contenu en lecture seule peut être déployé sur CDN si vous ciblez ces pays. Le CDN reflète le contenu statique en utilisant leurs propres moyens et le sert toujours via HTTPS. CDN peut être assez facile à trouver et, pour les petits sites Web, pas si coûteux à utiliser.
Maxthon Chan

8
@ MaxthonChan, essayez d'expliquer à ma mère ce qu'est un CDN ..... Cependant, elle peut créer un site Web avec les heures des services de l'église locale.
Ian Ringrose

6
@ MichaelHampton comment un cache peut-il lire l'image d'un flux HTTPS sans disposer des clés de description? Et feriez-vous confiance à un FAI avec vos clés?
Ian Ringrose

8
Vous devriez préciser les caches dont vous parlez.
Michael Hampton

2
@IanRingrose Si votre mère crée un site Web avec des informations sur le service de l'église locale, il est peu probable qu'un comportement de mise en cache sur des connexions internationales entre en jeu, à moins que ce ne soit une église très populaire.
Jason C

14

Le responsable affirme que TLS doit être facultatif. Pourquoi?

Pour vraiment connaître la réponse à cette question, vous devez leur demander. Nous pouvons cependant faire des suppositions.

Dans les environnements d'entreprise, il est courant que les services informatiques installent un pare-feu qui inspecte le trafic entrant et sortant pour détecter les programmes malveillants, les activités suspectes de type CnC, le contenu jugé inapproprié pour le travail (pornographie, par exemple), etc. Cela devient beaucoup plus difficile lorsque le trafic est crypté. Il y a essentiellement trois réponses possibles:

  1. Abandonnez la surveillance de ce trafic.
  2. Installez une autorité de certification racine sur les ordinateurs des utilisateurs afin de pouvoir effectuer le déchiffrement et l'inspection MitM.
  3. Bloquer le trafic crypté.

Pour un administrateur système concerné, aucune de ces options n'est particulièrement attrayante. Un grand nombre de menaces s’attaquent à un réseau d’entreprise et il leur incombe de protéger l’entreprise contre elles. Cependant, le blocage d'un grand nombre de sites soulève entièrement l'ire des utilisateurs, et l'installation d'une autorité de certification racine peut sembler un peu délicate, car elle introduit des considérations de confidentialité et de sécurité pour les utilisateurs. Je me souviens d’avoir vu (désolé, je ne trouve pas le fil) une pétition sysadmin reddit la première fois qu’ils allumaient HSTS parce qu’il était exactement dans cette situation et qu’il ne voulait pas bloquer tout Reddit simplement parce qu’il était contraint par l’entreprise. bloquer les subreddits axés sur le porno.

Les rouages ​​de la technologie ne cessent de tourner, et vous en trouverez de nombreux qui soutiennent que ce type de protection est démodé et devrait être supprimé progressivement. Mais il y en a encore beaucoup qui le pratiquent, et peut-être que ce sont eux qui intéressent votre mystérieux mainteneur.


que diriez-vous de terminer SSL sur le serveur frontal / équilibreur de charge / similaire et de journaliser le trafic par la suite?
eis

1
@ eis Cela suppose que la société contrôle chaque site Web visité par les employés, ce qui est peu probable. Le message ne semble pas concerner TLS sur un site intranet.
Xiong Chiamiov

5

Tout dépend de vos exigences en matière de sécurité, du choix de l'utilisateur et du risque de déclassement implicite. Désactiver les anciens chiffrements côté serveur est en grande partie nécessaire, car les navigateurs vont heureusement tomber sur des chiffrements absolument horribles côté client au nom de l'expérience utilisateur / de la commodité. S'assurer que rien de votre part qui dépend d'un canal sécurisé à l'utilisateur ne peut être atteint avec une méthode non sécurisée est, bien sûr, également très sain.

Ne pas me permettre de rétrograder explicitement en HTTP non sécurisé lorsque j'ai estimé que votre article de blog expliquant pourquoi vous aimez plus Python que Ruby (ne le dites pas, c'est juste un exemple générique) ne me dérange pas des spooks ou du public. Le problème auquel je me suis rendu est juste de me mettre sur mon chemin sans raison valable, en partant du principe que HTTPS sera trivial pour moi.

Il existe aujourd'hui des systèmes embarqués qui ne sont pas capables d'utiliser TLS par défaut ou qui sont bloqués par de vieilles implémentations (je pense que c'est terriblement dommage que ce soit le cas, mais en tant qu'utilisateur expérimenté de [insert embedded appareil ici], je ne peux parfois pas changer cela).

Voici une expérience amusante: essayez de télécharger une version récente de LibreSSL à partir du site amont d'OpenBSD via HTTPS avec une implémentation TLS / SSL suffisamment ancienne. Vous ne pourrez pas. L’autre jour, j’ai essayé sur un appareil doté d’une version plus ancienne d’OpenSSL datant de 2012 environ, car je souhaitais mettre à niveau ce système embarqué pour le rendre plus sécurisé, avec de nouveaux éléments de la source. Je n’ai pas le luxe d’un package préconfiguré. Les messages d'erreur lorsque j'ai essayé n'étaient pas vraiment intuitifs, mais je suppose que c'était parce que mon ancien OpenSSL ne prenait pas en charge les éléments appropriés.

Ceci est un exemple où le déplacement du seul système HTTPS peut réellement nuire aux personnes: si vous n'avez pas le luxe de bénéficier de packages pré-construits récents et que vous souhaitez résoudre le problème vous-même en générant à partir des sources, vous êtes bloqué. Heureusement, dans le cas de LibreSSL, vous pouvez demander explicitement à HTTP. Bien sûr, cela ne vous évitera pas un attaquant réécrivant déjà votre trafic, capable de remplacer les paquets source par des versions compromises et de réécrire toutes les sommes de contrôle dans des corps HTTP décrivant les paquets disponibles au téléchargement sur les pages Web que vous parcourez, mais cela reste utile dans la plupart des cas. cas plus commun.

La plupart d’entre nous ne sont pas à un téléchargement non sécurisé d’être détenu par un APT (Advanced Persistent Thread: jargon de sécurité pour les agences de renseignement nationales et autres cyber-menaces extrêmement bien dotées). Parfois, je veux juste wgetune documentation en texte brut ou un petit programme dont je peux rapidement auditer la source (mes propres petits utilitaires / scripts sur GitHub, par exemple) sur un boîtier ne prenant pas en charge les suites de chiffrement les plus récentes.

Personnellement, je demanderais ceci: votre contenu est-il tel qu'une personne puisse légitimement décider "Je suis d'accord pour que je puisse accéder à la connaissance publique"? Existe-t-il un risque plausible de risque réel pour les personnes non techniques qui rétrogradent accidentellement HTTP vers votre contenu? Pondérez vos exigences de sécurité, les exigences de confidentialité imposées pour vos utilisateurs et le risque de rétrogradation implicite par rapport à la capacité des utilisateurs qui comprennent les risques de faire un choix éclairé au cas par cas de ne pas être sécurisés. Il est tout à fait légitime de dire que pour votre site, il n'y a aucune bonne raison de ne pas appliquer HTTPS - mais je pense qu'il est juste de dire qu'il existe toujours de bons cas d'utilisation pour le HTTP simple.


1
"essayez de télécharger une version récente de LibreSSL à partir du site amont d'OpenBSD via HTTPS avec une implémentation TLS / SSL suffisamment ancienne" Inversement, essayez de télécharger un navigateur récent avec un navigateur suffisamment ancien, par exemple celui qui implémente uniquement HTTP / 1.0 sans support pour l'en- Host:tête. Ou essayez de surfer sur des sites modernes avec un navigateur Web qui ne supporte que le Javascript de 2001. À un moment donné, notre communauté doit passer à autre chose, ce qui, malheureusement, casse des problèmes pour certains. La question devient alors: la valeur ajoutée en vaut-elle la peine?
un CVn

@ MichaelKjörling Ce sont aussi des problèmes, de gravité variable. J'ajouterai les versions récentes du compilateur à cette liste. Certains sont plus défendables que d'autres. Je ne sais pas si vous exprimez un désaccord ou pourquoi, dans la deuxième phrase de mon message, je suis d'accord pour dire qu'il est justifié d'empêcher les anciens chiffrements sur une connexion HTTPS de protéger la plupart des utilisateurs contre les attaques par dégradation ". d autrement n’avoir aucune visibilité significative ou défense contre. (Je ne pense pas que la plupart des sites Web modernes qui ne parviennent pas à se dégrader gracieusement soient aussi justifiés à distance, mais c'est un peu à côté du
problème

@ MichaelKjörling Pour clarifier, le point soulevé est qu'il s'agissait d'un exemple d' avantage évident de fournir un HTTP simple à l'utilisateur, ce qui était le point central de la question à laquelle il répondait. Ce n’était en aucun cas de jeter un éclairage négatif sur les projets OpenBSD / LibreSSL, pour lesquels j’ai beaucoup de respect. Je pensais que la deuxième phrase du premier paragraphe aurait exclu une telle interprétation négative. Si vous pensez que cela n’est pas clair ou que l’on pourrait mieux le formuler, n'hésitez pas à modifier ma réponse ou à suggérer des améliorations.
mtraceur

3

Il y a beaucoup de discussions ici pour savoir pourquoi cela est bon - mais cela n'a jamais été demandé comme dans le post original.

Maxthon a posé 2 questions:

1) pourquoi a-t-il décidé de maintenir à la fois les présences http et https sur un site aléatoire sans nom?

2) Existe-t-il un impact négatif pour Maxthon ne servant que 301 réponses aux requêtes http?

En ce qui concerne la première question, nous ne savons pas pourquoi les fournisseurs ont choisi de conserver les sites http et https. Il peut y avoir beaucoup de raisons. Outre les points relatifs à la compatibilité, à la mise en cache distribuée et à quelques indications sur l'accessibilité géopolitique, il convient également de prendre en compte l'intégration de contenu et d'éviter les messages laids du navigateur à propos du contenu non sécurisé. Comme Alvaro l'a fait remarquer, TLS n'est que la partie visible de l'iceberg en matière de sécurité.

La deuxième question, cependant, est répondable. Exposer une partie de votre site Web via http lorsque cela nécessite réellement https pour un fonctionnement sécurisé fournit un vecteur exploitable pour les attaques. Cependant, il est judicieux de le conserver afin d'identifier les endroits où le trafic est dirigé de manière incorrecte vers le port 80 de votre site et de résoudre le problème. En d'autres termes, il existe à la fois un impact négatif et une opportunité d'avoir un impact positif. Le résultat net dépend de si vous faites votre travail en tant qu'administrateur.

Sysadmin1138 indique que https a un impact sur le classement SEO. Alors que Google a déclaré que cela affectait les classements, les seules études fiables que j'ai vues suggèrent que la différence est minime. Cela n’aide pas les gens qui devraient mieux savoir prétendre que, puisque les sites classés au premier rang sont plus susceptibles d’avoir une présence https, une présence https améliore donc le classement.


1

Dans le passé, je devais utiliser HTTP plutôt que HTTPS parce que je voulais des <embed>pages d’ailleurs qui avaient elles-mêmes été servies via HTTP, sans quoi elles ne fonctionneraient.


Vous pouvez utiliser votre serveur pour inverser le proxy d’une version SSL.
Maxthon Chan

1

Ce n'est pas une bonne raison, car cela signifie que vous avez des clients défectueux / cassés / insécurisés, mais si des processus automatisés accèdent aux ressources via les http://URL existantes , il est possible que certains d'entre eux ne prennent même pas en charge le protocole https (par exemple, busybox wget, qui ne 't as support TLS en interne et l'a seulement ajouté plus récemment via un processus enfant openssl) et se briserait si on leur donnait une redirection vers une URL https qu'ils ne pouvaient pas suivre.

Je serais tenté de traiter cette possibilité en écrivant la règle de redirection pour exclure la redirection des chaînes d’agent utilisateur inconnues (ou connues), et leur permettre d’accéder au contenu via http si elles le souhaitent, afin que les navigateurs actuels puissent en tirer parti. https / hsts forcés.


1
Rappelez-moi il y a combien de décennies un outil bien entretenu (par exemple, wget) ne prenait pas en charge HTTPS?
Oleg V. Volkov

@ OlegV.Volkov: Je pense que vous avez manqué le mot busybox dans ma réponse.
R ..

Vérifié - bien, maintenant je vois. Je ne comprends pas vraiment pourquoi alors ne peut pas juste construire ce foutu truc et ensuite ne pas empaqueter des outils de construction, mais peu importe. En y repensant, je me suis également souvenu de cas plus fréquents où les utilisateurs étaient limités à des outils déshabillés ou obsolètes et il serait bien d’avoir un protocole HTTP simple. Pourriez-vous s'il vous plaît réparer les majuscules afin que je puisse rétablir le vote après modification également?
Oleg V. Volkov

1

Il existe très peu de bonnes raisons d'utiliser HTTP au lieu de HTTPS sur un site Web. Si votre site Web traite des transactions de tout type ou stocke tout type de données sensibles ou personnelles, vous devez absolument utiliser HTTPS si vous souhaitez que ces données soient sécurisées. La seule raison valable que je verrais pour ne pas appliquer HTTPS est si votre site Web repose sur la mise en cache, car HTTPS ne fonctionne pas avec la mise en cache. Cependant, il vaut souvent la peine de sacrifier un peu de performance pour assurer la sécurité de votre site web. Il est également possible que vos clients ne prennent pas en charge le protocole HTTPS, mais en réalité, en 2017, ils le devraient.

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.