Julien.D a écrit 137 commentaires

J’ai d’ailleurs breveté le nombre 42.

Bonsoir,

Post intéressant, mais est-ce que les serveurs DNS sont-t-ils vraiment les maillons faibles de la sécurité d'un service ?

Dans le sens où si l'on souhaite attaquer un service et que l'on a le choix entre le service lui-même ou les serveurs DNS du service, attaquer les premiers peut avoir un impact direct sur la qualité du service alors qu'une attaque sur un serveur DNS n'impacterait que les clients qui l'interroge, et avec le système de cache du DNS ces requêtes sont relativement rares (par rapport aux requêtes que doivent gérer les serveurs du même service). Pour toucher la totalité des clients ne faudrait-t-il pas que l'attaque dure autant de temps que le TTL de l'enregistrement DNS comme je le pense (je prend comme référence le TTL de votre blog qui est d'environ 24h) ? Après il est vrai que si le résolveur DNS d'un FAI par exemple n'arrive pas à contacter le serveur DNS du service, cela risque de toucher de très nombreuses personnes et qu'il est peut-être plus facile de faire tomber les serveurs DNS d'un service que le service lui-même.

Des attaques DDOS sur les serveurs DNS d'un service sont-t-elles réellement courantes ? Et si oui, réussissent-t-elles et dans quelle proportion ? Le coût en temps et en bande passante est-t-il rentable pour un attaquant ?

ps : Le cas présenté dans le journal est tout de même bien différent puisqu'il mentionne des attaques sur des serveurs qui servent un TLD entier.

https://linuxfr.org/redaction/news/bloc-notes-l-expression-artistique-sous-gnu-linux

Julien.D : Révision n°854 - 29 août 2015 14:52:16
BAud : Révision n°854 - 29 août 2015 14:52:16

Il ne fait pas une copie d'écran, c'est bien le sujet. Si tu me réponds, réponds dans le sujet s'il te plait, et le sujet est le journal (une bidouille pour faire plus qu'une copie d'écran).

C’est bien une capture d’écran qu’il fait. Seulement il s’arrange pour que la fenêtre de son navigateur soit plus grande que son écran pour avoir une plus grande résolution et la fait via non pas son système mais son navigateur.
Il aurait le même résultat avec un écran avec une plus grande résolution, et cela sans cette bidouille.

XMPP est modulaire et c’est l’une de ses plus grandes force et faiblesse. Quand on parle à un connaisseur d’XMPP, il nous le présente comme un protocole multi-usages qui permet de faire des choses merveilleuses (et c’est vrai dans l’absolu). Mais quand on doit le présenter à quelqu’un, on ne peut le présenter que comme un protocole de messagerie, en mentionnant qu’il y a des projets en cours pour de la visio-conférence ou du microblogging tout simplement parce que dans les faits c’est loin d’être au point et quand ça l’est, ce sont les logiciels qui ne suivent pas. Tel serveur supporte ça, tel client supporte ça…

Bref, XMPP et les XEP c’est génial mais pour l’utilisation c’est assez « ça tombe en marche quand tout va bien ».

Pourquoi ne pas instaurer des versions d’XMPP ?
« pour prétendre faire du XMPP version 1, il faut implémenter pleinement et de manière fonctionnelle les XEP a, b et c ».
Pour la version 2, il est nécessaire d’implémenter en plus les XEP d, e et f.

Cela inciterait les développeurs à implémenter les XEP, offrirait plus d’homogénéité et facilité la vie des utilisateurs.

Je suis un utilisateur d’XMPP, j’aime ce protocole, mais je suis déçu de ne pas pouvoir en utiliser toute la puissance.

montre que l'équipe des dev de Gimp est hermétique aux suggestions des utilisateurs

Les utilisateurs n'ont pas à imposer leurs idées aux développeurs. On peut trouver que certains choix sont mauvais, on peut essayer d'argumenter et d'échanger avec les développeurs, mais ils restent ceux qui prennent les décisions au final.

Je ne dis pas que le fonctionnement actuel soit idéal, j'aimerais plutôt une boite de dialogue de ce genre.

Cette image est au format PNG. Souhaitez-vous l'enregistrer en format PNG ou XCF ?
                [PNG]                      [XCF]
[ ] Se souvenir de ce choix pour cette image

et avec une configuration globale dans le logiciel.

Les développeurs voient les choses autrement ? C'est dommage, mais ils restent les développeurs.

Je réagis surtout sur le fait que non, les utilisateurs ne peuvent pas forcer les développeurs à faire les choses comme eux l'entendent.

Le curseur est très bien placé je trouve. C’est le juste milieu entre technique et simplification, je sais tout ce que tu as expliqué pour le moment mais pour ceux qui ne connaissent XMPP que de nom mais qui s’intéressent à son fonctionnement, cela me semble très bien fait, en partant du début et en progressant petit à petit.
Bonne continuation.

Je ne sais pas d'où ça vient, mais certains conférenciers ont exprimé la volonté de diffuser leur vidéos sans cette clause.

C'est dans l'onglet "Information" sur chaque vidéo (CC-BY-NC-SA principalement). Pour le téléchargement par BitTorrent certains voulaient attendre l'upload de toutes les vidéos puis faire un torrent PSES2015, je ne sais pas si ça va être mise en place ou pas.

Si vous souhaitez télécharger les vidéos, sachez que j'ai récupérer leurs urls. Comme je ne suis pas très sûr que ça soit voulu, je ne les postes pas ici mais je vous invite à m'envoyer un petit message sur XMPP (mon adresse est renseignée dans mon profil) pour les obtenir.

Bonne soirée et oui les conférences citées plus haut méritent bien d'être regardées.

"ne vaut pas le coup" est un meilleur argument que "les gens sont habitués"

Quelle différence ?
Pour moi, c’est un seul et même argument « Cela ne vaut pas le coup de changer l’icône car les gens sont habitués et que le coût de changer leurs habitudes est plus élevé que le gain obtenu. »

Le fait de garder une interface similaire à celle d'avant est un bon conseil en termes d’interface utilisateur qui te semble si chère.
Un utilisateur apprend à utiliser un logiciel, si tu le forces à modifier ses habitudes, il se sent perdu, presque trahi par cette nouvelle version.
Tout dépend des modifications, je te l’accorde mais tout de même c’est une réaction courante.
Il suffit de voir les réactions d’utilisateurs à la disparition du menu démarrer sur un certain système d’exploitation.

L’interface et les habitudes qu’a un utilisateur avec un logiciel est quelque chose de très important si on tient au confort de l’expérience utilisateur.

Et cela même si c’est en contraction totale avec la logique ou l’évolution du logiciel, il est donc nécessaire de trouver un bon équilibre entre évolution et conservation, ce qui n'est pas toujours simple et dont la vision peut être très différente selon les gens et les contextes.

Pour la réalisation de la dépêche L’expérience artistique sous GNU/Linux, cette proposition serait la bienvenue par exemple !

L'intuitivité d'un logiciel n'est pas forcément inversement proportionnelle au nombre de fonctionnalités !

Le bon agencement des fonctionnalités, ainsi qu'un accès simplifié et clair à celles les plus utilisées sont des critères qui définissent davantage si un logiciel est intuitive ou non.

Jehan< a très bien résumé l’intérêt de ce système.

Cette initiative est intéressante, car elle essaye de fournir une solution similaire à celle de Windows dans GNU/Linux, on aurait ainsi les avantages de l’une des méthodes qui gomment les inconvénients de l’autre.
La plupart des utilisateurs se moquent de la version du logiciel qui tourne sur leurs machines, l’important c’est généralement la stabilité et la sécurité. Chose que fournissent déjà les distributions.
C’est dans les cas où l'on attache une importance particulière à la version du logiciel que cela pose problème.

On peut très bien imaginer qu’avec ce standard, on puisse diffuser des versions par la distribution comme à l’heure actuelle et à côté des versions plus récentes ou au contraire des versions LTS.
Ces versions pourraient indiquer des dépendances dont la version est sans importance (et donc ne pas consommer d’espace ni de bande passante supplémentaire en profitant de la version de la bibliothèque disponible sur le système) et d’autres dont la version serait importante, et packagées dans le logiciel.

Le problème de ces dépendances serait toujours le possible manque de stabilité ou de sécurité, mais plusieurs points sont alors à prendre en considération :

• Les logiciels diffusés ainsi devraient être minoritaires en nombre à ceux qui sont installés à partir des dépôts des distributions et uniquement installés à la demande de l’utilisateur, ils seront donc peu nombreux.
• Comme je l’ai dit, on peut imaginer un système de dépendance qui puisse également utiliser les versions des bibliothèques du système.
• Avec un standard de package de ce genre de programme, il est possible de lister les programmes qui utilisent des dépendances obsolètes et essayer de mettre à jour les logiciels concernés ou uniquement leurs dépendances.
• la taille occupée par les logiciels est généralement relativement faible par rapport aux données utilisateurs (chez moi, ce rapport est de l’ordre de 1 :100 et je pense que chez beaucoup il doit au-moins être supérieur à 1 :10). Pas sûr que quelques dépendances en double soit très handicapant de ce côté-là.

Finalement cette solution pourrait augmenter les possibilités offertes par le monde GNU/Linux dans l’installation de logiciels, mais il faut que les choses soient bien faites, en n’ignorant pas cette problématique de sécurité et de stabilité.

Je me demande si les ports BSD permettent l’installation de plusieurs versions d’une même dépendance ?

Ah j’ai oublié de parler de Blender.

J’ai déjà eu à utiliser son api pour faire quelque chose de similaire à ton idée et faire de Blender un outil collaboratif ne se fera pas sans un changement dans son code interne, l’api possède des limitations à ce niveau-là et malgré les hacks existants ton projet ne me semble pas actuellement réalisable. Il faudrait en parler aux développeurs de Blender si cette question les intéresse. Comme il est possible que je me trompe.

• Ne pensez-vous pas que le fait de refuser la connexion à des réseaux comme Facebook, Twitter, Google+ peut empêcher la transition de gens qui seraient potentiellement intéressés mais pas encore tout à fait prêt à quitter ses réseaux ? Si oui, est-ce un choix pleinement assumé ? Des passerelles développées par d’autres pourraient-elles être intégrées à votre projet ?
• Qu’est-ce qui vous fait dire que la technologie n’est pas neutre ? Est-ce parce que certaines technologies facilitent certains usages alors que d’autres les empêchent ?
• La version native pour téléphones et tablettes vise Android ? Firefox OS ? Ubuntu ? OSX ?
• Quel public pour la commercialisation d’un boitier pré-installé ? S’il est peu averti, il y a tout l’aspect sécurité et maintenance à la charge d’un utilisateur qui n’est peut-être pas forcément à l’aise avec ça, du coup comment cela sera géré ? Si c’est pour un public averti, quel intérêt pour ce dernier ?
• L’intégration à Firefox me semble plus intéressante que celle à des logiciels comme Freecad ou Blender.

Beau projet soit dit en passant et bon courage pour demain.

Je peux pas te laisser dire ça, il y a pleins de gens dans les commentaires qui ont montré des exemples similaires à ceux que tu critique, envers les hommes cette fois-ci.

Combattre le sexisme et nier le sexisme antihommes est ridicule. Zenitram en parler un peu plus haut.

Comment peut-t-on prétendre qu'un sexisme envers un sexe n'existe pas ? Qu'il soit négatif et/ou positif, femmes et hommes subissent les effets du sexisme.

Et ceux qui refusent d'y croire sont au-moins autant sexistes que ceux qu'ils prétendent combattre.

Beau combat mais incompris, même (et surtout ?) par ceux qui pensent savoir, c'est triste tout de même car de toute évidence le monde se porterait mieux en excluant le sexe dans l'analyse des comportements, des aptitudes intellectuelles et des passions des personnes. On en est loin malheureusement, mais essayons d'avancer.

http://www.madmoizelle.com/sexisme-anti-hommes-242205

Siffler un garçon dans la rue, même si ce n’est pas très fin, ne peut pas être considéré comme « sexiste » au même titre que siffler une fille

Donc un même acte ne devient sexiste que lorsque qu'il est répandu ?
Ou alors le fait qu'il soit sexiste ou non dépend du sexe de celui qui le fait ?
Curieux.

Non sérieusement si des commentaires «dans l’autre sens» sont courants (ce qui reste à démontrer…)

Le sexisme antihommes serait à démontrer, le sexisme antifemmes évident ?

L’humour, éternelle excuse pour justifier tout et n’importe quoi. Je vous conseille de lire cet article, ainsi que les articles liés: ça, ça et ça.

Pourtant une partie de ma citation est :

ce qui ne signifie pas pour autant se laisser marcher dessus

Ce que je souhaitait dire, c'est qu'il y a un juste milieu à trouver car dans le cas contraire les gens se braquent, campent sur leurs positions respectives, et le sexisme reste là, davantage amplifié.

On a droit à un commentaire qui ressort l’excuse classique des féministes qui ne s’attaquent pas au vrais combats, qui présuppose de ce que les intéressée pensent de la situation, et qui compare une oppression à un cas particulier.

Il me semble lire bien plus d'attaques dans les commentaires que de remarques sexistes, c'est l'objet de ce paraphrase. Et je n'ai pas dit que le sexiste était un « faux » combat, seulement que sur linuxfr.org il y en aurait d'autres à mener.

Bizarrement, tous les commentaires de l’auteur et ses partisant·e·s sont dans le positif, tandis que la plupart des commentaires affirmant le caractère sexiste de l’expression se sont mystérieusement retrouvés à -10.

Quand je vois que ton journal est actuellement noté -3, j'imagine que tu vas penser que la communauté linuxfr.org est forcément sexistes, sans imaginer qu'ils puissent objectivement le trouver « inutile » ?

Je n'ai pas lu de réaction de ta part face à la proposition du journal, en aurais-tu une ? Car là il y a bien un effort d'aller vers l'utilisateur pour lui permettre de chiffrer ses mails avec plus de facilité.

Si tu considères la protection de la clef privée comme un problème important, en quoi ta solution fait-elle mieux que ce qui existe déjà ?

Ma solution (qui tient plus de la proposition car comme déjà expliqué n'est pas parfaite) est une réponse à la volonté de démocratisation du chiffrement des échanges entre utilisateurs, pas une amélioration de la sécurité des clés privées. Elle n'apporte donc rien de ce coté là, mais propose de faciliter l'accès au chiffrement aux utilisateurs.

Je pense que la protection de la clé privée pose plus de problèmes que la clé publique, mais les deux reste sensible mais avec des critères différents.

Si je devais proposer une solution réalisable à l'heure actuelle, elle ressemblerait à cela :
Une extension Firefox pré-installée qui permet de se connecter à son compte mail, génère un couple de clé, publie la clé publique sur un serveur de clé et peut chiffrer la clé privée avec un mot de passe.

Du coté expéditeur, lorsqu'on souhaite envoyer un mail à quelqu'un, on essaye de trouver une clé publique sur les serveurs de clé (pas fiable, car n'importe qui peut poster), mais l'extension proposerait à l'utilisateur d'envoyer un mail automatique pour recevoir la clé publique par mail. Cette partie de vérification de clé publique par envoi et réception de clé peut très bien être automatique.

Si un attaquant essaye de mettre une mauvaise clé sur les serveurs de clé, cela serait détecté par la vérification par mail.

En revanche, un fournisseur de compte mail peut très bien se faire passer pour vous sans vérification supplémentaire. Mais on peux très bien imaginer un système de niveau de sécurité :
0 : Pas de clé publique connue, chiffrement impossible
1 : Clé publique trouvée sur un serveur de clé, mais pas vérifier par mail
2 : Clé publique trouvée sur un serveur de clé et vérifier par mail
3 : Clé publique vérifier par un canal sécurisé
4 : Clé publique vérifier lors d'une rencontre physique

Ce n'est pas parfait mais il me semble que ça fonctionnerait pas mal, tout en restant accessible à tous

En ce moment, il me semble que le HTTPS soit de plus en plus utilisé. Certes ça n'est pas parfait (autorités de certifications, etc.), mais ça augmente le niveau globale de sécurité.
Et ça fonctionne, car c'est transparent pour l'utilisateur dans la plupart des cas.

Oui, alors attention car en effet HTTPS est l'exemple que donne souvent les gens pour montrer que le chiffrement pour tous et sans apprentissage est possible.
Mais ce n'est pas tout à fait la même chose, car HTTPS nécessite aussi un échange de clé, sauf qu'il est transparent à l'utilisateur pour la simple raison qu'il se produit au moment de l'échange. Quelque chose qui n'est pas adapté au mail.

(A et B représentent des adresses mails et des comptes associés)
- A génère un couple de clé, dit à B qu'il souhaite une connexion chiffrée en joignant sa clé publique
- B génère un couple de clé, et envoie à A sa clé publique
- A envoie à B le message chiffré
- B peut déchiffrer le message de A, et lui envoyer une réponse chiffrée

(sans compter les attaques MITM)

En sachant qu'un mail peut mettre du temps à arriver ce n'est pas réaliste, mais cela fonctionnerait dans d'autres protocoles comme XMPP, c'est même le principe d'OTR.

Donc tout cela fonctionne très bien pour des échanges en temps réel, mais pas pour du mail par exemple.

S/MIME je ne connais pas trop, mais on ne peut pas critiquer les faiblesses des autorités de certifications et proposer S/MIME comme solution de chiffrement.

chiffrement avec GPG, pour les geeks, ça fonctionne bien.
Mais il existerait(?) une méthode entre les deux
…
cat text.txt | convert -size 480x -font "Helvetica" -pointsize 16 caption:@- -type BiLevel text.png

Oui d’accord. :)

Bon admettons qu’il soit intégré au logiciel et qu’il ne pose pas de problème d’accessibilité, en quoi cela règle le problème du chiffrement, ta solution en n’étant pas ? Sans compter l’OCR qui donne de très bons résultats.

Sinon je viens de publier un journal pour répondre à cette problématique.

C'est mal comprendre mon propos, qui est qu'on ne peut pas utiliser GPG de façon sécurisée sans en comprendre un minimun les mécanismes et les précautions à prendre.

La génération d'une paire de clef pourrait se faire directement à l'installation.

Visiblement, ça fonctionne ainsi pour les nouveaux utilisateurs. (je n'en suis pas un, la création d'une clé ne m'as donc pas était proposée)

Tous les messages devraient être signé de base, et si on a une clef d'une personne : le mail devrait être directement crypté sans rien demandé de plus.

C'est le cas.

La clef publique (ou son fingerprint) peut aussi être attaché au mail signé

C'est le cas.

ainsi le plugin de la personne en face peut récupérer la clef toute seule.

C'est sûrement possible, mais ce n'est pas sécurisé. Quelqu'un peut se faire passer pour toi et envoyer à tes contacts une mauvaise clé.

C'est bien de critiquer pour voir les problèmes, le truc c'est de le faire après utilisation.

Et dans tous les cas, vous ne pouvez pas retirer l'étape de vérification des identités et des clés.