Discussion :

[RandomAccount243]

Ce qui me dérange le plus dans cette histoire c'est que google prend en compte de plus en plus de paramètres pour faire son référencement qui sont indépendant du contenu : HTTPS, mobile friendly. J'ai peur que la démarche actuelle de google à vouloir imposer certains standards web (à tord ou à raison) nuisent à la qualité des résultat vis à vis du contenu.

Google n'est pas le seul moteur de recherche web, si leur évolution vers un axe favorisant l'ergonomie (responsive design/mobile-friendly) et la sécurité (https) ne te convient pas il existe des solutions alternatives telle que Qwant par exemple

Mais je comprends ta réflexion, après si quelqu'un qui propose du contenu web n'est pas capable de penser à l'ergonomie et à la sécurité de son site et de ses utilisateurs ce ne sera peut être pas le mieux placé pour fournir du contenu (de type informatique en tout cas) de qualité... Mais c'est vrai qu'en écrivant ça j'ai oublié tout le contenu non informatique d'Internet qui n'est pas forcément proposé par des initiés...

[23JFK]

...

Je ne connais pas au jour d'aujourd'hui un site d'information qui ne soit pas commercial.

Https ne protège pas des virus, il permet juste de savoir évenuellement quel site l'a refilé, ce qui ne sert pas à grand chose vu qu'il est peu probable qu'un pekin lambda aille porter plainte contre le site.

[Zirak]

Je ne connais pas au jour d'aujourd'hui un site d'information qui ne soit pas commercial.

Je ne sais pas, DVP par exemple (qui n'est pas qu'un forum en .net, mais aussi un site en .com) ?


Sinon rien à voir, mais "au jour d'aujourd'hui", c'est mal... C'est un pléonasme et considéré comme un emploi fautif par l'Académie Française. Je tenais à le repréciser, si cela peut éviter à certains de se rendre ridicule devant des collègues, la hiérarchie, ou des clients.

[Neckara]

Je ne connais pas au jour d'aujourd'hui un site d'information qui ne soit pas commercial.

Et ?

Https ne protège pas des virus, il permet juste de savoir évenuellement quel site l'a refilé, ce qui ne sert pas à grand chose vu qu'il est peu probable qu'un pekin lambda aille porter plainte contre le site.

HTTPS protège l'origine et l'intégrité des données...

Je te parle d'injection sur une communication HTTP... voire de modification du site s'il dispose d'une interface d'administration.

[23JFK]

Je ne sais pas, DVP par exemple (qui n'est pas qu'un forum en .net, mais aussi un site en .com) ?


Sinon rien à voir, mais "au jour d'aujourd'hui", c'est mal... C'est un pléonasme et considéré comme un emploi fautif par l'Académie Française. Je tenais à le repréciser, si cela peut éviter à certains de se rendre ridicule devant des collègues, la hiérarchie, ou des clients.

Je n'aurais pas mis DVP dans la catégorie site d'informations, l'on peut alors effectivement considérer que toute page internet est un site d'information. De là à décréter qu'il faille tout protéger contre des modifications... Mais ce Dave n'a-t-il pas justement argumenté que le HTTPS ne protégeait pas contre une attaque par l'homme du milieu, méthode tout à fait valide pour mystifier un site ?

Vous pourrez jouer, avec les membres de l'Académie Française, le docte professeur de langue, quand le Français sera une langue morte. D'ici là, je n'ai absolument pas à craindre de me rendre ridicule devant qui que ce soit de part mon langage ni même des fautes d'orthographes que je puis pondre en série, j'ai lu assez de vieux grimoires pour savoir que la bonne orthographe et la bonne grammaire sont de l'ordre du mythe ; une science que les ignares en mal de reconnaissance aiment à mettre en avant.

HTTPS protège l'origine et l'intégrité des données...

Je te parle d'injection sur une communication HTTP... voire de modification du site s'il dispose d'une interface d'administration.

Je m'abstiendrais d'être aussi catégorique, tout système est faillible, en cela, https ne fait pas exception à la règle.

[Zirak]

une science que les ignares en mal de reconnaissance aiment à mettre en avant.

Je profitais juste de ma réponse (que vous avez merveilleusement bien esquivée dans votre message suite édition de votre message), pour signaler cette faute que l'on retrouve régulièrement un peu partout, je n'ai pas répondu seulement pour vous signaler votre faute.

Si vous aimez vous rendre ridicule, c'est votre droit, mais cela peut peut-être empêcher à d'autres de l'être, vous n'êtes pas le seul à me lire, c'est bien pour cela que j'avais précisé "à certains" au pluriel.



Après quand on considère qu'il n'existe aucun site non commercial, n'est pas ignare qui l'on croit, surtout lorsque l'on se contredit soit-même à deux messages d'intervalle :

Il va de soit que je ne dis pas que le https est toujours inutile, cependant son intérêt se limite à la couche commerciale du net, les autres sites n'ont rien à y gagner, les hackers contemporains ne s'intéressant qu'à ce qui est susceptible de apporter du fric.

Je ne connais pas au jour d'aujourd'hui un site d'information qui ne soit pas commercial.

Quels sont donc ces autres sites qui n'ont rien à y gagner, puisque selon vous, il n'en existe pas ?


Edit : puisque vous avez édité votre message dans une version un peu moins agressive, que considérez-vous comme un site d'information du coup ?

[intelligide]

Je n'aurais pas mis DVP dans la catégorie site d'informations, l'on peut alors effectivement considérer que toute page internet est un site d'information. De là à décréter qu'il faille tout protéger contre des modifications...

Ben oui, c'est ce qu'on appelle le liberté d'expression. Le fait d'empêcher les modifications permet d'éviter que des acteurs de la société transforment un message à leur avantage.

Mais ce Dave n'a-t-il pas justement argumenté que le HTTPS ne protégeait pas contre une attaque par l'homme du milieu, méthode tout à fait valide pour mystifier un site ?

même si vous utilisez un protocole sécurisé, ces mêmes attaques peuvent toujours être menées par des tiers malveillants.

ça, c'est dans le cas où on fait passer volontairement le traffic par un intermédiaire qui remplace les certificats au vol. ça relève plus de l'erreur humaine que d'un problème technique.

Je m'abstiendrais d'être aussi catégorique, tout système est faillible, en cela, https ne fait pas exception à la règle.

Bien sûr que le HTTPS est faillible, mais le temps que les protocoles de chiffrement soient cassés, ils auront déjà été changés.

[Neckara]

De là à décréter qu'il faille tout protéger contre des modifications...

Je crains que tu n'as même pas conscience des conséquences d'un manque d'intégrité et de confidentialité d'un site.

Par exemple, l'injection de code peut servir pour tout ce qui est "browser fingerprinting", minage de cryptomonnaies, tentative d'exploitation d'une faille d'un navigateur, constitution d'un pseudo-"botnet", etc.

Mais ce Dave n'a-t-il pas justement argumenté que le HTTPS ne protégeait pas contre une attaque par l'homme du milieu, méthode tout à fait valide pour mystifier un site ?

Mystifier ?

Et non, à moins de casser TLS ou d'avoir un CA (ou un hébergeur, proxy TLS) malveillant, tu ne peux pas faire de MITM sur TLS, donc sur HTTPS.
Et si tu arrives à casser TLS, et bien, je t'invites à publier un article de recherche.

Je m'abstiendrais d'être aussi catégorique, tout système est faillible, en cela, https ne fait pas exception à la règle.

Et ?

[23JFK]

...

Vous avez vous même qualifié "au jour d'aujourd'hui" comme étant du type pléonasme or, le pléonasme n'est pas considéré comme une erreur mais comme un effet de style, et un effet style ne peut pas être consideré comme une erreur de langage. Plus généralement, de mon point de vu, la langue Française est une langue d'exceptions, la notion de règle autorisée ou non en devient très relative (et le travail de l'Académie Française très futile), si vous aspirez à pratiquer une langue parfaite (au sens de règles strictes et inviolables) je vous invite à vous intéresser à l'espéranto ou quelque autre langue dite construite ayant priorisé cette philosophie.




A vrai dire, je ne decèle pas la contradiction que vous relevez.

[Saverok]

Et non, à moins de casser TLS ou d'avoir un CA (ou un hébergeur, proxy TLS) malveillant, tu ne peux pas faire de MITM sur TLS, donc sur HTTPS.
Et si tu arrives à casser TLS, et bien, je t'invites à publier un article de recherche.

TLS 1.0 a été cassé en 2011
La version 1.2, c'est une autre histoire mais il existe, malheureusement, encore beaucoup de serveurs qui restent en version 1.0...

[RandomAccount243]

Un vrai plaisir de lire Neckara qui a toujours les bons mots face à des arguments aussi incompréhensibles qu'indéfendables... J'arrive pas à comprendre comment on peut persister à chercher des arguments contre le HTTPS par rapport au HTTP. L'argument des sites commerciaux par exemple n'a aucun sens et chiffrer les communications sera toujours mieux que de laisser tout en clair, à moins de vraiment vouloir ne pas se protéger...

[qvignaud]

Et non, à moins de casser TLS ou d'avoir un CA (ou un hébergeur, proxy TLS) malveillant, tu ne peux pas faire de MITM sur TLS, donc sur HTTPS.
Et si tu arrives à casser TLS, et bien, je t'invites à publier un article de recherche.

Bonjour, bonsoir,

• Premièrement, HTTPS n'est pas invulnérable à l'attaque par l'homme du milieu : Callegati, F., Cerroni, W., & Ramilli, M. (2009). Man-in-the-Middle Attack to the HTTPS Protocol. IEEE Security & Privacy, 7(1), 78-81.
• Deuxièmement, HTTPS a d'autres failles qui ne sont pas forcément de ce type là : Möller, B., Duong, T., & Kotowicz, K. (2014). This POODLE bites: exploiting the SSL 3.0 fallback. Security Advisory.
• Troisièmement, TLS lui-même n'est pas invulnérable du tout (note : TLS repose sur RSA, ECDSA, ECDH ou encore DSA selon la configuration utilisée) : Chen, L., Chen, L., Jordan, S., Liu, Y. K., Moody, D., Peralta, R., ... & Smith-Tone, D. (2016). Report on post-quantum cryptography. US Department of Commerce, National Institute of Standards and Technology.

Du dernier ouvrage mentionné voici un extrait :



Voilà. Que chacun se rappelle que la sécurité n'est pas de savoir si les données échangées sont sécurisées ou pas, mais combien de temps elles le sont.
Pour le reste, bonne continuation dans ce débat.

[RandomAccount243]

Voilà. Que chacun se rappelle que la sécurité n'est pas de savoir si les données échangées sont sécurisées ou pas, mais combien de temps elles le sont.
Pour le reste, bonne continuation dans ce débat.

Tu en conviendras, l'usage du HTTP sur des sites avec formulaires de connexion ou de paiements n'est en aucun cas préférable à l'usage du HTTPS

[23JFK]

Un vrai plaisir de lire Neckara qui a toujours les bons mots face à des arguments aussi incompréhensibles qu'indéfendables... J'arrive pas à comprendre comment on peut persister à chercher des arguments contre le HTTPS par rapport au HTTP. L'argument des sites commerciaux par exemple n'a aucun sens et chiffrer les communications sera toujours mieux que de laisser tout en clair, à moins de vraiment vouloir ne pas se protéger...

Il ne s'agit pas d'être aussi radical, mais de savoir où une protection est nécessaire et où elle est superflue. De base, le problème est que le https se veut imposé en toutes occasions même quand cela ne présente vraiment aucun avantage sécuritaire mais certainement des contraintes de maintenances ou, des contraintes d'accès probables pour d'anciens dispositifs n'ayant pas de support adéquate ou de capacité de calcul suffisante pour établir une connexion sécurisée avant que le délai d'expiration de la connexion serveur ne soit atteinte. Vous parlez de chiffrer des communications, mais la consultation de site n'est pas invariablement une communication ayant vocation à être confidentielle notamment lorsqu'il ne s'agit que d'appeler une page, les métadonnées transmises dans intervalle qui précédè l'établissement de la connexion sécurisée suffit largement à désanonymiser vos précieuses activités secrètes.

[Saverok]

Tu en conviendras, l'usage du HTTP sur des sites avec formulaires de connexion ou de paiements n'est en aucun cas préférable à l'usage du HTTPS

HTTPS avec TLS 1.2 est 1000x mieux que HTTP
Par contre, entre du HTTP et du HTTPS avec TLS 1.0, c'est presque du kiffe kiffe (tellement les failles de TLS 1.0 sont connues et exploitées depuis longtemps) donc non seulement il faut marquer les sites en HTTP mais aussi ceux qui utilisent une ancienne version du TLS et là, ça devient super confus comme communication pour les usagers.

[Neckara]

TLS 1.0 a été cassé en 2011
La version 1.2, c'est une autre histoire mais il existe, malheureusement, encore beaucoup de serveurs qui restent en version 1.0...

Quand je parle de TLS, c'est bien évidemment le TLS state of the arts, pas les versions qui ont été dépréciées.
Si TLS 1.0 a été cassée en 2011, le TLS 1.1 est sorti en 2006, et le TLS1.2 en 2008.

Premièrement, HTTPS n'est pas invulnérable à l'attaque par l'homme du milieu : Callegati, F., Cerroni, W., & Ramilli, M. (2009). Man-in-the-Middle Attack to the HTTPS Protocol. IEEE Security & Privacy, 7(1), 78-81.

Ça c'est une faille utilisateur qui accepte les certificats auto-signé de ce que je lis dans la première page de l'article.

Deuxièmement, HTTPS a d'autres failles qui ne sont pas forcément de ce type là : Möller, B., Duong, T., & Kotowicz, K. (2014). This POODLE bites: exploiting the SSL 3.0 fallback. Security Advisory.

Au vu du titre, ça semble plus être un problème de configuration, que vraiment de HTTPS.

Troisièmement, TLS lui-même n'est pas invulnérable du tout (note : TLS repose sur RSA, ECDSA, ECDH ou encore DSA selon la configuration utilisée) : Chen, L., Chen, L., Jordan, S., Liu, Y. K., Moody, D., Peralta, R., ... & Smith-Tone, D. (2016). Report on post-quantum cryptography. US Department of Commerce, National Institute of Standards and Technology.

Construit déjà ta machine quantique avec suffisamment de q-bits, et on en reparle.

Voilà. Que chacun se rappelle que la sécurité n'est pas de savoir si les données échangées sont sécurisées ou pas, mais combien de temps elles le sont.
Pour le reste, bonne continuation dans ce débat.

Ouais, mais bon, dans le cas de HTTP, le "combien de temps" ne se pose même pas.

Sachant que derrière, toutes les attaques ne sont pas possibles à posteriori. Difficile par exemple de "voler" une connexion terminée il y a 10 ans.

[qvignaud]

Attention, qu'on ne me fasse pas dire ce que je n'ai pas dit !

À aucun moment je ne soutiens qu'il est mieux d'utiliser HTTP au lieu d'HTTPS.

Je dis seulement qu'il y a des cas inutiles, ou contre-productifs, tels que :

• forcer toutes les connexions à se faire un HTTPS, car dans le cas d'applications en localhost ou réseau local d'entreprise, cela requiert un certificat auto-signé, ce qui est une source significative de failles (comme l'illustre Callegati, F., Cerroni, W., & Ramilli, M. (2009). Man-in-the-Middle Attack to the HTTPS Protocol. IEEE Security & Privacy, 7(1), 78-81.) ;
• la sur-encapsulation dans le cas d'applications qui ont leur propre mécanisme de sécurité (comme les dépôts logiciels linux qui signent déjà les paquets, rajouter une connexion TLS est un surcoût pur sans aucun bénéfice).

Pour ce qui est du reste, l'erreur serait sans-doute de qualifier les connexions HTTP de "non-sécurisée" (très vague pour la majorité des utilisateurs), et non simplement de "connexion en clair". Et surtout de qualifier une connexion HTTPS de "sécurisée" : en rien le HTTPS ne garanti que l'utilisateur ait affaire à une page honnête, le serveur pouvant être corrompu ou autre ; cela veut juste dire que le tuyau est "plus solide" entre la pompe et l'évier, pas que l'eau qui y circule est potable.

Donc que le navigateur s'alarme qu'il y ait un formulaire ou du Javascript sur une page HTTP d'accord, encore plus si l'ordinateur est sur un réseau wifi public ; mais qu'il prétende à l'utilisateur qu'une page HTTPS est sûre, non.

Pour le reste, bien entendu passer au HTTPS semble le minimum que puissent faire les webmestres.

[Neckara]

forcer toutes les connexions à se faire un HTTPS, car dans le cas d'applications en localhost ou réseau local d'entreprise, cela requiert un certificat auto-signé, ce qui est une source significative de failles (comme l'illustre Callegati, F., Cerroni, W., & Ramilli, M. (2009). Man-in-the-Middle Attack to the HTTPS Protocol. IEEE Security & Privacy, 7(1), 78-81.) ;

Dans le cas d'un réseau d'entreprise, il suffit juste de rajouter un CA d'entreprise. Tant qu'on considère ce dernier sécurisé, il n'y aura aucun problème.

En revanche, les connexions en clair dans un réseau, même interne, d'entreprise, c'est pas bien. L'ennemi n'est pas toujours qu'à l'extérieur.

Pour le localhost, je ne pas pas que le navigateur posera problème pour une connexion HTTP.

la sur-encapsulation dans le cas d'applications qui ont leur propre mécanisme de sécurité (comme les dépôts logiciels linux qui signent déjà les paquets, rajouter une connexion TLS est un surcoût pur sans aucun bénéfice).

Dans ce cas, tu n'es plus vraiment dans de la navigation web via un navigateur web.

Et surtout de qualifier une connexion HTTPS de "sécurisée" : en rien le HTTPS ne garanti que l'utilisateur ait affaire à une page honnête, le serveur pouvant être corrompu ou autre ; cela veut juste dire que le tuyau est "plus solide" entre la pompe et l'évier, pas que l'eau qui y circule est potable.

C'est justement pour cela que Chrome va marquer les connexions HTTP comme non-sécurisé, et ne va rien marquer pour les connexions HTTPS.

[Bill Fassinou]

Pourquoi devriez-vous faire migrer vos sites statiques de HTTP vers HTTPS ?
Voici les raisons avancées par un expert en sécurité Web

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

[23JFK]

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.