GuiGui's Show

Le système de mon serveur personnel (pas celui qui héberge ce site web) est totalement chiffré (/boot est une partition indépendante même si GRUB permet de s'en passer). Au démarrage, je saisis la phrase de passe depuis le VNC proposé par l'hébergeur.

Très récemment, j'ai changé d'hébergeur. Avant mon déménagement, son VNC a été dysfonctionnel pendant quasiment une semaine. Ça a été le déclic : comment faire si je dois redémarrer mon serveur pendant une panne ou une maintenance du VNC de mon hébergeur ? Autant une panne du VNC de mon ancien hébergeur me semblait improbable ou très limitée dans le temps au nom du « too big to fail », autant une panne longue de mon nouvel hébergeur me paraît crédible. Donc il m'appartient de concevoir un plan B. (On pourra aussi argumenter qu'une connexion SSH directe sera toujours plus sécurisée que le VNC over HTTPS de l'hébergeur par la simple disparition de l'intermédiaire.)

Il est possible de demander à l'initrd de se connecter au réseau, de proposer un accès SSH (avec l'implémentation minimaliste dropbear) et un terminal (implémentation minimaliste busybox) qui permettent d'ouvrir le conteneur LUKS. J'avais lu ça chez Aeris il y a quelques années, mais on va adapter un peu.

• Installer un serveur SSH minimaliste uniquement dans l'initramfs : apt install dropbear-initramfs ;
  
  

• Ajouter sa clé publique SSH dans /etc/dropbear-initramfs/authorized_keys. L'auth par mot de passe est impossible (cela garantit la sécurité du serveur contre la force brute en cas de redémarrage inattendu suite à un plantage ou à une maintenance côté hébergeur) ;

• Créer un fichier /etc/initramfs-tools/conf.d/ip. Format : « IP=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip> » (via) ;

  • Exemple : (je ne configure ni serveur NFS ni nom d'hôte, ni DNS, ni NTP) : IP=192.0.2.42::192.0.2.1:255.255.255.0::eth0:off ;
    
    
  • ATTENTION : contrairement à ce que dit la doc', « IP= » est en majuscule et sensible à la casse (au moins sur Debian GNU/Linux Bullseye) ;
    
    
  • IPv6 statique n'est pas disponible sans ajouter des scripts persos. Vu la criticité de l'initrd, ça ne me tente pas. Des messages ICMPv6 « Router Solicitation » sont émis par l'initrd, ce qui laisse à penser qu'IPv6 dynamique est disponible. Mais, chez tout hébergeur sérieux, le niveau 2 (ARP, NDP, DHCP, STP, etc.) est filtré ou rendu caduque, donc ça n'a pas d'intérêt.

• Reconstruire les initrd : update-initramfs -uk all ;

• On fabrique un enregistrement DNS de type SSHFP ou une entrée pour le fichier known_hosts (cela permettra d'authentifier la machine, d'être sûr qu'on causera au bon serveur SSH qui aura booté sur l'initrd). Dans les deux cas, ça nécessite de convertir la clé privée du serveur depuis le format dropbear vers une clé publique au format openssh (attention : depuis OpenSSH 8.7, il ne peut y avoir qu'un seul enregistrement SSHFP par nom, donc une seule paire de clés pour l'initrd et le système…) :

  • known_hosts : ssh-keygen -y -f /dev/stdin <<< $(dropbearconvert dropbear openssh /etc/dropbear-initramfs/dropbear_rsa_host_key -). Ajouter la sortie au fichier known_hosts de la machine qui accédera au serveur ;
    
    
  • Enregistrement SSHFP : ssh-keygen -r <FQDN> -f /dev/stdin <<<$(ssh-keygen -y -f /dev/stdin 2>/dev/null <<<$(dropbearconvert dropbear openssh /etc/dropbear-initramfs/dropbear_rsa_host_key -)).
• reboot le serveur ;
  
  
• dropbear n'implémente pas toute la crypto moderne, donc, si comme moi tu blindes ta conf' client SSH, il faudra réduire tes prétentions. Cela peut se faire avec une entrée dédiée dans .ssh/config ;
  
  

• ssh root@<serveur> doit fonctionner ;

• Comme nous le dit le prompt, il suffit d'utiliser la commande cryptroot-unlock. Après la saisie de la phrase de passe, le système démarrera :

  ~ # cryptroot-unlock
  Please unlock disk sda2_crypt: 
  cryptsetup: sda2_crypt set up successfully
  ~ # Connection to 192.0.2.42 closed by remote host.
  Connection to 192.0.2.42 closed.

Visualiser / lister les prochains roulements (renouvellements) de clés DNSSEC planifiés par OpenDNSSEC : ods-enforcer rollover list.

Forcer le renouvellement / roulement / rollover des clés (en cas de compromission, par ex.) : ods-enforcer key rollover --zone <nom_zone>. On peut limiter à un type de clé (KSK ou ZSK) en ajoutant --keytype <KSK|ZSK>.

systemd-journald est conçu pour archiver puis supprimer les vieux journaux (logs) selon une politique d'occupation de l'espace de stockage. Détails ici.

Parfois, on a besoin de conserver un journal un certain temps, ni plus, ni moins. Exemple ? L'obligation de conservation des données de connexion qui, en France, pèse sur les opérateurs de communications et les hébergeurs. Elles doivent être conservées 1 an. En dessous, l'opérateur / l'hébergeur ne remplit pas son obligation. Au-delà, le traitement est illégal au regard du RGPD car dénué de base légale (l'obligation légale court pour 1 an, pas plus).

Exemple moins pertinent : avec un volumineux système de stockage, on se retrouve avec 4 Go de journaux qui peuvent donc remonter loin et être pénibles à exploiter. Mais dans ce cas, on préférera affiner la valeur des paramètres de journald.

Pour une politique temporelle de conservation, journald propose le paramètre MaxRetentionSec. Source. Délai après lequel un journal contenant des entrées plus vieilles que ce délai sera supprimé. Par défaut, sa valeur est 0 afin de mettre en œuvre uniquement une politique de conservation basée sur l'occupation disque.

Il faut également configurer MaxFileSec. Un journal ne peut pas stocker des entrées au-delà de cette durée (1 mois par défaut). Un nouveau journal sera créé (et, l'ancien, archivé, donc supprimable). Il faut la positionner à « 1day ». Ainsi, lors de la suppression d'un journal archivé, après 1 an, seules les entrées d'il y a 366 jours seront supprimées. De même, seules les entrées du jour seront dans le journal courant, le reste sera archivé. Sans ce paramètre, soit journald supprimera le 12^e mois (improbable), soit il conservera 1 an et 1 mois. Dans les deux cas, ça ne répond pas au besoin.

(Cette réflexion est basée sur le fait, qu'à priori, journald efface un journal en entier, pas les entrées d'un journal qui ont dépassé la date de péremption. Sa doc' consigne, pour le paramètre MaxFileSec : « However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. ». Et le manuel de journalctl, pour l'action rotate, consigne : « Journal file rotation has the effect that all currently active journal files are marked as archived and renamed, so that they are never written to in future ».)

Conséquence logique : il faudra également modifier la valeur de SystemMaxFiles, car il y aura jusqu'à 1 an de journaux archivés chaque jour. Et il faudra désactiver la politique de conservation fondée sur l'occupation de l'espace de stockage (cf) sinon journald pourra supprimer des journaux récents si l'espace de stockage vient à manquer.

On peut aussi désactiver totalement ou partiellement journald (Storage). Il continuera à transmettre les journaux à rsyslog (par défaut sous Debian), et on pourra les traiter à l'ancienne avec logrotate.

Firefox me gonfle à bloquer des téléchargements avec le motif « Fichier non téléchargé : risque de sécurité potentiel ».

about:config, dom.block_download_insecure => false.

C'est censé gueuler lors d'un téléchargement en HTTP (sans TLS), mais ça semble aussi dépendre de la source : un .deb depuis les serveurs de Debian, ça couine ; le même .deb depuis mon serveur perso, toujours en HTTP, ça passe.

Ça ne fait que le énième paramètre Firefox à changer…

Il est possible de demander la communication d'un certain nombre de documents détenus par une administration française. Si cette dernière s'y oppose (explicitement ou implicitement après un mois sans réponse), il est possible de saisir, dans les deux mois, une autorité administrative indépendante, la CADA, d'une demande d'avis (qui est un pré-requis pour contester le refus de l'administration au contentieux). Lire toutes les notes concernant cette procédure.

La CADA contacte alors l'administration visée afin qu'elle produise des observations (pourquoi a-t-elle refusé ?). Ces observations destinées à la CADA sont des documents administratifs… communicables (sous réserve des habituelles réserves ‒ vie privée, secrets des affaires, fiscal, défense, etc. ‒). Pré-requis : la CADA doit avoir rendu son avis (sinon, documents relatifs à une décision en cours d'élaboration, donc pas communicables). C'est le journaliste Marc Rees qui me l'avait appris (je ne trouve plus le tweet ou l'article NextInpact original, mais il y a ce tweet plus récent).

Il y a deux parties qui échangent (CADA et administration). À qui demander ? Est-il seulement possible d'adresser une demande de communication de docs à la CADA ? Oui ! Il est même possible de saisir la CADA contre un refus de communication de la CADA. :D Pour m'en assurer, j'ai cherché (et trouvé) des avis dans la base des avis de la CADA.

La CADA a répondu à ma demande de communication en me transmettant les observations produites par l'administration.

À titre d'inspiration, voici ma demande adressée à la CADA par email :

Sujet : Demande de communication de documents détenus par la CADA

Bonjour,

Je demande à la CADA de me communiquer une copie des documents suivants :

• Tous les échanges (email, courrier, etc.), toute la correspondance bidirectionnelle, entre la CADA et <CENSURE> intervenus dans le cadre de ma demande d'avis numéro <CENSURE> adressée à la CADA le <CENSURE> via son formulaire de saisine en ligne (avis rendu le <CENSURE> qui m'a été transmis le <CENSURE>). Pour les éventuels courriers postaux envoyés par la CADA, vous y joindrez toute preuve de dépôt La Poste (affranchissement, suivi LRAR, tampon La Poste, etc.) ;

L'existence de ces échanges est attestée dans le corps de l'avis rendu par la CADA, cf. PJ 1 (« en réponse à la demande qui lui a été adressée », « ce que fait valoir le président de <CENSURE> », « le président de <CENSURE> […] lui a indiqué », etc.).

Conformément à l’article L311-9, 3° du CRPA, je vous demande de m’adresser ces documents par courrier électronique à l’adresse <CENSURE>.

Cordialement.

Liste non exhaustive triée par préférence.

kdig

Ma préférence va à kdig, le dig de l'implémentation DNS Knot, car il donne des informations techniques sur la négociation TLS et le dialogue HTTP (status, etc.). Paquet knot-dnsutils dans Debian GNU/Linux.

DoT avec vérification du certificat x509 : kdig @ns1.fdn.fr +tls +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

DoH avec vérif' du cert' x509 : kdig @ns1.fdn.fr +https +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

dig

À partir de sa version empaquetée dans la version 12 (bookworm) de Debian GNU/Linux (paquet bind9-dnsutils), dig, l'outil de l'implémentation DNS BIND prend en charge DoT et DoH, mais il file aucune info sur la session TLS et les messages HTTP.

DoT avec vérif du cert' x509 : dig @ns1.fdn.fr +tls +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

DoH avec vérif : dig @ns1.fdn.fr +https +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

homer / remoh

Développé en python par Bortz. Dépôt git. Tutoriel. Il n'est plus maintenu (source : échange privé avec Bortz).

La sortie est brute de décoffrage. Outil plus pour s'amuser qu'autre chose et qui ne file aucune info sur la session TLS et les messages HTTPS. Vérif' du cert' x509 effectuée de base.

DoT avec vérif' : ./remoh.py -t ns1.fdn.fr shaarli.guiguishow.info AAAA.

DoH avec vérif' : ./remoh.py https://ns1.fdn.fr/dns-query shaarli.guiguishow.info AAAA.

Je note les options --check et --mandatory-level qui testent la conformité d'un serveur DoT / DoH avec les RFC, les bonnes pratiques, etc.

dog

Dépôt git.

La sortie est minimaliste : pas d'info, ni sur TLS, ni sur HTTPS ni sur le DNS lui-même. Codé en Rust, donc cargo télécharge la moitié de l'Internet (317 Mo pour un binaire de 14 Mo). En revanche, a priori, la vérification du cert' x509 est effectuée de base, sans option supplémentaire, en se reposant sur OpenSSL.

DoT avec vérif' : ./dog -S @ns1.fdn.fr shaarli.guiguishow.info AAAA

DoH avec vérif' : /dog -H @https://ns1.fdn.fr/dns-query shaarli.guiguishow.info AAAA

openssl / gnutls

Évidemment, toute la partie TLS peut être testée avec openssl et gnutls.

openssl s_client -connect ns1.fdn.fr:853

gnutls-cli ns1.fdn.fr:853.

Si Unbound refuse de résoudre des noms (même s'il est configuré pour transférer toutes les requêtes à un autre serveur DNS récursif) en consignant « error: failed to read /var/lib/unbound/root.key » dans syslog, il suffit de lancer sudo unbound-anchor -vv. :-

Le sujet est l'effet de contagion de la GPL, pas de faire ce qu'on « veut avec du code source libre pour le rendre propriétaire ». On parle donc d'un sous-ensemble, d'un cas minoritaire.

Payer ne résout pas le problème en cela que ça ne lève pas la contrainte posée par la GPL. Payer n'est utile dans le cas qui nous intéresse que si le code d'origine est sous une double licence privatrice, donc qu'on est sortis de la GPL et de sa contagion, donc du sujet. Mon « tu es essentiellement hors-sujet » vient de là.

De plus, si l'on prend la définition de « libre » du HV (en tout cas ce que j'en comprends de ses articles sur la GPL), la GPL a bien posé une restriction à la liberté de réutilisation du logiciel libre (qui est l'une de ses caractéristiques) puisque, dans un cas de contagion, le ré-utilisateur est marron si le code original n'est pas sous une double licence (ce qui est le cas majoritaire, peu de logiciels libres sont diffusés sous une double licence).

Jusque-là, comme lors de ma dernière intervention, je ne prends pas position, j'expose ce que j'ai compris des termes du débat.

Je suis dubitatif sur l'aspect moral de payer pour s'affranchir d'une contrainte au motif que ça contribuera indirectement au logiciel. Ça me rappelle toutes les compensations bidonnes (carbone, volet civil d'une affaire pénale, pour la perte accidentelle d'un proche, épargne salariale / partage de la valeur, etc.). L'argent résout-il tous les problèmes ? Sans compter que rien ne dit que les contributions payantes seront intégrées à la version communautaire (mais on espère que les devs pourront coder d'autres fonctionnalités avec l'argent reçu, youpi). Et que dire de payer pour pouvoir diffuser son travail dérivé.

As we’ll consider below, it might be impossible to use reCAPTCHA legally under EU law, but no data protection authority has said this.

Si, si, des APD ont clairement estimé que reCAPTCHA n'est pas conforme au RGPD, notamment dans des mises en demeure. Idem pour hCAPTCHA (arrêt CJUE Schrems II, raisonnement ici).

L'auteur connaît au moins l'une des mises en demeure de la CNIL sur le sujet, donc j'imagine qu'il voudrait qu'une APD dise que reCAPTCHA est illégal en tout temps et en tout lieu. Or, au moins en droit français, une autorité administrative ne peut pas prescrire des interdictions d'ordre général, mais elle doit examiner la conformité au cas par cas. C'est au responsable de traitement (et à son DPO) de décliner des lignes directrices ou une décision de justice ou celle d'une autorité administrative pour vérifier si ses traitements de données personnelles sont conformes au RGPD à travers le temps (il y a un travail de suivi).

Après tout, tu peux légalement faire télécharger aux visiteurs de ton site web une police de caractères depuis les serveurs de Google Fonts si tu installes un reverse proxy bien configuré au milieu (ceci dit, tu iras plus vite en hébergeant ladite police en local, avec les autres fichiers de ton site web). Tu peux légalement utiliser Google Analytics sous la même condition technique (mais tes stats vont perdre tout intérêt). Tu peux légalement stocker les données chiffrées de tes clients sur du stockage à froid ricain type mamazone S3. Etc. L'enjeu, c'est les conditions de mise en œuvre.

Par simplification, on fait parfois des raccourcis comme d'affirmer que Google Analytics est illégal, car les moyens de l'utiliser légalement détruisent complètement son intérêt, donc on sait d'avance qu'environ personne s'y aventurera, donc on peut directement affirmer que son utilisation est illégale. Mais il n'est pas toujours possible d'exclure tous les cas d'utilisation d'un produit / service.

Exemple. À l'heure actuelle, les conditions d'utilisation de reCAPTCHA précisent qu'il collecte beaucoup plus de données techniques identifiantes que ce qui est nécessaire pour la sécurisation d'un formulaire web. Donc son utilisation doit reposer sur le consentement du visiteur. Or, le RGPD dispose que le refus de consentir ne doit pas entraîner de préjudice. Donc il faudrait autoriser l'envoi du formulaire web protégé à tout visiteur qui refuserait de consentir… dont les robots. Ou basculer sur une deuxième procédure de vérification. Dans les deux cas, l'intérêt d'utiliser reCAPTCHA tombe. Tant que Google ne changera pas le fonctionnement interne de reCAPTCHA, ce raisonnement demeurera intact. Et ça, c'est pour un seul grief, il reste le deuxième, le fait que des données personnelles (ne serait-ce que l'adresse IP pour télécharger le CAPTCHA) sont envoyées à une société commerciale ricaine sans garanties suffisantes (arrêt Schrems II de la CJUE, toujours). Vu les données techniques récoltées par reCAPTCHA pour son fonctionnement, il n'est pas certain qu'intercaler un reverse proxy qui supprime les données persos permette son fonctionnement. Donc il n'est pas faux d'affirmer que reCAPTCHA n'est pas conforme au RGPD. Et encore moins qu'il vaut mieux dépenser de l'énergie à s'en passer plutôt que d'essayer de le tordre, ainsi que le RGPD, dans l'espoir que ça fasse le boulot.

Bug toujours présent dans la version 102.12 de Thunderbird packagée dans Debian 11. Pour SMTP, mais aussi pour IMAP.

Sérieusement… :(