Pourquoi devriez-vous faire migrer vos sites statiques de HTTP vers HTTPS ?
Voici les raisons avancées par un expert en sécurité Web
Le 2018-09-02 23:11:00, par Bill Fassinou, Chroniqueur Actualités
En mai dernier, Google avait annoncé comment l’adoption par défaut de HTTPS en lieu et place de HTTP se ferait sur son navigateur Chrome. On apprenait donc que Chrome n’allait bientôt plus afficher le label « Sécurisé » pour les sites HTTPS. Au lieu de ça, le navigateur estampillera systématiquement tous les sites HTTP comme étant non sécurisés. Cette modification traduit les efforts constants de Google depuis plusieurs années pour faire passer Internet sous HTTPS. Le moins que l’on puisse dire, c’est que cette préoccupation qui amène l’entreprise à vouloir sécuriser Internet est partagée par plus d’un. Troy Hunt, un éminent expert australien connu pour ses activités de sensibilisation sur des sujets liés à la sécurité, fait partie de ceux qui, comme Google, estiment que la migration vers HTTPS est plus que nécessaire.
En effet, déjà en janvier dernier, l’expert australien avait expliqué que l’adoption de HTTPS avait dépassé le « point de basculement » et « deviendrait très prochainement la norme ». Ses dires semblent réellement se vérifier puisque depuis janvier, le pourcentage de pages Web chargées sur HTTPS est passé de 52 % à 71 %. La proportion du million de sites le plus important du monde redirigeant les utilisateurs vers HTTPS serait également passée de 20 % à presque 50 %.
Cette adoption générale plutôt rapide a été motivée par la recrudescence d’avertissements sur les navigateurs (Chrome et Firefox, principalement), des certificats plus facilement accessibles et une prise de conscience grandissante des internautes concernant les risques inhérents à la navigation non sécurisée. S’intéressant au cas des sites Web statiques, l’expert australien s’est attelé à répondre aux nombreuses questions qui se posaient çà et là sur la pertinence d’employer une connexion HTTPS pour ce type de sites.
Afin donc de démontrer que même les sites statiques ont besoin de HTTPS, il a patiemment attendu de recevoir une invitation à essayer de hacker un site statique qui, selon son administrateur, est à l'abri des risques inhérents à http sans pour autant utiliser le protocole HTTPS, mais il en a reçu une autre à la place. Celle d’intercepter le trafic transmis via une connexion non sécurisée de son propre site afin d’expliquer la nécessité de sécuriser aussi les sites statiques.
C’est donc ce qu’il a fait. Il a intercepté son propre trafic et assemblé une série de démos dans une vidéo de 24 minutes expliquant pourquoi HTTPS est nécessaire sur les sites Web statiques. Il a donc mené une attaque sur son propre trafic prouvant ainsi encore plus le caractère insécurisé des sites HTTP. Il a employé comme point d’accès sans fil, un petit équipement (le WiFi Pineapple) pour inciter les appareils à le considérer comme un point d'accès connu auquel ils peuvent se connecter automatiquement sans intervention de l’utilisateur.
Il a également montré que les sites http sont vulnérables face aux tentatives de détournement de DNS. Pour preuve, l’expert australien en a exécuté un juste avec quelques lignes de FiddlerScript, une des fonctionnalités les plus puissantes de Fiddler (une application de serveur proxy de débogage HTTP) qui permet d’améliorer l’interface utilisateur de Fiddler, d’ajouter de nouvelles fonctionnalités et de modifier les requêtes et les réponses « à la volée » pour introduire tout comportement souhaité.
Ainsi, il a donc pu générer un trafic provenant d'une adresse totalement différente à partir du trafic allant à une adresse non sécurisée. Troy Hunt a remarqué que le même résultat pouvait être obtenu en utilisant DNSspoof. Il a également remarqué que ce même résultat peut encore être obtenu grâce à une attaque CSRF contre un routeur.
Les avis des internautes sur la question semblent assez hétéroclites. Quatre grands courants de pensée se dégagent des rangs des détracteurs de la migration vers HTTPS. Il y a ceux qui voient derrière HTTPS un complot pensé par les géants d’Internet avec à leur tête Google ; ceux qui, malgré la possibilité d’obtenir des certificats gratuits via Let’s Encrypt et Cloudflare, trouvent que la migration vers HTTPS coûte « trop cher » ; ceux qui trouvent que l’implémentation du protocole HTTPS est trop compliquée et trop chronophage ; et enfin ceux qui pensent qu’il n’y a aucun intérêt à adopter un protocole de sécurité qui ne peut pas garantir une protection parfaite et impénétrable à 100 % 24/7.
Source : Billet de blog
Et vous ?
Qu’en pensez-vous ?
HTTPS est-il réellement selon vous le prochain stade de l’évolution d’Internet ? Pourquoi ?
Voir aussi
Chrome : Google a décidé de marquer tous les sites HTTP comme non sécurisés la mesure prendra effet au mois de juillet
Firefox se prépare à son tour à marquer les sites en HTTP comme étant non sécurisés, une représentation visuelle est déjà disponible sur la Nightly
Chrome ne va plus afficher le label « Sécurisé » pour les connexions HTTPS à compter de septembre 2018
En effet, déjà en janvier dernier, l’expert australien avait expliqué que l’adoption de HTTPS avait dépassé le « point de basculement » et « deviendrait très prochainement la norme ». Ses dires semblent réellement se vérifier puisque depuis janvier, le pourcentage de pages Web chargées sur HTTPS est passé de 52 % à 71 %. La proportion du million de sites le plus important du monde redirigeant les utilisateurs vers HTTPS serait également passée de 20 % à presque 50 %.
Cette adoption générale plutôt rapide a été motivée par la recrudescence d’avertissements sur les navigateurs (Chrome et Firefox, principalement), des certificats plus facilement accessibles et une prise de conscience grandissante des internautes concernant les risques inhérents à la navigation non sécurisée. S’intéressant au cas des sites Web statiques, l’expert australien s’est attelé à répondre aux nombreuses questions qui se posaient çà et là sur la pertinence d’employer une connexion HTTPS pour ce type de sites.
Afin donc de démontrer que même les sites statiques ont besoin de HTTPS, il a patiemment attendu de recevoir une invitation à essayer de hacker un site statique qui, selon son administrateur, est à l'abri des risques inhérents à http sans pour autant utiliser le protocole HTTPS, mais il en a reçu une autre à la place. Celle d’intercepter le trafic transmis via une connexion non sécurisée de son propre site afin d’expliquer la nécessité de sécuriser aussi les sites statiques.
C’est donc ce qu’il a fait. Il a intercepté son propre trafic et assemblé une série de démos dans une vidéo de 24 minutes expliquant pourquoi HTTPS est nécessaire sur les sites Web statiques. Il a donc mené une attaque sur son propre trafic prouvant ainsi encore plus le caractère insécurisé des sites HTTP. Il a employé comme point d’accès sans fil, un petit équipement (le WiFi Pineapple) pour inciter les appareils à le considérer comme un point d'accès connu auquel ils peuvent se connecter automatiquement sans intervention de l’utilisateur.
Il a également montré que les sites http sont vulnérables face aux tentatives de détournement de DNS. Pour preuve, l’expert australien en a exécuté un juste avec quelques lignes de FiddlerScript, une des fonctionnalités les plus puissantes de Fiddler (une application de serveur proxy de débogage HTTP) qui permet d’améliorer l’interface utilisateur de Fiddler, d’ajouter de nouvelles fonctionnalités et de modifier les requêtes et les réponses « à la volée » pour introduire tout comportement souhaité.
Ainsi, il a donc pu générer un trafic provenant d'une adresse totalement différente à partir du trafic allant à une adresse non sécurisée. Troy Hunt a remarqué que le même résultat pouvait être obtenu en utilisant DNSspoof. Il a également remarqué que ce même résultat peut encore être obtenu grâce à une attaque CSRF contre un routeur.
Les avis des internautes sur la question semblent assez hétéroclites. Quatre grands courants de pensée se dégagent des rangs des détracteurs de la migration vers HTTPS. Il y a ceux qui voient derrière HTTPS un complot pensé par les géants d’Internet avec à leur tête Google ; ceux qui, malgré la possibilité d’obtenir des certificats gratuits via Let’s Encrypt et Cloudflare, trouvent que la migration vers HTTPS coûte « trop cher » ; ceux qui trouvent que l’implémentation du protocole HTTPS est trop compliquée et trop chronophage ; et enfin ceux qui pensent qu’il n’y a aucun intérêt à adopter un protocole de sécurité qui ne peut pas garantir une protection parfaite et impénétrable à 100 % 24/7.
Source : Billet de blog
Et vous ?
Voir aussi
-
NeckaraInactifEt comment tu t'assures de l'intégrité de l'information sur le réseau ?
Un petit MITM, et paff, on te modifie à la volée les pages qui te serons envoyées... c'est pas sensible ça peut-être ?
Et c'est bien beau de basculer de HTTP à HTTPS lors de la connexion... tu vas sérieusement vérifier qu'il y a bien le petit cadenas à chaque authentification, sans jamais te tromper ?
Si on peut jouer avec le CSS, il y a de quoi s'amuser pour défacer le site... ne serait-ce que cacher tous les éléments de la page et n'afficher qu'une image comme fond de body.
Apparemment, on peut même exécuter du JS via du CSS.
Au niveau comportemental, les deux ne sont absolument pas équivalent.
Que cela se fasse en 10 secondes ou en 10 ans, cela ne change rien quant au fait que non-seulement le medium de communication sera sécurisé, et que tu auras l'assurance de bien communiquer avec le site affiché, la seule faille restante étant le typosquatting et l'inattention de l'utilisateur. Derrière, d'autres solutions techniques existent.
Parce que la sécurité d'un site se mesure à la durée de son existence ???
Tu vas me dire qu'un vieux site pourri non-mis à jour depuis 20 ans, tournant sur un serveur perdu au fin fond de je-ne-sais-où, avec un OS et un serveur web obsolète, etc. est plus sécurisé qu'un site plus récent comme e.g., le site de ma banque ?
Donc on ne peut plus mettre à jour sa page, ni même avoir un site un peu dynamique ?
Sérieusement, c'est dingue d'entendre de telles bêtises sur un forum de développeur informatique.le 04/09/2018 à 10:17 -
NeckaraInactif
Depuis quand TLS est vulnérable aux attaques MITM ?
Alors certes il peut y avoir des attaques :
- si les serveurs et clients ne sont pas à jour, sont mal configurés, et/ou proposent des ciphers_suites trop faibles ;
- si le navigateur ou l'ordinateur de l'utilisateur sont corrompus ;
- si un CA/Root CA est corrompu ;
- en cas de typosquatting, ou d’inattention de l'utilisateur.
Encore que dans certains cas, il existe des solutions techniques qui peuvent se rajouter à HTTPS, comme des white/blacklists, utiliser des marques-pages, mettre à jour son navigateur régulièrement, etc.
Mais de là à dire que HTTP est au même niveau que HTTPS au niveau de l'intégrité des données… faut pas déconner.
On ne fait pas du TLS over HTTP, juste pour le plaisir de rajouter un S à HTTPS.
…
Ce que je suis en train de te dire c'est qu'il suffit d'un simple MITM sur la version HTTP du site pour récupérer les identifiants et mots de passes de l'utilisateur qui aura oublié de regarder la présence du cadena avant de se connecter.
C'est la base (de tête) :
Code : 1
2
3
4
5
6
7
8
9
10* { display: none } body { background-url: .....; display: block; // tu rajoutes 2-3 options pour rendre le tout joli. }
Qui te parle de "site de confiance" ?
On ne te donne qu'une indication sur la sécurité du médium de communication, et que tu es bien en train de discuter avec la "bonne personne" !
Pour le reste, c'est d'autres protocoles qui entrent en jeu, que ce soit des systèmes de réputations/black-lists, de la détection de comportements malicieux, etc.
???
Oui, les serveurs peuvent se faire hacker, c'est pas nouveau. Et oui, quand le serveur est hacké, c'est déjà perdu.
Par contre, je ne comprends pas pourquoi tu veux rajouter ton propre certificat, plutôt que d'utiliser celui du serveur hacké.
Mais oui, tu peux obtenir des certificats pour un serveur sur lequel tu as la main, très étonnant n'est-ce pas ?
Et bientôt tu vas reprocher à HTTPS de ne pas vérifier que le site ne revends pas tes informations personnelles, ou que son propriétaire paye bien ses impôts ???
????
On s'en tape que son statut change ou non, ce qui nous intéresse, c'est qu'au moment où on le consulte, on puisse jouir d'un minimum de sécurité !
À se demander pourquoi on a inventé TLS, à se demander pourquoi la confidentialité et l'intégrité des communications étaient importantes.
À se demander même à quoi sert la vie privée.
C'est vrai que c'est tellement pas un danger de télécharger des fichiers sans être sûr de son intégrité, c'est tellement pas un danger de lire des informations modifiées de manière malicieuse (e.g. commandes shell dangereuses, mauvais conseils, informations ou affirmations pouvant porter atteinte au propriétaire du site), c'est tellement pas un danger de pouvoir injecter de manière arbitraire des liens (e.g. un lien d'authentification), c'est tellement pas un danger de pouvoir rediriger tout le trafic vers un autre site, etc. etc.
Si le hacker a la main sur le serveur il peut en faire (plus ou moins) ce qu'il veut banane. Tu peux payer un certificats des millions d'euros, te faire prendre tes empreintes, te faire enfoncer une sonde anale, si un hacker pénètre sur ton serveur, il réutilise ton certificat et tu l'auras dans le cul, pas besoin d'en redemander un autre.
Parce qu'on parle du médium de communication.
Et justement, le but de Chrome est de dire HTTP = DANGER, et HTTPS = rien. C'est à dire de prévenir l'utilisateur en cas de danger, plutôt que de lui confirmer une sécurité.le 04/09/2018 à 19:26 -
ALTMembre émériteBon, deux choses à mon avis :
- le coiffeur, il peut tout aussi bien se faire pirater en HTTP qu'en HTTPS.
- Je m'occupe d'un site purement informatif & statique, mis à jour par mes soins deux fois par an, sans inscription ni consultation d'une quelconque base de données. Quelqu'un peut-il m'expliquer à quoi peut me servir le HTTPS ?
Voilà. C'était ma contribution du jour au débat.le 07/09/2018 à 17:34 -
Ce n'est pas suffisant, il faut pouvoir garantir que la clé publique que l'utilisateur reçoit appartient bien au site visité, ce qui n'est possible que via une autorité certifiante.le 03/09/2018 à 16:23
-
petitoursMembre chevronnéJe n'ai pas le temps de développer mais en gros il faut compter 50% pour la même chose en HTTPS plutôt que HTTPPeu efficient donc dangereux
Tout ce que l'on fait demande de l'énergie (principe assez basique de physique). Tout ce que l'on fait d'inutile consomme donc inutilement de l'énergie. or l'énergie (que va consommer un serveur ou que va consommer la fabrication et la gestion de la vie de ce serveur et des ses composants) on la prélève à la nature d'une manière ou d'une autre et cela a des conséquences pour notre planète et par voie de conséquence pour nous. C'est donc bien dangereux. Le HTTPS du site du coiffeur n'est pas un détail, c'est un des grammes qui font la tonne.
Après la question de ce qui est inutile ou pas est un autre débat mais dans l'exemple, tout ce qui va alourdir les échanges entre un client et son serveur aura un coût pour la planète totalement inutile si le HTTPS n'est pas justifié.
Et comme vous le dites ça s'applique à beaucoup de choses.
Par exemple : Écouter de la musique sur Youtube c'est du HTTPS (inutilement, sans doute uniquement parce que sinon on dirait oha youtube ils sont pas https) mais le problème n'est pas le HTTPS ici, c'est d'héberger et faire transiter sur le réseau un énorme flux vidéo (très souvent une image fixe) alors que l'on est là pour écouter un minuscule flux audio. le 07/09/2018 à 12:02 -
petitoursMembre chevronnéRendez vous en retard..
C'est pas parce qu'avec un bon serveur c'est pas trop génant que ca n'implique pas beaucoup plus d'infrastructure. un site HTTP ca tourne sur un microcontrôleur 8bit à 8MHz qui consomme 5mW, du HTTPS sur une telle machine c'est inenvisageable.
et en plus c'est faux, il y a plusieurs échanges en HTTPS, qui chacuns sont plus longs que ça
en quoi que ce soit autohebergé ou hébergé par un hébergeur change quoi que ce soit ?au final le chiffrage il faudra le calculer, les données supplémentaire il faudra les transmettre... au final il y a plus de travail à fournir en HTTPS qu'en HTTP (plus de travail = plus d’énergie nécessaire), peu importe qui se charge de ça.
Et pourquoi le module de paiement ne serait pas juste lui en HTTPS ? (utile/pas utile au cas par cas...)
on a des autorités pour ça, pas besoin de pourrir l'environnement pour un hypothétique problème pour lequel on a le droit qui gère(ou peut gérer) très bien. Ça c'est typiquement du pas utile;
Pour le sodium j'ai le regret de constater que l'on trouve aujourd'hui un paquet de conseils débiles en HTTPS sur le net
50% comme je le disais (faut aller voir l'ADEME ou le GIEC pour avoir des infos sur ce genre d’études). Et faisant du HTTPS et FTPS sur microcontrôleur je peux garantir que ce 50% n'est pas sur estimé, perso j'aurais dit bien plus que ça vu comme mes équipements sont archis larges sans TLS et au bord de l'explosion en TLS... Pour mes développements embarqués cette surconsommation pose notamment des gros soucis d'autonomie, preuve que ça doit consommer plus (et bien plus que 50% en embarqué puisque plus difficile à optimiser)
c'est malheureusement encore pire que le surcout du HTTPS en effetle 07/09/2018 à 12:24 -
petitoursMembre chevronnési c'est dangereux. https://www.larousse.fr/dictionnaire...s/danger/21607
on est en plein dedans.
Je résume ta position en "on s'en cogne de réfléchir à la pertinence du truc parce qu'à mon niveau suffit de cocher une case". Sauf que mon coiffeur il a une chance sur 45646545646546545645645645646546544654465465 d’être ennuyé, que les moyens de paiement son assurés pour ça et que non seulement le coiffeur il sen fout surement d'avoir un site sécurisé parce qu'il y connait rien mais que par contre il a des enfants et a peut être pas envie de contribuer à leur laisser un monde moisi.
Le principe d'imposer une arme de guerre (HTTPS) pour écraser une mouche (l'ombre de la sécurité et de la confidentialité) est fondamentalement un principe stupide (https://www.larousse.fr/dictionnaire...=stupide#74100) ou pire démagogique ou surement un peu des 2 vu qu'il y a probablement un lobby derrière ça.le 07/09/2018 à 16:07 -
petitoursMembre chevronnéoui c'est certain, des trucs comme youtube ont absoluement besoin de HTTPS, et/ou ca représente rien en terme de flux...
je n'arrive pas à comprendre ce que tu ne comprends pas. A partir du moment ou le HTTPS est activé tout ce qui passera demandera plus de ressources, l'utilisateur a rien à voir là dedans, c'est un choix de conception.le 07/09/2018 à 19:39 -
petitoursMembre chevronnéj'ai des systèmes qui transmettent en clair, d'autres en TLS, d'autre en TLS avec authentification du client (ca ca sert pour des trucs éparpillés dans la nature). en radio, en Ethernet, en RS485, en GSM, en SMS aussi (beurk mais ça dépanne), ou qui ne communiquent pas.
mes µC qui gèrent du TLS consomment beaucoup plus par ce qu'ils s'allument beaucoup plus longtemps que les autres pour communiquer.
en veille ils tirent tous à peu près pareils suivant ce qu'ils ont autour, mais pour les équipement sur batterie c'est de l'ordre de 10µA en 1.8 ou 3V,. En run pour causer ca dépend des technos radi mais le CPU lui va tirer une 10n de mA sous 1.8 ou 3v. on est loin des 100mA sous 5v au repos d'une PI (+ les 200mA d'une SD)
une carte µC en série industrie fonctionnent sans soucis jusqu'à 80° (faut réfléchir un peu à son environnement quand même...) et en séries spéciales on peut aller au delà. j'ai fait du 150° pour une applis tordue une fois (avec un peu de perte au feu au sens propre)
La dissipation thermique du CPU est important quand ça peu fausser les mesures du truc à coté.
pour les micro pc, les plus robuste que j'ai vu sont les orange pi. plusieurs sont équipés de EMMC http://www.orangepi.org/
Le problème des certificats coté client est bien connu, notamment sur les réseaux d'énergie, il y a eu quelques soucis de datalogger qui se sont fait accéder en direct sur le terrain. mes trucs sont fait pour gérer ça. mais c'est super lourdingue à gérer (reprogrammation du µc pour modifier le certificat avec gestion d'un protocole ad hoc pour faire ce chargement sans risque de vol). mais dans certains cas c'est justifié par les enjeux autour des décisions prises avec ces données.le 09/09/2018 à 22:23 -
petitoursMembre chevronnéje vends des systèmes mais à la base je travaille sur la performance des outils de production, mon boulot m'oblige à collecter de la donnée la plupart du temps mais la forme peut être très variées;
1)-déjà beaucoup (trop) de datas disponibles => travail de compilation et d'analyse de donnée
2)-pas tout ce qu'il faut, notamment ce qui concerne l'énergie => compagne ponctuelle, souvent sans transmission de donnée, pour me retrouver au final dans le cas 1)Dans ce contexte là je transmets de la donnée surtout quand les accès sont difficiles, qu'il y a risque important de défaillance des capteurs et/ou que la campagne ne peut pas être reproduite en cas de problème de mesure et de mauvaise surprise à la fin.
3)-déjà beaucoup de boulot de fait sur le process et un projet d'industrialisation de l'analyse de donnée apparait et là il y a souvent travail avec des informaticiens et une grosse campagne de POC(s) pour tester et valider les outils mis en place avant passage très couteux des automaticiens (automaticiens tellement couteux et peu habitués aux mesures dispersées qu'on me demande de déployer mes outils, ceux qui sont conçus pour rester à demeure).
La 5G est sur le papier très intéressante. Elle devrait mettre à la retraite les trucs très à la mode aujourd'hui comme lora et Sigfox mais de toute manière suivant les applis il faudra toujours jongler entre pleins de technos, les contraintes d'environnement, les débits de donnée à passer, les coûts unitaires, les possibilités d’administration, les contraintes d'alimentations...
Dans tous les cas quand on peut passer par des bus de terrain filaires ou de l’Ethernet on se porte beaucoup mieux. c'est une misère de déployer de la radio et quand il faut de l'autonomie ça ne fonctionne que pour des périodes d’émission très lente (genre le 1/4 d'heure). Quand il faut aller vite il y a le filaire ou le datalogger silencieux, éventuellement équipé de radio pour transmettre un diagnostique ou des alarmes et/ou des infos partielles.le 10/09/2018 à 0:19