gouttegd a écrit 1805 commentaires

il va probablement […] se faire arrêter en bon et du forme avant d'être envoyé à Guatanamo

Mon détecteur d’ironie est en panne, c’est du second degré ou bien ?

j'ose espérer qu'ils se basent sur autre chose que ce qu'affirme l'ordinateur

Oh oui. La première fois ils se sont basés sur l’observation que la cible dans leur viseur est un « homme de grande taille auxquel d’autres personnes s’adressent avec révérence ». Si ça ce n’est pas une preuve que c’est « une cible appropriée » (même si « on ne sait pas exactement de qui il s’agit »), je ne sais pas ce qu’il te faut ⸮

Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.

Non, l’un comme l’autre peuvent être structurés ou non-structurés.

Plus précisément :

• Les informations autour du message de log (telles que la date, la machine, la priorité, etc.) sont toujours structurées, que ce soit avec syslog ou avec journald. La seule différence est que journald stocke beaucoup plus d’informations de ce genre qu’une implémentation typique de syslog (chez moi, syslog stocke uniquement la date/heure, le nom d’hôte, et le nom et PID du processus — mais toutes ces informations sont enregistrées d’une façon cohérente dans tous les fichiers de logs et sont parsables sans surprise).

• Le message de log proprement dit (ce qu’envoie le programme au système de journalisation, via syslog(3) ou sd_journal_print(3)) peut être structuré ou non, mais la plupart du temps il ne l’est pas, c’est une chaîne de caractères que le programme formatte à sa guise. Je doute fort que journald change quoi que ce soit à ça, c’est entièrement du ressort du programme émetteur (et ça fait des années que la possibilité d’envoyer des messages structurés à syslog existe sans que personne ne s’en serve, donc je ne vois pas pourquoi tout le monde déciderait subitement de le faire juste parce que journald le permet aussi).

Exemple, le format de mod_security est relou […] Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.

Les programmes qui se chargent eux-mêmes de leurs propres logs (souvent avec leur propre format) au lieu de passer par le démon de journalisation du système poseront toujours problème, peu importe que le démon de journalisation soit syslogd ou journald…

Je poste dans le but de savoir […] si le format de fichier *.desktop est universel dans le monde Linux

Oui. Ce format est autant « universel » qu’on peut l’espérer dans le monde Linux. C’est une spécification de freedesktop.org.

Et puis aussi si cela est bien le cas si ces fichiers sont tous situer dans le dossier /usr/share/applications.

Ils sont stockés sous $XDG_DATA_DIRS/applications, où $XDG_DATA_DIRS est définie par la spécification XDG Base Directory. Par défaut, $XDG_DATA_DIRS vaut /usr/local/share/:/usr/share/, ce qui veut dire que les fichiers .desktop sont à chercher successivement dans /usr/local/share/applications et dans /usr/share/applications.

L’utilisateur peut aussi installer ses propres fichiers .desktop dans $XDG_DATA_HOME/applications (avec $XDG_DATA_HOME = $HOME/.local/share par défaut).

Ou définir la seconde carte comme carte par défaut, avec quelque chose dans ce genre-là (à mettre dans /etc/asound.conf ou ~/.asoundrc) :

pcm.!default {
    type hw
    card 1
}

ctl.!default {
    type hw
    card 1
}

Question intéressante sur laquelle je ne m’étais pas penchée. Si un attaquant s’en prend à l’AFNIC et obtient le contrôle de la zone fr. (ou si l’attaquant est l’AFNIC, ce qui revient au même), que peut-il faire ?

L’option la plus simple, je pense, est de supprimer l’enregistrement DS pour example.fr., brisant ainsi la chaîne de confiance allant de la racine jusqu’au contenu de la zone. L’enregistrement TLSA pour www.example.fr. sera toujours là, mais en l’absence de délégation sécurisée cet enregistrement sera considéré non-sécurisé et le navigateur web devra obligatoirement l’ignorer (RFC 6698, §4.1). L’attaquant peut alors tenter son attaque MITM en présentant un faux certificat — la réussite ou l’échec de cette attaque dépendra des autres moyens de vérification implémentés dans le navigateur (PKIX, Convergence, éventuellement HPKP si ce n’est pas la première visite, etc.), mais l’attaquant ne sera plus gêné par DANE qui est hors-jeu à ce stade.

Une faiblesse de cette attaque est qu’elle est facilement détectable : une zone entière qui devient subitement non-sécurisée, il y a peu de chance que ça passe inaperçu. Par contre, un avantage est qu’elle offre un certain déni plausible : si l’AFNIC est prise la main dans le sac, elle peut facilement faire passer ça pour une honnête erreur (« oups, désolé, l’enregistrement DS a sauté à cause d’une bête erreur dans le script qui re-signe périodiquement le fichier de zone, on a viré le stagiaire ça n’arrivera plus, promis ») — un peu comme les CA prises à émettre des certificats frauduleux, d’ailleurs.

Donc il y a bien 2 intermédiaires. Dans mon exemple :

AFNIC -> Gandi -> example.fr

Oui, clairement. J’argumenterais que ça reste mieux que le système PKIX où il faut faire confiance à toutes les CA, mais dire que le bureau d’enregistrement est le seul tiers de confiance était exagéré.

Et je ne compte pas l'ICANN qui gère la racine

Il faudrait pourtant, même si une attaque à ce niveau serait probablement encore moins discrète qu’une attaque au niveau du TLD.

je ne dois pas simplement faire confiance au gérant de la zone, mais aussi à tous les registars avec lesquels il travaille.

Erreur de vocabulaire de ma part, désolé.

L’acte de foi est bien envers le bureau d’enregistrement auprès de qui le gérant de la zone a obtenu son domaine (et à qui il communique sa clef DNSSEC, ou l’empreinte de celle-ci).

Pour ce qui est du gérant de la zone, il faut certes aussi lui faire confiance, mais je partais du principe que celui-ci relève généralement de la même entité que celle qui gère le service auquel je veux me connecter — cette entité n’est pas un tiers de confiance, c’est l’une des deux parties dans la communication.

le problème reste la première connexion

Euh, dans ton hypothèse où « DNSSEC est déployé partout et que ça marche bien », la première connexion n’est plus critique. Tu récupères l’empreinte du certificat du serveur dans le DNS avant la première connexion au serveur TLS, donc le serveur est correctement authentifié dès le départ, il n’y a pas besoin de leap of faith ou de trust on first use.

Le seul « acte de foi » requis est envers le gérant de la zone DNS : s’il te raconte n’importe quoi (par malveillance, incompétence ou parce que son système d’avitaillement a été piraté — ce qu’on peut ranger dans l’incompétence en un sens, il lui appartient de savoir se protéger), ce n’est pas DNSSEC qui va te protéger de ça.

C’est l’équivalent, dans le monde DNSSEC/DANE, de l’acte de foi envers les autorités de certification du monde PKIX. À celà près que dans le monde PKIX, tu dois faire confiance à toutes les CA reconnues, quand DNSSEC/DANE te demande de faire confiance au seul bureau d’enregistrement du domaine que tu visites.

Et si on allait chercher trop loin alors qu'on a déjà des solutions ?

C’est exactement ce que je me suis dit en lisant ta proposition…

Un système de clé privée/publique par domaine, avec son empreinte qu'on pourrait publier dans les enregistrements DNS, et le tout avec du Perfect Forward Privacy.

On peut faire tout ça sans avoir à créer un nouveau protocole, tout est déjà en place. Mince, je fais déjà tout ça, moi tout seul dans mon coin, qu’on ne vienne pas me dire que ce n’est pas possible.

Le problème n’est pas de pouvoir faire ça, mais de faire en sorte que les clients s’en servent. Et là, je te souhaite bon courage pour obtenir des éditeurs de navigateurs qu’ils prennent en charge ton shttp.

Je m'imagine donc une prise en charge des naviguateurs et des serveurs web en douceur, puisse qu'on ne touche pas à HTTP, ni à HTTPS

Et la marmotte… DANE non plus ne touche à rien de ce qui existe déjà, il peut complètement coexister avec le modèle actuel, et regarde les réticences qu’il rencontre.

Les points négatifs, j'ai du mal à les voir.

Premier point : si les empreintes sont publiées dans le DNS, il faut pouvoir se fier aux données du DNS. Bonne nouvelle, il suffit de les signer, et DNSSEC et là pour ça. Mauvaise nouvelle : les acteurs du web mettent un point d’honneur à faire comme si DNSSEC n’existait pas.

(En fait, ils se moquent tellement de DNSSEC et du fait que le DNS seul n’est pas fiable que lors de l’annonce de la faille Kaminsky — qui trivialise l’empoisonnement de cache —, beaucoup de gens ont réagi en disant « bof, pas grave, de toute façon on a SSL par-derrière pour “garantir” (sic) qu’on se connecte bien au bon serveur, si le DNS nous envoie ailleurs la couche SSL nous avertira ».)

Deuxième point : c’est le même point négatif que toutes les autres alternatives envisagées depuis des années : tant que tu ne mettras pas Google, Mozilla, Microsoft ou Apple derrière toi, ça ne sera jamais implémenté que par quelques geeks dans leur coin.

Oh oui, jetons aux oubliettes ce RSA qui ne résiste aux attaques que depuis trente ans, et jetons-nous à corps perdus dans des algorithmes chaudement recommandés par la NSA et dont les paramètres (pour les courbes autorisées dans DNSSEC) ont été choisis sur des critères non-spécifiés ⸮

On pourrait implémenter des certificats GPG et se baser sur cette chaîne de confiance.

C’est déjà spécifié, mais à ma connaissance il n’y a que GnuTLS qui implémente ça.

Il y a aussi Monkeysphere, qui vise à peu près la même chose de façon indépendante.

Quelle distribution GNU/Linux moderne n’embarque pas PAM actuellement ?

(3×)Slackware

Je suis étonné que personne n’ait saisi une telle perche : « on a demandé une distribution moderne… »

Serait-ce l’ultime déchéance d’une distribution qui est tellement oubliée qu’on n’a même plus le cœur à vanner ses utilisateurs ?

(Tss, DLFP n’est plus ce qu’il était. Voilà qu’il faut se moquer soi-même de sa distribution à présent.)

L’idée est globalement la même, à savoir publier les clefs dans le DNS. Je ne sais pas à quels enregistrements DNS ils font référence, mais il s’agit probablement des enregistrements de type CERT (RFC 4398), qui sont précisément conçus pour ça. (DANE de son côté utilise des enregistrements TLSA (RFC 6698).)

Le principe est que si je cherche un certificat (X.509 ou OpenPGP, les enregistrements CERT sont utilisables pour les deux) pour Monsieur Michu michu@example.net, je peux le trouver dans le DNS sous la forme d’un enregistrement CERT pour le nom michu.example.net..

C’est une approche intéressante et en théorie prometteuse de la distribution des clefs, dans la mesure où elle pourrait être réalisée automatiquement par les fournisseurs de messagerie (qui ont logiquement le contrôle de la zone DNS dans laquelle se trouve les adresses de leurs utilisateurs). En théorie seulement car ① je ne connais aucun fournisseur de messagerie qui fasse cela ou même qui ait exprimé un quelconque intérêt à cette technique, et ② ce n’est fiable que si les zones DNS des fournisseurs de messagerie sont signées, ce qui n’est le cas de pratiquement aucune.

Oui, à condition de maitriser les installation des navigateurs pour leur changer leur certificat racine.

Non, il suffit de demander à une CA reconnue un certificat avec l’extension Basic Contraints CA:true, et tu deviens de fait une sous-CA capable de signer des certificats que tout le monde acceptera.

Les CA ne sont pas supposées délivrer de tels certificats à la légère, mais dans les faits ce n’est pas difficile d’en trouver qui le font. D’ailleurs quand l’une d’elles admet qu’elle le fait, il s’en trouve pour… applaudir son honnêteté (“I Think Trustwave should be commended for being the first CA to come forward”).

Sinon, cela ne marche pas sans démarche illégale.

IANAL, mais je ne pense pas qu’il soit illégal de demander à une CA un certificat pouvant servir de sous-CA, ni qu’il soit illégal pour une CA de délivrer un tel certificat. C’est contraire aux consignes du CA/Browser Forum, mais celles-ci n’ont pas force de loi, elles ne servent qu’aux navigateurs pour décider d’inclure ou non une CA dans leurs magasins.

Du MITM avec de faux certificats, ça ne demande pas des ressources énormes (ce n’est pas de la cryptanalyse). Beaucoup d’entreprises le font sur leur réseau.

Faire ça à l’échelle d’un pays est un peu plus difficile, mais pas d’inquiétude, la France peut fournir (et a fourni à certains) l’équipement nécessaire.

Slackware comme déjà dit, et il y a apparemment des distributions qui le fournissent mais laissent la possibilité de s’en passer (c’est le cas de SourceMage, où ulimits est d’ailleurs empaqueté sous la forme d’un « sort » dans le « grimoire »).

D’après ce que j’ai constaté, la plupart des KSK en circulation font 2048 bits, ce sont les ZSK qui font souvent 1024 bits.

Des clefs de 2048 bits qui changent tous les deux ans (pas obligatoire, mais c’est la période de validité la plus souvent recommandée pour les KSK) et des clefs de 1024 bits qui changent tous les quelques mois (encore une fois, ce n’est pas obligatoire, mais ça semble être la pratique courante), ça me paraît un assez bon compromis entre performance (les signatures sont d’autant plus grosses, et leur vérification plus longue, que les clefs sont de grande taille) et sécurité.

Je ne serais pour ma part pas mécontent qu’on mette un peu le hola à l’augmentation irréfléchie de la taille des clefs cryptographiques. Une bonne gestion des clefs (incluant, par exemple, un renouvellement fréquent) est plus pertinent à mon sens que des clefs de 3072 ou 4096 bits.

sans Perfect-Forward-Secrecy, ça expose toutes les connexions à un décryptage a-posteriori sur une échelle de temps plutôt courte.

Il ne faut pas tout mélanger. Les clefs de DNSSEC ne sont pas utilisées pour chiffrer, elles ne font que signer.

Si quelqu’un casse la clef DNSSEC d’un domaine (ou même de la racine) dans cinq ans, ça lui permettra, à ce moment-là, de falsifier des signatures DNSSEC (et donc, dans le cas de DANE, de falsifier un enregistrement TLSA et de faire accepter un certificat qui n’est pas celui publié par le propriétaire du site visé).

Ça ne permettra absolument pas de revenir déchiffrer les communications préalablement enregistrées avant que la clef ne soit cassée, il n’y a même pas besoin de Forward Secrecy pour le garantir.

Oui, le système des CA est cassé, mais pour le moment il n'y a que lui et la mise en place d'une nouvelle CA est une solution sur le court terme.

La mise en place d’une nouvelle CA est peut-être une solution au problème que pas assez de monde ne chiffre, mais sûrement pas une solution au problème que « le système des CA est cassé »…

Ca prends du temps de créer un nouveau système de certification et qu'il soit accepté par tout le monde.

Ça en prend encore plus quand on ne fait rien qui aille dans ce sens, ce qui est précisément le cas des éditeurs de navigateurs (qui sont pourtant les mieux placés pour le faire, ce sont eux qui décident de ce qui est accepté ou pas).

Le seul effort en la matière actuellement est Certificate Transparency (c’est le seul qui a une chance d’aboutir, puisque poussé par Google — Convergence, DANE, les clefs brutes, et tous les autres sont condamnés d’avance pour ce qui est du web¹), et ce n’est pas un « nouveau système de certification », au contraire c’est une affirmation qu’on ne veut absolument pas se passer de l’ancien, et que toutes les propositions alternatives peuvent aller se faire voir. (CT considère comme un problème le fait que l’on puisse créer son certificat dans son coin et le publier dans le DNS.)

---

¹ Ils ont en revanche plus d’avenir du côté d’autres protocoles, comme SMTP, IMAP, XMPP, SIP & co.

Un pays dans lequel le simple fait de consulter certaines pages Wikipédia peut t’attirer des ennuis est probablement un pays dans lequel les fournisseurs d’accès aux ordres du gouvernement n’hésiteront pas à faire du MITM avec des certificats frauduleux signés par une sous-CA complaisante…

Dans ce cas de figure, le chiffrement généralisé non seulement ne protège personne (du moins tant qu’on n’aura pas d’autres moyens de vérifier un certificat que de faire confiance à des CA), mais met en danger les gens qui visiteront les sites interdits en se croyant naïvement protégés, alors qu’ils n’auraient peut-être pas pris ce risque si on ne leur avait pas promis une (illusoire) protection.

mais quand je tape la commande :

# cryptsetup --cipher aes-cbc-essiv:256 --key-size 256 --hash sha256 --iter-time 1000 --use-random --verify-passphrase luksFormat /dev/sda1

il me dit sa :

[ 7257.313898] device-mapper: table: 254:1: crypt: Error creating IV
device-mapper: reload ioctl on failed: no such file or directory Failed to setup dm_crypt key mapping for device /dev/sda1. check that kernel supports aes-cbc-essiv:256 cipher (check syslog for more info).>

L’algorithme aes-cbc-essiv:256 n’existe pas (c’est une erreur de l’auteur du billet de blog que tu cites). Fais cryptsetup --help pour avoir la liste des algorithmes possibles. Ici, tu veux probablement aes-cbc-essiv:sha256.

Tu te fous de la gueule de qui?

Au pire, c'est 2 ans

Pas forcément, la réduction de la durée de validité des certificats est une des idées en vogue en ce moment. C’est une des pistes pour contourner les faiblesses des mécanismes de révocation (les CRL qui sont quasiment inutiles en pratique et OCSP qui pose plus de problèmes qu’il n’en résout).

Le raisonnement est qu’avec un certificat à courte durée de vie, si la clef privée est compromise, à défaut de pouvoir révoquer le certificat (ou plutôt, à défaut de pouvoir faire parvenir aux clients l’information que le certificat est révoqué), au moins il expirera vite et la période pendant laquelle la clef privée compromise pourra faire des dégâts sera réduite.

Plusieur sites de Google ont déjà des certificats valides pour seulement un mois. Adam Langley va jusqu’à proposer des certificats valides quelques jours.

Que faire d'une autorité dont la confiance peut être mise en cause ou d'une à qui on veut bien faire confiance mais qui a du mal à se faire accepter ? […] Le projet Certificate Transparency a pour but de répondre a ces questions

Non.

Certificate Transparency répond aux questions « ce certificat a-t-il été émis par telle CA ? » et « y a-t-il en circulation un autre certificat pour le même domaine, émis par l’une quelconque des CA participant à Certificate Transparency ? ».

Certificate Transparency ne répond pas du tout à la question « que faire d’une CA indigne de confiance ? ». Et pour cause, ce n’est pas une question technique susceptible d’être résolue par un protocole, c’est une question politique, qui dépend de facteurs comme « combien de nos utilisateurs vont se plaindre si on retire cette CA du magasin de notre navigateur ? », « ceux qui vont se plaindre parlent-ils la même langue que nous ? », « quelles sont nos relations avec cette CA (est-ce que je joue au golf avec son PDG) ? », etc.

Certificate Transparency ne répond même pas à la question « cette CA est-elle digne de confiance ? ». Si Certificate Transparency détecte un doublon (une CA qui émet un certificat alors qu’un autre a déjà été enregistré dans les journaux CT), ça peut tout au plus laisser planer un doute mais ça ne dit pas avec certitude que l’un des certificats est frauduleux (il y a des raisons légitimes de faire émettre un certificat pour un même domaine à deux CA différentes, HPKP encourage cette pratique d’ailleurs), ni lequel des deux est frauduleux (ce n’est pas forcément celui qui a été émis en deuxième).

Certificate Transparency répond surtout aux inquiétudes des autorités de certification qui commençaient à craindre que les propositions de validation alternative (Convergence, DANE et assimilés) ne finissent par saper leur position. Trop de gens se mettaient à dire qu’il serait temps de se passer des CA, heureusement CT est là pour remettre les pendules à l’heure et rappeler à tout le monde que les CA sont indispensables (rappel : les journaux CT n’acceptent que les certificats émis par les CA « reconnues », en pratique les mêmes que celles dont le certificat est inclus dans les navigateurs).

Ce ne sont pas les news qu’il faut regarder, c’est les Changelogs. Résultat : dernière activité le 26 avril au soir, et une grosse mise à jour quelques jours plus tôt.

Oui, Slackware est toujours vivante, et non, Debian n’est pas la plus ancienne distribution GNU/Linux en activité. :P

OpenSSH 6.7 : prise en charge des algorithmes ed25519, Chacha20-poly1305, AES en mode GCM et HMACs en mode Encrypt-Then-MAC

Pour continuer un peu là-dessus, un petit constat potentiellement intéressant : configurer un serveur SSH pour n’autoriser que ces nouveaux algorithmes¹ a pour effet de drastiquement diminuer les tentatives de brute-forçage, car il semble que les outils utilisés par les script-kiddies ne connaissent pas (encore) ces algorithmes.

Testé depuis maintenant plusieurs mois sur ma Slackware, avec un ssh qui tourne sur le port 22 (donc soumis à toutes les tentatives de scan habituelles), voilà ce que ça donne dans les logs :

sshd: fatal: Unable to negotiate a key exchange method [preauth]
sshd: fatal: Unable to negotiate a key exchange method [preauth]
…

Ça ne saurait être considéré comme une mesure de sécurité, bien sûr, mais je trouve ça amusant de claquer comme ça la porte aux nez des pirates en herbe. Pour un peu j’entendrais presque mon serveur se moquer du gars en lui disant « mets-toi un peu à jour avant de vouloir jouer au pirate, pauv’naze ». :D

---

¹ À ne faire que si votre client SSH les prend en charge aussi, évidemment, sinon vous vous fermez dehors…

Bah c’est surtout que les vannes sur Systemd, ça commence à être lourd (et puis, on ne sait jamais vraiment si c’est une vanne ou pas)…

C’est un peu comme les blagues du genre « le jour où Microsoft fera un truc qui ne plante pas, ce sera un clou ! »… (OK, je plaide coupable, j’ai moi aussi sorti cette blague, comme tout le monde, il y a quinze ans. Mais bon, au bout d’un moment on passe à autre chose.)

(Disclaimer : je ne t’ai pas moinssé.)