Wé ’fin en même temps, parler de NVIDIA ou AMD sous GNU, c’est un peu bizarre… Forcément, les fabriquants ne font rien pour supporter ce système !
Ici, on parle de truc prévu pour s’installer nativement sous Windows ou GNU et de manière supportée à la base. Pas de machins qui s’installent par dessus la jambe au chausse-pied.
Euh alors là, j’aurais tendance à dire totalement l’inverse…
Je suis toujours capable d’installer un vim 3.0-3 de Lenny 2009 sur une Debian Stretch actuelle. Et ça fonctionne. Essaie d’installer du vieux soft sur un Windows 8 ou 10, tu vas pleurer.
Et surtout, la compatibilité est dans les 2 sens sous GNU (modulo une recompilation), je peux aussi facilement installer des programmes actuelles sur une Lenny sans soucis. Installe Office 365 sur un Windows XP ou 3.1, on va rigoler.
Et pour les maj qui se passent bien, j’ai la MÊME Debian depuis 2005, je n’ai jamais connu de maj qui se soient (réellement) mal passées. Il y a quelques problèmes de temps en temps (un fichier qui manque, le cas tordu pas traité…), mais je n’ai jamais eu besoin de faire de réinstallation ou de sortir l’arme atomique, et je n’ai jamais eu à virer de logiciels pour faire l’upgrade.
Tente de passer de Windows XP à Windows 10, déjà on va rigoler, et ensuite, tu risques d’avoir à virer des logiciels pour y arriver sans tout péter… Grandes chances que tu aies même à effectuer une réinstallation système intégrale au final…
Quand les maj se passent mal sous GNU, c’est essentiellement parce que les mainteneurs s’y prennent comme des manchots (ah ah) plutôt qu’une tare innée de GNU (Ubuntu, si tu m’écoutes…).
Pas plus que ça.
Il y a du cache un peu partout, et les serveurs racines et de 1er niveau sont assez nombreux et bien répartis sur la planète (via de l’anycast).
Le mieux étant quand même de mettre un unbound unique pour tout ton LAN (sur une pi par exemple), qui servira de cache pour toutes tes machines.
Ça a aussi l’avantage de pouvoir faire du vrai DNSSec, une validation DNSSec en dehors du LAN, ça vaut presque 0 en terme de sécurité (il suffit d’ajouter/virer le bit AD avec du MitM pour activer/désactiver la validité de la réponse).
Depuis quand faut-il accepter les CGU du fournisseur de son interlocuteur ?
Ce que fait Gafam des messages que tu envoies à jean.michu@gafam.example est l’affaire de Gafam et de Jean Michu uniquement.
Non justement. Quand Jean Michu m’écrit, il transmet au Gafam des données que je n’ai pas forcément envie de voir traiter par une entité tierce. Idem quand je lui répond, je vais devoir transmettre des données que je n’ai pas envie de voir traiter non plus (ou alors je ne lui répond juste pas, ce qui est généralement très difficile socialement et « efficacement » parlant).
Du coup, si Jean Michu a décidé que ton message devait être traité par les services de Gafam, d’après moi c’est son droit le plus strict et je ne vois rien d’anormal à ce qu’on ne t’ait pas demandé ton avis.
Si une agence immobilière hébergée chez GMail te transmet tout ton dossier bancaire par mail sans te demander la permission avant (vécu personnellement…), c’est quand même massivement chiant et tu ne peux strictement plus rien faire, tes données sont dorénavant chez Google…
Et si tu veux réellement cet appartement, tu n’auras pas d’autre choix que de continuer à balancer tes données très privées à Google (extrait de compte, contrat de travail, attestation d’asurance, attestation de caution, questionnaire médicale…), sauf à te faire très beaucoup chié à devoir te déplacer physiquement lors des horaires d’ouvertures en espérant que l’agent immobilier n’est pas en cours de visite ou en rendez-vous client ou que les pièces à communiquer sont extrêment urgentes…
Perso, j’ai mis en place un script sieve qui prévient les utilisateurs de solutions privatrices que le fait qu’ils correspondent avec moi peut être génant. Pour eux comme pour moi.
J’ai eu des retours assez positifs de ce système, les personnes recevant ce message s’interrogent et reviennent vers moi pour demander plus d’informations ou des systèmes alternatifs.
Ça s’est révélé bien plus efficace que des années d’advocacy intensif :D
Il faut encore que je l’améliore pour faire de la détection plus fine (par exemple le mail de lemonde.fr est hébergé par Google…).
il est raisonnable d'envoyer les informations S, T, et C que je possède à l'utilisateur authentifié ? Est-ce que j'ai un autre choix ?
S, T et C sont publiables sur un lien non fiable. C’est même tout le but recherché par le chiffrement :D
Par contre si tu fais de la crypto côté client, le mieux serait de ne jamais avoir à envoyer ces données sur le réseau.
Tu calcules et conserves S,T,C uniquement côté client, et tu mets juste en place un moyen de transférer la clef maîtresse sur un autre périphérique (par exemple avec un QR code ou une chaîne mnémotechnique).
Je peux garder soit le mot de passe de l'utilisateur, soit la clé de chiffrement K. Quel est la meilleur solution ?
Les 2 solutions sont équivalentes en terme de sécurité (si tu as le pass, tu as la clef K de toute façon).
J’aurais tendance à conserver la clef en mémoire, ça évite d’avoir à redériver le pass et à déchiffrer la clef à chaque fois qu’on en a besoin.
La clé privée ne chiffre rien du tout : DH et ses variantes sont des protocoles pour se mettre d'accord sur un secret commun. J'ai l'impression que tu mélanges un peu tout.
Pas quand on utilise un algo non PFS.
Dans le cas du non PFS (donc sans DHE ni ECDHE), le client et le serveur s’échange un nounce random, l’un des 2 en déduit une pre-master-key (généralement le client) qui est chiffré avec la clef publique de l’autre et est envoyé sur le réseau.
Le récepteur déchiffre cette pre-master-key avec sa clef privée, et les 2 peuvent alors calculer la master-key de session à partir de cette pre-master-key commune (l’un des côtés l’a calculé, l’autre l’a recu).
Sans PFS
Avec PFS
Ça a été tout le drame de Heartbleed et du key reusage : si la NSA a intercepté et stocké l’intégralité des communications entre X clients et un serveur, l’accès à la clef privée du serveur via Heartbleed leurs permettait alors de déchiffrer toutes les pre-master-key et d’en déduire les clefs de session permettant de déchiffrer tout le reste de toutes les communications.
Ce n’est plus du tout le cas avec PFS puisque cette pre-master-key ne circule pas sur le réseau mais est calculée des 2 côtés via un mécanisme en 0-knowledge (Diffie Hellman en version nombre premier pour DHE ou courbe elliptique pour ECDHE).
Et la NSA doit alors casser chaque clef de session indépendament les unes des autres, il n’y a plus de moyen de les casser toutes en une seul fois.
Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.
Je vois pas ce que ça change. Dans ton schéma plus haut, si MK tombe tes clés uniques tombent aussi.
Oui, mais à la différence d’une clef réutilisée, elle n’a pas vocation à être transporté sur le réseau, de manière directe ou indirecte (via un chiffré).
Ça la rend beaucoup plus robuste en pratique (des attaques ne sont plus possibles, comme une attaque en known-plain-text ou une par oracle par exemple).
Il y a donc un gros fossé en terme de robustesse entre une clef maîtresse réutilisé (inaccessible sans hack de la bdd) et une clef secondaire réutilisée (accessible au moins indirectement par les chiffrés).
Réutiliser une clé n'est pas une erreur grave, tant que le service est le même (par exemple, une clé utilisée pour chiffrer toutes les autres).
Par contre réutiliser un IV est une erreur grave. Tous les couples (clé,IV) doivent être différents. On peut donc utiliser une IV I une fois avec la clé K1 et une fois avec la clé K2 mais jamais deux fois avec la même clé.
C’est complètement faux. Et c’est même l’inverse.
L’IV peut être une donnée publique (qu’on peut par exemple générer de la même manière qu’un sel) et peut être réutilisée sans problème tant qu’on changera la clef de chiffrement (c’est le couple clef+iv qui doit être unique lors du chiffrement).
C’est juste emmerder encore plus un attaquant que de le générer via un moyen cryptographique sûr et de ne pas le communiquer (clef de 256 bits + iv privé de 256 bits peut donner jusqu’à 512 bits de sécurité totale si ils sont générés de manière indépendante).
La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).
Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).
La règle générale est donc clef à usage unique par défaut.
Et tu ne réutilises jamais une clef, sauf à RÉELLEMENT savoir ce que tu fais (et même dans ce cas, ne la réutilise pas, la probabilité est importante que tu ais raté quelque chose dans ton étude).
Oui, pardon pour l’abus de langage, il faut comprendre clef par « clef + iv » effectivement. Tant que le couple est unique, on est tranquille (en tout cas dans le cas de AES).
En théorie, tu n’as même pas besoin de clef maître, puisque tu pourrais la baser sur le mot de passe via une dérivation de clef.
Tu en as besoin en pratique pour permettre le changement de mot de passe et d’éviter de le stocker au login.
La subtilité est d’arriver à obtenir une clef et un iv (même si c’est moins grave pour le 2nd) unique pour chaque chiffrement à réaliser. Réutiliser une clef de chiffrement est une erreur grave en crypto (on est potentiellement capable de deviner des choses sur les textes en clair à partir des données chiffrées uniquement).
À la création de l’utilisateur :
on génère un sel S de 64 bits via un CSPRNG
on génère une clef maîtresse MK de chiffrement de 256 bits via un CSPRNG
on calcule une clef de chiffrement K et un IV IV via K, IV = PBKDF2(password, S)
on chiffre MK via C, T = AES-256-GCM(MK, K, IV)
on stocket S, T et C en bdd, associé à l’utilisateur
Au login utilisateur :
on calcule K, IV = PBKDF2(password, S)
on déchiffre MK via MK = AES-256-GCM(C, K, IV, T)
Pour chiffrer une donnée :
on génère un salt s de 64 bits via un CSPRNG
on calcule une clef de chiffrement k et un iv de 256 bits à partir de de la master key via k, iv = PBKDF2(MK, s) (en résumé c’est cette étape qui manque chez toi)
on chiffre les données d via c, t = AES-256-GCM(d, k, iv)
on stocke s, t et c en bdd
Pour déchiffrer une donnée :
on lit s, t et c en bdd
on recalcule la clef et l’iv via k, iv = PBKDF2(K, s)
on déchiffre les données d via d = AES-256-GCM(c, k, iv, t)
J’ai regardé rapidement ta crypto, elle n’est pas correcte du tout (key/iv reusage, password as key, no HMAC…) :P
Je vais t’ouvrir tout plein de petits tickets sur Bitbucket du coup.
HPKP et DANE n'entrent pas dans ce processus et c'est normal: pour créer un certificat tu dois juste avoir une paire de clés, un nom de domaine et une autorité reconnue.
HPKP et DANE font parti de la stack X.509 et assimilé. DNSSec devrait être déployé partout (98% de MitM mail si tu es en Turquie à cause de ce manque…)
Une CA doit permettre de les respecter.
Sinon c’est juste une « yet another plain old CA ».
C'est toi qui choisit de lier ces 3 concepts, c'est ton problème.
Euh non, c’est ce qu’on appelle une stack TLS correcte en 2016.
HPKP devient limite critique vu les attaques aujourd’hui, TLSA arrivera derrière.
Quand tu sais que Symantec, root-CA, vient d’acquérir BlueCoat, vendeur de matos DPI, HPKP et TLSA, ce ne sont clairement plus des jouets mais ce qui peut faire la différence entre la vie privée ou pas…
Pour dnnsec, c'est la même remarque: tu as choisit de rendre manuel le changement de ressources DNS, donc c'est ton problème.
Je n’ai pas choisi. C’est l’état de l’art d’un serveur OpenDNSSec d’avoir un shadow master hors DMZ. Et ça casse tout l’intérêt de DNSSec si tes clefs sont dispos sur une machine accessible depuis le net.
DNSSec impose un roulement régulier de ta clef de signature.
En fait de tes 3 clefs de signature :
la signature de zone, renouvelée toutes les 2h
la ZSK, renouvelé tous les 90j, qui signe ta zone DNS
la KSK, renouvelé 1× par an
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Pour parvenir à tenir le renouvellement toutes les 2h de manière sécurisée, on utilise ce qu’on appelle un shadow master. Ton DNS primaire devient en réalité un secondaire, et tu montes un serveur DNS OpenDNSSec bien à l’abri dans ton parc derrière une tonne de firewall et isolé de l’Internet (air-gap, et potentiellement éteint 99% du temps).
À chaque signature de zone, le shadow master signale à ton DNS « primaire » qu’il y a eu un changement de zone, et ton primaire va alors télécharger la nouvelle zone via le mécanisme AXFR de DNS.
Si tu dois modifier ta zone DNS, tu dois alors intervenir sur le shadow master, demander la resignature de la zone, qui sera poussée sur ton primaire.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Sauf que pour faire ça, il faudrait qu’il ait accès à ton shadow master. Qui par définition ne doit jamais être mis en contact avec une machine de ta DMZ. Donc pas de ton frontal web. Donc impossible de mettre à jour TLSA. Donc impossible d’utiliser LE.
Pour l’idée des paquets Debian ou autres, ce n’est pas possible avec HTTPs, puisqu’il faudrait être capable de synchroniser l’installation des paquets sur X machines (dont des machines hors DMZ pour DNSSec) lors du renouvellement du certificat : déploiement du certificat sur tous les HTTPd (backend, reverse et HA proxy), modification des vhosts HTTPd concernés pour HPKP, changement des TLSA pour DANE (impossible car hors DMZ, sans connectivité, voire éteint).
Sans synchro, on pourrait se retrouver avec des certificats différents fonction du reverse sur lequel tu tombes après le HA proxy ou si tu passes par IPv4 (reverse) ou IPv6 (backend), avoir un certificat présenté différent de celui indiqué dans les entêtes HPKP ou les entrées TLSA, etc.
(Pour HPKP, c’est même encore plus problématique puisqu’il faut prévoir le rollover de l’empreinte au moins 60j avant la modification réelle. Donc déjà avoir le prochain certificat à dispo.)
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
DNS est basé sur UDP, et ne peut donc pas envoyer de paquets de plus de 548 octets, donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins) et des algos de hash faibles (SHA-1) pour pouvoir faire rentrer tout ça dans UDP.
On doit donc renouveller TRÈS fréquement les clefs et les hash pour éviter un bruteforce de la zone qui prendrait peu de temps vu les algos utilisés.
De plus, DNS embarque nativement un mécanisme de synchronisation (NOTIFY pour signaler un changement, AXFR pour récupérer les modifications), ce qui facilite le montage d’un shadow master hors DMZ, alors que LE/HTTPS/X.509 n’en possède pas.
Et enfin, DNSSec peut être fait totalement offline sur le shadow master (qui est du coup un vrai shadow master) alors que LE impose une connectivité internet et l’accès aux frontaux web (donc pas de shadow master hors DMZ possible).
Demander des challenges DNS pour son CSR au serveur ACME
Je t’arrêtes immédiatement à partir d’ici.
Mon DNS a DNSSec activé, DNSSec étant géré avec OpenDNSSec sur un shadow master contenant les clefs privées de signature de ma zone (ce qui est la configuration recommandée quand on gère du DNSSec).
Ma zone DNS n’est donc pas modifiable automatiquement, il faut nécessairement une intervention humaine.
Et sur le point 3, tu as oublié :
modifier les empreintes TLSA (DNS) et HPKP (HTTPd) des certificats renouvelés
Qui pose aussi le problème de l’accès au shadow master DNSSec, mais aussi casserait l’intérêt de TLSA si fait automatiquement (l’intérêt étant d’avoir justement 2 chemins bien distinct entre la gestion du certificat et celle du DNS).
Ainsi que celui du rollover de l’empreintre HPKP qui doit être faite au moins 60j avant le véritable changement de certificat (et nécessite d’avoir déjà le certificat à disposition pour le calcul de l’empreinte).
En bref, ton processus est parfaitement faisable si tu réduis l’environnement HTTPS à uniquement clef + certificat.
Dès que tu y mets les autres technos associées (DNSSec, HPKP & TLSA), c’est mort pour une automatisation et encore pire à 60j.
En gros, ils prêchent l’automatisation à 100% mais refusent la certification via HTTPS pour cause d’admin incompétents incapables de gérer correctement leur vhost par défaut (et du coup le 1er nom de domaine dans l’ordre lexicographique est capable de générer des certificats pour tous les autres domaines multi-tenants…).
D’ailleurs je n’ai toujours pas compris pourquoi ils ont ciblé HTTPS uniquement, alors que HTTP pose exactement le même problème (la seule piste de réponse que j’ai pu avoir est qu’il y aurait encore plus d’admins incompétents en HTTPS qu’en HTTP).
Mais, le renouvellement/création du certificat par http n'empêche pas de forcer l'utilisation des sites web en https tout le temps. Il faut simplement créer une exception basée sur le motif de l'url de validation : .well-known/acme-challenge
À partir du moment où tu as du HTTP actif, SSLStrip est possible, ou du leak de données involontaires.
Que tu y mettes des limitations logicielles derrière ne change rien, au niveau réseau des données peuvent continuer à passer en clair avant de se prendre un 3xx ou un 4xx.
Le lancement de la procédure (automatique et sécurisée) nécessite l’accès à une machine air-gap ou à des ressources hors ligne (clef SSH administrateur, disque dur chiffré verrouillé…), qu’il faut déverrouiller et lancer manuellement.
Je peux parfaitement faire ça 1 ou 2× par an (c’est ce qui est fait pour la signature DNSSec racine par l’ICANN par exemple), je ne peux pas faire ça tous les 60j (et encore moins avec 100 certificats qui fait que je vais devoir le faire presque chaque jour).
Un des buts de Let's Encrypt étant de favoriser l'automatisation, ça n'arrivera pas.
Quand on fait de la sécurité, tout n’est pas automatisable. Loin de là.
Va dire par exemple à l’ICANN qu’ils n’ont qu’à automatiser le renouvellement de la clef racine DNSSec (qui aujourd’hui réclame 4h et une 20aine de personne)…
Vu tes idées et ton goût pour la maintenance manuelle, je suggérerais plutôt de monter une alternative à Let's Encrypt, proposant le même service mais sans le but d'automatisation.
Je l’aurais fait sans soucis si je n’avais pas besoin de ce f***** audit pour être intégré aux navigateurs.
Et comme signalé plus haut, beaucoup d’auto-hébergés n’utilisent pas LE pour cause de trop grande complexité…
Le cas d’usage standard de LE est trop restrictif pour être utilisable en pratique (mono-serveur, mono-domaine). Dès que tu dépasses de ce niveau (ce qui est en pratique le cas dès que tu touches un peu à l’auto-hébergement), les ressources nécessaires pour l’automatisation te sont hors de portée.
Et ceux qui s’y mettent réellement tombent rapidement sur les os mentionnés un peu partout ici et au fur et à mesure qu’ils vont s’amuser avec leur infra et se semi-professionalisé (reverse proxy, virtualisation, puis HPKP, puis TLSA).
Mais ils seront bridés car pas les ressources humaines et temporelles pour développer toutes les verrues nécessaires un peu partout (httpd, dns…) à une automatisation à 60 jours.
Les grands gagnants dans l’affaire ont été les fournisseurs d’offres mutualisées et les vrais professionnels qui ont pu enfin délivrer du certificat en masse et qui ont les infras humaines, matérielles, temporelles et financières pour gérer l’automatisation (en se foutant au passage de HPKP et de TLSA) via le développement d’outillage ad-hoc pour leur infrastructure.
Parce que la 1ère requête HTTP avant la redirection contient déjà les données POST par exemple. Et peut donc suffire à leaker des données pas cool.
Et que ça permet des attaques marrantes comme SSLStrip par exemple (tu interceptes le « 302 redirect » de la requête HTTP, tu récupères le contenu HTTPS, tu remplaces tous les https:// par http:// dans le contenu que toi tu as reçu, tu envoies un « 200 found » avec le contenu modifié, tu recommences avec la prochaine requête qui sera du coup en http://, etc).
Il y a même des attaques plus marrantes qui laissent le joli cadena vert dans la barre d’adresse (avec du AJAX qui recharge toute la page en HTTP plutôt que de faire la vraie requête GET/POST) ! http://www.crack-wifi.com/tutoriel-sslstrip-hijacking-ssl-mitm-https.php
La désactivation complète de HTTP est par exemple préconisée pour les API par Mozilla.
[^] # Re: Il oublie LES 2 raisons principales
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi Windows. Évalué à -1.
Wé ’fin en même temps, parler de NVIDIA ou AMD sous GNU, c’est un peu bizarre… Forcément, les fabriquants ne font rien pour supporter ce système !
Ici, on parle de truc prévu pour s’installer nativement sous Windows ou GNU et de manière supportée à la base. Pas de machins qui s’installent par dessus la jambe au chausse-pied.
[^] # Re: Il oublie LES 2 raisons principales
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi Windows. Évalué à 7.
Euh alors là, j’aurais tendance à dire totalement l’inverse…
Je suis toujours capable d’installer un vim 3.0-3 de Lenny 2009 sur une Debian Stretch actuelle. Et ça fonctionne. Essaie d’installer du vieux soft sur un Windows 8 ou 10, tu vas pleurer.
Et surtout, la compatibilité est dans les 2 sens sous GNU (modulo une recompilation), je peux aussi facilement installer des programmes actuelles sur une Lenny sans soucis. Installe Office 365 sur un Windows XP ou 3.1, on va rigoler.
Et pour les maj qui se passent bien, j’ai la MÊME Debian depuis 2005, je n’ai jamais connu de maj qui se soient (réellement) mal passées. Il y a quelques problèmes de temps en temps (un fichier qui manque, le cas tordu pas traité…), mais je n’ai jamais eu besoin de faire de réinstallation ou de sortir l’arme atomique, et je n’ai jamais eu à virer de logiciels pour faire l’upgrade.
Tente de passer de Windows XP à Windows 10, déjà on va rigoler, et ensuite, tu risques d’avoir à virer des logiciels pour y arriver sans tout péter… Grandes chances que tu aies même à effectuer une réinstallation système intégrale au final…
Quand les maj se passent mal sous GNU, c’est essentiellement parce que les mainteneurs s’y prennent comme des manchots (ah ah) plutôt qu’une tare innée de GNU (Ubuntu, si tu m’écoutes…).
[^] # Re: unbound
Posté par Aeris (site web personnel) . En réponse au journal DNS anonyme. Évalué à 5. Dernière modification le 05 janvier 2017 à 14:38.
Pas plus que ça.
Il y a du cache un peu partout, et les serveurs racines et de 1er niveau sont assez nombreux et bien répartis sur la planète (via de l’anycast).
Le mieux étant quand même de mettre un unbound unique pour tout ton LAN (sur une pi par exemple), qui servira de cache pour toutes tes machines.
Ça a aussi l’avantage de pouvoir faire du vrai DNSSec, une validation DNSSec en dehors du LAN, ça vaut presque 0 en terme de sécurité (il suffit d’ajouter/virer le bit AD avec du MitM pour activer/désactiver la validité de la réponse).
[^] # Re: Script sieve
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 2. Dernière modification le 09 décembre 2016 à 00:23.
Effectivement, j’en ai conservé une copie ici :
https://imirhil.fr/et-puis-merde-à-la-vie-privée.html
Ça ressemble d’ailleurs furieusement à ce journal :D
[^] # Re: Script sieve
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 4.
Non justement. Quand Jean Michu m’écrit, il transmet au Gafam des données que je n’ai pas forcément envie de voir traiter par une entité tierce. Idem quand je lui répond, je vais devoir transmettre des données que je n’ai pas envie de voir traiter non plus (ou alors je ne lui répond juste pas, ce qui est généralement très difficile socialement et « efficacement » parlant).
Si une agence immobilière hébergée chez GMail te transmet tout ton dossier bancaire par mail sans te demander la permission avant (vécu personnellement…), c’est quand même massivement chiant et tu ne peux strictement plus rien faire, tes données sont dorénavant chez Google…
Et si tu veux réellement cet appartement, tu n’auras pas d’autre choix que de continuer à balancer tes données très privées à Google (extrait de compte, contrat de travail, attestation d’asurance, attestation de caution, questionnaire médicale…), sauf à te faire très beaucoup chié à devoir te déplacer physiquement lors des horaires d’ouvertures en espérant que l’agent immobilier n’est pas en cours de visite ou en rendez-vous client ou que les pièces à communiquer sont extrêment urgentes…
# Script sieve
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 2.
Perso, j’ai mis en place un script sieve qui prévient les utilisateurs de solutions privatrices que le fait qu’ils correspondent avec moi peut être génant. Pour eux comme pour moi.
J’ai eu des retours assez positifs de ce système, les personnes recevant ce message s’interrogent et reviennent vers moi pour demander plus d’informations ou des systèmes alternatifs.
Ça s’est révélé bien plus efficace que des années d’advocacy intensif :D
Il faut encore que je l’améliore pour faire de la détection plus fine (par exemple le mail de lemonde.fr est hébergé par Google…).
[^] # Re: Analyseur logique
Posté par Aeris (site web personnel) . En réponse à la dépêche Les ateliers du labx : 1 - l’oscilloscope numérique. Évalué à 1.
Je veux bien le modèle aussi, parce qu’à moins de 200€, je n’ai jamais rien trouvé /o\
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 1. Dernière modification le 06 octobre 2016 à 10:20.
S, T et C sont publiables sur un lien non fiable. C’est même tout le but recherché par le chiffrement :D
Par contre si tu fais de la crypto côté client, le mieux serait de ne jamais avoir à envoyer ces données sur le réseau.
Tu calcules et conserves S,T,C uniquement côté client, et tu mets juste en place un moyen de transférer la clef maîtresse sur un autre périphérique (par exemple avec un QR code ou une chaîne mnémotechnique).
Les 2 solutions sont équivalentes en terme de sécurité (si tu as le pass, tu as la clef K de toute façon).
J’aurais tendance à conserver la clef en mémoire, ça évite d’avoir à redériver le pass et à déchiffrer la clef à chaque fois qu’on en a besoin.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 0. Dernière modification le 04 octobre 2016 à 00:27.
Pas quand on utilise un algo non PFS.
Dans le cas du non PFS (donc sans DHE ni ECDHE), le client et le serveur s’échange un nounce random, l’un des 2 en déduit une pre-master-key (généralement le client) qui est chiffré avec la clef publique de l’autre et est envoyé sur le réseau.
Le récepteur déchiffre cette pre-master-key avec sa clef privée, et les 2 peuvent alors calculer la master-key de session à partir de cette pre-master-key commune (l’un des côtés l’a calculé, l’autre l’a recu).
Sans PFS
Avec PFS
Ça a été tout le drame de Heartbleed et du key reusage : si la NSA a intercepté et stocké l’intégralité des communications entre X clients et un serveur, l’accès à la clef privée du serveur via Heartbleed leurs permettait alors de déchiffrer toutes les pre-master-key et d’en déduire les clefs de session permettant de déchiffrer tout le reste de toutes les communications.
Ce n’est plus du tout le cas avec PFS puisque cette pre-master-key ne circule pas sur le réseau mais est calculée des 2 côtés via un mécanisme en 0-knowledge (Diffie Hellman en version nombre premier pour DHE ou courbe elliptique pour ECDHE).
Et la NSA doit alors casser chaque clef de session indépendament les unes des autres, il n’y a plus de moyen de les casser toutes en une seul fois.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2. Dernière modification le 03 octobre 2016 à 21:49.
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2.
Ah oui, j’avais zappé le nounce effectivement /o\
Oui, mais à la différence d’une clef réutilisée, elle n’a pas vocation à être transporté sur le réseau, de manière directe ou indirecte (via un chiffré).
Ça la rend beaucoup plus robuste en pratique (des attaques ne sont plus possibles, comme une attaque en known-plain-text ou une par oracle par exemple).
Il y a donc un gros fossé en terme de robustesse entre une clef maîtresse réutilisé (inaccessible sans hack de la bdd) et une clef secondaire réutilisée (accessible au moins indirectement par les chiffrés).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 1. Dernière modification le 03 octobre 2016 à 14:28.
C’est complètement faux. Et c’est même l’inverse.
L’IV peut être une donnée publique (qu’on peut par exemple générer de la même manière qu’un sel) et peut être réutilisée sans problème tant qu’on changera la clef de chiffrement (c’est le couple clef+iv qui doit être unique lors du chiffrement).
C’est juste emmerder encore plus un attaquant que de le générer via un moyen cryptographique sûr et de ne pas le communiquer (clef de 256 bits + iv privé de 256 bits peut donner jusqu’à 512 bits de sécurité totale si ils sont générés de manière indépendante).
La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).
Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).
La règle générale est donc clef à usage unique par défaut.
Et tu ne réutilises jamais une clef, sauf à RÉELLEMENT savoir ce que tu fais (et même dans ce cas, ne la réutilise pas, la probabilité est importante que tu ais raté quelque chose dans ton étude).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2.
Oui, pardon pour l’abus de langage, il faut comprendre clef par « clef + iv » effectivement. Tant que le couple est unique, on est tranquille (en tout cas dans le cas de AES).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 4. Dernière modification le 03 octobre 2016 à 13:04.
En théorie, tu n’as même pas besoin de clef maître, puisque tu pourrais la baser sur le mot de passe via une dérivation de clef.
Tu en as besoin en pratique pour permettre le changement de mot de passe et d’éviter de le stocker au login.
La subtilité est d’arriver à obtenir une clef et un iv (même si c’est moins grave pour le 2nd) unique pour chaque chiffrement à réaliser. Réutiliser une clef de chiffrement est une erreur grave en crypto (on est potentiellement capable de deviner des choses sur les textes en clair à partir des données chiffrées uniquement).
À la création de l’utilisateur :
Au login utilisateur :
Pour chiffrer une donnée :
Pour déchiffrer une donnée :
# Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 8. Dernière modification le 03 octobre 2016 à 10:41.
Hello !
J’ai regardé rapidement ta crypto, elle n’est pas correcte du tout (key/iv reusage, password as key, no HMAC…) :P
Je vais t’ouvrir tout plein de petits tickets sur Bitbucket du coup.
Cf https://blog.imirhil.fr/2016/03/03/chiffrement-donnees.html
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 0.
HPKP et DANE font parti de la stack X.509 et assimilé. DNSSec devrait être déployé partout (98% de MitM mail si tu es en Turquie à cause de ce manque…)
Une CA doit permettre de les respecter.
Sinon c’est juste une « yet another plain old CA ».
Euh non, c’est ce qu’on appelle une stack TLS correcte en 2016.
HPKP devient limite critique vu les attaques aujourd’hui, TLSA arrivera derrière.
Quand tu sais que Symantec, root-CA, vient d’acquérir BlueCoat, vendeur de matos DPI, HPKP et TLSA, ce ne sont clairement plus des jouets mais ce qui peut faire la différence entre la vie privée ou pas…
Je n’ai pas choisi. C’est l’état de l’art d’un serveur OpenDNSSec d’avoir un shadow master hors DMZ. Et ça casse tout l’intérêt de DNSSec si tes clefs sont dispos sur une machine accessible depuis le net.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 0.
C’est plus compliqué que juste le lien avec LE.
DNSSec impose un roulement régulier de ta clef de signature.
En fait de tes 3 clefs de signature :
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Pour parvenir à tenir le renouvellement toutes les 2h de manière sécurisée, on utilise ce qu’on appelle un shadow master. Ton DNS primaire devient en réalité un secondaire, et tu montes un serveur DNS OpenDNSSec bien à l’abri dans ton parc derrière une tonne de firewall et isolé de l’Internet (air-gap, et potentiellement éteint 99% du temps).
À chaque signature de zone, le shadow master signale à ton DNS « primaire » qu’il y a eu un changement de zone, et ton primaire va alors télécharger la nouvelle zone via le mécanisme AXFR de DNS.
Si tu dois modifier ta zone DNS, tu dois alors intervenir sur le shadow master, demander la resignature de la zone, qui sera poussée sur ton primaire.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Sauf que pour faire ça, il faudrait qu’il ait accès à ton shadow master. Qui par définition ne doit jamais être mis en contact avec une machine de ta DMZ. Donc pas de ton frontal web. Donc impossible de mettre à jour TLSA. Donc impossible d’utiliser LE.
Pour l’idée des paquets Debian ou autres, ce n’est pas possible avec HTTPs, puisqu’il faudrait être capable de synchroniser l’installation des paquets sur X machines (dont des machines hors DMZ pour DNSSec) lors du renouvellement du certificat : déploiement du certificat sur tous les HTTPd (backend, reverse et HA proxy), modification des vhosts HTTPd concernés pour HPKP, changement des TLSA pour DANE (impossible car hors DMZ, sans connectivité, voire éteint).
Sans synchro, on pourrait se retrouver avec des certificats différents fonction du reverse sur lequel tu tombes après le HA proxy ou si tu passes par IPv4 (reverse) ou IPv6 (backend), avoir un certificat présenté différent de celui indiqué dans les entêtes HPKP ou les entrées TLSA, etc.
(Pour HPKP, c’est même encore plus problématique puisqu’il faut prévoir le rollover de l’empreinte au moins 60j avant la modification réelle. Donc déjà avoir le prochain certificat à dispo.)
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
DNS est basé sur UDP, et ne peut donc pas envoyer de paquets de plus de 548 octets, donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins) et des algos de hash faibles (SHA-1) pour pouvoir faire rentrer tout ça dans UDP.
On doit donc renouveller TRÈS fréquement les clefs et les hash pour éviter un bruteforce de la zone qui prendrait peu de temps vu les algos utilisés.
De plus, DNS embarque nativement un mécanisme de synchronisation (NOTIFY pour signaler un changement, AXFR pour récupérer les modifications), ce qui facilite le montage d’un shadow master hors DMZ, alors que LE/HTTPS/X.509 n’en possède pas.
Et enfin, DNSSec peut être fait totalement offline sur le shadow master (qui est du coup un vrai shadow master) alors que LE impose une connectivité internet et l’accès aux frontaux web (donc pas de shadow master hors DMZ possible).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 2.
Si tu as un FAI qui te file une box sans hairpinning, je pense que IPv6 est aussi un mot de la langue étrangère pour lui…
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 0. Dernière modification le 23 septembre 2016 à 14:10.
Je t’arrêtes immédiatement à partir d’ici.
Mon DNS a DNSSec activé, DNSSec étant géré avec OpenDNSSec sur un shadow master contenant les clefs privées de signature de ma zone (ce qui est la configuration recommandée quand on gère du DNSSec).
Ma zone DNS n’est donc pas modifiable automatiquement, il faut nécessairement une intervention humaine.
Et sur le point 3, tu as oublié :
Qui pose aussi le problème de l’accès au shadow master DNSSec, mais aussi casserait l’intérêt de TLSA si fait automatiquement (l’intérêt étant d’avoir justement 2 chemins bien distinct entre la gestion du certificat et celle du DNS).
Ainsi que celui du rollover de l’empreintre HPKP qui doit être faite au moins 60j avant le véritable changement de certificat (et nécessite d’avoir déjà le certificat à disposition pour le calcul de l’empreinte).
En bref, ton processus est parfaitement faisable si tu réduis l’environnement HTTPS à uniquement clef + certificat.
Dès que tu y mets les autres technos associées (DNSSec, HPKP & TLSA), c’est mort pour une automatisation et encore pire à 60j.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 2. Dernière modification le 23 septembre 2016 à 12:02.
Les admins débiles et les environnements multi-tenants.
https://www.ietf.org/mail-archive/web/acme/current/msg00524.html
En gros, ils prêchent l’automatisation à 100% mais refusent la certification via HTTPS pour cause d’admin incompétents incapables de gérer correctement leur vhost par défaut (et du coup le 1er nom de domaine dans l’ordre lexicographique est capable de générer des certificats pour tous les autres domaines multi-tenants…).
D’ailleurs je n’ai toujours pas compris pourquoi ils ont ciblé HTTPS uniquement, alors que HTTP pose exactement le même problème (la seule piste de réponse que j’ai pu avoir est qu’il y aurait encore plus d’admins incompétents en HTTPS qu’en HTTP).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 2.
À partir du moment où tu as du HTTP actif, SSLStrip est possible, ou du leak de données involontaires.
Que tu y mettes des limitations logicielles derrière ne change rien, au niveau réseau des données peuvent continuer à passer en clair avant de se prendre un 3xx ou un 4xx.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1.
Si la fréquence change beaucoup de chose.
Le lancement de la procédure (automatique et sécurisée) nécessite l’accès à une machine air-gap ou à des ressources hors ligne (clef SSH administrateur, disque dur chiffré verrouillé…), qu’il faut déverrouiller et lancer manuellement.
Je peux parfaitement faire ça 1 ou 2× par an (c’est ce qui est fait pour la signature DNSSec racine par l’ICANN par exemple), je ne peux pas faire ça tous les 60j (et encore moins avec 100 certificats qui fait que je vais devoir le faire presque chaque jour).
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1. Dernière modification le 23 septembre 2016 à 11:15.
Quand on fait de la sécurité, tout n’est pas automatisable. Loin de là.
Va dire par exemple à l’ICANN qu’ils n’ont qu’à automatiser le renouvellement de la clef racine DNSSec (qui aujourd’hui réclame 4h et une 20aine de personne)…
Je l’aurais fait sans soucis si je n’avais pas besoin de ce f***** audit pour être intégré aux navigateurs.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 0.
Et comme signalé plus haut, beaucoup d’auto-hébergés n’utilisent pas LE pour cause de trop grande complexité…
Le cas d’usage standard de LE est trop restrictif pour être utilisable en pratique (mono-serveur, mono-domaine). Dès que tu dépasses de ce niveau (ce qui est en pratique le cas dès que tu touches un peu à l’auto-hébergement), les ressources nécessaires pour l’automatisation te sont hors de portée.
Je le vois bien avec Cozy, on reçoit ÉNORMÉMENT de retours négatifs (trop complexe, ne fonctionne pas, pas clair…) des utilisateurs. https://forum.cozy.io/search?q=let’s%20encrypt
Et ceux qui s’y mettent réellement tombent rapidement sur les os mentionnés un peu partout ici et au fur et à mesure qu’ils vont s’amuser avec leur infra et se semi-professionalisé (reverse proxy, virtualisation, puis HPKP, puis TLSA).
Mais ils seront bridés car pas les ressources humaines et temporelles pour développer toutes les verrues nécessaires un peu partout (httpd, dns…) à une automatisation à 60 jours.
Les grands gagnants dans l’affaire ont été les fournisseurs d’offres mutualisées et les vrais professionnels qui ont pu enfin délivrer du certificat en masse et qui ont les infras humaines, matérielles, temporelles et financières pour gérer l’automatisation (en se foutant au passage de HPKP et de TLSA) via le développement d’outillage ad-hoc pour leur infrastructure.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 3. Dernière modification le 23 septembre 2016 à 00:51.
Parce que la 1ère requête HTTP avant la redirection contient déjà les données POST par exemple. Et peut donc suffire à leaker des données pas cool.
Et que ça permet des attaques marrantes comme SSLStrip par exemple (tu interceptes le « 302 redirect » de la requête HTTP, tu récupères le contenu HTTPS, tu remplaces tous les https:// par http:// dans le contenu que toi tu as reçu, tu envoies un « 200 found » avec le contenu modifié, tu recommences avec la prochaine requête qui sera du coup en http://, etc).
Il y a même des attaques plus marrantes qui laissent le joli cadena vert dans la barre d’adresse (avec du AJAX qui recharge toute la page en HTTP plutôt que de faire la vraie requête GET/POST) !
http://www.crack-wifi.com/tutoriel-sslstrip-hijacking-ssl-mitm-https.php
La désactivation complète de HTTP est par exemple préconisée pour les API par Mozilla.