Accepter une clé RSA weak t’expose à du downgrade attack parce qu’un attaquant peut forcer le repli vers une suite faillible. C’est donc une faille de sécurité et actuellement c’est de toute façon une violation des lignes directrices de l’ANSSI (pas de PFS = support de données après 2030 = 3072 bits minimum) donc une violation du RGPD.
Tu peux argumenter tant que tu veux, c’est un fait juridique.
Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD, et que c’est même exactement ce traitement qui est visé avec Schrems II, la sanction de Google Analytics (malgré l’anonymisation prouvée derrière par la CNIL), Google Fonts, Cloudflare ou tout CDN ou contenu tiers servi par un site internet (violation de l’obligation de minimisation de données article 5 et 6)...
La connexion chiffrée va ensuite échanger un mot de passe et un nom d’utilisateur qui sera aussi une DCP, même si le tunnel lui-même est chiffré. Données accessibles en clair au service en face donc n’étant PAS anonymisées.
Delta-chat est le moyen utilisé pour cette transmission, la finalité étant elle-même décidé par l’utilisateur. Sauf qu’un responsable de traitement est celui qui définit la finalité OU le moyen et donc delta-chat reste responsable de traitement, éventuellement est même sous-traitant au sens du RGPD si delta-chat est utilisé dans le cadre d’une asso ou d’une entreprise (qui est elle-aussi responsable de traitement pour avoir définit la finalité).
Mais tu ne fais que confirmer que tu n’as strictement aucune idée de ce qu’est le RGPD...
[^] # Re: Des sources intéressantes mais trop de mauvaise foi
Posté par Aeris (site web personnel) . En réponse au lien [blog] Sécurité informatique VS Liberté informatique (attention, ça pique). Évalué à -1. Dernière modification le 21 février 2024 à 10:48.
Accepter une clé RSA weak t’expose à du downgrade attack parce qu’un attaquant peut forcer le repli vers une suite faillible. C’est donc une faille de sécurité et actuellement c’est de toute façon une violation des lignes directrices de l’ANSSI (pas de PFS = support de données après 2030 = 3072 bits minimum) donc une violation du RGPD.
Tu peux argumenter tant que tu veux, c’est un fait juridique.
Établir une connexion TCP/IP, même chiffrée, reste une transmission de DCP (l’adresse IP de l’utilisateur) et est donc en soit un traitement de données soumis au RGPD, et que c’est même exactement ce traitement qui est visé avec Schrems II, la sanction de Google Analytics (malgré l’anonymisation prouvée derrière par la CNIL), Google Fonts, Cloudflare ou tout CDN ou contenu tiers servi par un site internet (violation de l’obligation de minimisation de données article 5 et 6)...
La connexion chiffrée va ensuite échanger un mot de passe et un nom d’utilisateur qui sera aussi une DCP, même si le tunnel lui-même est chiffré. Données accessibles en clair au service en face donc n’étant PAS anonymisées.
Delta-chat est le moyen utilisé pour cette transmission, la finalité étant elle-même décidé par l’utilisateur. Sauf qu’un responsable de traitement est celui qui définit la finalité OU le moyen et donc delta-chat reste responsable de traitement, éventuellement est même sous-traitant au sens du RGPD si delta-chat est utilisé dans le cadre d’une asso ou d’une entreprise (qui est elle-aussi responsable de traitement pour avoir définit la finalité).
Mais tu ne fais que confirmer que tu n’as strictement aucune idée de ce qu’est le RGPD...