Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
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.Envoyé par archqt
Pour éviter l'attaque "Man In The Middle" je suppose
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.
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.
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.
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 ?
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.
de la même façon qu'en HTTPS qui ne préserve pas de l'attaque MIM
comme en HTTPS
ce n'est pas un choix de l'utilisateur, mais du serveur
tu me fais une démonstration ?
et HTTPS ne t'en préserve pas non plus
mais HTTPS n'a jamais voulu dire "site de confiance" !
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.
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é.
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)
ah mais c'est pas moi qui déclare que HTTP est un danger mortel
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é.
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 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.
C'est la base (de tête) :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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. }
À partir du moment où tu ne peux pas injecter arbitrairement du contenu… ben si.
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é.
la consommation énergétique des data center est déjà un problème, là on ferait de la surqualité nullissime à tous les niveaux
1) plus de boulot = plus de latence = moins d'ergonomie pour le visiteur
2) plus de boulot = plus de puissance = plus de couts et une consommation d’énergie très supérieure. Toutes les études que j'ai pu lire dans ce domaine parlent en gros de 50% de plus, c'est collosal à l'echelle de la bulle internet qui représentait déjà en 2013 une consommation d'énergie au niveau mondial qui, si c’était un pays, l'aurait placé en 3ieme position juste derrière les US et la Chine.
3) plus de boulot = plus de serveurs = surcout d’énergie encore une fois mais lié à la production de ces serveurs.
Bref, inutile donc stupide. Peu efficient donc dangereux.
Les conversations seraient plus élégantes sans les 'bananes', les 'faut pas déconner' etc
Hello,
A vous lire, on se demande qui est expert en quoi ?
Tout peut se dire avec élégance et respect.
En tout état de cause, la sécurité qu'elle soit informatique ou autre demande un travail sans fin et ne se suffit pas des convictions des uns et des autres.
Affirmer que le HTTPS est plus sécure que le HTTP, certainement.
En faire une doctrine absolue, certainement pas, ce qui devrait rendre chacun d'entre nous un peu plus humble devant nos 'in-certitudes' qui sont faites, par essence, pour s'adapter et changer dans le temps.
Donc refaites votre débat dans 10 ans et nous en reparlerons !
Bonne journée les petits.. et les grands loups...
Souvenez vous de l'histoire des 3 petits cochons... et du cyclone 'IRMA' !!!!
Ou des trous noirs supers massifs qui sont passés de 'rares' à 'il en existe au moins un dans chaque galaxie'.
Les certitudes sont les cancers de la pensée...elles la tuent !!!!
Justement perso avant d’être développeur je suis "expert" en performance énergétique.
L'énergie ça sert à faire quelque chose. dit à l'envers :tout ce que l'on fait demande de l’énergie et donc demande de la réflexion (pensée hic) sur la valeur ajoutée que l'on souhaite créer, ce qui justifie vraiment de dépenser de l'énergie.
Imposer que le site vitrine du coiffeur de la rue du port soit en HTTPS coûte (à tous les points de vue mais je vois surtout celui énergétique) mais n'apporte pas la moindre valeur ajoutée, en sécurité comme en quoi que ce soit d'autre.
Pire que cela, cela fait mécaniquement perdre en réactivité le site et donc baisse la qualité de l'expérience utilisateur, seule vraie valeur ajoutée du site en question...
C'est à se demander si le HTTPS n'est pas pour ces GAFA un bon moyen de camoufler tout ce qu'ils vont pomper comme infos, ou en tous cas un intérêt pour eux exclusivement. Parce que sinon il faudra m'expliquer quel risque encours le visiteur du site du coiffeur de la rue du port. OK, un pirate peut se faire passer pour le coiffeur et affirmer que la boutique ferme à 17h au lieu de 18h, c'est vrai... peu probable et oh combien sans gravité. La surconsommation (y compris l’énergie grise pour fabriquer les machines) a quand a elle un impact certain et permanent.
Pour la latence... franchement ce qui prends le plus de temps, c'est généralement la limite des navigateurs quant au nombre de connexions simultanées ouvertes en même temps.
Sur une connexion HTTPS, on est de l'ordre de la millisecondes, c'est invisible pour l'utilisateur.
Pourquoi inutile ?
Non consequitur.
Ton coiffeur ne va pas auto-héberger son propre serveur... aujourd'hui HTTPS est totalement transparent, car géré par l'hébergeur.
C'est marrant, j'ai un site HTTPS qui se charge en 1/4 de secondes pour la première page, et est instantanée pour les autres.
Les données envoyées/reçues seront toujours visibles en local pour peu qu'on souhaite les voir, donc cela ne camoufle rien quant aux données qu'ils pompes.C'est à se demander si le HTTPS n'est pas pour ces GAFA un bon moyen de camoufler tout ce qu'ils vont pomper comme infos
De plus, si le but est de protéger les infos... mieux vaut utiliser HTTPS que HTTP et les balancer en clair
- installer un faux module de payement ;
- insérer des phrases du type : "on ne coiffe pas les juifs" ;
- insérer des conseils dangereux : "pour votre shampoing, mélanger du sodium pur dans l'eau".
- défacer le site pour insérer des spams : "enlarge your ponytail".
Pour les machines, cela demande une augmentation de combien de % du "nombre" de serveurs ou de ses capacités ?
Après, je pense qu'on aura aussi fort à faire avec le coût des blockchains, la publicité/trackers, dimensionnement des images, streaming, etc.
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 HTTP
ça ce n'est pas "Non consequitur". Apparemment vous ne vous êtes pas encore interrogé sur les questions de l'énergie et je vous rassure vous n'êtes pas le seul.Peu 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.
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 effet
si le coiffeur utilise CMS avec comme mot de passe admin/admin, tu aurais tout cela en HTTPS, ça ne change strictement rien...par contre l’authentification en deux étapes est tout aussi efficace en HTTP qu'en HTTPS et ça ne coûte pas un rond.
Si tu veux aller par là, tout est dangereux. Quand on dit "dangereux" dans un contexte informatique, on fait allusion à la sécurité du système, pas à la nature.
D'ailleurs si on voulait pinailler, ce ne serait plutôt néfaste que dangereux.
On peut très simplement justifier HTTPS par la simple notion de vie privée et du principe de secret des communications/échanges.
22ms pour ma connexion, 20ms pour la liaison TLS, 24ms d'attente. Environ 60ms pour le html de la page d'accueil. C'est de l'ordre de la ms.
Le https me fait perdre 80ms sur 400ms, sachant que la moitié, c'est de l'interprétation DOM/JS, je dois pouvoir encore améliorer cela.
Derrière, les autres pages se chargent instantanément.
Bref, c'est rien en terme temps de chargement.
Et ton petit coiffeur n'en a rien à faire, tout ce qui l'importe, c'est que son site soit sécurisé.en quoi que ce soit autohebergé ou hébergé par un hébergeur change quoi que ce soit ?
Qu'il soit en http ou https, si c'est un hackeur qui l'a ajouté en défaçant le site, cela n'a guère d'importance.
C'est bien beau d'invoquer la Justice, mais derrière, le coiffeur subit un préjudice souvent difficilement chiffrable.
Il va avoir des problèmes de réputations, potentiellement des actes de vandalismes, des insultes, l'incompréhension des clients, une potentielle baisse de fréquentation, et si cela ne suffisait pas, potentiellement des frais de Justice/avocat, ainsi que des années de lourdes procédures. Sachant que derrière, on pourra lui objecter une négligeance concernant la sécurité de son site web.
Bref, que de soucis pour pas grand chose.
Sachant que derrière, on ne pourra pas tout passer par du HTTP, donc il faudrait aussi "estimer" le gain potentiel en fonction des sites que vous souhaiteriez voir passer en HTTP.
On frôle le ridicule...
Nan, mais c'est vrai, et si le coiffeur écrit son login/mot de passe en gros sur sa devanture, le HTTPS aussi ne change strictement rien... Donc il faut supprimer le HTTPS de partout, ça sert à rien, CQFD.
Alors ça c'est intelligent.
Donc ton coiffeurs s'authentifie, et ensuite ton hackeur peut faire tout ce qu'il veux en MITM et/ou en volant la connexion.
Sachant qu'on perd par la même occasion tout l'intérêt de l'authentification forte.
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.
Bon, 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.
https://academie.atilf.fr/consulter/danger
https://academie.atilf.fr/consulter/menace
Le danger inclue une notion d'incertitude, de chose qui peut ou ne peut pas arriver, de probabilité.
Or le fait que la consommation soit plus importante, et donc contribue à la dégradation de l'environnement est plus du domaine de la certitude que de l'incertitude. Le terme néfaste est donc plus approprié.
Mon pinaillage va dans ton sens, te plains pas trop.
Chiffre sorti de ton chapeau.
Sachant que ce n'est pas qu'une question de probabilité, mais aussi d'impact si l’événement redouté se produit.
Bon, y'a des termes dédiés, pour ça, va falloir que je révise la gestion de risque
Le problème est s'il n'a justement pas de moyen de payements, et que ce dernier a été injecté par un attaquant.
Sachant que j'ai aussi évoqué d'autres risques.
Moi j'm'en fou j'ai pas d'enfants.
Plus sérieusement, il faut aussi regarder la proportion que ces sites représentent dans cette pollution, et le gain potentiel. C'est la loi de Pareto, autant se concentrer sur 20% des causes qui produisent 80% des effets. Comparer la consommation électrique d'Internet à un pays est ridicule, Internet est utilisé dans plus de 200 pays. On me donne 10 à 15% de la consommation électrique mondiale. Derrière, il faudrait comparer avec la consommation pour le chauffage, les transports, l'agriculture, etc.
Au niveau de la quantité de données échangées, un site web tout bête est anecdotique face à une vidéo.
Mon site est à 183k (on va arrondir à 200K). Un film peut peser aujourd'hui 1G. Donc regarder un film est équivalent à 5 000 sites web au niveau du "poids". Je ne parle même pas de la VoIP, comme par exemple un appel Skype, des chats en lignes, des jeux en lignes, des téléchargements de mises à jours, où là tu as besoins de TLS, etc.
Qu'est-ce que ton coiffeur va réellement économiser ? N'aurait-il pas plus vite fait d'installer du triple vitrage pour réduire sa consommation de chauffage ? De faire recycler les cheveux qu'il coupe ?
La sécurité et la vie privée sont loin, très loin, d'être anodines. Cela va même jusqu'à des enjeux démocratiques, donc non, c'est loin, très loin d'être une mouche.
Pas avec la même probabilité, et sûrement pas avec les mêmes moyens.
Defacing, modification des informations/statistiques, ajout d'une bannière "soutenez-moi sur bidule (donnez moi des sousous)", etc.
J'ai déjà évoqué cela.
Répondre avec citation
Partager