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, mais pas de le mandater comme le font beaucoup de sites Web. Le responsable affirme que TLS doit être facultatif. Pourquoi?
Sur mon propre site Web, j'ai longtemps configuré TLS et HSTS obligatoires avec de longues périodes, et les suites de chiffrement les plus faibles sont désactivées. L'accès en texte clair est garanti d'être protégé par un HTTP 301 vers la version protégée par TLS. Est-ce que cela affecte négativement mon site Web?
Il y a plusieurs bonnes raisons d'utiliser TLS
(et seulement quelques raisons marginales de ne pas le faire).
- Si le site dispose d'une authentification, utilisez HTTP exposer pour voler des sessions et des mots de passe.
Même sur des sites statiques et simplement 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 a aidé les webmasters à configurer leurs serveurs de façon plus sécurisée, mais a également utilisé 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 pour marquer tous les sites HTTP comme non -sécurisé.
- La conférence Google Chrome Developers team Mythbusting HTTPS indique clairement leur attitude.
Le blog de sécurité de Mozilla a également annoncé Déprécier 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 au navigateur fonctionnalités pour les sites Web non sécurisés, en particulier les fonctionnalités qui présentent des risques pour la sécurité et la confidentialité des utilisateurs.
Il existe également plusieurs bonnes raisons d'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 ont des certificats racine installés. Le seul problème de compatibilité que j'ai vu depuis des années a été Android appareils et autorité de certification intermédiaire manquante as Android ne fait confiance qu'à root) Autorités de certification directement. 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 direct 301 Moved Permanently, par exemple pour garantir l'accès à partir de navigateurs ou d'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 HTTP Strict Transport Security (HSTS) 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 The Tor Project et Electronic Frontier Foundation et résolu par un multibrowser HTTPS Everywhere extension:
De nombreux sites sur le Web offrent une prise en charge limitée du cryptage via HTTPS, mais rendent son utilisation difficile. Par exemple, ils peuvent par défaut utiliser HTTP non chiffré ou remplir des pages chiffrées avec des liens qui renvoient au site non chiffré.
Le contenu mixte était également un énorme problème en raison d'éventuelles attaques XSS sur les sites HTTPS en modifiant JavaScript ou CSS chargé via une connexion HTTP non sécurisée. Par conséquent, de nos jours, tous les navigateurs traditionnels avertissent les utilisateurs des pages à contenu mixte et refusent de le charger automatiquement. Cela rend difficile la maintenance d'un site sans le 301 redirige 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 sont des marqueurs que votre site est géré par des professionnels auxquels on peut faire confiance pour savoir ce qu'ils font. Il s'agit d'une norme minimale émergente pour la fiabilité, comme en témoigne Google déclarant qu'ils fourniront un classement positif aux sites qui le font.
À l'autre extrémité, la compatibilité maximale. Il existe encore des clients plus âgés, en particulier dans des parties du monde qui ne sont pas les États-Unis, l'Europe ou la Chine. Le HTTP simple fonctionnera toujours (cependant, ne fonctionne pas toujours bien ; c'est une autre histoire).
TLS + HSTS: Optimiser pour le classement des moteurs de recherche
HTTP simple: Optimiser pour la compatibilité
Cela dépend de ce qui compte le plus pour vous.
Il existe une bonne raison pour laquelle les sites Web simples en lecture seule ne doivent pas utiliser HTTPS.
- Les caches Web ne peuvent pas mettre en cache les images transportées via HTTPS.
- Certaines parties du monde ont des connexions internationales à très bas débit, dépendent donc des caches.
- L'hébergement d'images d'un autre domaine nécessite des compétences que vous ne pouvez pas attendre des opérateurs des petits 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 quelques suppositions.
Dans les environnements d'entreprise, il est courant que le service informatique installe un pare-feu qui inspecte le trafic entrant et sortant pour détecter les logiciels malveillants, les activités suspectes de type CnC, le contenu jugé inapproprié pour le travail (par exemple, la pornographie), etc. Cela devient beaucoup plus difficile lorsque le trafic est crypté. Il y a essentiellement trois réponses possibles:
- Abandonnez la surveillance de ce trafic.
- Installez une autorité de certification racine sur les machines des utilisateurs afin de pouvoir effectuer le décryptage et l'inspection MitM.
- Bloquez le trafic crypté en gros.
Pour un administrateur système concerné, aucune de ces options n'est particulièrement intéressante. Il existe un grand nombre de menaces qui attaquent un réseau d'entreprise et il leur appartient de protéger l'entreprise contre elles. Cependant, le blocage d'un grand nombre de sites soulève entièrement la colère des utilisateurs et l'installation d'une autorité de certification racine peut sembler un peu compliquée, car elle introduit des considérations de confidentialité et de sécurité pour les utilisateurs. Je me souviens avoir vu (désolé, je ne trouve pas le fil) une pétition d'administrateur système reddit quand ils allumaient HSTS pour la première fois parce qu'il était exactement dans cette situation, et ne voulait pas bloquer tout reddit simplement parce qu'il était contraint par l'entreprise pour bloquer les subreddits axés sur le porno.
Les roues de la technologie continuent d'avancer, et vous trouverez beaucoup de gens qui soutiennent que ce type de protection est démodé et devrait être supprimé. Mais il y en a encore beaucoup qui le pratiquent, et c'est peut-être eux qui concernent votre mystérieux mainteneur.
Tout dépend de vos exigences de sécurité, du choix de l'utilisateur et du risque de rétrogradation implicite. La désactivation des anciens chiffrements côté serveur est largement nécessaire, car les navigateurs passeront volontiers à des chiffrements absolument horribles côté client au nom de l'expérience utilisateur/de la commodité. S'assurer que rien de la vôtre qui dépend sur un canal sécurisé pour l'utilisateur ne puisse ê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 pour HTTP non sécurisé lorsque j'ai jugé que votre article de blog expliquait pourquoi vous aimez Python plus que Ruby (ne dites pas que vous le faites) , juste un exemple générique) n'est pas quelque chose qui me dérange les fantômes ou le public sachant que j'ai accédé me gêne sans raison, en supposant que HTTPS sera trivial pour moi.
Il existe, aujourd'hui, des systèmes embarqués qui n'ont pas la capacité d'utiliser TLS prêts à l'emploi, ou d'autres qui sont bloqués sur d'anciennes implémentations (je pense que c'est terriblement mauvais 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 OpenBSD en amont sur HTTPS avec une implémentation TLS/SSL suffisamment ancienne. Vous ne pourrez pas. J'ai essayé l'autre jour sur un appareil avec une version OpenSSL plus ancienne de 2012 ou plus, parce que je voulais mettre à niveau ce système embarqué vers de nouveaux trucs plus sécurisés à partir de la source - je n'ai pas le luxe d'un package pré-construit. Les messages d'erreur lorsque j'ai essayé n'étaient pas exactement intuitifs, mais je suppose que c'était parce que mon ancien OpenSSL ne supportait pas les bonnes choses.
C'est un exemple où le passage du seul HTTPS peut réellement nuire aux gens: si vous n'avez pas le luxe des packages prédéfinis récents et que vous souhaitez résoudre le problème vous-même en créant à partir de la source, vous êtes verrouillé. Heureusement, dans le cas LibreSSL, vous pouvez revenir à la demande explicite de HTTP. Bien sûr, cela ne vous évitera pas qu'un attaquant réécrit déjà votre trafic, capable de remplacer les packages source par des versions compromises et de réécrire toutes les sommes de contrôle dans les corps HTTP décrivant les packages disponibles en téléchargement sur les pages Web que vous parcourez, mais cela reste utile dans la plupart des cas. cas plus courant.
La plupart d'entre nous ne sont pas à un téléchargement non sécurisé appartenant à un APT (Thread persistant avancé: jargon de sécurité pour les agences de renseignement nationales et autres cybermenaces extrêmement bien dotées en ressources). Parfois, je veux juste à wget une 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 une boîte qui ne prend pas en charge les suites de chiffrement les plus récentes.
Personnellement, je demanderais ceci: votre contenu est-il tel qu'une personne pourrait légitimement décider "Je suis d'accord avec moi pour avoir accès au domaine public"? Existe-t-il une possibilité plausible de risque réel pour les personnes non techniques de rétrograder accidentellement vers HTTP pour votre contenu? Évaluez vos exigences de sécurité, les exigences de confidentialité imposée à vos utilisateurs et le risque de déclassements implicites 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 encore de bons cas d'utilisation pour le HTTP simple.
Il y a beaucoup de discussions ici pour savoir pourquoi tls est bon - mais cela n'a jamais été demandé comme dans le message d'origine.
Maxthon a posé 2 questions:
1) Pourquoi un site aléatoire et non nommé a-t-il décidé de maintenir les présences http et https
2) Y a-t-il un impact négatif pour Maxthon qui ne sert 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 plusieurs raisons. En plus des points sur la compatibilité, la mise en cache distribuée et quelques conseils sur l'accessibilité géopolitique, il y a également une considération à propos de l'intégration de contenu et d'éviter les messages de navigateur laids concernant le contenu non sécurisé. Comme l'a souligné Alvaro, TLS n'est que la pointe de l'iceberg en matière de sécurité.
La deuxième question, cependant, est recevable. Exposer n'importe quelle partie de votre site de votre site Web via http alors qu'il nécessite réellement https pour un fonctionnement sécurisé fournit un vecteur exploitable pour les attaques. Cependant, il est logique de maintenir cela afin d'identifier où le trafic est mal dirigé vers le port 80 sur votre site et de corriger la cause. C'est à dire. il y a à la fois un impact négatif et la possibilité d'un impact positif, le résultat net dépend si vous faites votre travail en tant qu'administrateur.
Sysadmin1138 dit que https a un impact sur les classements de référencement. Alors que Google a déclaré que cela avait un impact sur les classements, les seules études fiables que j'ai vues suggèrent que la différence est petite. Cela n'est pas aidé par les gens qui devraient savoir mieux affirmant que, puisque les sites les mieux classés sont plus susceptibles d'avoir une présence https, une présence https donc améliore le classement.
Il y a très peu bon raisons d'utiliser HTTP au lieu de HTTPS sur un site Web. Si votre site Web gère des transactions de toute nature 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 décente que je verrais pour ne pas appliquer HTTPS est si votre site Web s'appuie 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 afin d'assurer la sécurité de votre site Web. Il est également possible que vos clients ne prennent pas en charge HTTPS, mais vraiment, en 2017, ils le devraient.
Ce n'est pas une raison bonne, car cela signifie que vous avez des clients défectueux/cassés/non sécurisés, mais s'il existe des processus automatisés accédant aux ressources via le http:// urls, il est possible que certains d'entre eux ne prennent même pas en charge https (par exemple busybox wget, qui ne prend pas en charge TLS en interne et l'a ajouté plus récemment via un processus enfant openssl) et se briserait s'ils ont reçu une redirection vers une URL https qu'ils ne peuvent pas suivre.
Je serais tenté de gérer cette possibilité en écrivant la règle de redirection pour exclure les chaînes inconnues (ou connues) de l'agent utilisateur de la redirection et de les laisser accéder au contenu via http si elles le souhaitent, afin que les navigateurs réels puissent tous bénéficier de https/hsts forcés.
Dans le passé, j'ai dû utiliser HTTP plutôt que HTTPS parce que je voulais <embed> les pages d'ailleurs qui ont elles-mêmes été diffusées via HTTP, et elles ne fonctionneront pas autrement.