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

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?

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:

  • Google aide les webmasters à configurer leurs serveurs de manière plus sécurisée, mais utilise également HTTPS comme signal de classement .
  • Plus récemment, Google Chrome a commencé à marquer les sites HTTP comme non sécurisés , dans le cadre d'un plan à long terme visant à marquer tous les sites HTTP comme non sécurisés .
  • La conférence Mythbusting HTTPS de l' équipe Google Chrome Developers explique clairement son attitude.

• 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.

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.

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 .

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.

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.

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.

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.

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.

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.