Proton Mail, le service de messagerie chiffré qui vend de la confidentialité à tout prix, a transmis des données de paiement aux autorités suisses. Ces données ont ensuite atterri entre les mains du FBI, qui a pu identifier la personne derrière un compte mail anonyme lié au mouvement Stop Cop City à Atlanta.

Une carte bancaire et c'est plié

Le FBI enquêtait sur Defend the Atlanta Forest, un groupe affilié au mouvement Stop Cop City qui s'opposait à la construction d'un centre d'entraînement de police dans un parc d'Atlanta. Pour identifier qui se cachait derrière une adresse Proton Mail utilisée par le groupe, les Américains sont passés par un traité d'entraide judiciaire avec la Suisse (le MLAT).

Le 25 janvier 2024, les autorités suisses ont donc renvoyé au FBI le nom complet de la personne qui avait payé l'abonnement Proton avec sa carte bancaire. Les mails restent chiffrés, personne n'a lu quoi que ce soit, mais le simple fait d'avoir utilisé une carte de crédit a suffi à lever l'anonymat.

Déjà vu en 2021

Proton avait déjà fait parler en 2021, quand l'entreprise avait fourni l'adresse IP d'un militant écologiste français du collectif Youth for Climate, sur ordre d'un tribunal suisse. L'information avait transité par Europol et avait conduit à des arrestations en France.

Proton avait ensuite discrètement retiré de son site la mention "nous n'enregistrons pas votre adresse IP". Côté communication, le discours est rodé : Edward Shone, responsable de la comm chez Proton, assure que l'entreprise n'a rien transmis directement au FBI et ne fournit que "les informations limitées dont elle dispose" quand la justice suisse l'exige.

Ce que Proton sait de vous

Le chiffrement de bout en bout, ça fonctionne. Proton ne peut pas lire vos mails, et personne ne remet ça en question. Mais l'entreprise conserve les données de facturation, et si vous avez payé par carte bancaire, votre nom et vos coordonnées sont dans leurs fichiers.

Proton propose des moyens de paiement anonymes (cryptomonnaies, espèces par courrier), mais dans les faits, peu d'utilisateurs y pensent. La personne identifiée dans cette affaire n'a d'ailleurs jamais été inculpée, mais son identité est entre les mains du FBI.

Il faut vraiment garder en tête que le chiffrement protège le contenu de vos messages, pas votre identité. Proton a beau vendre de la confidentialité, l'entreprise reste soumise au droit suisse comme toutes les autres. Payer un service "confidentiel" avec sa carte Visa et espérer rester anonyme, autant mettre un cadenas sur une porte vitrée...

Sources : 404Media , YCombinator

Le chiffrement complet du disque, tout le monde vous dit que c'est la base. LUKS sous Linux, BitLocker sous Windows, FileVault sous macOS... sauf que personne vous dit quoi faire quand votre serveur reboot à 3h du mat et qu'il attend sagement sa passphrase.

Là, vous êtes coincé !!!!

Parce que oui, le truc vicieux avec le chiffrement intégral, c'est qu'au démarrage, le système ne peut pas lire le disque tant que vous n'avez pas tapé le mot de passe. Du coup, si votre machine est dans un datacenter ou chez un hébergeur, ben... faut se déplacer physiquement. Et ça c'est bien relou !!!

La solution, c'est d'embarquer un serveur SSH directement dans l' initramfs (oui, le mini OS qui tourne AVANT votre vrai système, sur le port 22). En gros, votre machine boot, charge l'initramfs, lance un serveur SSH... et vous n'avez plus qu'à vous connecter à distance pour taper la passphrase. Comme ça le disque se déverrouille et le boot continue. Voilà quoi, c'est simple la vie quand on lit Korben.info !! loool

L'initramfs, c'est quoi exactement ?

Alors pour ceux qui débarquent, l'initramfs c'est une archive compressée dans /boot/initramfs-linux.img qui contient un système Linux minimal. Son boulot, c'est de préparer le terrain avant de passer la main au vrai OS, genre charger les modules noyau, détecter le matériel, monter les systèmes de fichiers... et dans notre cas, demander la passphrase LUKS. Genre un second OS, mais en version bonsaï !

Installer Dropbear dans l'initramfs

Dropbear , c'est un serveur SSH ultra-léger (environ 110 Ko) parfait pour l'initramfs. L'article de jyn qui m'a inspiré pour cet article , recommande Arch Linux avec mkinitcpio, mais sachez que sous Debian/Ubuntu le paquet dropbear-initramfs fait le même boulot avec update-initramfs.

Sur Arch, vous installez mkinitcpio-systemd-extras puis vous modifiez /etc/mkinitcpio.conf pour ajouter les hooks réseau et Dropbear :

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck systemd-network dropbear)

Attention, l'ordre des hooks compte. Le réseau doit être configuré AVANT Dropbear, sinon votre serveur SSH démarre sans interface réseau. Pas super utile donc !

Configurer le réseau dans l'initramfs

Ensuite faut créer un fichier de config réseau dans /etc/systemd/network-initramfs/. En fait, c'est du systemd-networkd classique, donc si vous avez déjà configuré ça, c'est pareil. Un simple fichier .network avec DHCP fait le job en Ethernet (et pour un serveur, c'est clairement recommandé). Pour les plus paranos, une IP statique marche aussi, sauf que faudra pas oublier de la mettre à jour si vous changez de réseau.

La touche Tailscale

Après si votre serveur est derrière un NAT ou un firewall, bah... le SSH classique ne passe pas. Du coup, jyn a eu la bonne l'idée d'embarquer Tailscale dans l'initramfs aussi. Comme ça, la machine rejoint votre réseau privé Tailscale dès le boot, même avant le déchiffrement du disque.

Vous lancez setup-initcpio-tailscale, ça vous donne un lien d'authentification sur login.tailscale.com et c'est réglé. Après faut penser à configurer les ACL Tailscale pour que SEULE votre machine d'admin puisse se connecter à l'initramfs car OUI ON NE LAISSE PAS UN PUTAIN DE SSH ouvert sur un système pré-boot sans protection, HEIN ?? HEIN ?? Donc faites ça !!

Les précautions de sécurité

Vous vous en doutez, y'a quand même quelques pièges à éviter. D'abord, les clés SSH de Dropbear dans l'initramfs (stockées dans /etc/dropbear/) doivent être DIFFÉRENTES de celles d'OpenSSH dans /etc/ssh/. Parce que l'initramfs n'est pas chiffré (bah oui, il doit tourner avant le déchiffrement), donc ces clés sont techniquement accessibles à quelqu'un qui a un accès physique au disque.

Ensuite, attention, limitez ce que Dropbear peut faire. Pas de shell complet, juste la commande systemd-tty-ask-password-agent qui sert uniquement à taper la passphrase. Comme ça, même si quelqu'un arrive à se connecter, il ne peut rien faire d'autre.

Et désactivez aussi l'expiration des clés Tailscale pour la machine initramfs via --auth-key avec un token non-éphémère, sinon votre serveur va se retrouver éjecté du réseau au pire moment.

Reconstruire et tester

Une fois tout configuré, un petit mkinitcpio -P pour reconstruire l'initramfs et c'est bon. Si ça ne marche pas du premier coup, vérifiez les logs avec journalctl -b. Mais attention, testez ça sur une VM ou une machine avec accès console (IPMI, iDRAC, KVM-over-IP) d'abord, parce que si le réseau de l'initramfs ne monte pas, votre serveur devient une brique inaccessible... et là, c'est le vrai drame de votre vie qui commence (et la découverte de France Travail) !

Au prochain reboot, votre serveur va donc démarrer, charger l'initramfs, se connecter à Tailscale, lancer Dropbear... et attendre patiemment que vous tapiez la passphrase depuis votre canapé.

Si vous gérez des serveurs chiffrés à distance, c'est le genre de setup un peu touchy à la base mais qui change la vie. Comme ça, plus besoin de supplier / soudoyer / menacer (chacun sa technique) le technicien du datacenter d'astreinte de brancher un clavier ^^.

Découvrir le tuto complet de Jyn ici !