La différence est grande entre une opinion (ce que je souhaiterais) et une analyse jurisprudentielle (les orientations que prennent les condamnations) :D
Là il se trouve que la tendance des condamnations me va plutôt bien, mais ça aurait pu ne pas être le cas et ça aurait été tout aussi intéressant à étudier.
Pour moi, ça indique bien qu'un SaaS avec un service pré-existant peut quand même être un data processor (sous certaines conditions).
Aligné, ça reste(rait) possible, mais les conditions ont l’air tellement minces qu’en pratique tu as plutôt intérêt à envisager autre chose (self-hosting ou au moins on premise) qui coûtera moins cher et sera moins complexe administrativement parlant.
Les requalifications de DP en DC sont quand même vachement nombreuses et avec des cas où je n’aurai même pas parié un kopec dessus à l’origine (typiquement celle de l’IAB, certains considérants me semblent complètement hallucinants, comme 328 par exemple…).
Et dans les lignes EDPB, le « a detailed description » me semble assez hors de portée d’une relation de sous-traitance conventionnelle en tout cas telle qu’envisagée en 2022…
Tu dois littéralement collé au cul de ton sous-traitant pour connaître l’intégralité de tous ses petits secrets… à date et surtout sur toute la durée de la prestation. Avec côté sous-traitant de sacrées restrictions dont on n’a(vait) pas l’habitude aujourd’hui (peu de liberté d’innovation, pas de gestion/évolution de son propre produit, en tout cas pas sans accord de tous ces clients, etc).
Ça me semble vachement changer des relations de sous-traitances telles qu’on les connaît aujourd’hui.
En outre, on considère généralement que la définition des finalités du traitement l'emporte sur celle des moyens lorsqu'il s'agit d'établir la responsabilité d'une organisation.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible… En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »…)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases…
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup… 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon… On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP… 🤔
Or, je ne pense pas que tous les services SaaS déterminent eux-mêmes les finalités pour leurs clients. Si un service fournit un chatbot, il peut servir pour des finalités commerciales, ou du support, ou d'autres raisons, et c'est au client de ce service de définir la finalité pour laquelle il compte utiliser le services en question.
Tout à fait, ils fournissent un service « as is » et ce qu’en fait le client est effectivement de sa propre responsabilité.
Mais ils ont aussi fait LEURS propres choix (techniques, infras…), le soft est souvent fournis avec d’autres fonctionnalités qui ne sont pas directement une demande du client (debug & maintenance, au moins, voir ici l’IAPD des Pays-Bas sur ce sujet pour Microsoft Office 365, § 16.2.4 Microsoft does not act as a data processor), ce qui fait qu’ils en deviennent de fait un co-responsable de traitement.
Au final on a 3 bouts distincts : les parties à la charge stricte du client (faire du support sur le chatbot), les parties à la charge stricte du prestataire (maintenance, debug…) mais un gros bout en co-responsabilité de traitement qui représente l’essentiel des finalités (vu que le presta a quasi tout développé de sa propre initiative, donc a minima choisi les moyens).
Pour le cas du ET ou du OU entre les 3 clauses, ici l’APD a fait son taff en pointant tous les manquements, mais le texte est clair : c’est bien finalité OU moyens. Et il me semble qu’il existe une ligne directrice EDPB qui formalise justement cette compréhension du OU, je vais la rechercher :)
C’était le taff de l’APD d’aligner le plus de non-conformités possibles pour estimer l’amende à la fin. Ils ont condamné pour l’ensemble de l’œuvre, mais ils auraient pu condamner juste avec un seul chapitre.
Tu peux avoir un logiciel SaaS hébergé en Europe par une société européenne.
Non justement. La décision prise envers l’IAB Europe s’applique également aux SaaS européen du coup.
Il n’y a de toute façon pas de notion de localisation des services dans le délibéré, uniquement de responsable de traitement contre sous-traitant. Une boîte EU hébergeant un service SaaS EU est du coup tout aussi dans la mouise.
Après ça va certainement mettre du temps à percoler avec d’autres condamnations arrivants à des sanctions pour ce même motif, mais c’est ce que j’entrevois entre les lignes du délibéré.
Schrems II a éradiqué les US. Panoptikon a éradiqué le SaaS.
Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
Si tu as une bibliothèque à disposition pour analyser les iCal et sortir les données souhaitées dans une base de données supportée par Metabase, ça fera le travail sans problème !
Avec 2 bouts de python ou de ruby, ça doit être rapide à faire.
C’est exactement le point. La BI telle qu’on la faisait avant est mise pas mal à mal avec l’entrée en vigueur du RGPD en 2016.
Beaucoup des traitements effectués avant sont dorénavant très touchy niveau RGPD, avec des bases légales frileuses.
EDPB est assez clair sur le sujet : ces stats ne sont pas une obligation légale et n’ont généralement pas un intérêt légitime suffisant devant les dérives possibles (oui, le RGPD adore raisonner selon les possibilités théoriques et non selon les réalités pratiques), la seule base légale a priori recevable sauf justification très forte est le consentement.
Et la plupart des utilités supposées de la BI disparaissent encore plus avec du consentement, parce que ça veut dire que tes chiffres deviennent imprécis (fort probabilité de refus du consentement = données non fiables = pertes d’intérêts = encore moins de légalité du traitement) et que le process de détention des données devient trop chronophage et coûteux par rapport à la plus-value qui en ressort (gestion de la rétractation du consentement nécessitant la suppression des données et des traitements ultérieurs, droits d’accès et rectifications, DPIA avant intégration au registre de traitement, etc)
Les 2 sont importants. J’ai peut-être donné l’impression de ne parler que de l’un, mais ce n’est pas le cas. Et à mon sens les 2 sont assez liés, une nouvelle finalité risque fort de réclamer une nouvelle base légale.
C’est particulièrement vrai dans le cas de la BI, les données à dispo sont souvent sous une base légale de collecte (obligation légale ou nécessaire au contrat) incompatible avec des finalités statistiques qui elles nécessitent obligatoirement de l’intérêt légitime voire du consentement d’après EDPB.
Et les produits de BI sont souvent marketés comme « vous avez des données dont vous ne faites rien, sortez-en des stats utiles ». Typiquement chez Metabase, « Meet the easy, open source way for everyone in your company to ask questions and learn from data ».
De plus, le RGPD interdit l’ajout préventif de finalité/base légale « pour des besoins ultérieurs » selon les mots de EDPB. Les besoins doivent être factuels, présents et justifiés. Les finalités de collectes sont du coup nécessairement incompatibles avec l’ajout ultérieur à la volée de filtres/recroisement dans des outils comme Metabase.
C’est uniquement mon point soulevé : la facilité d’ajout de dashboard/filtre/graphe, de recroisement ou d’accès à la donnée est en décalage comparée à la rigidité et la difficulté d’ajout de telles nouvelles finalités dans le cadre d’une conformité RGPD correcte.
C’est un peu plus compliqué que ça. 2 traitements différents portant sur la même donnée peuvent effectivement avoir des bases légales différentes, mais la donnée initiale elle-même a déjà fait l’objet d’un traitement (sa collecte) avec une certaine base légale et tous les traitements derrière ne peuvent du coup qu’avoir une base légale compatible avec la base légale initiale.
Il est impossible de faire un traitement ultérieur d’une données sous la base légale « intérêt légitime » si la base légale initiale de la collecte de cette donnée ne contenait que « consentement ». Ton point de collecte définit le périmètre maximal qu’il ne sera jamais possible de dépasser sur l’ensemble des traitements ultérieurs présents ou futurs qui sera fait sur ces données.
Et mon point est justement là : Metabase est la porte ouverte à toutes les fenêtres, les utilisateurs envisageant difficilement quelles requêtes vont être toujours dans le scope légale de la collecte initiale. Ce n’est pas parce que la donnée est à dispo et que tu peux en sortir un joli dashboard sous Metabase que ce que tu fais est autorisé.
Et ce n’est pas parce que tu renseignes ton registre de traitement avec le nouveau traitement et sa base légale qu’il devient magiquement légal s’il reste incompatible avec la finalité et base légale de la collecte initiale.
Voir par exemple les condamnations pour finalités incompatibles avec la collecte initiale de la donnée.
Tu manipules très souvent des données personnelles hein… Ou dit autrement des stats sans données personnelles à l’origine ou à la fin sont généralement assez peu intéressantes.
Et bien penser aussi qu’un traitement de données personnelles, c’est aussi la collecte de la donnée, et pas uniquement l’extraction ou affichage ultérieur. Si l’origine même de ta donnée contient une donnée perso (facture, paiement, etc), alors sa réutilisation pour des finalités autres que initiale est encadrée voire proscrite.
Typiquement des stats sur ta compta sont aussi touchées par le RGPD parce que ta facture initiale contient de la donnée perso, même si la stat finale, elle, ne contient pas de données perso.
Et la base légale (« intérêt légitime ») et finalité (« suivre mon commerce ») de tes stats seraient plutôt en contradiction avec la finalité initiale de la facture (« encaisser un paiement ») et sa base légale (« obligation légale »). Tu n’as donc pas le droit de partir de ton stock de facture pour établir tes stats de commerce (détournement de finalité et utilisation d’une base légale incompatible).
Si Metabase est un outil extrêmement puissant, c’est aussi typiquement le genre d’outil qui sera très rapidement bordeline niveau conformité RGPD.
Le fait de pouvoir dynamiquement faire tout plein de requêtes, de recroiser les données dans tous les sens voire mettre à dispo les données brutes non agrégées est la porte ouverte à tous les détournements de finalité.
La conformité RGPD limite souvent la puissance de Metabase, puisque les données brutes doivent nécessairement (article 5.c) être déjà agrégées et leur format interdire (article 5.b) le détournement de finalité, donc de limiter les possibilités de requêtes ou de création de dashboard « à la volée ».
Et Metabase se transforme du coup en « simple » visualiseur avancé permettant de filtrer par date/catégorie des tables pré-définies, perdant beaucoup de sa flexibilité.
Il y a bien d’autres tests que juste les ciphers avec CryptCheck, et beaucoup ne sont pas encore affichés sur l’interface faute d’avoir des personnes compétentes en UI/UX pour me filer un coup de patte :)
En l’occurence le « E » s’explique ici par le manque de HSTS.
Quant au banques, si au moins elles n'obligeaient pas à utiliser des applis merdiques et propriétaires pour le 2FA… Et encore ils n'ont pas osé à la CÉ (ils sont en retard mais bon, c'est pas nouveau).
DSP2 impose(ra) forcément du « propriétaire » à ce niveau.
Plus exactement il impose une 2FA « contextuelle » pour éviter les man-in-the-middle. Ça suppose d’afficher des données supplémentaires à l’OTP pour que l’utilisateur puisse identifier de manière fiable le demandeur de l’OTP.
Dans le cas d’une validation de virement ou de paiement, c’est par exemple le montant de la transaction ainsi que son destinataire, pour éviter un attaquant qui ferait proxy et te débiterait le montant qu’il souhaite à son propre profit si on se limitait au seul OTP.
Dans celui de la connexion, ça pourrait être l’affichage d’un symbole spécifique connu uniquement de toi et de ta banque. Une banque belge dont j’ai perdu le nom avait implémenté ça dans un token OTP matériel d’ailleurs, mais je n’en retrouve plus la référence…
En pratique ça demande(ra) donc du développement spécifique à chaque banque et même si la théorie derrière est libre et commune (T-OTP), chaque banque risque d’avoir sa propre application ou fonctionnement pour couvrir ce besoin de « contextualisation ».
C’est même la raison n°1 de pourquoi les banques préfèrent encore violer la DSP-2 et ont demandé une rallonge de 2 ans pour continuer avec le SMS, elles n’ont actuellement pas de solution conforme à disposition.
D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.
Je veux dire par là que SCSV protège uniquement des attaques (semi) passives consistant à bloquer la connection TCP à la détection d’une connexion TLSv1.2 en espérant que le client va retenter derrière en TLSv1.1.
À partir du moment où on considère un attaquant actif capable d’éditer le flux, alors il shootera SCSV de la même manière qu’il modifierait les paquets pour supprimer les ciphers safe et forcer une connection vers 3DES. Il lui suffit de supprimer le flag SCSV de la demande de connexion TLSv1.1. Le handshake n’étant pas signé…
A noter que 0.2% ça peut être rien pour toi, mais pour un support client de millions de personnes, c'est de la thune à dépenser pour dire aux clients d'upgrader leur bousin ce qui eut assez mal passer. Tu ne peux pas ne pas faire la différence entre des entités qui gèrent TLS 1.3 avec CHACHA20 mais aussi TLS 1.1 et des entités qui gèrent que TLS 1.1.
Axa ou N26 l’ont fait. Je ne vois du coup pas ce qu’il y a d’insurmontable.
PS : pour le downgrade de suite de chiffrement, au temps pour moi, remplacer 1.2 par 1.3… Le besoin est donc surtout de gérer 1.3, et si je comprend bien alors 1.1 peut être encore gérer sans risque pour les clients 1.3.
Ils ont déjà du mal à supporter 1.2, alors 1.3, si on l’a d’ici 10 ans je serais étonné…
Et encore une fois, avoir du 1.3 & des trucs pétés dans la boucle, c’est s’ouvrir la porte à toutes les fenêtres. On ne peut/doit pas parier la sécurité de son bordel sur une conjonction improbable d’éléments divers et variés…
« Alors tu es safe si tu as du 1.3 ou du 1.2 avec du SCSV et je laisse des trucs pétés uniquement sur 1.1 en espérant que tu ne tomberas pas dessus par l’opération du saint-esprit »
D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.
SCSV permet simplement de ne pas downgrade vers TLSv1.1 si le client et le serveur supportent TLSv1.2 (le serveur verra passer une demande en 1.1 avec le flag SCSV et va hurler).
Ça ne permet pas de protéger d’un downgrade de (TLSv1.2) ECDHE-ECDSA-AES256-GCM-SHA384 vers (TLSv1.2) DES-CBC3-SHA qui est pété depuis 2016 et sweet32 si le site en face supporte les 2.
En gros ça protège le protocole (TLSv1.2/1.1/1.0) et pas les ciphers suites (AES, 3DES, RC4…), il faut attendre TLSv1.3 pour corriger ça avec un handshake lui-même signé (en TLSv1.2 il ne l’est pas).
Comme tu pourras le voir ici, une suite de chiffrement permettant d’être A+ est compatible avec la quasi-totalité du monde à l’exception de IE6/XP, qui sont une hérésie en 2020 de toute façon.
Une suite qui serait conforme avec le futur A+ (disparition de SHA-1) est conforme avec l’intégralité de la planète aussi, minus 2-3 trucs complètement obsolètes en 2020…
Mais sinon, oui ça a l'air de faire partie des sites "intégristes" qui ne regardent que si tu supportes un "mauvais" protocoles même si c'est pour supporter des vieux clients sans réduire la sécurité des nouveaux clients
Le problème est que trop de sites se réfugient derrière cette pseudo-compatibilité pour ne pas faire évoluer leur sécurité. 3DES est pété depuis déjà 2016 (4 ans bordel…) et on le trouve encore sur les banques & le reste.
Un navigateur qui ne supporte PAS TLS1.2 ou AES suppose que tu utilises un navigateur/OS type Android 4.3 (><) et moins ou Firefox 26 et moins. Des trucs de 2015 qui étaient DÉJÀ pétés en 2016 et la disparition de 3DES.
Ces sites montrent bien un véritable problème de sécurité pour ne pas avoir fait les mises-à-jour nécessaires et mettre tous les autres utilisateurs (qui eux ont fait les mises-à-jours) en péril…
merci TLS 1.2 et la non possibilité d'inciter à prendre un vieux protocole si au milieu).
Ça c’est globalement faux. Il existe pas mal de moyen de contraindre un site à négocier une suite pétée à partir du moment où le serveur supporte une suite merdique.
Tu peux très bien négocier du AES128-SHA voire du DES-CBC3-SHA alors que tu es bien en TLSv1.2 (cas de google.fr).
L’employeur n’a pas légalement pas besoin de te demander ton avis avant d’utiliser un service de dématérialisation. Il doit uniquement te permettre de t’y opposer, et ceci n’importe quand.
Une fois un service choisi, il relève du coup de l’intérêt légitime pour l’entreprise d’utiliser ce service.
J’ajouterais un 2nd « intérêt légitime + obligation légale » puisqu’on est ici dans le cadre professionnel, donc avec une obligation de subordination qui fait qu’un employeur peut t’imposer ce genre d’outils.
Posté par Aeris (site web personnel) .
En réponse au journal Flatpak.
Évalué à 7.
Dernière modification le 12 octobre 2018 à 19:59.
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Pourtant unattended-upgrades est active par default avec Debian et Gnome: https://wiki.debian.org/UnattendedUpgrades
Je parlais bien évidemment dans le cas de FlatPak et au point de vue du build de l’image, pas au niveau de l’upgrade côté utilisateur.
Dans le cas de Debian, les mises-à-jour ne sont justement pas automatiques.
Un mainteneur intervient manuellement pour mettre à jour son ou ses (quelques) paquets maintenus, s’emmerde à lire les releases notes pour s’assurer que c’est bien ABI compatible avec la dernière version, etc.
Il pousse ensuite son paquet, et tout le monde en profite dans toutes les applications.
Il n’est pas noyé sous la tonne de dépendance dont il n’est même pas supposé être le mainteneur, comme c’est le cas de freedesktop qui va devoir se coltiner les releases note aussi diverses et variées que gpg (j’espère qu’ils ont des cryptologues), xorg (et aussi des experts en matos vidéo), nano, ffmpeg, gstreamer, gcc, cmake, zip et j’en passe.
S’amuser à tester toutes les combinaisons possibles jusqu’à trouver un truc qui tombe en marche capable de builder tout ce petit monde (un libssl 1.2.x pour compiler gnupg 2.2.10, ça passe ou pas ?).
Pousser leur image… Et devoir notifier tous les mainteneurs des applications du dessus pour les mettre à jour et remonter les problèmes de build éventuels (« coucou, on a mis à jour gcc ! il build toujours ton projet ? »).
Qui devront rebuilder leur image, pester contre les mainteneurs de freedesktop (stabilité et reproductibilité vous avez dit ?), etc.
D’ailleurs, rien que de voir actuellement du 1.0.2o en libssl pour freedesktop, ça montre bien le problème…
La branche 1.0.x est obsolète, même Debian est plus à jour quoi…
Et il n’y a pas le patch 1.0.2p qui date pourtant de août 2018 et patche une CVE…
Sinon concernant les tests, la quasi majorités des logiciels libres importants sont aujourd'hui couvert par un nombre de tests suffisamment important pour garantir leur bon fonctionnement dans un environnement donnée
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
encore faut-il que les sysadmins se donne la peine de réaliser ces mises à jours compte tenu du risque que cela représente. Quand tu as la possibilité de réaliser ces mises à jours dans une environnement reproductible, tu n'as plus aucune raison pour ne pas les faire étant données que tu as toujours la possibilité de revenir en arrière si dans le pire des cas tu observais un problème après avoir effectué l'upgrade.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement µclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.
# Oui et ça a même déjà été acté par une sanction
Posté par Aeris (site web personnel) . En réponse au journal RGPD et adresse mail. Évalué à 3. Dernière modification le 10 février 2022 à 12:54.
Cf ici : https://gdprhub.eu/index.php?title=Court_of_Appeal_of_Brussels_-_2019/AR/1006
Le fournisseur a l’obligation de se conformer à ce que tu lui demandes de mettre, quitte à devoir refaire tout son système d’information et à changer de langage si nécessaire.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 3.
La différence est grande entre une opinion (ce que je souhaiterais) et une analyse jurisprudentielle (les orientations que prennent les condamnations) :D
Là il se trouve que la tendance des condamnations me va plutôt bien, mais ça aurait pu ne pas être le cas et ça aurait été tout aussi intéressant à étudier.
Aligné, ça reste(rait) possible, mais les conditions ont l’air tellement minces qu’en pratique tu as plutôt intérêt à envisager autre chose (self-hosting ou au moins on premise) qui coûtera moins cher et sera moins complexe administrativement parlant.
Les requalifications de DP en DC sont quand même vachement nombreuses et avec des cas où je n’aurai même pas parié un kopec dessus à l’origine (typiquement celle de l’IAB, certains considérants me semblent complètement hallucinants, comme 328 par exemple…).
Et dans les lignes EDPB, le « a detailed description » me semble assez hors de portée d’une relation de sous-traitance conventionnelle en tout cas telle qu’envisagée en 2022…
Tu dois littéralement collé au cul de ton sous-traitant pour connaître l’intégralité de tous ses petits secrets… à date et surtout sur toute la durée de la prestation. Avec côté sous-traitant de sacrées restrictions dont on n’a(vait) pas l’habitude aujourd’hui (peu de liberté d’innovation, pas de gestion/évolution de son propre produit, en tout cas pas sans accord de tous ces clients, etc).
Ça me semble vachement changer des relations de sous-traitances telles qu’on les connaît aujourd’hui.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 2. Dernière modification le 07 février 2022 à 15:58.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
C’est aussi plutôt visible dans les lignes directrices EDPB.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible… En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »…)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases…
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup… 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon… On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP… 🤔
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 1. Dernière modification le 07 février 2022 à 11:22.
Tout à fait, ils fournissent un service « as is » et ce qu’en fait le client est effectivement de sa propre responsabilité.
Mais ils ont aussi fait LEURS propres choix (techniques, infras…), le soft est souvent fournis avec d’autres fonctionnalités qui ne sont pas directement une demande du client (debug & maintenance, au moins, voir ici l’IAPD des Pays-Bas sur ce sujet pour Microsoft Office 365, § 16.2.4 Microsoft does not act as a data processor), ce qui fait qu’ils en deviennent de fait un co-responsable de traitement.
Au final on a 3 bouts distincts : les parties à la charge stricte du client (faire du support sur le chatbot), les parties à la charge stricte du prestataire (maintenance, debug…) mais un gros bout en co-responsabilité de traitement qui représente l’essentiel des finalités (vu que le presta a quasi tout développé de sa propre initiative, donc a minima choisi les moyens).
Pour le cas du ET ou du OU entre les 3 clauses, ici l’APD a fait son taff en pointant tous les manquements, mais le texte est clair : c’est bien finalité OU moyens. Et il me semble qu’il existe une ligne directrice EDPB qui formalise justement cette compréhension du OU, je vais la rechercher :)
C’était le taff de l’APD d’aligner le plus de non-conformités possibles pour estimer l’amende à la fin. Ils ont condamné pour l’ensemble de l’œuvre, mais ils auraient pu condamner juste avec un seul chapitre.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 3. Dernière modification le 05 février 2022 à 22:21.
Non justement. La décision prise envers l’IAB Europe s’applique également aux SaaS européen du coup.
Il n’y a de toute façon pas de notion de localisation des services dans le délibéré, uniquement de responsable de traitement contre sous-traitant. Une boîte EU hébergeant un service SaaS EU est du coup tout aussi dans la mouise.
Après ça va certainement mettre du temps à percoler avec d’autres condamnations arrivants à des sanctions pour ce même motif, mais c’est ce que j’entrevois entre les lignes du délibéré.
Schrems II a éradiqué les US. Panoptikon a éradiqué le SaaS.
# Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . En réponse au journal Une surprenante décision de la justice belge. Évalué à 7. Dernière modification le 04 février 2022 à 20:58.
Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
[^] # Re: Un petit peu HS
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 5.
Si tu as une bibliothèque à disposition pour analyser les iCal et sortir les données souhaitées dans une base de données supportée par Metabase, ça fera le travail sans problème !
Avec 2 bouts de python ou de ruby, ça doit être rapide à faire.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 1. Dernière modification le 29 novembre 2021 à 10:43.
C’est exactement le point. La BI telle qu’on la faisait avant est mise pas mal à mal avec l’entrée en vigueur du RGPD en 2016.
Beaucoup des traitements effectués avant sont dorénavant très touchy niveau RGPD, avec des bases légales frileuses.
EDPB est assez clair sur le sujet : ces stats ne sont pas une obligation légale et n’ont généralement pas un intérêt légitime suffisant devant les dérives possibles (oui, le RGPD adore raisonner selon les possibilités théoriques et non selon les réalités pratiques), la seule base légale a priori recevable sauf justification très forte est le consentement.
Et la plupart des utilités supposées de la BI disparaissent encore plus avec du consentement, parce que ça veut dire que tes chiffres deviennent imprécis (fort probabilité de refus du consentement = données non fiables = pertes d’intérêts = encore moins de légalité du traitement) et que le process de détention des données devient trop chronophage et coûteux par rapport à la plus-value qui en ressort (gestion de la rétractation du consentement nécessitant la suppression des données et des traitements ultérieurs, droits d’accès et rectifications, DPIA avant intégration au registre de traitement, etc)
Ça donne par exemple :
https://www.linkedin.com/pulse/gdpr-has-big-implications-business-intelligence-nick-ringle?articleId=6408376440735301632
https://wiiisdom.com/white-paper/business-objects-gdpr-compliance/
https://tdwi.org/articles/2018/06/04/biz-all-gdpr-impact-on-bi-1.aspx
et tant d’autres sujets qui sont actuellement complètement passés sous silence devant la facilité de ces outils de sortir du cadre réglementaire.
Voir aussi par exemple cette condamnation à 50.000€ d’amende, pour avoir eu un outil de BI trop ouvert.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à 2.
Les 2 sont importants. J’ai peut-être donné l’impression de ne parler que de l’un, mais ce n’est pas le cas. Et à mon sens les 2 sont assez liés, une nouvelle finalité risque fort de réclamer une nouvelle base légale.
C’est particulièrement vrai dans le cas de la BI, les données à dispo sont souvent sous une base légale de collecte (obligation légale ou nécessaire au contrat) incompatible avec des finalités statistiques qui elles nécessitent obligatoirement de l’intérêt légitime voire du consentement d’après EDPB.
Et les produits de BI sont souvent marketés comme « vous avez des données dont vous ne faites rien, sortez-en des stats utiles ». Typiquement chez Metabase, « Meet the easy, open source way for everyone in your company to ask questions and learn from data ».
De plus, le RGPD interdit l’ajout préventif de finalité/base légale « pour des besoins ultérieurs » selon les mots de EDPB. Les besoins doivent être factuels, présents et justifiés. Les finalités de collectes sont du coup nécessairement incompatibles avec l’ajout ultérieur à la volée de filtres/recroisement dans des outils comme Metabase.
C’est uniquement mon point soulevé : la facilité d’ajout de dashboard/filtre/graphe, de recroisement ou d’accès à la donnée est en décalage comparée à la rigidité et la difficulté d’ajout de telles nouvelles finalités dans le cadre d’une conformité RGPD correcte.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à -2. Dernière modification le 28 novembre 2021 à 14:39.
C’est un peu plus compliqué que ça. 2 traitements différents portant sur la même donnée peuvent effectivement avoir des bases légales différentes, mais la donnée initiale elle-même a déjà fait l’objet d’un traitement (sa collecte) avec une certaine base légale et tous les traitements derrière ne peuvent du coup qu’avoir une base légale compatible avec la base légale initiale.
Il est impossible de faire un traitement ultérieur d’une données sous la base légale « intérêt légitime » si la base légale initiale de la collecte de cette donnée ne contenait que « consentement ». Ton point de collecte définit le périmètre maximal qu’il ne sera jamais possible de dépasser sur l’ensemble des traitements ultérieurs présents ou futurs qui sera fait sur ces données.
Et mon point est justement là : Metabase est la porte ouverte à toutes les fenêtres, les utilisateurs envisageant difficilement quelles requêtes vont être toujours dans le scope légale de la collecte initiale. Ce n’est pas parce que la donnée est à dispo et que tu peux en sortir un joli dashboard sous Metabase que ce que tu fais est autorisé.
Et ce n’est pas parce que tu renseignes ton registre de traitement avec le nouveau traitement et sa base légale qu’il devient magiquement légal s’il reste incompatible avec la finalité et base légale de la collecte initiale.
Voir par exemple les condamnations pour finalités incompatibles avec la collecte initiale de la donnée.
[^] # Re: Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à -3.
Tu manipules très souvent des données personnelles hein… Ou dit autrement des stats sans données personnelles à l’origine ou à la fin sont généralement assez peu intéressantes.
Et bien penser aussi qu’un traitement de données personnelles, c’est aussi la collecte de la donnée, et pas uniquement l’extraction ou affichage ultérieur. Si l’origine même de ta donnée contient une donnée perso (facture, paiement, etc), alors sa réutilisation pour des finalités autres que initiale est encadrée voire proscrite.
Typiquement des stats sur ta compta sont aussi touchées par le RGPD parce que ta facture initiale contient de la donnée perso, même si la stat finale, elle, ne contient pas de données perso.
Et la base légale (« intérêt légitime ») et finalité (« suivre mon commerce ») de tes stats seraient plutôt en contradiction avec la finalité initiale de la facture (« encaisser un paiement ») et sa base légale (« obligation légale »). Tu n’as donc pas le droit de partir de ton stock de facture pour établir tes stats de commerce (détournement de finalité et utilisation d’une base légale incompatible).
# Attention quand même au RGPD :D
Posté par Aeris (site web personnel) . En réponse à la dépêche Metabase - Business intelligence open source. Évalué à -4. Dernière modification le 28 novembre 2021 à 12:24.
Si Metabase est un outil extrêmement puissant, c’est aussi typiquement le genre d’outil qui sera très rapidement bordeline niveau conformité RGPD.
Le fait de pouvoir dynamiquement faire tout plein de requêtes, de recroiser les données dans tous les sens voire mettre à dispo les données brutes non agrégées est la porte ouverte à tous les détournements de finalité.
La conformité RGPD limite souvent la puissance de Metabase, puisque les données brutes doivent nécessairement (article 5.c) être déjà agrégées et leur format interdire (article 5.b) le détournement de finalité, donc de limiter les possibilités de requêtes ou de création de dashboard « à la volée ».
Et Metabase se transforme du coup en « simple » visualiseur avancé permettant de filtrer par date/catégorie des tables pré-définies, perdant beaucoup de sa flexibilité.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Il y a bien d’autres tests que juste les ciphers avec CryptCheck, et beaucoup ne sont pas encore affichés sur l’interface faute d’avoir des personnes compétentes en UI/UX pour me filer un coup de patte :)
En l’occurence le « E » s’explique ici par le manque de HSTS.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 6. Dernière modification le 20 juillet 2020 à 11:31.
DSP2 impose(ra) forcément du « propriétaire » à ce niveau.
Plus exactement il impose une 2FA « contextuelle » pour éviter les man-in-the-middle. Ça suppose d’afficher des données supplémentaires à l’OTP pour que l’utilisateur puisse identifier de manière fiable le demandeur de l’OTP.
Dans le cas d’une validation de virement ou de paiement, c’est par exemple le montant de la transaction ainsi que son destinataire, pour éviter un attaquant qui ferait proxy et te débiterait le montant qu’il souhaite à son propre profit si on se limitait au seul OTP.
Dans celui de la connexion, ça pourrait être l’affichage d’un symbole spécifique connu uniquement de toi et de ta banque. Une banque belge dont j’ai perdu le nom avait implémenté ça dans un token OTP matériel d’ailleurs, mais je n’en retrouve plus la référence…
En pratique ça demande(ra) donc du développement spécifique à chaque banque et même si la théorie derrière est libre et commune (T-OTP), chaque banque risque d’avoir sa propre application ou fonctionnement pour couvrir ce besoin de « contextualisation ».
C’est même la raison n°1 de pourquoi les banques préfèrent encore violer la DSP-2 et ont demandé une rallonge de 2 ans pour continuer avec le SMS, elles n’ont actuellement pas de solution conforme à disposition.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 4. Dernière modification le 19 juillet 2020 à 22:14.
Je veux dire par là que SCSV protège uniquement des attaques (semi) passives consistant à bloquer la connection TCP à la détection d’une connexion TLSv1.2 en espérant que le client va retenter derrière en TLSv1.1.
À partir du moment où on considère un attaquant actif capable d’éditer le flux, alors il shootera SCSV de la même manière qu’il modifierait les paquets pour supprimer les ciphers safe et forcer une connection vers 3DES. Il lui suffit de supprimer le flag SCSV de la demande de connexion TLSv1.1. Le handshake n’étant pas signé…
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Axa ou N26 l’ont fait. Je ne vois du coup pas ce qu’il y a d’insurmontable.
https://cryptcheck.fr/https/connect.axa.fr
Ils ont déjà du mal à supporter 1.2, alors 1.3, si on l’a d’ici 10 ans je serais étonné…
Et encore une fois, avoir du 1.3 & des trucs pétés dans la boucle, c’est s’ouvrir la porte à toutes les fenêtres. On ne peut/doit pas parier la sécurité de son bordel sur une conjonction improbable d’éléments divers et variés…
« Alors tu es safe si tu as du 1.3 ou du 1.2 avec du SCSV et je laisse des trucs pétés uniquement sur 1.1 en espérant que tu ne tomberas pas dessus par l’opération du saint-esprit »
D’autant plus que SCSV est présent dans le handshake non signé de TLSv1.2 donc en théorie est shootable par une attaque active du même niveau technique que le fallback de cipher.
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3. Dernière modification le 19 juillet 2020 à 22:03.
Il faudrait que je refasse tourner la moulinette, mais en mai 2019, c’était une grosse catastrophe…
https://imirhil.fr/tls/banks.html
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 7. Dernière modification le 19 juillet 2020 à 21:56.
SCSV permet simplement de ne pas downgrade vers TLSv1.1 si le client et le serveur supportent TLSv1.2 (le serveur verra passer une demande en 1.1 avec le flag SCSV et va hurler).
Ça ne permet pas de protéger d’un downgrade de (TLSv1.2) ECDHE-ECDSA-AES256-GCM-SHA384 vers (TLSv1.2) DES-CBC3-SHA qui est pété depuis 2016 et sweet32 si le site en face supporte les 2.
En gros ça protège le protocole (TLSv1.2/1.1/1.0) et pas les ciphers suites (AES, 3DES, RC4…), il faut attendre TLSv1.3 pour corriger ça avec un handshake lui-même signé (en TLSv1.2 il ne l’est pas).
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 4.
Comme tu pourras le voir ici, une suite de chiffrement permettant d’être A+ est compatible avec la quasi-totalité du monde à l’exception de IE6/XP, qui sont une hérésie en 2020 de toute façon.
Une suite qui serait conforme avec le futur A+ (disparition de SHA-1) est conforme avec l’intégralité de la planète aussi, minus 2-3 trucs complètement obsolètes en 2020…
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Le problème est que trop de sites se réfugient derrière cette pseudo-compatibilité pour ne pas faire évoluer leur sécurité. 3DES est pété depuis déjà 2016 (4 ans bordel…) et on le trouve encore sur les banques & le reste.
Un navigateur qui ne supporte PAS TLS1.2 ou AES suppose que tu utilises un navigateur/OS type Android 4.3 (><) et moins ou Firefox 26 et moins. Des trucs de 2015 qui étaient DÉJÀ pétés en 2016 et la disparition de 3DES.
Ces sites montrent bien un véritable problème de sécurité pour ne pas avoir fait les mises-à-jour nécessaires et mettre tous les autres utilisateurs (qui eux ont fait les mises-à-jours) en péril…
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
Ça c’est globalement faux. Il existe pas mal de moyen de contraindre un site à négocier une suite pétée à partir du moment où le serveur supporte une suite merdique.
Tu peux très bien négocier du AES128-SHA voire du DES-CBC3-SHA alors que tu es bien en TLSv1.2 (cas de google.fr).
[^] # Re: À jour ?
Posté par Aeris (site web personnel) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 3.
https://cryptcheck.fr/https/cryptcheck.fr
Certains y arrivent pourtant :)
[^] # Re: Le RGPD est clair pour ceux qui pensent qu'il est clair ^^
Posté par Aeris (site web personnel) . En réponse au journal « votre bulletin de paye électronique ». Évalué à 8. Dernière modification le 06 juin 2019 à 00:32.
Ne pas oublier aussi que le consentement n’est QU’UN des moyens légaux opposables à une collecte de données.
Au pif, on a aussi
En l’occurrence ici, je vois au moins 2 moyens possibles permettant l’utilisation de ce service sans avoir de consentement à recueillir :
Décret n° 2016–1762 du 16 décembre 2016 relatif à la dématérialisation des bulletins de paie et à leur accessibilité dans le cadre du compte personnel d’activité
https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000033625104&categorieLien=id
L’employeur n’a pas légalement pas besoin de te demander ton avis avant d’utiliser un service de dématérialisation. Il doit uniquement te permettre de t’y opposer, et ceci n’importe quand.
Une fois un service choisi, il relève du coup de l’intérêt légitime pour l’entreprise d’utiliser ce service.
J’ajouterais un 2nd « intérêt légitime + obligation légale » puisqu’on est ici dans le cadre professionnel, donc avec une obligation de subordination qui fait qu’un employeur peut t’imposer ce genre d’outils.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 7. Dernière modification le 12 octobre 2018 à 19:59.
Je parlais bien évidemment dans le cas de FlatPak et au point de vue du build de l’image, pas au niveau de l’upgrade côté utilisateur.
Dans le cas de Debian, les mises-à-jour ne sont justement pas automatiques.
Un mainteneur intervient manuellement pour mettre à jour son ou ses (quelques) paquets maintenus, s’emmerde à lire les releases notes pour s’assurer que c’est bien ABI compatible avec la dernière version, etc.
Il pousse ensuite son paquet, et tout le monde en profite dans toutes les applications.
Il n’est pas noyé sous la tonne de dépendance dont il n’est même pas supposé être le mainteneur, comme c’est le cas de freedesktop qui va devoir se coltiner les releases note aussi diverses et variées que gpg (j’espère qu’ils ont des cryptologues), xorg (et aussi des experts en matos vidéo), nano, ffmpeg, gstreamer, gcc, cmake, zip et j’en passe.
S’amuser à tester toutes les combinaisons possibles jusqu’à trouver un truc qui tombe en marche capable de builder tout ce petit monde (un libssl 1.2.x pour compiler gnupg 2.2.10, ça passe ou pas ?).
Pousser leur image… Et devoir notifier tous les mainteneurs des applications du dessus pour les mettre à jour et remonter les problèmes de build éventuels (« coucou, on a mis à jour gcc ! il build toujours ton projet ? »).
Qui devront rebuilder leur image, pester contre les mainteneurs de freedesktop (stabilité et reproductibilité vous avez dit ?), etc.
D’ailleurs, rien que de voir actuellement du 1.0.2o en libssl pour freedesktop, ça montre bien le problème…
La branche 1.0.x est obsolète, même Debian est plus à jour quoi…
Et il n’y a pas le patch 1.0.2p qui date pourtant de août 2018 et patche une CVE…
Ou encore gpgme 1.1, quand on en est à la 1.12…
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 3.
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement µclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.