ThibG a écrit 53 commentaires

Ah bah si on se lance là-dedans, quelques recommandations de jeux vidéos dispos sous linux et sans DRMs :
* Undertale : à ne surtout pas manquer, un jeu de rôle rétro très inspiré de Mother et Earthbound, un peu lent, pas très joli, mais des musiques qui vous resteront dans la tête, des personnages plus drôles et attachants les uns que les autres, un univers travaillé et plein de surprises !
* Shovel Knight : encore du rétro, de la plateforme cette fois, gameplay relativement rigide et exigeant, beaucoup de contenu à se mettre sous la dent
* Oddworld: New'n'Tasty : remake plutôt réussi du premier Oddworld, l'Odyssée d'Abe, un jeu de plateforme plein de charme
* Night in the Woods : plutôt une histoire interactive avec des éléments de plateforme, avec une ambiance très singulière ; la fin est un peu décevante
* Factorio : vous aviez encore une vie ? Désolé.
* Orwell : je recommande moins chaudement que les précédents, mais c'est un jeu intéressant

Il est dispo sur GOG, dont un argument de vente est de n'avoir jamais de DRMs : https://www.gog.com/game/epistory_typing_chronicles

Je rajoute que c'est un bug identifié, qui vient a priori d'être corrigé dans le git: https://bugzilla.gnome.org/show_bug.cgi?id=760745

J'ai eu un problème de copier-coller similaire : parfois, quand je colle depuis le presse-papier, gnome-shell prend 100% de CPU et ne traite quasiment plus les autres événements, ce qui rend la machine inutilisable. J'avais rapporté le bug, mais je n'ai jamais pu l'identifier précisément : tout ce que je sais, c'est que ça arrive en collant (dans une application wayland native comme dans une application X11), mais pas quand je viens immédiatement de copier. Copier quelque chose dans le presse-papier peut faire revenir les choses à un état à peu près normal, mais c'est délicat étant donné que gnome-shell ne répond quasiment plus.

Edit : depuis, je ne colle que des trucs très récemment copiés, et je ne suis pas retombé sur le problème. Il a peut-être été corrigé.

Pour préciser, c'est la partie crypto qui est intéressante, et elle est plutôt bien spécifiée, mais ça ne semble pas être le cas du protocole d'échange de messages (qui est d'ailleurs a priori différent entre Signal et Whatsapp).

Il est alors un peu dommage que le protocole ne semble être spécifié formellement nulle part.

https://fr.wikipedia.org/wiki/Double_nationalit%C3%A9#Allemagne je dis ça je dis rien

« en prenant le premier prototype », donc environ 300€

À regarder aussi du côté d'OSVR: http://www.osvr.org/
Il s'agit à la fois d'un casque plus cheap et d'un projet libre d'infrastructure pour la VR. Il y a d'ailleurs un plugin pour les versions de développement de l'Oculus Rift (en utilisant le SDK proprio par contre).

Par contre, ceux qui ont kickstarté le projet (en prenant le premier prototype) vont recevoir gracieusement le Rift (oui, celui à 700€).

Après, je ne sais pas si le passage à Facebook change grand chose finalement. Ça a peut-être mis le focus un peu plus sur le mobile (Gear VR) et Windows, mais le tout avait toujours été proprio et il n'y a jamais eu d'annonce comme quoi ce serait libre.

De plus, comme depuis le début, le SDK et les runtimes sont proprio.
Au début, les sources étaient disponibles (mais pas libres), du coup on pouvait étudier facilement le protocole et le documenter pour réimplémenter ça librement. Ce n'est plus le cas.
Enfin, le tout a été brièvement disponible pour linux, mais ce n'est plus le cas non plus.

Bref… on va devoir trouver un peu de temps pour faire du reverse engineering !

La seconde attaque a eu lieu le 14 décembre et non le 14 novembre !

En ce qui concerne ton second point, la conformité à PCI-DSS interdit formellement :
- le transit, en clair, de Primary Account Numbers, à savoir de numéros de carte
- le stockage, en clair, d'un PAN
- le stockage, sous quelque forme qu'il soit, du CVV

Ainsi, non seulement les numéros de carte sont obligatoirement transmis de manière chiffrée, mais leur stockage est également soumis à régulation, à savoir un chiffrement double en utilisant 2 clés possédées par des personnes physiques différentes.

J'ajouterais qu'il est interdit de logguer les numéros de carte, à défaut de faire subir à ces logs les mêmes contraintes de double chiffrement.

Enfin et pour en finir sur la sécurité, la certification exige que soient menés chaque trimestre :
- un scan externe des infras, par un ASV (ex, qualys)
- un scan interne des infras, via un outil répondant aux exigences PCI (ex, Nessus)
- une revue des règles firewall
- une revue du fonctionnement des caméras
- une revue des ports réseau et VLANs par lesquels transitent des PANs

Merci pour ces précisions (je lirai les documents de certification PCI-DSS plus tard).
Une question que je me pose, par contre (n'y vois aucune attaque), c'est si les données de HiPay sont considérées par CloudFlare comme des informations sujettes à la certification PCI-DSS.

Pour rebondir sur "des infras non contrôlées", le problème reste entier, utilisation de Cloudflare ou non :
- akamai ? même deal
- hébergement chez online ? même deal, tu passes par leur AS et leur matos réseau
- hébergement en propre ? même deal quand même, t'es pas un tier1 tu dois forcément passer par un transitaire quelconque, et mécaniquement, ses équipements réseau

Je ne vois pas pourquoi les équipements réseau du transitaire auraient tes données en clair, ce qui est le cas de CloudFlare.

Pour ce qui est de ton dernier point, je te signale quand même que c'est OP qui sort un article avec des faits fondamentalement incorrects, et que ces derniers ne peuvent rester sans réponse.

Lesquels ?

Sous-entendre que CF espionne les clients HiPay est dommageable pour la réputation des deux entités, et basé sur de la pure spéculation.

Je ne sous-entend pas que CloudFlare l'a fait, le fait, ou le fera, je parle de la possibilité technique qu'ils ont de le faire.

Oui, CF pourrait intercepter les numéros de carte, au même titre que Akamai, Amazon, ou n'importe qui d'autre dont les équipements servent à un moment ou un autre pour faire transiter les données.

Je vois qu'on est d'accord, en fait.

Non, CF ne le fait pas car ils subissent tout comme les autres entités certifiées PCI, un audit annuel au cours duquel leurs logs sont épluchés, leurs configurations vérifiées, leurs équipes auditées.

C'est aussi simple que ça, quand on est pas sûr de ses infos, il ne faut pas propager de fausses rumeurs, ce qu'a fait OP sans chercher à approfondir sa réflexion, ou tout simplement à contacter les équipes techniques pour avoir des réponses à ses questions.

C'est pourtant la base de toute entreprise vaguement journalistique (et pense bien qu'écrire un article à portée publique en est une), que de s'assurer de la véracité des informations que l'on poste.

Encore une fois, je ne dis pas que CloudFlare espionne, je dis juste qu'ils en ont la capacité, et que ça me paraît dommageable de donner autant de confiance à un même acteur. Désolé s'il semblait en être autrement.

Nous tenons à la disposition de quiconque la demande l'Attestation Of Compliance PCI-DSS délivrée à HiPay.

Merci pour l'information !

Premièrement, CF a été choisi pour faire office de frontal contre les attaques volumétriques et autres script kiddies, tu m'excuseras mais on a pas tous 8x40gb d'uplink.

Je n'ai jamais dit le contraire, et je suis tout à fait d'accord que se prémunir d'attaques par déni de service distribué n'est pas chose aisée. Mais cela pourrait se faire au niveau IP et ne pas nécessiter de déchiffrer le trafic TLS (après, difficile de faire la différence pour l'internaute…)

Deuxièmement, que le prestataire technique choisi soit CF, tartampion ou TamaireInc, les numéros de CB passent toujours sur les interwebs , via des AS hors de ton contrôle et des équipements hors de ton contrôle.

J'ose espérer que tu n'es pas en train de dire que chez HiPay, ces données passent en clair sur les interwebs et par différents AS.

Si a un moment donné tu as cru que le TLS apportait ne serait-ce qu'une once de sécurité, c'est peut être le moment de te re pencher sur le sujet.

Euh… on laisse tout tomber alors ?

Troisièmement, HiPay est certifié PCI-DSS depuis 2013 (CF est également certifié PCI-DSS d'ailleurs).
Je t'invite à jeter un oeil rapide à la liste des requirements dressés par le Council pour avoir son attestation de compliance.

Je lirai ça à l'occasion.

Tu as sûrement une alternative viable techniquement et économiquement, envoie ton CV et on en parlera pendant ton entretien.

Désolé, mais je ne suis pas actuellement à la recherche d'un emploi, mais merci pour la proposition.

En effet, il y a différentes utilisations possibles de CloudFlare. Tu peux l'utiliser purement comme un CDN pour des choses comme des libs JS, de façon « centralisée » ou « multi-site » comme tu dis, et cela pose moins de problème. Enfin, cela pose toujours problème, mais c'est facilement mitigé par quelque chose comme https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/

Mais l'usage principal de CloudFlare, et la manière dont ils t'encouragent à l'utiliser, c'est comme un truc magique qui va gérer l'intégralité de ton trafic, bloquer les attaques par déni de service, automatiquement mettre en cache les données statiques… c'est d'ailleurs la seule vrai façon d'éviter les attaques par déni de service : si tu as un bout qui dépasse, il peut être attaqué, si tu es derrière CloudFlare, ils peuvent absorber la charge.

En effet, le terme “Homme du milieu” est employé abusivement, c'est un tiers de confiance, mais pas toujours très visible de l'internaute (voire pas du tout, à moins de regarder qui annonce l'adresse IP de la machine à laquelle il se connecte).

On peut pas vraiment comparer au FAI, qui, lui, n'a pas accès au trafic chiffré.

CloudFlare est au milieu des deux correspondants, a tout en clair, et alors qu'on lui demande de faire suivre les requêtes sans modification (à part pour l'usage d'un cache et pour bloquer les attaques), est en position de surveiller et altérer le trafic, ce qui serait a priori indétectable des deux côtés.

Arf, zut ! Oui, ce serait bien de corriger ! Au passage, il y aurait une autre une petite chose à changer (quelle idée d'écrire si tard…) : « Une grosse partie de leur marketting considère » → « Une grosse partie de leur marketting consiste ».

Le prestataire est Cap Collectif, je ne sais pas comment il a été choisi, ni pourquoi il a choisi CloudFlare.

Allez, je la ramène ici aussi. Tout le site est derrière CloudFlare, de toutes façons. Donc tout le trafic passe par une boîte US qui a tout en clair (c'est eux ton correspondant TLS). Ils semblent aussi utiliser Google Analytics. Bref, voilà.

Tout le monde fait tous les calculs parce qu'un nœud ne fait pas confiance aux autres.

L'intérêt du protocole, c'est que tout le monde soit d'accord sur le contexte dans lequel les contrats ont été appelés, de manière complètement décentralisée.

Le nombre de personnes ayant fait le calcul ne change strictement rien pour aucun des nœuds. Pour un nœud, c'est toujours pareil : soit il est lui-même à l'origine d'un block (il a réussi à miner), soit un voisin lui en fournit un nouveau. Il ne sait pas combien de nœuds ont calculé la même chose que ce voisin, et il ne peut pas lui faire aveuglément confiance. Du coup, il vérifie le block, et pas de miracle, ça nécessite de refaire les calculs.

Bref, si les calculs sont faits par tout le monde, c'est pas pour rassurer quelqu'un qui n'aurais pas fait le calcul, mais parce qu'aucun des nœuds ne fait confiance aux autres, et refait le calcul pour lui-même.

Tu parles de BOINC, mais ça n'a rien à voir, ce n'est ni le même modèle ni le même but. Le but n'est clairement pas de faire du calcul distribué, mais que tout le monde s'accorde sur le résultat d'exécution des programmes, et surtout sur le contexte dans lequel ils s'exécutent.

Ce n'est pas le fait qu'il y ait X personnes qui ont trouvé le même résultat qui te garantit la fiabilité de ce dernier, mais le fait que tu calcules toi-même pour vérifier.

Après, je suis effectivement d'accord que ça limite fortement la complexité et le nombre d'exécutions de programmes sur le réseau, vu que le temps de calcul n'augmente pas avec le nombre de nœuds du réseau.

D'ailleurs, plus le réseau va grandir, plus il y aura potentiellement d'appels à des contrats, ce qui nécessitera des nœuds de plus en plus performants (c'est évidemment vrai pour bitcoin aussi, mais peut-être pas dans ces proportions, étant donné qu'Ethereum a pour vocation de faire tourner du code arbitraire), laissant les plus modestes incapables de vérifier la blockchain…

C'est bien ce que j'ai compris, mais du coup, ça pose une limite assez forte soit sur les nœuds vérifiants les blocks (miners ou pas), soit sur les programmes que l'on peut exécuter dans Ethereum : le temps de calcul disponible pour Ethereum étant celui du nœud du réseau en ayant le moins…

C'est tout l'enjeu de la compilation reproductible (et points bonus si la compilation est certifiée). Je ne sais pas si c'est fait/prévu pour les langages haut niveau mis en avant pour Ethereum.

De ce que je comprends (arrêtez moi si je dis des conneries), l'ether fonctionne à peu près comme les bitcoins, l'ether étant introduit par le minage, et récupéré par les mineurs qui acceptent des transactions/contrats.

Même si Ethereum semble promouvoir le fait de concevoir des monnaies au-dessus d'Ethereum, non corrélées à l'ether, ce dernier est nécessaire pour toute transaction, et devient donc un ressource importante, et potentiellement rare.

De plus, la dynamique me semble assez différente de Bitcoin : si l'ether n'est pas considéré comme une monnaie, il y a peu de raisons que les utilisateurs « lambda » reçoivent de l'ether, ils vont surtout le dépenser pour appeler des contrats… ce qui peut arriver à la situation où quelqu'un a beaucoup d'argent dans une monnaie implémentée sur Ethereum, mais n'a pas d'ether pour faire le dépenser.

De manière similaire, l'exemple du financement participatif (outre le fait qu'un bénéficiaire de la levée de fonds pourrait faire un don suffisant pour passer le but pour « tricher ») nécessite que quelqu'un active le contrat pour rendre les sous, non ? S'il y a beaucoup de participants, ça peut coûter pas mal d'ether ?

Quelle était donc cette affaire ? Je n'ai pas suivi !