Bonjour'nal
Jusqu'à présent pour mouler sur LinuxFR de manière sécurisée avec mon copain TLS on est obligé d'utiliser les services de l'EFF, on est maintenant en 2k17 et ça nous déçois un peu…
Administrateurs, si vous nous lisez ne voulez-vous pas déposer une petite redirection 301 de http://linuxfr.org vers https://linuxfr.org ?
Si non, voulez-vous bien éclairer ma lanterne fort cabossée ? Qu'est-ce qui serait limitant pour forcer HTTPS aujourd'hui ?
La bise.
# Mon opinion
Posté par Sytoka Modon (site web personnel) . Évalué à 0.
Sur les sites web que je gère (donc pas DLFP). http -> connexion anonyme. https -> connexion identifié DÈS le reverse proxy sur un annuaire LDAP. Pas une ligne de Python exécuté avant que l'identification soit faites.
Je ne sais pas comment faire aussi clean et aussi simple en mettant tout en https…
[^] # Re: Mon opinion
Posté par FreeFax . Évalué à 9.
Les choix liés à la sécurité ne devraient pas être une affaire d'opinion mais de connaissances solides, ça évitera qu'on voit des banques/assurances/startups/administrations/que-sais-je se faire trouer tous les jours.
Aucun rapport avec le fait d'utiliser HTTPS ou pas.
Et ta page de login ? Par définition, ton utilisateur est anonyme au moyen où il/elle envoie gentiment son login/password en vadrouille sur les réseaux vers ton serveur. Merci pour eux, maintenant tout le Starbucks connaît leurs identifiants (et leur FAI, et ton FAI, et bien d'autres…, et la NSA bien-sûr ;)).
Dans le cas d'un Man in the Middle (quelqu'un intercepte tout ce qui passe entre le navigateur de ton utilisateur et ton serveur), le méchant fait croire au navigateur que le serveur parle HTTP, il communique avec ton serveur en HTTPS si ça te fait plaisir, mais en chemin il voit tout ce qui passe, et ni toi ni le navigateur ne se doutent de quoi que ce soit… Un bon moyen d'empêcher ça, c'est de dire au navigateur qu'il ne doit accepter rien d'autre que du HTTPS de ta part. (cf une réponse plus bas)
Au contraire, tout est on ne peut plus simple et clean ! Tu communiques uniquement en HTTPS. Point final. Comment ça pourrait être moins simple ? Un petit coup de HSTS et de Public Key Pinning, et tu es au top (ou tout cas bien mieux que l'immense majorité des sites webs).
[^] # Re: Mon opinion
Posté par FreeFax . Évalué à 1.
(Hors-sujet : on peut plus éditer ses commentaires ? Je ne trouve plus le bouton…)
En relisant le commentaire auquel je répondais, j'ai l'impression d'avoir peut-être mal compris ce que l'auteur voulait dire par "connexion anonyme" et "connexion identifié". S'il repasse par là, j'aimerai bien une clarification.
[^] # Re: Mon opinion
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Visiteur anonyme, sans session avec authentification, donc sans envoi de login/pass, https ou non, d'autant que la personne ou le bot n'a peut-être même pas de compte sur le site. Versus un utilisateur qui se logue sur le site.
[^] # Re: Mon opinion
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Exact. Anonyme => pas d'identification.
Via reverse proxy, si tu as un site SPIP, tu rediriges le /ecrire vers le site en HTTPS, si tu as un site Wordpress, tu rediriges le /wp-admin en https…
Bref, en http, pas de login/pass, pas de chiffrement. C'est de la consultation et bon pour les robots. Dès qu'il y a un couple login/pass, cela bascule en https avec authentification dès le reverse proxy (donc avant l’exécution de code python ou php). Je ne suis pas un spécialiste de la sécurité mais je me dis que minimiser le nombre de ligne de code et simplifier les choses ne peuvent pas faire de mal. Mais attention, ce sont des modules intégrés de base dans Apache qui font le boulot et si je ne peux avoir confiance en eux, je peux presque arrêter mes sites web…
Et j'ai pas de traceur de stat sur mes sites. On me le demande parfois mais je renvoie ces personnes vers l'écriture de nouvelles pages !
[^] # Re: Mon opinion
Posté par Antoine . Évalué à 3.
En fait, tu tiens à protéger ton espace privé, mais une interception de flux pour remplacer le contenu du site public par un autre ne te dérangerait pas ? Note que cette attaque peut aussi retirer ta redirection du
/ecrire
vers le site en HTTPS, et du coup remplacer l'espace privé par n'importe quoi d'autre.[^] # Re: Mon opinion
Posté par Sytoka Modon (site web personnel) . Évalué à -4.
Normalement, en http, il ne devrait pas y avoir de droit d'écriture sur la base de donnée… (mais je suis loin d'être sur que tout soit bien écrit effectivement)
Sinon, la redirection est faite sur le reverse proxy qui est une autre machine ou il n'y a ni PHP ni Python ni rien de tous ces trucs… Donc remplacer la redirection me semble non pas infaisable mais non triviale…
[^] # Re: Mon opinion
Posté par Sytoka Modon (site web personnel) . Évalué à -5.
C'est effectivement peu appréciable mais au vu de l'importance de MES sites, peu probable non plus.
Sinon, on parle ici de la véracité d'un site donc de sa signature. Il suffit d'avoir une page signé numériquement pour la valider comme on signe un courriel. Pas besoin de chiffrement et d'https donc. Une page signée suffit à certifier que la page provient bien de mon site web (ce qui ne veut pas dire mais cela est vrai dans 100% des cas que mon site n'a pas été piraté).
Signer le HTTP, oui. Tout chiffrer et basculer en HTTPS, ce n'est pas forcément utile à mon sens.
[^] # Re: Mon opinion
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Pourquoi ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mon opinion
Posté par Sytoka Modon (site web personnel) . Évalué à -3.
Parce que justement j'utilise le HTTPS pour authentifier ! Sinon je met tout en https, il faut que je trouve un autre moyen pour authentifier. Mes sites web sont consultable pour la plupart authentifié ou non, or j'aime bien que l'authentification ait lieu sur le reverse proxy, en amont du site web, sur une machine n'ayant pas de langage de script !
[^] # Re: Mon opinion
Posté par aiolos . Évalué à 3.
Tu utilise les certificats clients pour authentifier tes utilisateurs ? Sinon, je ne vois pas ce que tu veux dire par "j'utilise le HTTPS pour authentifier".
Si c'est bien ce que tu veux dire, tu peux écrire tes règles de reverse proxy pour agir différemment si un certificat client est présent ou non, il me semble.
[^] # Re: Mon opinion
Posté par flan (site web personnel) . Évalué à 3.
C'est très probablement des certificats clients.
En tout cas avec Apache, tu peux en effet rendre le certificat client optionnel… sauf que dans ce cas, le navigateur va probablement ne jamais demander au client de fournir le certificat (de mémoire, c'était le comportement quand j'avais essayé).
[^] # Re: Mon opinion
Posté par Cyril Brulebois (site web personnel) . Évalué à 1.
Côté apache ça ressemble à :
(avec
optional
au lieu derequire
)Et si, Firefox (45 mais c'était déjà le cas il y a plusieurs années) propose l'utilisation d'un certificat dans ce cas…
Debian Consultant @ DEBAMAX
[^] # Re: Mon opinion
Posté par gouttegd . Évalué à 10.
Un des intérêts de la généralisation du chiffrement, c’est de rendre le trafic chiffré suffisamment « commun » ou « banal » pour que la simple utilisation du chiffrement ne permette pas d’identifier le trafic « intéressant ».
[^] # Re: Mon opinion
Posté par Sytoka Modon (site web personnel) . Évalué à -5.
Les personnes mettent du HTTPS et des liens vers 36 sites, soit google analytics, soit des bibliothèques javascripts…
Un paquet de site non authentifié sont encore (et heureusement) non pas des applications mais principalement du texte ouvert au moteur de recherche. J'évite tout script externe, tout appel DNS externe, toutes images externes…
Bref, pour moi, ce n'est pas forcément une priorité de chiffrer pour chiffrer du contenu que je met à la disposition du public et vérifiant (je l'espère) toutes les lois de la république. Tout est dans les caches des moteurs de recherche…
[^] # Re: Mon opinion
Posté par Ph Husson (site web personnel) . Évalué à 5. Dernière modification le 17 février 2017 à 15:24.
De mémoire, Google a commencé à mettre un score supérieur à du https que du http
# utiliser hsts
Posté par Christophe Turbout . Évalué à 10.
La redirection 301 utilisée seule peut subir une attaque de "man in the middle", il est préférable pour ceci d'utiliser aussi le protocole HSTS fait spécialement pour résoudre le problème :
Deux liens disponibles sur le sujet :
[^] # Re: utiliser hsts
Posté par Fkdikdbejdid . Évalué à 2.
Tout à fait, c'est un navrant oubli de ma part, à ajouter comme doléance aux administrateurs bien entendu.
Merci pour le rappel.
# aller regler ca dans tes parametres
Posté par NeoX . Évalué à -2. Dernière modification le 14 février 2017 à 18:40.
si c'est pour de la lecture seule => http, sans login
si c'est pour repondre, tu es loggué => https
ah non, il faut etre loggué en https pour que ca le conserve…
# Suivi
Posté par Harry . Évalué à 8.
Je suppose que ça mériterai une entrée dans le suivi. D'ailleurs, il y a déjà 3 tickets en rapport avec l'HTTPS :
# merci !
Posté par Adrien . Évalué à 6.
Grâce à ton journal je m'aperçois que j'utilise HTTP et non HTTPS, malgré https-everywhere…
Hop zou c'est changé, merci ! Comme quoi le HTTPS par défaut serait utile aux têtes en l'air.
[^] # Re: merci !
Posté par barmic . Évalué à -1.
Enfin faut être plus que tête en l'air pour ne jamais être passé au https (si tu le fait une fois ton navigateur t'empêchera de venir autrement ensuite).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: merci !
Posté par Dabowl_75 . Évalué à -9.
Https n'a aucun intérêt si le proxy interne de ta boite negocie le chiffrement avec ton arpenteur.
Je comprends pas cette mode davoir envie de chiffrer du contenu qui ne le mérite pas.
[^] # Re: merci !
Posté par Adrien . Évalué à 9.
Prenons le problème à l'envers : Pourquoi ne pas chiffrer alors que ça ne coûte quasiment rien ?
Et comment tu fais la distinction entre du contenu méritant et le reste ?
[^] # Re: merci !
Posté par Dabowl_75 . Évalué à -6.
Ce qui est privé doit rester privé.
Par exemple une conversation entre deux personnes. Ce qui n'est pas le cas dans un forum par exemple. Encore qu'il peut y avoir des forums privés, on appelera ça des salons plutôt.
Poster des contenus sur un site comme dlfp relève du public. Alors je ne vois pas l'intérêt de chiffrer.
[^] # Re: merci !
Posté par ff9097 . Évalué à 1.
Donc au lieu d'utiliser un protocole unique tu proposes d'en utiliser deux. Intéressant.
[^] # Re: merci !
Posté par foobarbazz . Évalué à 5.
Ce qui est sur LinuxFR est public, mais les méta données sur les posts ne le sont pas.
Et la question n'est pas « Pourquoi chiffrer par défaut » mais plutôt « Pourquoi ne pas le faire par défaut ? ». Chiffrer par défaut ne pose aucun problème…
[^] # Re: merci !
Posté par Zenitram (site web personnel) . Évalué à 0.
Je ne comprend pas cette mode de ne pas se renseigner quand on ne comprend pas, ici un peu de recherche sur le net t'indiquera rapidement les multiples raisons.
Non, je n'ai pas envie de t'en faire un résumé, trop gros surtout pour un lecteur de LinuxFr.
[^] # Re: merci !
Posté par Dabowl_75 . Évalué à -5.
Explique moi l'intérêt de chiffrer tes commentaires sur le web….sachant que dlfp est accessible à tout le monde et que le contenu sera quand même scanné, indexé etc…
Respect de la vie privée ? Dès lors qu'un contenu que tu postes n'a pas un minimum de confidentialité, il devient publique. C'est ainsi qu'on peut s'en servir contre toi. Le chiffrement ne change rien à l'affaire.
Et si en plus tu te sers de l'accès web de ton boulot pour poster des insanités sous couvert d'anonymat, le https ne te sera d'aucun recours.
[^] # Re: merci !
Posté par Romeo . Évalué à 6.
Ne pas se faire profiler sur un réseau publique ?
[^] # Re: merci !
Posté par oinkoink_daotter . Évalué à 8.
Pour la confidentialité :
1) ton authentification (cookie et/ou mot de passe) ne passe pas en clair sur un réseau que tu ne maîtrises pas ;
2) il est beaucoup plus compliqué de relier le contenu de ce que tu postes ou consultes sur un site via un crawling de celui-ci, par rapport à une analyse de ce qui passe effectivement sur le tuyau, ce qui est important quand SFR annonce qu'il va "tester" les publicités ciblées sur son offre TV.
[^] # Re: merci !
Posté par peikk0 . Évalué à 8.
Il n'y a pas que le chiffrement des communications qui est important, ya aussi et surtout l'authentification du site que tu visites. Sans HTTPS tu ne sais pas si t'es en train de lire le vrai linuxfr.org ou si quelqu'un au milieu n'est pas en train d'injecter du vilain JS ou des pubs dans ce que te renvoie le site.
[^] # Re: merci !
Posté par Wawet76 . Évalué à 6.
Même si le contenu est public, le fait que tu le consulte peut être considéré comme privé.
Par exemple Wikipedia n'a que des pages publiques, mais tu n'a pas forcement envie que ton FAI puisse savoir si tu te renseignes sur la version d'IE livrée avec Windows 8, sur Napoléon 3 ou sur les hémorroïdes.
[^] # Re: merci !
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Et je suis sur que tu as ton Smartphone dans ta poche arrière toute la journée ;-)
[^] # Re: merci !
Posté par Romeo . Évalué à 2.
Ok donc tu ne veux pas forcément que ton FAI sache que tu te renseignes sur les hémorroïdes d'où l'usage du HTTPS.
[^] # Re: merci !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Attention, autant la NSA fait ce qu'elle veut, autant ton FAI est soumis à la loi française (ou belge, ou…) et ne peut pas faire ce qu'il veut !
[^] # Re: merci !
Posté par cbri . Évalué à 1.
Oui mais pas vu, pas pris.
Ou dit autrement ce n'est pas parce que la loi l'interdit que certains ne font des actions illégales surtout quand cela rapporte de l'argent. Ensuite, il faut qu'une enquête soit lancée puis que la justice soit saisie.
[^] # Re: merci !
Posté par Antoine . Évalué à 2.
Sous quelle forme est-ce que cela leur rapporterait de l'argent ?
[^] # Re: merci !
Posté par EauFroide . Évalué à 0. Dernière modification le 23 février 2017 à 13:52.
Reventes d'informations (par exemple : QUE VALENT VOS DONNÉES PERSONNELLES ?)
1) il existe plein de logiciels libre pour reprendre le contrôle de son smartphone (sans compter la facilité a wiresharker ton smartphone en wifi pour checker se qu'il trame (attention jeu de mot! :D))
2) mode avion (en plus les smartphones sont utilisable sans Sim)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: merci !
Posté par Romeo . Évalué à 2.
Comme ça :
http://www.francetvinfo.fr/internet/telephonie/sfr-va-tester-les-publicites-ciblees-a-la-television-une-premiere-en-france_2057061.html
[^] # Re: merci !
Posté par steph1978 . Évalué à 10.
On chiffre le contenu qui ne le mérite pas pour que le contenu qui le mérite et qui sera chiffré ne se fasse pas remarquer.
D'autre part qui décide/juge du mérite d'un contenu à être chiffré : chaque site ? Non, c'est l'utilisateur qui doit le faire. Or un site ne peut pas savoir à l'avance ce que va décider l'utilisateur, il doit donc chiffrer par défaut.
Une somme de contenus qui ne méritent pas d'être chiffrés peuvent constituer un profile d'un utilisateur qui lui doit être chiffré.
Ton commentaire, si il est répandu chez une majorité d'internaute, est effarant IMHO.
[^] # Re: merci !
Posté par Parleur . Évalué à 6.
Moi, je ne comprends pas cette mode d'être aussi affirmatif quand on écrit des bêtises, tout en se sachant pourtant incompétent.
# Désengorger HTTPS-Everywhere
Posté par Bisaloo . Évalué à 6.
Sans compter que le nombre de règles de réécriture dans HTTPS-Everywhere devient vraiment grand. Ça alourdit l'extension.
Les règles sont supprimées lorsqu'un site rejoint la liste preloaded de firefox et chromium. Du coup, je pense que ce serait une bonne chose que tous les sites qui le peuvent passent en HSTS preloaded.
# redirect permanent
Posté par Hodj . Évalué à -2.
Dans la conf d'apache et celle de nginx, il y a des directives pour faire de la redirection permanente pourquoi ne pas utiliser cela
[^] # Re: redirect permanent
Posté par Fkdikdbejdid . Évalué à 1.
C'est exactement à quoi je fais allusion lorsque je parle de redirection 301 .
# Par pitié non
Posté par Dabowl_75 . Évalué à -10.
Il y a des entreprises chez qui le https est interdit par défaut. Seule une petite liste blanche autorise quelques sites.
Alors de grâce laissez le choix à l'utilisateur merci
[^] # Re: Par pitié non
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 16 février 2017 à 09:40.
T'es mal barré : le mouvement est clairement de rediriger HTTP vers HTTPS.
De quel choix tu parles? C'est un protocole, c'est tout.
Et justement, que tout les sites passent à HTTPS mettra alors la pression sur ta "super-entreprise" à l'admin dangereux pour qu'elle arrête sa liste blanche et autorise tout site en HTTPS (au pire si elle veut quand même scanner en mettant son certificat en intermédiaire, du moment où elle vérifie quand même que le site en face est le bon, bref sans casser la sécurité une fois sortie de l'entreprise).
note que je comprend que tu dois te taper une boite pourrie pour avoir des sous à la fin du mois, mais pas la peine de faire le syndrome de Stockholm, tu a l'air de trouver ça pas dérangeant que de bloquer HTTPS alors que c'est quand même un gros problème de sécurité.
[^] # Re: Par pitié non
Posté par Dabowl_75 . Évalué à -10.
Cette boite est un grand bancaire français. Et d'autres font pareil.
Je suis contre le fait qu'on m'impose le https aux motifs falacieux.
[^] # Re: Par pitié non
Posté par Romeo . Évalué à 10.
Si ma boite interdit les sites contenant un s, dois-je demander à tout les sites de ne pas m'imposer des noms en s ?
Si ta boite a un fait un choix technique, c'est son problème.
[^] # Re: Par pitié non
Posté par steph1978 . Évalué à 10.
Si ta boite ne veut pas que tu surf, c'est son choix.
Peut être estime-t-elle que ce n'est pas utile à ton travail.
Dans ce cas ton surf est personnel. Surfe avec un équipement personnel comme ton mobile par exemple.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.