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 , 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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de 23JFK 23JFK - Membre expérimenté https://www.developpez.com
le 03/09/2018 à 14:09
Google & co vont nous faire le même coup qu'avec Map, gratuit jusqu'au jour ou il faudra payer un bras pour continuer à avoir accès au service.
Avatar de archqt archqt - Membre actif https://www.developpez.com
le 03/09/2018 à 15:46
Pourquoi y a besoin d'une service de certification ? Il suffit juste que le site donne à l'utilisateur la clé publique et ensuite quand l'utilisateur (le navigateur donc) dialogue avec le site, celui-ci utilise la clé privée pour retrouver es informations en clair et "amorcer" ensuite un dialogue en clé symétrique ?
Avatar de John Bournet John Bournet - Membre éclairé https://www.developpez.com
le 03/09/2018 à 16:23
Citation Envoyé par archqt Voir le message
Pourquoi y a besoin d'une service de certification ? Il suffit juste que le site donne à l'utilisateur la clé publique et ensuite quand l'utilisateur (le navigateur donc) dialogue avec le site, celui-ci utilise la clé privée pour retrouver es informations en clair et "amorcer" ensuite un dialogue en clé symétrique ?
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.
Avatar de archqt archqt - Membre actif https://www.developpez.com
le 03/09/2018 à 18:24
Citation Envoyé par John Bournet Voir le message
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.
Pour éviter l'attaque "Man In The Middle" je suppose
Avatar de pvincent pvincent - Membre confirmé https://www.developpez.com
le 04/09/2018 à 8:33
En somme, on en revient à l'époque de Jane Austen (https://fr.wikipedia.org/wiki/Jane_Austen) quand deux personnes de la bonne société ne pouvaient pas entrer en conversation l'une avec l'autre avant d'avoir été présentées par une troisième de confiance (lire à ce sujet Northanger Abbey). Évidemment, c'est avec beaucoup d'ironie que la célèbre romancière évoque cette règle si souvent violée.
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 04/09/2018 à 8:51
Sinon la solution est d'identifier/désigner l'interlocuteur par sa clé publique.

C'est à dire qu'on ne parle pas, e.g. à google.com, mais à, e.g., 0x123456789ABCDEF.
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 04/09/2018 à 9:18
je suis d'accord avec Dave (Winer, pas le chanteur...encore qui lui non plus ne dit pas que des conneries mine de rien)

il y a des tas de sites qui ne nécessitent pas HTTPS alors que HTTPS implique des ressources supplémentaires tant au niveau client qu'au niveau serveur (soyons un peu écolo tant qu'à faire)

évidemment, un site qui propose des données sensibles doit utiliser HTTPS, cela va de soit.

mais il existe aussi des tas de sites qui n'ont pas de données sensibles, et même des données publiques...prenons un exemple au hasard: Wikipedia...C'est une encyclopédie en ligne totalement libre, elle pourrait sans problème être en HTTP...ah oui je vous vois venir, mais non il y a des mots de passe, et n'importe qui pourrait modifier les pages (ça c'est un peu le but) en se faisant passer pour quelqu'un d'autres (ça c'est moins bien) en sniffant le réseau pour capter son mot de passe (en effet).

Sauf que combien d'entre vous ont un compte sur Wikipedia (moi j'en ai un) ? Combien de fois consultez vous Wikipedia sans vous connecter à votre compte (99% du temps dans mon cas)....rien n'empêche Wikipedia de fonctionner en HTTP en lecture seule et de basculer en HTTPS pour les mises à jour. Ce n'est pas un travail supplémentaire, c'est le même site, il suffit que le module d'authentification s'assurer qu'on est sur du HTTPS et le tour est joué, ça tient en deux lignes de code.

Le navigateur pourrait aussi s'assurer que les ressources HTTP et HTTPS soient isolées afin de pouvoir mettre toutes les ressources statiques en HTTP (images, CSS, ...) et les données vives et sensibles en HTTPS (html, js) en laissant évidement le choix au développeur de savoir ce qui est sensible et ce qui ne l'est pas.

Et de façon générale, l'affirmation de Dave la plus vraie et que mettre un panneau "DANGER" sur un site HTTP est tout aussi absurde que mettre "SECURE" sur un site HTTPS....notamment depuis l'existence de Let's Encrypt qui permet d'avoir un certificat valide pour un site web quelconque en 10 secondes montre en main (et je sais de quoi je parle). Et taguer "DANGER" sur tous les sites HTTP historiques qui sont en ligne depuis 20 ans est tout aussi absurde...si Google veux sécuriser ces sites (qu'il indexe déjà), qu'il en prenne une empreinte, si celle-ci ne bouge pas, c'est qu'il est tout aussi secure qu'avant.
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 04/09/2018 à 10:17
Citation Envoyé par Paul TOTH Voir le message
rien n'empêche Wikipedia de fonctionner en HTTP en lecture seule et de basculer en HTTPS pour les mises à jour.
Et 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 ?

Citation Envoyé par Paul TOTH Voir le message
Le navigateur pourrait aussi s'assurer que les ressources HTTP et HTTPS soient isolées afin de pouvoir mettre toutes les ressources statiques en HTTP (images, CSS, ...) et les données vives et sensibles en HTTPS (html, js) en laissant évidement le choix au développeur de savoir ce qui est sensible et ce qui ne l'est pas.
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.

Citation Envoyé par Paul TOTH Voir le message
Et de façon générale, l'affirmation de Dave la plus vraie et que mettre un panneau "DANGER" sur un site HTTP est tout aussi absurde que mettre "SECURE" sur un site HTTPS....
Au niveau comportemental, les deux ne sont absolument pas équivalent.

Citation Envoyé par Paul TOTH Voir le message
notamment depuis l'existence de Let's Encrypt qui permet d'avoir un certificat valide pour un site web quelconque en 10 secondes montre en main (et je sais de quoi je parle).
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.

Citation Envoyé par Paul TOTH Voir le message
Et taguer "DANGER" sur tous les sites HTTP historiques qui sont en ligne depuis 20 ans est tout aussi absurde...
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 ?

Citation Envoyé par Paul TOTH Voir le message
si Google veux sécuriser ces sites (qu'il indexe déjà), qu'il en prenne une empreinte, si celle-ci ne bouge pas, c'est qu'il est tout aussi secure qu'avant.
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.
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 04/09/2018 à 18:02
Citation Envoyé par Neckara Voir le message
Et comment tu t'assures de l'intégrité de l'information sur le réseau ?
de la même façon qu'en HTTPS qui ne préserve pas de l'attaque MIM

Citation Envoyé par Neckara Voir le message
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 ?
comme en HTTPS

Citation Envoyé par Neckara Voir le message
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 ?
ce n'est pas un choix de l'utilisateur, mais du serveur

Citation Envoyé par Neckara Voir le message
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.
tu me fais une démonstration ?

Citation Envoyé par Neckara Voir le message
et HTTPS ne t'en préserve pas non plus

Citation Envoyé par Neckara Voir le message
Au niveau comportemental, les deux ne sont absolument pas équivalent.
mais HTTPS n'a jamais voulu dire "site de confiance" !

Citation Envoyé par Neckara Voir le message
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.
sauf que si je hack un site, il me faut 10 secondes pour activer mon propre certificat dessus et détourner www.nabamque-en-ligne.com sur ce faut site sans le moindre warning HTTPS.

Citation Envoyé par Neckara Voir le message
Parce que la sécurité d'un site se mesure à la durée de son existence ???
un site qui n'a pas bougé depuis 20 ans, il est sur depuis 20 ans, ou pas, mais ce statut n'a pas changé.

Citation Envoyé par Neckara Voir le message
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 ?
je n'ai pas dit que HTTPS ne permettait pas de faire des sites sûr, je dis que les sites HTTP ne sont pas des dangers potentiels (tout comme les cookie ne te sautent pas à la gorge)

Citation Envoyé par Neckara Voir le message
Donc on ne peut plus mettre à jour sa page, ni même avoir un site un peu dynamique ?
ah mais c'est pas moi qui déclare que HTTP est un danger mortel

Citation Envoyé par Neckara Voir le message
Sérieusement, c'est dingue d'entendre de telles bêtises sur un forum de développeur informatique.
ce qui serait bien c'est d'avancer des éléments techniques probants...HTTPS ne permet pas de s'assurer de la nature du site sécurisé, uniquement qu'il possède un certificat, et Let's Encrypt s'assure simplement que le demandeur est en mesure de mettre à jour le site...ce que sait faire tout hacker par définition.

Du coup dire HTTP = DANGER, HTTPS = SECURE c'est trop binaire pour refléter la réalité.
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 04/09/2018 à 19:26
Citation Envoyé par Paul TOTH Voir le message
de la même façon qu'en HTTPS qui ne préserve pas de l'attaque MIM
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.

Citation Envoyé par Paul TOTH Voir le message
ce n'est pas un choix de l'utilisateur, mais du serveur


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.

Citation Envoyé par Paul TOTH Voir le message
tu me fais une démonstration ?
C'est la base (de tête) :
Code : Sélectionner tout
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.
}
Citation Envoyé par Paul TOTH Voir le message
et HTTPS ne t'en préserve pas non plus
À partir du moment où tu ne peux pas injecter arbitrairement du contenu… ben si.

Citation Envoyé par Paul TOTH Voir le message
mais HTTPS n'a jamais voulu dire "site de confiance" !
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.

Citation Envoyé par Paul TOTH Voir le message
sauf que si je hack un site, il me faut 10 secondes pour activer mon propre certificat dessus et détourner www.nabamque-en-ligne.com sur ce faut site sans le moindre warning HTTPS.
???

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 ???

Citation Envoyé par Paul TOTH Voir le message
un site qui n'a pas bougé depuis 20 ans, il est sur depuis 20 ans, ou pas, mais ce statut n'a pas changé.
????

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é !

Citation Envoyé par Paul TOTH Voir le message
[…]je dis que les sites HTTP ne sont pas des dangers potentiels […]
À 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.

Citation Envoyé par Paul TOTH Voir le message
ce qui serait bien c'est d'avancer des éléments techniques probants...HTTPS ne permet pas de s'assurer de la nature du site sécurisé, uniquement qu'il possède un certificat, et Let's Encrypt s'assure simplement que le demandeur est en mesure de mettre à jour le site...ce que sait faire tout hacker par définition.
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.

Citation Envoyé par Paul TOTH Voir le message
Du coup dire HTTP = DANGER, HTTPS = SECURE c'est trop binaire pour refléter la réalité.
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é.
Contacter le responsable de la rubrique Accueil