gouttegd a écrit 1805 commentaires

toute zone mémoire a pu être touchés DONT la clef SSH

Toute zone mémoire appartenant au(x) processus utilisant OpenSSL. La faille ne remet pas en cause l’isolation des processus (qui est assurée par le noyau, pas par OpenSSL), elle ne permet pas de se promener dans la mémoire d’un processus autre que celui qui reçoit le paquet TLS Heartbeat.

Même en étant très paranoïaque, je ne peux imaginer aucune raison de craindre que les clefs privées SSH se retrouvent dans la mémoire des processus utilisant TLS (serveurs web, serveurs de courrier, etc.).

et les mots de passe

Là d’accord, mais encore une fois, uniquement ceux qui transitent par le serveur TLS (mot de passe de connexion à la partie privée d’un site web par exemple, ou à un compte mail). Les mots de passe SSH sont hors de portée.

Mais en pratique ça n'arrive pas, j'ai eu le cas hier avec le fichier de ~ 70 Mio qu'on a essayé de m'envoyer depuis un compte gmail, et comme déjà dit je gère mes propres serveurs, c'est pas de mon côté que ça coinçait (enfin j'ai pas vérifié, mais a priori je n'ai rien mis dans ma conf pour bloquer quoi que ce soit).

Bah vérifie alors, parce que si toi tu n’as « rien mis dans ta conf », la configuration par défaut de ton serveur peut très bien être de limiter la taille d’un message.

Avec Postfix par exemple, la configuration par défaut limite à ~10 Mo.

Déjà, les clefs SSH ne sont pas concernées par Heartbleed. Heartbleed est une faille dans l’implémentation du protocole TLS, qui n’a rien à voir avec SSH (même si des notions de cryptographie sous-jacentes aux deux protocoles sont communes).

OpenSSH utilise une partie de OpenSSL (libcrypto, justement pour les fonctions cryptographiques), mais pas celle impliquée dans la faille Heartbleed.

Cependant, dans mon répertoire /etc/ssl/certs, la quasi totalité de mes certificats datent de 2010 à 2013 !!!

De quels certificats parles-tu ? Si tu parles des certificats racines fournis avec ta distribution (paquet ca-certificates sous Debian), ce ne sont pas tes certificats et ce n’est pas à toi de les renouveller, mais aux autorités de certifications qui les ont émis. Et encore, les certificats racines ne sont vraisemblablement même pas concernés non plus, parce que j’ose espérer que les autorités de certification conservent les clefs privés de ces certificats à l’abri sur des machines qui ne sont pas directement accessible depuis l’Internet (enfin, ça, c’est si les CA prenaient leur job au sérieux).

Les certificats que tu dois révoquer et remplacer sont ceux que tu as généré, fait signer (ou signé toi-même) et utilisé pour protéger n’importe quel service utilisant TLS.

je vois un certain nombre de souci avec ton script.

Il est rudimentaire, c’est certain. C’est pour ça que je l’apprécie. Il fait le job 99.9% du temps, je n’en demande pas plus.

Je précise que ce n’est pas à l’unité systemd qu’il faut comparer ce script (ça n’aurait aucun sens), mais bien au script System V, qui est beaucoup trop long pour le peu de services qu’il rend.

Tout ça, ça se corrige dans ton script.

Non ! C’est justement en voulant à tout prix essayer de gérer les 0.1% (et encore) de cas tordus directement dans le script qu’on en est venu à des scripts d’init de deux cents lignes. Si je voulais vraiment gérer ces cas tordus (personnellement je m’en moque, mais je comprends ceux qui le veulent), je préférerais encore utiliser systemd.

H.S. :

Et je parle pas d'avoir /var/lib en readonly ( livecd, etc ). Mais bon, c'est un détail, on peut supposer trivialement que ça se trouve dans /var/run, un truc poussé par systemd au passage.

J’aurais aimé mettre stunnel.pid dans /var/run avec les autres, mais en l’occurence, avec stunnel c’est un peu plus délicat, il est chrooté dans /var/lib/stunnel/ et le fichier de pid ne peut se trouver que dans le chroot. J’imagine que le script d’init pourrait se charger de récupérer le PID et l’écrire lui-même à la bonne place, mais on rentre précisément dans le genre de complications inutiles que je ne veux pas voir dans mes scripts d’init.

D’ailleurs, que propose systemd dans ce cas de figure ?

Les scripts d’init System V comme ceux-là sont imbitables, c’est clair, mais il ne faudrait pas oublier qu’il existe d’autres façons de faire qui n’impliquent pas de remplacer le système init tout entier…

Chez moi, un script d’init, ça ressemble plutôt à ça :

#!/bin/sh

PIDFILE=/var/lib/stunnel/stunnel.pid

case "$1" in
start)
    /usr/sbin/stunnel
    ;;

stop)
    [ -s $PIDFILE ] && kill `cat $PIDFILE`
    rm -f $PIDFILE
    ;;

restart)
    $0 stop
    sleep 1
    $0 start
    ;;

status)
    if [ -s $PIDFILE ] && kill -0 `cat $PIDFILE` ; then
        echo "stunnel is running."
    else
        echo "stunnel is not running."
    fi
    ;;

*)
    echo "Usage: $0 {start|stop|restart|status}"
    exit 1
    ;;

esac

Il est rare que je trouve les bonus suffisamment intéressants pour être conservés, mais quand c’est le cas, oui.

Pour ma part, je convertis mes DVD en fichiers Matroska (.mkv) contenant :

• la piste vidéo transcodée en H.264 ;
• la piste audio « principale » (bande son du film en VO) copiée dans son encodage d’origine (AC-3 généralement) ;
• (éventuellement) la piste audio française (lorsque le français n’est pas la version originale) transcodée en Vorbis ;
• (éventuellement) d’autres pistes audio que je trouve intéressante de garder (c’est rare), transcodées en Vorbis elles aussi ;
• les pistes de sous-titre, en VO et en français ;
• le chapitrage d’origine.

En moyenne, j’obtiens à l’arrivée un fichier .mkv d’environ 1 Go. Je ne suis pas vraiment en mesure d’estimer si le transcodage en H.264 provoque une perte notable de qualité (ça provoque forcément une perte de qualité je suppose, mais je ne remarque rien d’évident). Les menus ne sont pas préservés, mais je dirais que « it’s not a bug, it’s a feature » — sérieusement, je n’ai jamais compris l’intérêt des menus de DVD…

MPlayer n’a aucun problème à relire ledit .mkv et à permettre de naviguer entre les différentes pistes audio et de sous-titre.

Pour ceux que ça intéresse, le script que j’utilise pour produire un Matroska à partir d’un DVD est disponible. C’est essentiellement un mince wrapper autour de mplayer, mencoder, oggenc et mkvmerge. Attention, le script est assez « brut de décoffrage », rien à voir avec l’outil présenté dans le journal.

Eux, je ne sais pas, mais moi franchement, à leur place, je dirais « eh bien allez vous faire foutre. Ça fait quinze ans que le code est là, qu’il est libre, et que vous n’aviez pas de problèmes à vous en servir. Si vous trouviez le code horrible vous pouviez vous en mêler plus tôt, ou aller trouver du code plus joli ailleurs. »

Sérieusement, je trouve assez écœurant de voir tout le monde se réveiller et tomber sur OpenSSL comme si c’était de la merde et que tout le monde savait que c’était de la merde, alors que c’est de la merde que tout le monde était bien content d’utiliser sans rien faire pendant des années.

« La gratitude est la maladie des chiens. »

Donc au final si ils virent tout le merdier spécifique à Windows, tant mieux. Franchement faire tourner un serveur Web Apache de prod sur Windows c'est pas sérieux…

Il paraîtrait que OpenSSL peut aussi être utilisé par des logiciels clients, même sous Windows…

en virant tout les machins spécifiques à VMS et Windows, ils ont viré la moitié du bloat qu'il y avait

Ils ont aussi viré les algorithmes d’origine russe… Ceux-ci ont pourtant leurs RFCs et devraient avoir droit de cité au même titre que les algorithmes occidentaux.

La NSA n’arrivait pas à les casser, c’est ça ?

http://guides.ovh.net/dnssec

Ça, c’est le guide pour ceux qui gèrent eux-même leur zone DNS avec leur propre serveur (cas de Zenitram apparemment), et qui voudraient ajouter le support de DNSSEC.

Mais pour ceux dont la zone DNS est servie par les serveurs d’OVH (c’est mon cas, parce que je ne me sens pas assez confiant pour gérer le DNS moi-même, encore moins DNSSEC — comme je disais, « admin du dimanche »…), j’insiste, la seule chose à faire est de cliquer sur « Enable DNSSEC ».

espérons que l'avenir apportera plus de facilité pour les "admins du dimanche"

Parfois c’est déjà le cas. Je suis un « admin du dimanche », mais mon domaine est signé. Comment ai-je fait ? J’ai cliqué sur le bouton « Enable DNSSEC » dans l’interface de configuration de mon hébergeur…

Alors certes, DNSSEC est complexe, mais je pense que son faible déploiement s’explique aussi par un certain laxisme.

Il y en a qui pensent à DNSSEC si j'ai bien compris, mais c'est loin d'être acquis et c'est complexe)

Oui, c’est le cas notamment de DANE, DNS-based authentication of named entities. C’est ce qu’il y a de plus prometteur d’après moi et ce n’est pas, en soi, très compliqué. Côté utilisateur en particulier, c’est même encore plus simple que le système actuel des CA, puisque l’utilisateur n’a besoin de faire confiance que dans le DNS (ce qu’il fait déjà pour la résolution du nom de toute façon) et non pas dans des CA tierces dont il ignore tout.¹

Le gros problème de DANE, c’est que ce n’est fiable qu’au-dessus de DNSSEC, qui lui est en effet complexe, pas encore très déployé côté serveur (sur tous les sites que je fréquente habituellement, je n’en connais qu’un seul dont le domaine soit signé), et encore très mal supporté côté client…

---

¹ À noter toutefois que DANE peut aussi, à la discrétion de l’administrateur, s’utiliser en complément du système des CA et non pas uniquement en remplacement de celui-ci.

Je ne comprends pas comment tu peux à deux posts d’intervalle ① réclamer quelque chose d’utilisable par les « non geeks » et ② dire aux mêmes non-geeks que c’est leur problème s’ils font aveuglément confiance aux CA de leur navigateur. Qui à part un geek peut savoir ce qu’est une « CA », et a fortiori trier les bonnes CA des mauvaises CA ?

Ce post est daté du 7 avril à 11h du matin, mais s’agit-il de l’heure UTC ou de l’heure locale au siège de CloudFlare (heure du Pacifique, soit UTC-8) ?

Si c’est l’heure UTC, alors c’est 5 heures avant que les développeurs d’OpenSSL publient leur propre annonce et poussent le commit corrigeant la vulnérabilité sur leur dépôt public. Dans ce cas, c’est irresponsable.¹

Si c’est l’heure du Pacifique, c’est 19 heures UTC, soit deux heures après la publication par les développeurs d’OpenSSL.

---

¹ Et présenter ça comme un bon exemple de « responsible disclosure » est, euh, comment dire…

Tout-à-fait. Et révoquer les anciens certificats, aussi, qui pourraient sinon être ré-utilisés par les bad guys pour se faire passer pour quelqu’un d’autre.

Un reload suffit peut-être pour qu’Apache utilise la version mise à jour de la bibliothèque, mais ça ne corrigera pas le fait que les clefs privées des certificats SSL ont peut être déjà fuité…

Donc non, on ne peut pas simplement mettre à jour libssl, recharger les serveurs et se croire tranquille. Il faut aussi renouveller les certificats.

Pour Debian Stable, j'ai eu un mail annonçant la faille avec le paquet fixé le 7 avril à 21H36, ce qui me semble très honnête niveau timing.

L’annonce de la faille a été faite semble-t-il à 17h27 le 7 avril. Si c’est à ce moment-là que le mainteneur de OpenSSL pour Debian en a pris connaissance, je suis d’accord pour dire que publier le paquet corrigé à peine quelques heures plus tard est effectivement « très honnête », voire remarquable.

Mais la question est : est-ce que les développeurs Debian ont été prévenus avant la publication de la faille, ou bien l’ont-ils appris en même temps que le reste du monde ?

À voir le bugtracker de Debian, j’ai bien l’impression qu’ils ont découvert le problème le 7 avril au soir, après l’annonce par openssl.org… donc ils ne sont pas dans le cercle de ceux prévenus à l’avance dans le cadre du « responsible disclosure ».

J'utilise personnellement Rsync qui me convient.

Pas mieux.

J’ai deux machines hébergant des données à sauvegarder : un PC portable (“aurora”, ma machine principale, utilisée chez moi et au bureau) et un PC de bureau chez moi (“borealin”).

Les sauvegardes sont réalisées en plusieurs temps :

① D’abord, un script (à base de rsync) sur chaque machine fait une première copie des données à sauvegarder dans un dossier réservé sur la même machine. Ce script est exécuté automatiquement une fois par semaine sur borealin, et manuellement sur aurora — une exécution automatique à heure fixe s’est avérée peu pratique sur mon portable, parce que je ne peux jamais être certain qu’il sera allumé au bon moment. J’ai pris l’habitude de lancer le script le vendredi soir comme la dernière chose que je fais avant de partir du bureau. Au final, le risque que j’oublie de lancer le script est plus faible que le risque que j’oublie de laisser le portable allumé à la bonne heure.

Les sauvegardes ne sont pas incrémentales. J’ai fait des sauvegardes incrémentales (avec rdiff-backup) pendant quelques années, avant de me rendre compte que, si j’ai déjà eu à plusieurs reprises besoin de récupérer la dernière version sauvegardée d’un fichier, je n’ai jamais eu besoin de récupérer une version plus ancienne. Par ailleurs, tous mes fichiers importants sont déjà placés sous contrôle de version (Git), donc la dernière sauvegarde du dépôt contient déjà tout l’historique si je devais en avoir besoin. En définitive, j’ai décidé de faire l’impasse sur les sauvegardes incrémentales, qui ne sont pas justifiées dans mon cas.

② Ensuite, un second script (toujours à base de rsync) exécuté depuis aurora se charge de synchroniser les sauvegardes entre les deux machines : la sauvegarde de aurora est copiée sur borealin, et la sauvegarde de borealin est copiée sur aurora.

③ Enfin, les sauvegardes de aurora et borealin (toutes deux présentes sur aurora) sont copiées sur un disque externe que je laisse sur mon lieu de travail. Un sous-ensemble des données de aurora, contenant uniquement mes données professionnelles, est également sauvegardé une fois par semaine sur un serveur de stockage mis à disposition par mon labo (où elles sont par suite dupliquées régulièrement sur un second serveur de stockage, mais ça ce n’est pas de mon ressort).

J’ai donc à tout moment trois copies de sauvegardes (cinq pour mes données professionnelles) : une sur aurora, une sur borealin, et une sur le disque externe. Pour faire bonne mesure, sur borealin les sauvegardes sont stockées sur un volume RAID 1.

Et je me demande toujours si je suis assez paranoïaque… Quelle situation à laquelle je n’ai pas encore pensé pourrait rendre mon schéma de sauvegarde inutile ?

Il reste le problème d'une catastrophe type inondation ou incendie qui pourraient tuer les 3 disques.

Il y a 4 km entre la copie de sauvegarde stockée sur borealin et celle stockée sur le disque de mon bureau. Je pense que si une catastrophe devait menacer les deux copies simultanément, je me préocuperais davantage de ma propre intégrité physique que de l’intégrité de mes sauvegardes…

J'ai mis à jours vers la 1.0 (archlinux), j'ai toujours pas trouvé les graphiques…

Il y a une dépendance supplémentaire sur GOffice pour les graphiques, peut-être que le mainteneur ne l’a pas vue ?

Bon, sinon je dirais peut être Scribus plutôt qu'Inkscape.

Pour avoir déjà réalisé un poster avec Scribus, je confirme, ça me semble un très bon choix.

Ça me fait réaliser qu’il est loin le temps où recompiler son noyau était LE rite initiatique que tout Linuxien devait accomplir tôt ou tard, même s’il n’avait aucune intention de devenir développeur noyau…

Quelque soit le sujet tu vas forcément remettre l'écosystème Linux sur le tapis juste pour le critiquer, non ?

Lorsqu’il parle « d’une des marques les plus connues », je ne pense pas qu’il fasse référence à une marque de l’écosystème Linux…

Ben si.

Ben non, surtout quand juste avant de dire que « rien ne la justifie », l’Académie prend bien le temps de remarquer que la forme est devenue « d’usage courant ».

Peu importe que la forme soit incorrecte au départ, une faute passée dans l’usage courant n’en est plus une. Sur ce point les académiciens sont moins « vieux cons » que ceux qui voudraient que la langue française soit figée à tout jamais.

Après peut-être faudrait il que les projets fournissent une suite de tests pour que les mainteneurs puissent vérifier que rien n'a rien régressé au moment du packaging ?

Ça tombe bien, c’est que font les développeurs de OpenSSL. Le mainteneur n’a qu’à faire make test après la compilation pour vérifier que le patch qu’il a cru bon d’appliquer sur les sources n’a pas cassé trop de choses.

Dans le cas de la faille qui nous intéresse, toutefois :
– je n’ai aucune idée si Kurt Roeckx a testé son patch ainsi, ni plus généralement si cela fait partie du « workflow » Debian de systématiquement exécuter ces suites de test quand elles existent ;
– même s’il l’a fait, je ne suis pas sûr que ces tests soient capables de détecter un problème aussi subtil que celui introduit par son patch : comment teste-t-on qu’un générateur de nombres aléatoires produit bien des nombres « suffisamment » aléatoires ?