Le 07/02/2024 à 23h 21

Tu remarqueras la présence du « généralement » à la fin de ma phrase 🤣
Dans 99.9999% des cas le DPO ne pourra de toute façon comparer avec rien du tout donc pièce inutile…

Le 07/02/2024 à 17h 12

Alors pour le coup, la saisie de la CNIL n’est pas exclusif de la saisie des juridictions civiles et pénales. La triple saisie est même ce qui devrait être fait à chaque fois…

Et la procédure à la CNIL est au final aussi longue et pénible que le civil et le pénal…

Le 07/02/2024 à 17h 10

Alors la dernière boîte qui m’a dit être conforme RGPD s’est fait un poil pilorisée pour violation du RGPD en long en large et en travers 🤣.
Il y a aussi « le meilleur logiciel RGPD du marché » qui a une petite plainte de ma parte pas piquée des hannetons sur le bureau de la CNIL.

Le 07/02/2024 à 17h 08

La demande de communication d’une pièce d’identité est une non conformité RGPD généralement.
C’est la CNIL qui le dit.
https://twitter.com/CNIL/status/1039175426571231232

Le 06/02/2024 à 18h 56

(J’ai BlueSky aussi à la limite hein… Quitte à utiliser un truc pas conforme RGPD, autant que ça soit celui qui assume clairement ne pas l’être ? 🤣)

Le 06/02/2024 à 18h 53

Pardon, pas 573. Ça c’était le mois dernier. 799 maintenant. Pfiou, faut la suivre celle-là… 🤣

Le 06/02/2024 à 18h 50

En vrai ? Non.
AEPD, la CNIL espagnole, c’est 20% de budget (15 millions contre 20 millions de mémoire) et d’effectifs (180 contre 220) en moins pour le même volume de plaintes (~14 000/an). Par contre AEPD c’est déjà 573 condamnations, contre 40 pour la CNIL… 😑
Ce n’est pas un manque de moyen, c’est un grave manque d’organisation… et des ordres politiques de ne pas toucher au business… 😡

Le 24/05/2023 à 20h 53

Je les tanne quasiment chaque jour hein 🤣

Le 24/05/2023 à 20h 04

Ou juste pas du tout. 30 sanctions par an nous place bon dernier dans les APD européennes vu le nombre de plaintes et le budget disponible.
Les sanctions étant majoritairement non publiques, elles ne permettent pas non plus de faire avancer la conformité globale, les autres responsables de traitement n’étant pas informés de la violation/sanction et donc allant continuer à faire la même chose que l’entité sanctionnée, en attendant sa propre sanction qui ne viendra jamais.

Dans mon cas personnel, c’est aussi plus de 80 plaintes de déposées avec quasiment aucune réponse concrète de la CNIL, pour des violations notoirement identifiées, connues et déjà traitées par la CNIL.
Ça se solde le plus souvent par un simple courrier de la CNIL après 3 ans de délai et jamais aucune sanction à la clef.

Au global, un responsable de traitement a tout intérêt à violer la loi. La CNIL ne le sanctionnera quasiment jamais, le risque encouru étant ridicule et se soldera certainement plutôt par un simple courrier de rappel à la loi au bout de X années de violation, et autant de bénéfices engrangés par rapport à avoir respecter la loi.

Même les grosses sanctions de la CNIL (380.000€ à Doctissimo) sont juste astronomiquement anecdotique (0.05% du CA annuel) et ne pousserons pas les entreprises à se mettre en conformité (Doctissimo a certainement encaisser 5 à 10× le montant de la sanction entre temps).

Le 17/12/2022 à 12h 35

DavidLibeau a dit:

Alors pourquoi tu écris l’inverse sur ton blog : “Il suffit d’un seul des 3 critères [nécessité, proportionnalité, et le troisième n’est même pas mentionné] en défaut pour ne pas pouvoir se placer sous le régime de l’intérêt légitime.”. C’est faux, la nécessité c’est dans TOUS les cas. Pas que pour l’intérêt légitime. Merci d’arrêter de dire n’importe quoi sur le RGPD.

Je ne vois pas en quoi ce que je dis est en contradiction avec mon blog. La nécessité est effectivement partout, et dans le cas de l’IL, il faut en plus la légitimité et la proportionnalité.

Faux, considérant 47 du RGPD : “Le traitement de données à caractère personnel strictement nécessaire à des fins de prévention de la fraude constitue également un intérêt légitime du responsable du traitement concerné.”

Considérant 50 de EDPB 2/2019 : la fraude peut être sous IL uniquement si proportionné et nécessaire. Généralement elle ne l’est pas et enlever la lutte contre la fraude coûte moins cher pour moins de données moins de complexité moins de rétention et moins d’intrusion sur les droits, le tout sans remettre en question le service (vu qu’elle n’est de toute façon pas une obligation contractuelle parce que pas nécessaire au service, même considérant). Dans l’extrêmeme majorité des cas, la lutte contre la fraude ne passe pas le triple test de l’IL permettant de fonder le traitement sur cette base légale. Beaucoup de condamnation et de requalification en consentement à ce sujet par exemple sur le scoring bancaire pour l’obtention de prêt.

Le 15/12/2022 à 17h 44

fdorin a dit:

Autrement dit, quand tu prends le soin de minimiser les données et les traitements, l’usage de la base contractuel couvre un large panel de cas d’utilisation, sans avoir besoin de recourir au consentement.

Encore une fois : non. La minimisation des données est l’étape initiale et obligatoire du RGPD, peu importe la base légale derrière. Toute finalité non minimale pour ton business est de toute façon à rejeter et est non conforme by design.
Pour chaque finalité survivante à la minimisation, tu dois alors trouver la base légale à retenir, et les GL montrent que dans 90% des cas, tu devras les placer sous le strict régime du consentement parce que ne sera pas strictement nécessaire à la réalisation du service (et non de ton business), donc pas contrat ni intérêt légitime, ou proportionné, donc pas intérêt légitime.
Tu vas du coup devoir encore élaguer dans tes finalités pour ton business tout en maintenant celle pour ton service, ou les placer sous consentement qui généralement tue ton business (mais pas ton service).
Tout le monde confond complètement les 2 mondes. Ton business n’est pas ce dont le RGPD traite, mais exclusivement ton service.
La gestion de fraude, l’amélioration du service, le suivi de ta compta ou de tes objectifs marketing ne sont PAS plaçables sous l’intérêt légitime ou le contrat (parce que non nécessaire à la fourniture du service ou trop intrusif sur la vie privée des utilisateurs par rapport aux avantages retirées) alors qu’ils sont nécessaires à ton business.

Et c’est là que ça coince en général, parce qu’on a construit la plus grosse partie de la viabilité de nos business sur des choses qui sont aujourd’hui illicites de par le RGPD. À de très rares exceptions près, aucune entreprise ne sait conserver son activité une fois passé le crible de la minimisation et de l’affectation des finalités restantes à des bases légales recevables.
L’intersection des bases légales acceptables au point de vue business par rapport à celle légalement acceptable pour le service est proche du vide. Typiquement pour le suivi marketing de ta boîte, il est inenvisageable de placer ça autre part que contrat ou intérêt légitime (parce que tes chiffres n’ont de sens que si tu touches 80-100% de ta base client) alors que le RGPD t’impose le consentement (et que tu en toucheras maximum 20-30% du coup, personne n’ayant d’intérêt à consentir à ce suivi pour tes beaux yeux).
Et même sous consentement, en touchant seulement 30% de ta base client, tes KPI business perdent du coup tout intérêt et deviennent non nécessaires puisque plus pertinentes, ne devraient du coup plus passer le crible de la minimisation et devraient être purement et simplement supprimées, conduisant à la fermeture de ta boîte qui ne sait plus fonctionner sans.

EDPB est au dessus de la CNIL (de toutes les CNILs en fait) et est là pour gérer les cas transfrontaliers et les problèmes. Elles émets des avis sur des cas spécifiques qui ont valeur jurisprudentiel afin d’harmoniser les interprétations au niveau européen lorsqu’elle est saisie (soit par elle-même, soit par une autorité).
Son rôle est aussi de publier des lignes directrices, des recommandations et des bonnes pratiques. Mais cela reste des recommandations et non des exigences. C’est très important car cela signifie que le non respect des guides n’est pas directement sanctionnable. C’est donc très différent d’un avis contraignant.

Non. Son boulot est d’homogénéiser l’ensemble des décisions des 27 APD et aucune APD ne peut traiter un dossier sans consulter EDPB avant. Tout décision, ligne directrice, avis ou sanction d’une APD est rendue exclusivement après consultation de l’ensemble des 26 autres APD. Toutes les APD n’ont donc d’autres choix que d’appliquer strictement les lignes directrices émises par EDPB (en auto-saisie ou sur demande d’une APD). Si ce n’était pas le cas, l’obligation de cohérence serait violé.
EDPB a d’ailleurs bien rappeler la règle récemment : https://twitter.com/EU_EDPB/status/1600414827607998464

Le 15/12/2022 à 13h 15

Oui

Le 15/12/2022 à 12h 35

fdorin a dit:

Beaucoup de si…. Mon propos, c’est juste pour dire que, contrairement à ce que tu affirmes, les bases contractuelles remplissent beaucoup de cases.

Non. Correction, les gens voudraient qu’elles cochent beaucoup de cases. Les GL sur le sujet sont très claires : ce qui est couvert par cette base légale doit être extrêmement limité (considérant 27 & 28 page 10 des GL ²⁄₂₀₁₉).
De la même manière qu’avoir un intérêt légitime pour une finalité ne veut pas automatiquement dire que tu peux te prévaloir de la base légale de l’intérêt légitime (il faut encore prouver la nécessité et la proportionnalité), une clause que tu mets dans ton contrat ne relève pas automatiquement de l’obligation contractuelle (il faut aussi prouver la stricte nécessité).

Un mauvais choix de base légal pour un traitement en particulier ne signifie pas que les bases légales autres que le consentement sont inutilisables en général.

Non, mais que si tu t’es planté de base légale au départ, tu es en non conformité. Même si tu aurais pu te placer sous une autre base pour effectuer légalement la finalité.

Là dessus, je ne suis absolument pas d’accord. Un avis de 2014 n’a pas autant d’effets juridiques alors que celui-ci a été remis à plat depuis. Il peut émettre des avis, mais pas des avis contraignants.

L’avis de 2014 a le même poids légal que celui de 2019. D’ailleurs il est cité en référence dedans (note 26 de bas de page 16) et ses idées sont reprises textuellement.
Tant que ces GL WP29 (nouvellement EDPB) pré 2016 ne sont pas abrogées par EDPB (anciennement WP29), elles ont légalement le même effet que celles émises par EDPB post 2016.

Par contre, il peut émettre des décisions contraignantes, dans le cas d’affaires en particulier, par exemple, lorsqu’il y a mésentente entre différentes autorités nationales. Ou alors j’ai mal compris son rôle.

Tu as mal compris. EDPB est comme la CNIL, un organe de droit souple. Ils ne peuvent pas légalement émettre d’avis « contraignant » au sens réglementaire (et se font sanctionner s’ils le font, comme la CNIL au Conseil d’État pour l’interdiction des cookie wall). Mais étant aussi les organes de sanction, forcément que c’est contraignant parce que les APD (via EDPB et l’article 63 du RGPD) n’iront pas à l’encontre des GL édictées et approuvées collectivement et à l’unanimité par elles.
L’absence de contrainte au sens légal du terme ne veut pas dire qu’il n’y aura pas sanction à la fin et reconnaissance de la non conformité via le non respect de ces GL. ET donc en pratique contrainte de respecter ces GL quand même, sous peine de sanction.

Le 15/12/2022 à 10h 02

fdorin a dit:

Attention quand même, l’un des documents n’est qu’un avis de 2014, soit 2 ans AVANT l’adoption du RGPD, et 4 ans avant sa mise en application !

Ce sont des avis contraignants de WP29 aka EDPB, qu’ils retranscrivent régulièrement en version moderne. L’avis de 2014 a autant d’effets juridiques que celui de 2019 donc.

Dès lors qu’on respecte le principe de minimisation de la collecte des données, c’est-à-dire collecter uniquement ce dont on a besoin, ce n’est vraiment pas un souci.

Si justement. Non seulement tu dois minimiser, mais en plus tu dois avoir la bonne base légale. Si tu as minimisé sous le régime de l’intérêt légitime ou du contrat mais qu’une APD requalifie ça en consentement parce que ni 6(1)f ni 6(1)b n’étaient possible, ton traitement n’en reste pas moins tout autant non conforme et illicite.

Mais en faisant les choses correctement, contrat, intérêt légitime et obligation légale remplissent très bien leur rôle dans beaucoup de cas.

Encore une fois non justement. Beaucoup trop de finalités sont placées sous ces bases légales alors qu’elles peuvent et ne devraient qu’exclusivement relever du strict consentement et sont donc de facto illicites.
Il faudrait que je retrouve la condamnation en question, mais un mauvais choix de base légale, ça veut possiblement dire une condamnation à devoir effacer l’intégralité des données collectées (oui, parce qu’on ne peut pas changer de base légale en court de route). Et ceci même si elles étaient minimisées. C’est TRÈS con quand c’est l’intégralité de ta base client :)

La minimisation serait en fait même violée, parce que sous la base du consentement, les données n’auraient juste pas du/pu du tout être collectées (et on fait difficilement plus minimal que pas de données du tout).

Le 14/12/2022 à 22h 46

fdorin a dit:

Qu’appelles tu GL ?

GuideLines, en l’occurence
https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines-art_6-1-b-adopted_after_public_consultation_fr.pdf pour le 6(1)b « nécessaire au contrat » et https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp217_fr.pdf pour 6(1)f « intérêt légitime »

J’ai l’impression que tu parles d’expériences dans le domaine bancaire

Je parle de fraude au sens général du terme, ça inclut aussi par exemple les portiques de sécurité de la RATP qui ne peuvent pas être couverts par « nécessaire au contrat » (tu peux parfaitement les supprimer sans compromettre le service « je paie pour que tu me transportes de A à B »).
Et la RATP ne peut pas non plus le mettre sous l’intérêt légitime parce que la CNIL a dit que les pass nominatifs étaient non proportionnés à l’objectif visé.

Beaucoup de choses que tu considères comme pouvant relever du 6(1)b ou du 6(1)f ne peuvent en fait pas les utiliser (lire pages 9 et suivantes des GL ²⁄₂₀₁₉) et seul le consentement reste valide.

Après, comme tu le soulignes, il y a aussi des obligations légales. Tu cites le LCB-FT. Si tu fais ce qui est demandé au niveau de la loi, tu n’as absolument aucun souci pour légitimer ta base légale.

Certes, mais encore une fois, il faut que ça relève réellement d’une obligation légale et pas de vague truc décidés par des entités de droit privé (et il y en a plein).

Je connais beaucoup plus le domaine de la santé que le domaine bancaire. Et les bases utilisées sont soit le contrat, soit l’obligation légale, soit l’intérêt général (sauvegarde du patient). Si tu ne t’écartes pas de ce que tu dois faire (par obligation légale ou contrat), il n’y a aucune difficulté à justifier un traitement.

Tout à fait, mais dans les cas généraux, le consentement est réellement le truc qui représente 90% des cas au doigt mouillé. Et c’est bien tout le problème : personne ne veut avoir à gérer du consentement et donc plutôt que de virer le traitement, ils le font rentrer aux forceps dans contrat ou intérêt légitime…

J’ai surtout l’impression que tu imagines de nombreux traitements (ex: lutte contre la fraude bancaire) à la marge d’un traitement de base (ex: fournir un compte en banque)

Pas vraiment. EDPB a bien indiqué dans GL ²⁄₂₀₁₉ considérant 50 que la « lutte contre la fraude » (au sens large, pas que bancaire) ne pouvait pas relever du contrat mais uniquement de l’intérêt légitime. Et que l’intérêt légitime devait être nécessaire et proportionné en plus d’être légitime.

Tous tes services annexes ne peuvent par définition pas relever du contrat et devraient relever de l’intérêt légitime ou du consentement.
Dans BEAUCOUP de cas, ton intérêt légitime tombe et du coup sauf consentement, ton traitement annexe devient impossible.
Traitement annexe que toi, prestataire du service, tu considères pourtant comme une condition nécessaire à la réalisation de ton contrat et n’envisage pas du tout de faire sans. En d’autres termes, tu n’envisages pas de pouvoir rendre ton service principal sans être en non conformité RGPD à cause des finalités secondaires…
Tu as le choix entre fermer ta boîte ou être en non conformité. Je te laisse deviner ce que la plupart des gens choisissent…

Le 14/12/2022 à 17h 29

Jean_G a dit:

Et puis ici on peut l’utiliser pour un CDN car c’est un impératif pour la réalisation du contrat (= la délivrance du service de CDN).

Non, c’est justement refusé comme « nécessaire au contrat » parce que tu sais parfaitement fournir le même service sans CDN du tout (tu le fais toi-même avec ton infra en propre). C’est du coup exclusivement « intérêt légitime » mais c’est très fragile surtout fonction des CGU de ton CDN en face (cf décision CDN US et Schrems II). Et consentement impossible à appliquer en pratique. Ça veut donc dire juste devoir supprimer le CDN tout court car aucune base légale valide.

Le 14/12/2022 à 17h 27

fdorin a dit:

mais dans beaucoup de traitements, les obligations légales ou une base contractuelle sont largement exploitable.

Tu devrais relire les GL sur l’intérêt légitime et l’obligation contractuelle. Tu serais très surpris…
La lutte contre la fraude bancaire ? Ni nécessaire au contrat (tu peux rendre le service sans, c’est juste que tu prends un risque) ni intérêt légitime (les scores réalisés nécessitent des violations de vie privée non proportionnés aux risques), consentement obligatoire… 🤣 Pas obligation légale parce que ce sont des obligations (PCI-DSS) d’organismes privés (GIE-CB ou autres) et non des textes réglementaires (seul LCB-FT l’est).
Les cas réellement obligation légales, contrat ou intérêt légitimes sont BEAUCOUP plus rares que tu ne le penses en pratique.

Le 14/12/2022 à 15h 50

the_Grim_Reaper a dit:

Sauf si t’as une obligation légale supérieure liée à ton activité

Oui tout à fait, faut toujours regarder ton cas à toi dans tous les cas. Mais en tout cas le nécessaire au contrat ou l’intérêt légitime ne tiendrait pas sur un compte « trop » inactif.

Le 14/12/2022 à 15h 49

aurel_gogo a dit:

Tiens question à ceux qui savent.

Pour faire simple, on va dire que ma boite est une sorte d’intermédiaire technique qui permet à des PME de faire du marketing direct par SMS.

Quand un utilisateur se désabonne, on lui donne une adresse email de contact si il veut plus d’info.

Un des désabonnés m’a demandé de supprimer toutes les données qu’on a sur lui. Pas de soucis, j’ai que le téléphone, donc c’est simple…. Sauf que je lui ai dit que je ne supprimerai pas son numéro de téléphone car cela serait contraire à sa demande de désabonnement.

En gros, pour qu’un utilisateur ne reçoive plus de SMS, il me faut une “blocklist”, si je supprime son numéro, il n’est plus dans la blocklist et peut donc recevoir des SMS marketing et c’est donc en opposition avec son souhait.

Ai-je bien répondu, à votre avis ?

Oui et non. La blackliste devrait être constituée par exemple d’un hash du n° de téléphone et pas du numéro de téléphone en clair. En théorie ça reste de la pseudonymisation et donc ça reste une DCP, mais ça élimine les possibilités de détournement de finalité à partir de la base de donnée des blacklists.
Et la bonne réponse serait du coup « on a bien purgé toutes vos données, par contre, sauf opposition explicite de votre part, on conserve le hash pour notre blacklist et vous voyez, on respecte bien la minimisation de données et les mesures techniques de protection »

Le 14/12/2022 à 15h 45

fdorin a dit:

Déjà, présenter le consentement comme obligatoire avec 5 exceptions n’est pas vraiment juste. Le RGPD ne met absolument pas en avant une des bases légales pour légitimer un traitement. Il existe 6 bases légales, dont le consentement. C’est quand même très différent d’un régime à base d’exception tel que présenté dans l’article.

En fait si quand même. Les 2 autres régimes généralement utilisables (contrat et intérêt légitime) sont soumis à un régime TRÈS strict (beaucoup de choses que tu envisages sous l’un de ces 2 régimes y est généralement explicitement interdit), du coup le consentement est trop souvent la seule base légale licite.

Le 14/12/2022 à 15h 36

La CNIL conseille (aka sanctionnera sinon ) 1 à 2 ans de conservation des données d’un compte inactif. Après il faut purger.

Le 13/11/2019 à 15h 00

C’est plus compliqué que ça. Les trackers sont sur des sous-domaines délégués à Eulerian via le DNS. Eulerian arrive donc durant la résolution récursive du résolveur DNS, et est donc invisible au niveau de la résolution (non récursive) du client… Les systèmes de blocage simples sont complètement aveugles à cette étape, qui n’a lieu que dans le résolveur.
Le système de pi-hole ne fonctionne pas nativement du coup pour bloquer ce type de merde, il faut descendre encore plus bas…

Le 30/01/2018 à 11h 07

skankhunt42 a écrit :

Tu à totalement raison mais le crétin il doit manger et payer ses factures…


J’aurais bien aimé mettre 1200€ dans autre chose que des frais de justice tu vois. Genre dans de la bouffe.
Donc que tu manges c’est une chose, mais fait en sorte que ça ne soit pas au détriment de la bouffe des autres hein… Surtout ceux qui sont simple particuliers et qui ne peuvent pas compenser la perte sèche par du chiffre d’affaire supplémentaire. Ou les PME qui vont se retrouver Wanacryptées et mettre la clef sous la porte.

 


skankhunt42 a écrit :

J’ai vraiment des doutes… Ils désactivent chaque modules avant d’upgrade puis les réactive un par un ? Sachant qu’en moyenne c’est 90% de page blanche sur les modules non natifs et qu’il y à pas forcément une mise à jours de dispo ( payante ) ? Ensuite il le reconfigure / test un par un ? Pareil pour le thème ? Sachant que bien évidement la doc ne sera dispo au mieux qu’un an plus tard, sois six mois avant une nouvelle version ?

 
Ils vont péter les rotules de la boîte de presta qui s’occupe du Wordpress jusqu’à ce que ça retombe en marche oui. Et te résilie ton contrat si tu ne fais pas ce qu’il faut pour préserver l’intégrité du réseau Internet malgré leur relance. Une boîte éthique qui fait correctement son boulot quoi.
Et oui, ils ont des gens à temps plein qui passent leur vie à passer sur des milliers de Wordpress et à les configurer aux petits oignons, à les tester un par un, à thuner les caches quand ça merde, à désinfecter les Wordpress quand ils se font powner (oui, parce que même à jour, ça reste l’infection ces trucs…).

Le 29/01/2018 à 23h 33

skankhunt42 a écrit :

Du coup la sécurité n’est pas la non plus… 

   Tu prends de l’infogérance et du coup c’est ton presta qui s’occupe de faire les majs de sécu et le reste. Cfhttps://www.planet-work.com/ par exemple, qui gère ton Prestashop ou Wordpress de A à Z, y compris niveau sécu et maintenance. Mais forcément, c’est pas le même tarif que ton truc à 600€ complètement bâclé…          

           

skankhunt42 a écrit :

L’hébergeur possède un minimum de protection, si un truc louche est détecté sur le réseau le serveur est déconnecté en moins de 10 minutes et tu reçois un email d’abuse. Après j’ai rajouté un FW + RKhunter donc c’est quand même protégé un minium.

   Tu peux aller expliquer ça à l’OCLCTIC s’il te plaît ? Leur dire de me rendre les serveurs qu’ils m’ont saisi, puisqu’il est a priori impossible que j’ai été la cible d’une attaque de la part d’un très grand industriel français qui a refusé de faire ses mises-à-jour de sécurité et que son hébergeur lui aurait couper le réseau le cas échéant quand l’ensemble de son parc info a été infecté par un ransomware ? Ça m’a un peu coûter 1200€ juste en frais de justice si tu veux. Et je suis un simple particulier.         

   Parce qu’un crétin comme toi leur a vendu des daubes pas maintenues (du genre du Windows XP ou du Samba 1) pour économiser 2 francs 6 sous…     

Et FW + RKHunter, ça te protège TOI d’une attaque externe, mais c’est juste totalement inutile si tu tournes avec un Wordpress de 10 ans de retard ou un PHP antédiluvien… Ce sont les autres que tu vas toi-même attaquer à coup de spam, de DDoS ou plus vicieux, de relai pour un C&C d’un ransomware ou l’hébergement de contenu pédo-pornographique…

Le 28/01/2018 à 21h 48

skankhunt42 a écrit :

Si l’ont part du principe qu’il faut être tout le temps à jours pour la sécurité alors un commerçant devra repayer tous les an et demi pour repartir “from scratch”, sachant qu’un site met parfois plusieurs mois pour être développé… A ce tarif c’est limite une équipe dédié en permanence et tous le monde ne peut pas ce l’offrir.

 
Si tu n’as pas les moyens de te payer un kiné complet, tu ne vas pas pour autant chez le charlatan du coin 3× moins cher mais qui risque plus de te niquer complètement ton dos qu’autre chose…
C’est pareil en info : si tu n’as PAS les moyens de mettre correctement un site en ligne (maj de sécu, veille technique, maintenance…), tu ne mets PAS un site en ligne.

Ton site qui te rapporte 600€ mais livré sans maintenance ni mise-à-jour de sécurité, il me coûte peut-être à moi 100€/mois parce que ton super client va venir faire du DDoS chez moi, ou m’envoyer du spam, ou servir de plate-forme de relai de Wanacry, ou que sais-je encore.

Le 26/01/2018 à 15h 09

Erwannys a écrit :

Si tu souhaites t’améliorer et un peu automatiser la génération du site statique tu élabores un framework XML/XSL, toujours avec Notepad++ ou Brackets.


Ça existe déjà hein :P

https://middlemanapp.com/
https://jekyllrb.com/
https://gohugo.io/
https://blog.getpelican.com/

Mais forcément, tout le monde ne jure que par la « simplicité » de Wordpress, qui n’est simple que si on oublie de mentionner le coût et la complexité de la maintenance…

Le 26/01/2018 à 14h 58

Erwannys a écrit :

L’histoire de l’informatique est un éternel recommencement fait de médiocrité. 


Je connais bien, j’ai démissionné de mon ancien poste justement parce que je ne supportais plus la médiocrité ambiante…https://blog.imirhil.fr/2016/07/21/no-more-ssii.html

Le 26/01/2018 à 14h 51

aeris22 a écrit :

Si tu vends du Wordpress ou du Dotclear, tu DOIS vendre le support, la maintenance et les mises-à-jour de sécurité, sinon t’es juste en train de prendre ton client pour un con et tu es en train de mettre en péril MES serveurs, parce que les Wordpress que TU déploies se retrouveront dans 6 mois dans un botnet de DDoS ou d’envoi de spam qui viendront impacter MES services.


Wordpress CORE, c’est 47 vulnérabilités sur 2017 :https://www.cvedetails.com/vulnerability-list/vendor_id-2337/product_id-4096/yea…
Soit minimum une mise-à-jour par semaine.
Je ne te parle pas des plugins en plus, ou si tu as customisé le cœur…

Si tu utilises JetPack en plugin, tu as déjà 2 mises-à-jour critique
depuis début janvier :
https://www.cvedetails.com/product/21637/Automattic-Jetpack.html?vendor_id=11700

PHP, ça a été 43 vulnérabilités aussi :https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/year-2…
Donc idem, 1 maj par semaine aussi.

Le 26/01/2018 à 14h 40

skankhunt42 a écrit :

La semaine j’ai un site à faire pour une amie je lui propose donc 1500€ au lieu de 600€ ? Elle refusera.


Si tu veux vendre des trucs quick&dirty à pas cher, tu vends du truc quick&dirty à pas cher.
Un site statique en middleman ou jekyll ou hugo ou pelican ou whatever, ça coûte 600€ et ça ne nécessite ni maintenance ni mise à jour de sécurité. Mais oui, elle fera bien moins de chose qu’avec un DotClear ou un Wordpress.
Si tu vends du Wordpress ou du Dotclear, tu DOIS vendre le support, la maintenance et les mises-à-jour de sécurité, sinon t’es juste en train de prendre ton client pour un con et tu es en train de mettre en péril MES serveurs, parce que les Wordpress que TU déploies se retrouveront dans 6 mois dans un botnet de DDoS ou d’envoi de spam qui viendront impacter MES services.

Le 26/01/2018 à 14h 07

skankhunt42 a écrit :

A un moment donné tu à besoin de manger
donc tu travaille et le client à besoin d’un site à pas trop cher alors
il ce tourne vers toi. Si tu lui explique direct que tous les 5 ans il
va falloir repasser à la caisse pour une histoire de compatibilité /
sécurité il ira voir ailleurs…


Et c’est comme ça qu’on se retrouve avec des boîtes infectées par Wanacry et autres saloperies, parce que certains prestataires préfèrent taire les coûts cachés de sécurité et de mise-à-jour juste pour remporter les marchés…

Le 26/01/2018 à 12h 34

Ce n’est pas très compliqué à faire « juste pour du test ».
C’est plus embétant pour un contexte de production.
On attend la communauté pour nous filer un coup de main à supporter des architectures qu’on ne supporte pas officiellement :)

Le 26/01/2018 à 12h 10

Cozy est multi-utilisateur depuis la version 3 justement.
C’est même ce problème qui a fait qu’on a du tout recoder en v3 pour autoriser à scaller par rapport à la v2 où il fallait une stack complète par utilisateur.

Le 26/01/2018 à 12h 06

Imbattable au niveau de la compatibilité, mais au niveau de la sécurité ?
Si PHP5 a été déprécié, ce n’est pas pour rien… Cette version souffre de GRAVES problèmes de sécurité puisque n’est plus supportée officiellement par l’équipe PHP. Donc plus de correctif de sécurité depuis plusieurs années déjà…

Idem pour ta version 0.8 de EasyPHP, juste t’as un trou de sécurité juste monstrueux sur ta machine quoi…

Le 25/01/2018 à 14h 05

Tu vas sur quelle URL pour tomber là-dessus ?

Le 25/01/2018 à 13h 49

Elle arrive, elle arrive :)

Le 28/07/2017 à 18h 58

Je proteste ! Je vais poursuivre la CIA pour contrefaçon !

Le 11/07/2017 à 09h 45

hellmut a écrit :

sinon j’ai maté la conf d’Aeris qui est intéressante bien qu’un peu technique.
surtout on voit pas du tout les slides, ce qui ne facilite pas les choses.

Les slides sont dispos en ligne à côté de la vidéo hein :P

Le 29/05/2017 à 14h 44

Ben ils se sont juste fait un peu powned leur réseau parce qu’ils n’ont appliqué aucune des préconisations minimales de sécurisation d’un réseau ? " />

Le 19/05/2017 à 00h 35

C’est pour éviter le syndrôme « clef à molette » que je fais aussi très gaffe avec des systèmes 2FA ou autres.
Même en me cassant les genoux, si je n’ai pas accès à ce dont j’ai besoin, je ne suis pas en mesure de donner les infos nécessaires au déchiffrement :)

Le 18/05/2017 à 15h 53

Ça ne fonctionne pas vraiment comme ça avec les services cachés.

Le C&C va se connecter au réseau Tor, avec un simple client Tor indistinguable des autres clients.
Choisir quelques relais au pif (les introductions points), les contacter en établissant un circuit Tor (3 relais) et leur dire « si quelqu’un demande xxxx.onion, merci d’utiliser ce circuit ». Les introductions points publient dans une DHT gérée par l’ensemble des nœuds dit « HSDir » en disant « si vous voulez contacter xxxx.onion, vous pouvez joindre les introductions points suivants »

 Quand un client Tor standard veut accéder à xxx.onion, il demande aux HSDir quels sont les introductions points (toujours via un circuit Tor hein !), se connecte à l’un d’entre eux, et est mis en relation avec le service caché (derrière un circuit Tor lui-aussi donc).

Ni le HSDir ni l’introduction point ne connaissent l’adresse IP réelle de quelqu’un, ni du service caché ni du visiteur du service caché.
Saisir les nœuds Tor n’apprendra rien de plus :

• Les HSDir se répartissent la DHT (d’où le D de DHT), donc vous ne pouvez pas lister facilement tous les introductions points d’un service caché
  


• Si tu as du bol de saisir un introduction point, déjà dès que tu le fous offline, tu perds de toute façon le circuit Tor du service caché (qui changera de toute façon régulièrement) et même en le gardant online, ben tu ne fais que voir un autre nœud Tor (vu qu’il y a un circuit Tor entre l’introduction point et le service caché)
  


• Si tu saisis une autre machine, pareil, tu n’as aucune info supplémentaire, tu vois juste au mieux le client du service caché si tu tombes sur un guard, mais tu n’as aucun moyen de savoir que c’est bien lui (vu que le circuit ira vers un middle derrière, qui n’est ni l’introduction point ni le hsdir ni le service caché), et dans tous les autres cas tu ne verras que des tas de circuit Tor non identifiable…
  
  Bref, laissez les nœuds Tor tranquille SVP, ça ne sert à rien de les saisir…

Le 18/05/2017 à 15h 18

Il n’y a aucun nœud de sortie dans le cas de wanacry. Ça utilise des .onion, donc ça reste 100% en interne du réseau Tor. Le C&C n’est qu’un client Tor comme les autres, au même titre que toutes les machines infectées.

Le 18/05/2017 à 15h 11

0 aussi. Trop consommateur en temps et en ressources, trop intrusif sur le réseau, trop de données à collecter et à stocker. Pour une utilité proche du 0.

Le 18/05/2017 à 14h 31

Change de beau-frère.

Même si la NSA avait cette puissance de frappe (elle l’a effectivement sûrement sur le papier), elle réservera son usage à des cas extrêmements spécifiques vu le coût astronomique pour péter ce genre de choses.

C’est exactement pareil pour la France hein, ils ont des moyens « secret défense » utilisables si besoin pour péter de la crypto même très robuste. Juste ils ne s’en serviront jamais pour un pékin moyen.

Le 18/05/2017 à 14h 28

C’est généralement un OS standard sur lequel on vient installer Tor.
Les opérateurs de nœuds sont plutôt bien conscient des problèmes et installent correctement les choses.
Au niveau du kernel ou du firewall, personne n’est assez con pour activer un niveau de log aussi détaillé (IP source/destination pour CHAQUE paquet TCP entrant et sortant). Tu fusilles ta machine en 10min si tu actives un tel log de toute façon (300Mbps de trafic symmétrique dans mon cas = bobo les disques et la latence réseau…).
Et comme déjà précisé, même si un tel log existe, il est inexploitable : tout le trafic sortant de ma machine n’était que de la communication avec d’autres nœuds Tor (donc ni un client final ni un service caché ni quoi que ce soit d’autre qu’un des 6000 autres nœuds Tor du réseau). Donc tu n’en apprendras strictement pas plus que si tu n’avais pas eu ce log.

 La collecte des logs sur des nœuds Tor n’est pas décemment pas envisageable si tu veux remonter à une source ou à une destination. Va te falloir trouver autre chose. Et donc arrêter de saisir les nœuds.

Le 18/05/2017 à 14h 08

Non, par défaut les nœuds ne loggent rien. Je pense même que techniquement, rien n’est codé pour permettre un tel journal. La proba de tomber sur un nœud qui log quelque chose est donc vraiment très très très très faible. Je dirais même qu’elle est de 0 sans prendre beaucoup de risque (sinon un nœud malveillant).

Le 18/05/2017 à 09h 54

> combien de noeuds ont pu avoir leurs logs de connexions saisies.

La réponse est simple 0. Il n’y a aucun log sur les nœuds Tor. Jamais.
Partant de là…

Le 18/05/2017 à 08h 47

> si tu possèdes tous les logs
de connexion de toutes les machines

Tu peux t’arrêter là. Comme signaler, il n’existe aucun log de cet ampleur. Même la NSA ne doit pas avoir un tel truc.
 
Même si de tels logs existaient, il faudrait la participation de l’ensemble des pays pour espérer pouvoir faire cette corrélation. Les nœuds en Afghanistan, en Suisse, aux Pays-Bas ou autres zones très protectrices (ou très j’en-foutisme, c’est selon), tu vas pouvoir te brosser pour les avoir.
 
Et même si tu les as, tu te retrouves avec des terrachiés de bouzillions d’information qui sont totalement inexploitables. Parce qu’on ne parle que de 1To de données au total pour mon nœud, mais il y en a un peu plus de 6000 nœuds en tout, dont des 3× plus rapides que moi. Et les informations nécessaires à la corrélation doivent être sur les paquets IP, qui transitent sur des dizaines de routeurs rien que pour faire client Tor → guard.
 
Et même si tu es arrivé ici, comme signalé plus haut, un nœud Tor établit des milliers de connexions avec ses petits voisins, donc pour un unique paquet qui arrive sur un nœud Tor, c’est un bon millier de connexions sortantes qu’il va te falloir analyser. ×3 couches (3 nœuds Tor par circuit Tor). Pour chaque paquet IP. Sur des liens à 100Mbps minimum voire 1Gbps pour les plus gros nodes.

Bref, à chaque seconde, ce sont des milliards de connexions possibles qu’il va falloir que tu parviennes à discriminer pour savoir laquelle correspond réellement au morceau que tu connais (client Tor→guard). Une fois passé le 1er nœud, tu ne peux que constater qu’il existe un bon milliard de circuits Tor établit à l’instant T de l’arrivée du paquet au cul du guard, sans avoir aucune possibilité de savoir quel circuit est réellement celui utilisé pour la communication de ton client Tor.

Et tous ces circuits sont en plus absolument indiscriminables les uns des autres en se basant uniquement sur des méta-données IP.

Tu es donc fucked. Point. Même avec l’historique complet mondial des méta-données TCP/IP.

Les 2 seules attaques théoriques sur le réseau Tor est l’attaque Sybil, puisque si quelqu’un contrôle plus de 66% des nœuds Tor, il a une chance non nulle d’avoir au moins 2 machines à lui sur les 3 d’un circuit Tor et donc de pouvoir désanonymiser tout le trafic qui passe par 2 de ses machines. C’est pour ça qu’on a fait blacklister immédiatement les machines saisies, pour qu’une telle attaque ne puisse pas être possible.
L’autre attaque est le flux shaping. Tu modules le trafic client→guard de manière à avoir un profil de trafic « reconnaissable », ce qui te permet de justement pouvoir discriminer les 1000 flux derrière puisque seuls ceux avec un profil compatible vont t’intéresser. C’est un problème difficile à résoudre pour les réseaux à faible latence comme Tor (I2P n’est pas à faible latence et fixe ce problème en lissant tout le trafic entre les nœuds).

Le 17/05/2017 à 19h 19

Non, il n’y a pas de MAC dans la trame TCP. MAC c’est au niveau de la couche de liaison (couche 2 OSI), ça ne passe pas le 1er routeur et ça se retrouve encore moins dans le gros ternet (couche 3&4).

Le 17/05/2017 à 18h 19

Oui, il y a effectivement I2P aussi, mais il n’est pas/peu utilisable dans ce cas, vu que comme tu le dis tu deviens serveur et client à la fois (plus galère à faire tourner sur une machine chopée in the wild).

Le 17/05/2017 à 17h 58

Non, il n’y aura pas « d’IP à apparaître ». Tu ne verras que X CLIENTS Tor supplémentaires, et encore en espérant que tu sois Guard (ce qui ne sera pas le cas si tu as un comportement mauvais pour le réseau d’ailleurs). Sinon tu ne verras juste rien du tout puisque tu ne fais que discuter avec des nœuds Tor (middle ou exit, puisqu’ici tu n’as pas de vrais exit vers le dehors du réseau).
Donc tout ce que tu peux lister, c’est l’arrivée massive de toutes les machines infectés.
Le HS lui, il sera apparu X mois avant bien tranquillement quand il n’y avait encore personne à s’intéresser à Wannacry, ou bien noyé dans le gros bordel de machines compromises.