Aeris a écrit 435 commentaires

Oui sauf que le « bien plus tard » en terme de TLSA d’habitude, c’est plutôt de l’ordre de l’année :P
Je ne touche pas à mon shadow master tous les matins… Sécurité = stabilité !

C’est parfaitement de la faute à LE.
C’est une autorité de certification X.509, elle se doit donc de pouvoir respecter l’ensemble de la stack X.509. En particulier HPKP et TLSA.
C’est actuellement impossible, en tout cas simplement et de manière sécurisée.
C’est un non-sens total de la part d’une CA d’interdire les validations HTTPS ou de foutre des bâtons dans les roues de tout ceux qui veulent monter une infra sécurisée et fiable. Surtout quand on connaît la modification ultra simple (je ne la demande même pas par défaut dans certbot) qui le permettrait.

Ou sinon on est juste « yet another plain old CA », dont je me ferais une joie de me débarrasser dès l’émergence d’une solution alternative (coucou DANE-TA/EE !).

Et donc LE aura fait exactement comme l’IETF avec HTTP/2 : s’asseoir sur toute la stack TLS en la restreignant à simplement une clef et un certificat…
HPKP, TLSA, DNSSec ou même moins violent un simple reverse-proxy ou de la virtualisation, et ça ne fonctionne plus.
Quand on se place en pourfendeur du certificat auto-signé, ça pique un peu quand même… Surtout quand un simple changement de renouvellement à 1 an réglerait tous les problèmes…

Et tu ne peux pas restreindre les dynamic updates à juste les entrées de challenge. Tu as nécessairement besoin de pouvoir mettre à jour les entrées TLSA dans le cas d’un changement de certificat justement :D

Donc le problème ne vient pas de DNSSec, ça me rassure :)

Euh si quand même. Cf ma 2nde réponse :D
Je ne vois pas comment tu peux faire du DNS-01 challenge avec DNSSec activé. Les dynamic updates ne fonctionnent pas avec DNSSec.

En plus, les clients ACME n'ont absolument pas besoin d'avoir la clé privée à disposition: seul le CSR est nécessaire et la clé ACME de ton compte enregistré chez LE (ou un autre CA d'ailleurs…).

Je parlais plutôt des KSK et ZSK DNSSec. Pas envie de les filer à un truc en DMZ, qui fait du web, online 100% du temps, etc

D’ailleurs, je ne vois même pas comment DNS-01 peut être compatible avec DNSSec, en tout cas si on utilise OpenDNSSec.
OpenDNSSec ne supportant pas les mises-à-jour dynamiques, ça imposerait de réécrire tout le fichier de zone pour le faire signer par OpenDNSSec (qui mettra à jour le master Bind).
Ça ne me semble compatible qu’avec les serveurs DNS master + DNSSec, pas ceux séparant les 2 concepts (par exemple Bind9 + OpenDNSSec)

De devoir filer les clefs de mon shadow master DNSSec à un truc qui va gérer les certificats. Donc de casser la sécurité apportée par DANE/TLSA qui impose d’avoir 2 chaînes bien distinctes (DANE/TLSA d’un côté, le certificat de l’autre).
Mélanger les 2 fait qu’un attaquant qui prendrait possession de la clef privée ou du certificat aurait tout le loisir de changer au passage l’empreinte TLSA… Et donc rendrait inutile DANE/TLSA…

Les CGUs ne doivent pas être codées en dur dans les clients ACME: le dictionnary permet de connaître les CGUs en cours, il y a un Link aussi dans les réponses HTTP qui peut être renseigné par le serveur. Si l'utilisateur renseigne son e-mail lors de la création de son compte ACME, il pourrait aussi être averti en avance.

En pratique, c’est le cas… https://forum.cozy.io/t/du-fonctionnement-de-lets-encrypt-dans-cozy-et-des-certificats/2787/5?u=aeris

Le passage de X1 vers X3 s'est passé durant la phase bêta si je ne me trompe pas.

C’était déjà hors béta. Et LE a annoncé que ça pouvait arriver n’importe quand (s’ils doivent utiliser leur intermédiaire de secours par exemple).

Le challenge DNS permet de ne pas toucher à son serveur HTTP/HTTPS et permet une grande flexibilité dans son infrastructure. Par contre, il faut maîtriser un minimum son serveur DNS.

Et c’est incompatible avec DNSSec. Sauf comme déjà mentionner à devoir filer les clefs privées de son serveurs DNSSec à certbot…
Et TLS-SNI-01 impose d’utiliser un serveur HTTPd custom…

Ah et si leurs services ne te plaisent pas les spécifications sont ouvertes et leurs logiciels serveurs aussi il me semble…

Sauf que non, puisque du coup je ne pourrais pas être intégré aux navigateurs…

Oui, mais ça nécessite HTTP actif. Tu ne peux pas passer le challenge avec du HTTPS only…

Tu as le choix entre :
* Monter une infra délirante à l’opposé des principes de sécurité des technologies utilisées (TLSA étant intéressant quand il y a justement une séparation physique entre la machine détenant le certificat et celle détenant l’entrée DNS et que donc quelqu’un pouvant manipuler le certificat ou la clef ne pourra PAS manipuler le DNS), avec de la mise-à-jour automatique, des clefs partout et des systèmes de permission nécessitant presque d’écrire de nouveaux RFC pour gérer ton DNS de manière sécurisée
* Taper sur LE pour avoir des certificats de 1 an

Le rasoir d’Ockham indique que la bonne solution est la 2, pas la 1…

Je n’aurais pas mieux dis :)

Le post initial est https://status.imirhil.fr/notice/48923.
Et oui, je parlais aussi de moi. Malheureusement, Let’s Encrypt reste la seule solution viable pour les non-pro (je n’ai pas 400 boules par an à claquer dans un certificat, surtout quand je gère au moins une 10aine de domaine et une 100aine de certificats).

Et d’ailleurs, le gouvernement américain en est arrivé à la même conclusion que moi sur Let’s Encrypt :
* LE, ça ne marche simplement que quand tu as une mono-serveur
* un gros serveur god-master centralisateur en DMZ

https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cnames-shall-we/

Personnellement, à ta place je mettrais en place un système tiré. Tous les deux mois, ta machine spéciale fait signer et récupère un nouveau certificat, et toutes les semaines par exemple, tes machines tirent le certificat et relancent ou rechargent d'elles-mêmes leurs services. Si tu veux faire plus fin, elles peuvent ne relancer ou recharger leurs services que si le certificat a changé et après vérification de sa validité. Ça n'a pas besoin d'être spécialement synchronisé.

Ce n’est pas possible en pratique.
Tu dois synchroniser le changement de certificats sur l’ensemble du parc.
Par exemple les empreintes HPKP ou TLSA doivent être mise-à-jour en même temps que les certificats sur les HTTPd frontaux ou sur le postfix.
Tirer ne fonctionne que si tu n’as qu’une unique machine de concernée par le certificat. C’est rarement le cas en pratique (HPKP/TLSA) et surtout sur le web (reverse proxy, HA proxy, proxy cache…).
Tu ne peux pas te permettre d’avoir ton HTTPd qui tire le certif, et 2h après le TLSA qui se met à jour.

Eh bien pousse, dans ce cas. Ah oui, mettre à jour un fichier sur un serveur ça demande d'avoir un accès en écriture dessus ? Et c'est censé être un problème ‽ Mais c'est normal ça, tu voudrais quoi d'autre ? Franchement, je ne comprends pas l'argument, là.

Oui, c’est un problème. Actuellement, pour pouvoir pousser sur mon infra, je me retrouve avec une machine en DMZ avec un HTTPd dessus (pour le challenge ACME), contenant l’ensemble de mes clefs privées, CSR et certificats, avec une clef SSH root sans mot de passe permettant l’accès à la totalité de mon parc (HTTPd content + reverse, HA proxy, postfix/dovecot, jabber… nécessaire pour scp les clefs/certificats + restart des services associés), devant rester allumée la majorité du temps (quand tu gères une 100aine de certificats avec 90j de renew, tu en as au moins 1 par jour à être renouvelé), y compris au shadow master DNSSec (pour pouvoir changer les TLSA et resigner la zone) et à mes config HTTPd (pour les empreintes HPKP).
Je te laisse imaginer ce qu’il se passe si cette machine se fait compromettre…
Une telle machine existait auparavant, mais elle était sur une machine air-gap, allumée 1× par an pendant 10min pour renouveler tous les certificats en 1× (même si les dates d’expiration sont différentes, tu peux grouper fortement les batchs). Aujourd’hui, elle est en DMZ et allumée H24…

Eh bien, si ce n'est pas compliqué, il n'y a pas de problème. Tu veux que ce soit géré de façon automatique, automatise-donc sa gestion, mais ne te plains pas que Let's Encrypt ne le fasse pas pour toi : ils permettent de récupérer le certificat automatiquement, ce que tu en fais, ça te regarde.
Je n’ai jamais dis que LE devait automatiser pour moi.
Je dis simplement que les choix techniques (90j de renew en particulier, mais aussi le HTTP-only pour ACME) de LE m’empèche d’automatiser sans mettre DRASTIQUEMENT ma sécurité à genou.

Si tu épingles le certificat, forcément, tu doit faire un changement dans le DNS, mais ce n'est pas la faute de Let's Encrypt, seulement une conséquence de tes choix d'administrateur. Et si c'est compliqué à automatiser dans ton cas, tout ce que ça indique, c'est que tu as une architecture qui n'est gérée que de façon partiellement automatisée.

Non. Je me retrouve à 1- utiliser LE, à désactiver la moitié de ses features et paramètres par défaut, pinner sur la clef ou 2- utiliser LE, pinner sur le cert, avoir la fucking machine de l’horreur en prod et en DMZ ou 3- utiliser LE, pinner sur le cert, ne pas pouvoir automatiser complètement (TLSA non pris en charge de manière sécurisée).

Dans tous ces cas, les problèmes que tu soulèves ne viennent pas de Let's Encrypt, qui font simplement, à peu de chose près, ce qui peut se faire de mieux, à savoir automatiser l'émission et la récupération de certificats. Intégrer ça sur un serveur tout simple, c'est trivial, intégrer ça dans une architecture plus complexe, eh bien c'est plus complexe, mais toujours automatisable quand on s'en donne les moyens. Et dans tous les cas, c'est toujours mieux que le processus manuel avec les autres autorités de certification.

Non. L’automatisation avec LE implique une BAISSE de la sécurité globale de ton système. Uniquement par le fait du renouvellement du certificat à 90j. Ils le mettraient à 1 an, je pourrais automatiser complètement de manière sécurisée (avec certes un lancement humain de la procédure chaque année).
HTTP/2 a fait la même erreur que LE : réduire TLS à simplement les clefs et certificats X.509. TLS, c’est BEAUCOUP plus que ça, son écosystème est bien plus complexe.

Faudrait savoir, en quoi TLSA permet de s’affranchir des CA moisies si ce n’est « implémenté nulle part » ?

J’ai dit que DANE-TA/EE n’était pas implémenté (ie sans validation de la chaîne X.509 et qui permettrait d’avoir de l’auto-signé sans erreur lors de la navigation). PKIX-TA/EE est implémenté (plugin firefox disponible) et implique la validation X.509 en plus de DANE/TLSA.

Un pin sur le certificat ne te protège pas davantage contre ce cas, celui qui a mis la main sur ta clef pourra potentiellement s’en servir tant que la signature de l’enregistrement TLSA n’aura pas expirée.

Ça protège plus que juste sur la clef. Un pin sur le certificat empèchera par exemple une interception MitM via un faux certificat généré avec la même clef. En cas de compromission de la clef, avec un pin sur le certificat, le seul moyen d’attaque reste l’interception directe pour déchiffrement a posteriori du trafic RÉEL entre un client et le serveur.
Ce cas est hardcore, on est d’accord, mais ce petit détail peut te laisser un peu plus de temps pour révoquer la clef compromise sans mettre (trop) en péril tes utilisateurs.

Ah ouais quand même. Donc c’est trop dur pour un administrateur système d’invoquer openssl req correctement, par contre tu attends d’un simple utilisateur qu’il compare lui-même, manuellement, l’empreinte du certificat telle que présentée par le navigateur avec celle qu’il sera aller chercher dans le DNS.

Je ne pourrais pas te citer les cas concrets associés pour des raisons évidentes de sécurité, mais la vérification manuelle ça a (et ça peut toujours) potentiellement sauver des vies, oui :) (Par exemple quand ton navigateur ne permet pas la validation DNSSec ou DANE/TLSA).

$ openssl req -config req.cfg -new -key $keydir/mykey.pem -outform DER -out $outdir/req.csr
[… too much snip…]
Vas-y, rigole dans ton coin. Moi ça fait déjà quelques messages que tu ne me fais plus rire.

C’est exactement ce que je dis. Hors de portée d’une personne standard.
D’ailleurs ton exemple est erroné puisque le CN devrait être identique à au moins un des SAN indiqués, généralement même le 1er.
Et il te manque aussi la gestion des paramètres d’utilisation de la clef (avec sa compatibilité Netscape).

Pourquoi veux-tu que ça casse quoi que ce soit ? Le protocole ACME, et son implémentation par Let's Encrypt, fournit l'URL certificat intermédiaire lors de l'émission du certificat. Un client ACME bien fichu doit pouvoir l'utiliser, et n'a aucune raison de dépendre d'un certificat intermédiaire donné : s'il change, il récupère le nouveau et tout marche comme sur des roulettes.

Ce n’était pas le cas de certbot (à l’époque en tout cas) : il ne renouvellait que le certificat, et demandait à l’utilisateur d’embarquer en dur la chaîne intermédiaire (générée au 1er appel de certbot).
Et même pour ceux qui avait automatisé à mort, ils se sont retrouver avec 2 chaînes différentes (les certificats pas encore renouvelés et ceux fraîchement renouvelés), mais un seul chain.pem utilisé pour tous les vhosts via SSLCertificateChainFile (ça a donné pas mal de soucis en pratique en tout cas.)

Eh bien tu ne le pousse pas, tu le tires. Sérieusement, c'est un problème qui n'est pas du tout lié à Let's Encrypt : tu as une architecture compliquée, eh bien c'est compliqué à maintenir à la main, et compliqué à automatiser, c'est dur, mais c'est la vie.

Tirer, ça pose les problèmes de synchronisation. Il faut tiré pile après avoir renouvelé, et depuis toutes les machines en même temps pour éviter les problèmes de certificats pas identiques entre les machines.
Et mon archi n’est pas compliquée, c’est le b.a-ba d’une infra correcte aujourd’hui (virtualisation, dual stack ipv4 (reverse proxy)-ipv6 (direct access), HA proxy…)

Quant à DANE, je ne vois pas en quoi Let's Encrypt empêche ou complique excessivement quoi que ce soit.

Si tu changes de pin, il faut mettre à jour les entrées TLSA. Ce qui est encore plus compliqué à mettre en place que de tirer les certificats…

Et accessoirement, en fait tu peux tout à fait récupérer le certificat racine automatiquement : le certificat intermédiaire est fourni, et une fois que tu l'as, tu peux chercher l'URL de CA Issuers, qui permet de télécharger le certificat racine.

Quand ce n’est pas juste totalement buggé chez LE.

Dit autrement, c’est le principe même de l’enregistrement DANE-EE qui permet(trait) de dégager la notion de CA, pas le fait d’épingler le certificat au lieu de la clef publique.

DANE-TA/EE n’est encore implémenté nul part malheureusement :'(
Mais TLSA, si tu pin sur le certificat, permet de s’affranchir des CA moisies, vu que si un faux certificat est émis (y compris par ta CA), il ne validera pas TLSA.
Un pin sur ta CA ou son intermédiaire te protège uniquement d’une usurpation par une autre CA.
Un pin sur ta clef ne te protège plus d’une compromission de ladite clef (possibilité d’émettre de nouveaux certificats, mais je t’accorde que ce cas est de toute façon un « tout est foutu » :P).
Et il est plus facile pour un humain de valider l’empreinte du certificat (dispo nativement et facilement dans les détails du certificat de ton navigateur) que celle de la clef associée (beaucoup plus difficile d’accès).

Et je rappelle à toute fin utile que la décision de changer de clef à chaque renouvellement n’est pas une décision de l’autorité de certification Let’s Encrypt. C’est une décision purement locale qui est du seul ressors du client, Let’s Encrypt n’impose rien du tout sur ce point.

LE n’incite pas à faire autrement. Et les paramètres par défaut sont malheureusement plus proche d’une imposition par le prestataire que d’un choix local. Les probabilités qu’un utilisateur les remettent en cause sont assez faibles (c’est même un des gros problèmes actuels de la crypto, avec des softs possédants une configuration par défaut mauvaise, et un des cheval de bataille du monde sécu du moment avec le « privacy/security by design »).

Donc comprendre comment la générer proprement (SAN, SHA-2…), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante…

OK, en fait tu trolles.

Je te laisse mettre ici la ligne de commande openssl pour générer un CSR multi-domaine avec SAN et extensions X.509 corrects. On va rigoler…
J’ai même du développer ma propre PKI LE pour arriver à faire des choses correctes à ce niveau…

Je ne peux pas parler pour tous les clients, mais je réfute que ce soit « très complexe » avec le client Certbot. Il suffit de générer soi-même la clef et la requête de certificat (ce que tu devais faire de toute façon avec une CA plus traditionnelle), et d’utiliser l’option --csr de Certbot.

Je veux dire qu’il faut déjà savoir générer une CSR. Donc comprendre comment la générer proprement (SAN, SHA-2…), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante…

Pas plus que pour travailler avec une CA traditionnelle — avec laquelle tu dois déjà générer toi-même la CSR (si tu utilises une CA qui te génère la clef pour toi et te la donne en même temps que le certificat, euh comment dire…)

C’est un peu le sens de ce que je disais. Si tu veux faire les choses proprement, on en revient à restreindre LE à « une CA comme les autres ». Donc on s’attendrait à quand même pouvoir émettre du certificat d’un an…

Le renouvellement du certificat (pas de la clef) n’implique le renouvellement des enregistrements TLSA que si tu épingles le certificat lui-même (selector à 0) au lieu de la clef publique (selector à 1)… ce qui est déconseillé (même si pas très fortement) par le RFC 7671

Ça a l’intérêt de justement dégager la notion de CA, qui est bordélique au possible et devrait mourir vu le taux de compromission parmi ces trucs…

dans le cas où tu épingles au niveau terminal (DANE-EE au lieu de DANE-TA), il est conseillé d’épingler la clef publique plutôt que le certificat entier.

Donc de désactiver la gestion de la clef par LE :P

Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.

Je veux dire par là que ton serveur de renouvellement, nécessairement en DMZ par design (ACME challenge) va devoir modifier les entrées TLSA. Donc doit avoir accès à la zone DNS en écriture. Ce qui casse tout l’intérêt de TLSA (séparation forte/physique entre certificat et DNS).
En cas de compromission de ton certificat/clef, il y aura de fortes chances que l’attaquant puisse du coup modifier tes entrées TLSA au passage.

(En théorie, ton serveur DNSSec devrait être un shadow master hors DMZ, faisant les rollovers nécessaires et publiant via AXFR à ton « master » (en fait un slave du coup) DNS public qui lui est en DMZ. Ainsi tes clefs DNSSec sont à l’abri en cas de compromission de la DMZ.)

Des certificats valides pendant trois ans n’incitent pas les administrateurs à mettre en place une telle procédure.

Mais des certificats valides 90j n’incitent pas plus à la sécurité, au contraire. C’est incompatible avec la plupart des autres protections X.509 existantes. La sécurité préfère largement les situations stables à celles instables, ne serait-ce que parce que la confiance est difficile dans une situation dynamique.
Un certificat de 1 an permet BEAUCOUP plus de sécurité que ce que LE propose (rien que par le fait que je peux transmettre son empreinte à un correspondant sans craindre qu’elle ne soit plus valide demain).

Si la réponse est « plus de deux minutes », c’est que la procédure n’est pas assez automatique.

Certes, mais la différence est énorme entre « j’ai une procédure de 2 min automatique de renouvellement en cas de compromission » et « je l’applique violamment tous les 60j, on ne sait jamais ».

Un des objectifs de Let’s Encrypt est clairement de pousser à l’automatisation. En fait, c’est leur deuxième key principle :

Sauf qu’ils l’ont déjà rendu impossible par au moins 2 fois :
* Changement de l’URL de leur CGU, ce qui a explosé tous les outils de génération. Pas mal de monde a du attendre la mise-à-jour (de LE puis de leur distribution…) pour pouvoir générer de nouveau des certificats.
* Passage de l’intermédiaire X1 à X3, ce qui a cassé toutes les chaînes de certificats (si vous aviez HSTS actif, ça a signifié l’impossibilité totale pour vos visiteurs de se connecter à votre site, il n’y a plus de bouton « Continuer quand même » sur l’alerte de sécurité dans ce cas).

Et que certains choix techniques empêchent en pratique une génération 100% automatique sans réduire DRASTIQUEMENT la sécurité globale de ton système d’information :
* Gestion du multi-frontal, par exemple un HA proxy ou de la virtualisation (comment je pousse le même certificat et clef sur tout le parc sans avoir un god-master root en DMZ sur tout mon parc ie le 7ème cercle de l’enfer)
* Impossibilité de générer du certificat sur du HTTPS-only (il faut obligatoirement HTTP actif, un comble…)
* Gestion impossible ou extrêmement complexe de HPKP et pire de DANE/TLSA
* Pas de support de IPv6 jusqu’à très récemment
* Impossibilité de récupérer le certificat racine automatiquement

Alors en fait non, si je réclame plus que 90j de durée de vie, ce n’est pas pour me faciliter la vie :P C’est du à HPKP justement.

À chaque modification de ton épinglage, tu dois t’assurer que TOUS tes anciens visiteurs auront soit leur dernier épinglage vu expiré, soit qu’ils sont repassés suffisamment récemment sur ton site pour avoir le nouvel épinglage.
En pratique, ça n’est possible que si tu respectes 2 conditions :

• Tu dois toujours avoir un épinglage d’avance : si tu utilises actuellement la clef N, tu dois publier l’épinglage N et N+1.
• Si tu as une durée de rétention de ton épinglage de X, tu ne peux PAS renouveler ton épinglage plus souvent que X (cf https://twitter.com/aeris22/status/684513128143536128).

Les 2 cumulés font qu’avec Let’s Encrypt, c’est head shot direct…
Le 1er point fait que tu dois avoir une clef prête à l’avance que tu peux déjà publier dans ton épinglage et que tu utiliseras pour la génération de certificat suivante. Très complexe avec la plupart des clients Let’s Encrypt (et ça demande dans tous les cas une bonne maîtrise de X.509).
Le 2nd point fait que tu as un compromis à faire entre « je peux révoquer rapidement ma clef en cas de compromission » (X faible) et « HPKP n’est intéressant qu’avec un délai de rétention élevé » (Sinon expiration entre 2 visites et donc pas d’intérêt). En pratique, le RFC HPKP recommande une durée X de l’ordre de 60j. Avec Let’s Encrypt, comme il est conseillé de renouveler ses certificats à 60j (et pas 90j histoire de se laisser un peu de temps en cas de merde, et avec LE, les merdes arrivent toujours, avec des corrections non implémentables automatiquement…), tu passes en pratique l’intégralité de ta vie à ne RIEN pouvoir faire en cas de compromission de ta clef privée (tu ne peux pas renouveler avant l’expiration du délai de 60j, qui est pile ton délai de renouvelement, tu passes donc 100% de ton temps à poil…).

Pour que HPKP fonctionne correctement, il faut un délai de rétention de l’épinglage très inférieur au délai de renouvellement de ta clef privée.
En pratique, avec une rétention de 60j, j’aurais tendance à conseiller une clef d’au moins 2 ans (60j à poil tous les 730j, soit 8% du temps) voire 10 ans (60j sur 3650, soit 2%).
Et donc se passer totalement du renouvelement de la clef de Let’s Encrypt :)

J’ajoute aussi que, à la différence du certificat, une clef privée n’a PAS de date d’expiration. À partir du moment où vous avez utilisé une clef pour un échange protégé, vous DEVEZ la gérer À VIE, en particulier si vous avez utiliser une suite de chiffrement sans PFS. Cf l’épisode HeartBleed.
Il est donc étrange de la part de Let’s Encrypt d’indiquer que renouveler fréquemment une clef augmente la sécurité, ce n’est à mon avis pas du tout le cas, voire plutôt l’inverse…

Les problèmes précédents existent aussi pour DANE/TLSA, la version DNS de HPKP.
Il est même encore pire puisque DANE/TLSA implique DNSSec, et donc que la phase de renouvelement du certificat ou de la clef devrait impliquer le renouvelement des entrées DNS correspondantes… donc une nouvelle signature de votre zone DNSSec… donc votre serveur web ayant un contrôle root sur votre zone DNSSec… donc le désintérêt total de DNSSec et de DANE/TLSA…

Je pense que dans une ère post Snowden, ce genre de feature est trivial !

Attention à ne pas tout mélanger !
Snowden a montré que les communications doivent être protégées. Le stockage en lui-même non, en tout cas pas pour des motifs liés à cette affaire.

Le stockage chiffré est intéressant uniquement pour se protéger d’une divulgation involontaire des données dans la nature (machine perdue, intrusion informatique, saisie judiciaire…).
Et le chiffrement côté stockage vient avec pas mal d’inconvénients si le chiffrement est fait en haut niveau (contenue de la base de données). Impossible de lancer (en tout cas de manière efficace) une recherche par nom de fichier ou sur le contenu d’un mail par exemple.
Ou totalement inutile si fait en bas niveau (système de fichiers ou moteur de base de données). En effet dans ce mode de fonctionnement, les données sont accessibles en clair tant que la machine est maintenue allumée.

Cozy utilise TLS (correctement configuré !) pour le chiffrement des communications, donc adresse le problème de l’affaire Snowden autant que possible (les méta-données restent un problème difficile à résoudre, pour tout le monde).

Le chiffrement haut niveau du stockage est inutilisable en pratique à l’heure actuelle sans chiffrement homomorphique, ou avec pertes très importantes en terme de performances ou de fonctionnalités.
On pourrait chiffrer en bas niveau, mais on se prémunirait uniquement d’un cambriolage dans le cas des auto-hébergés et d’une saisie judiciaire côté offre hébergée. Autant dire d’un risque plus que faible voire inexistant. Et dans tous les cas les données seraient accessibles tant que le système resterait en ligne (pas de protection contre une intrusion par exemple).

Oui, le chiffrement est important. Non, ce n’est pas la solution à tous les maux. :)

Personnellement, je préfère éviter de chiffrer mes disques principaux avec une phrase de passe. J’utilise exclusivement un fichier de clef de 512 octets. Ça évite un éventuel bruteforce de ma passphrase :P

La passphrase se trouve uniquement dans le mini-conteneur LUKS contenant la partition de clef, qui sert ensuite à déchiffrer tout le reste.

Alors je viens de tester, je ne vois pas l’impossibilité ou alors je ne l’ai pas comprise…

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 8G 0 disk

├─sda1 8:1 0 94M 0 part /boot
└─sda2 8:2 0 7,9G 0 part

└─sda2_crypt 254:0 0 7,9G 0 crypt
└─vg-lv 254:2 0 15,9G 0 lvm /
sdb 8:16 0 8G 0 disk

└─sdb1 8:17 0 8G 0 part

└─sdb1_crypt 254:1 0 8G 0 crypt
└─vg-lv 254:2 0 15,9G 0 lvm /

$ pvs
  PV                     VG   Fmt  Attr PSize PFree
  /dev/mapper/sda2_crypt vg   lvm2 a--  7,90g    0 
  /dev/mapper/sdb1_crypt vg   lvm2 a--  7,99g    0

$ vgs
  VG   #PV #LV #SN Attr   VSize  VFree
  vg     2   1   0 wz--n- 15,89g    0

$ lvs
  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv   vg   -wi-ao---- 15,89g

Avec une méthode de type LVM on LUKS (la plus couramment utilisée), on perd la possibilité d'étendre ses volumes logiques sur plusieurs disques

Hum, je n’ai jamais tenté, mais je ne vois pas en quoi ça serait génant.
Une fois ouvert, le conteneur LVM sera vu comme un périphérique bloc (dans /dev/mapper) et me semble du coup totalement utilisable comme volume physique LVM normal, donc y compris pour extension d’un volume logique sur plusieurs disques…