Ça y’est, nous en savons plus sur les moyens de sécurisation HADOPI, après la diffusion (par Numerama) de leurs spécifications fonctionnelles (publiques mais secrètes), établies par M. Riguidel (soupçonné de conflits d’intérêts).

Sémantique

Ce document nous confirme que le logiciel de sécurisation est en fait un mouchard, un logiciel de surveillance et de contrôle des utilisateurs.

En effet, la sécurité permet de se prémunir d’attaques extérieures et d’espionnage. Au contraire, les spécifications présentées définissent un logiciel espion qui journalise les faits et gestes (du moins ceux qui l’intéressent) des internautes. Dans l’esprit des architectes de la loi, la surveillance des utilisateurs est un moyen de sécurisation de la forme actuelle de la propriété intellectuelle, de la même manière que la censure est un moyen de sécurisation de l’opinion publique. Mais il ne s’agit absolument pas de sécurisation informatique.

Il est d’ailleurs amusant d’avoir précisé que logiciel devait espionner mais sans trop se faire remarquer (page 13) :

les moyens ne sont pas reconnus comme un « malware » par les antivirus du marché

Principe de fonctionnement

Le principe de ce mouchard est d’enregistrer les actions de l’utilisateur dans deux fichiers (une version en clair et une version « sécurisée »). La version « sécurisée » doit être conservée un an, et servira au besoin à prouver que l’utilisateur a ou n’a pas fait telle ou telle action. C’est exactement comme proposer à la population l’installation d’une caméra de surveillance sur la tête qui conserverait les enregistrements pendant un an, dans le but de prouver son innocence lors d’une éventuelle accusation.

Ces spécifications sont inquiétantes par leur logique de surveillance et de contrôle. Les objectifs sont assez clairs. De plus en plus de politiques prenant conscience des enjeux de la neutralité du net (le Chili a même voté une loi pour la garantir), il paraît difficile d’imposer un filtrage (par ailleurs inefficace) pour combattre le partage de fichiers (quoique l’idée pourrait encore resurgir). Il serait également délirant d’imposer à chacun l’installation d’un tel mouchard sur toutes ses machines (même la Chine a reculé). La solution est donc de créer une insécurité juridique avec des accusations aléatoires (sans aucune preuve) et de proposer un outil de surveillance qui permettra de prouver sa bonne foi. S’ils ne peuvent pas prouver leur innocence, les utilisateurs risquent une amende de 1500€ et/ou une coupure d’accès Internet pendant un mois pour délit de négligence caractérisée. Une subtile manipulation de la présomption d’innocence.

L’arnaque technique

Attention, on rentre dans la technique, c’est là que ça devient rigolo.

Un journal… sécurisé

Je disais que le logiciel devait journaliser les actions des utilisateurs dans deux fichiers, une version en clair et une version « sécurisée ». C’est la partie cruciale du fonctionnement du logiciel de sécurisation. Tout est détaillé pages 28 et 32 :

Il existe deux sortes de journaux qui sont produits en temps réel dans deux bases de données distinctes :

Un journal en clair que les utilisateurs et l’administrateur peuvent consulter.

Un journal sécurisé. Ce journal est confidentiel, authentique et infalsifiable. Toute tentative de falsification éventuelle est détectable. Pour des raisons de sécurité, cette seconde version du journal est en mode binaire, compressée, signée électroniquement, chiffrée, et archivée pendant une période d’au moins une année. Ce journal sera accessible en clair à la demande du titulaire de l’abonnement. Il permettra de vérifier, après déchiffrement avec la clé privée correspondant au logiciel, laquelle est détenue par le tiers de confiance, la mise en œuvre du logiciel de sécurisation à une date et heure donnée, et l’activité informatique de l’internaute concerné. Ce journal permet de refléter, sans interférence possible du titulaire de l’abonnement, les événements de l’accès Internet considéré.

Le chiffrement des journaux s’opère avec de la cryptographie asymétrique, en utilisant la clé publique fournie, avec le logiciel, par un tiers de confiance.

On a donc un journal en clair, et une copie en binaire-compressé-signé-chiffré-archivé-infalsifiable-incopiable. Comment est chiffrée cette copie? Par une clé publique (fournie avec le logiciel). Comment est signée cette copie? Ce n’est pas dit, mais c’est forcément par une clé (privée), fournie elle-aussi avec le logiciel.

Le poste de l’utilisateur possède donc la clé de chiffrement et la clé de signature, mais attention, abracadabra, il ne doit pas pouvoir créer un « faux » journal chiffré et signé ! Et s’il tente de créer un faux journal, le logiciel doit le détecter !

Un logiciel impossible

Le but du journal « sécurisé » est évidemment de s’assurer qu’il a bien été généré par le mouchard et qu’il n’a pas été modifié. On se demande alors l’intérêt de le chiffrer par une clé publique (vu que de toute façon le journal est accessible en clair). Ce qu’il faut, c’est le signer. Et pour signer, il faut une clé privée. Et une clé privée, on ne peut pas l’intégrer au logiciel, car alors elle serait rendue publique, et n’importe qui pourrait signer n’importe quoi. La clé privée du « tiers de confiance » ne peut donc pas être diffusée pour signer les journaux.

Envoyer les journaux chez le « tiers de confiance » (ce qui est clairement exclu de toute façon) ne fonctionnerait pas mieux, car rien n’empêcherait l’utilisateur d’envoyer de faux journaux.

Il n’est donc pas possible de réaliser un tel logiciel.

Mesdames et messieurs de l’Hadopi, si une société vous propose un logiciel qui répond aux spécifications, méfiez-vous, il n’y répond pas. Mesdames et messieurs les commerciaux des sociétés informatiques, réfléchissez bien avant d’accepter un tel contrat, vos équipes projets ne pourront pas le réaliser.

La cryptographie asymétrique

Pourtant, la cryptographie, ça fonctionne bien et c’est accessible à tous très simplement. Pourquoi donc un tel logiciel ne peut pas fonctionner ?

La cryptographie asymétrique, ça permet à A d’écrire un message à B de telle manière que B soit sûr que le message provienne de A et que A soit sûr que seul B puisse le lire. A et B se font confiance.

Ici, par définition, le tiers de confiance vis-à-vis de l’Hadopi (B) ne fait pas confiance à l’internaute (A). Donc B veut écrire et signer le message (ici le journal) qui se trouve chez A. Pour cela, une partie de B (le mouchard) doit se trouver chez A : cette partie peut donc être contrôlée par A. On en déduit que A peut signer les messages qu’il veut en se faisant passer pour B.

Il n’y a d’ailleurs rien d’étonnant à ce qu’un outil de sécurité et de protection ne réponde pas au besoin d’un logiciel de surveillance et de contrôle.

Cachez le code

Logiciels propriétaires

Il reste une petite subtilité à détailler. J’ai dit que si la clé privée était intégrée au logiciel, alors elle était publique (accessible à tous), et que si le mouchard se trouvait chez un internaute, il pouvait être contrôlé par l’internaute.

En fait, certains logiciels ne permettent pas aux utilisateurs d’en étudier directement le fonctionnement, et donc a fortiori d’en modifier le comportement : ce sont les logiciels dits propriétaires ou privateurs (du moins ceux dont les sources ne sont pas fournies). Ces logiciels sont par définition une privation d’une partie du contrôle de sa propre machine : l’utilisateur doit faire confiance aveuglément aux actions du logiciel. C’est l’idéal pour un programme de surveillance.

Mais il ne s’agit en rien d’une sécurité, la clé se trouve quand même dans le programme, et sera un moment ou à un autre utilisée (pour signer le journal). Ne pas fournir les sources du programme ne fera que rendre la tâche un petit peu plus difficile (il faudra sans doute lire de l’assembleur), mais je n’ai aucun doute sur le fait que 48 heures après le programme diffusé, un outil permettant d’en extraire la clé sera disponible.

Bien loin d’une protection rendant le journal infalsifiable comme exigée.

Logiciels libres

Les rédacteurs du document ont bien compris que le logiciel libre ne devait pas être écarté du champ du mouchard, et qu’il fallait que l’expression « logiciel libre » apparaisse dans les spécifications (page 6) :

Les moyens peuvent être réalisés à partir de logiciels libres et/ou fonctionner sur des systèmes d’exploitation libres.

Ils peuvent être réalisés « à partir » ou « fonctionner sur » des logiciels libres. Mais fondamentalement, un mouchard ne peut pas être libre. Le logiciel libre permet à l’utilisateur d’avoir le contrôle de sa machine ; le mouchard lui propose de perdre une partie de ce contrôle pour être surveillé. C’est forcément incompatible.

Concrètement, c’est très simple à comprendre : il suffit de modifier les sources du logiciel qui écrit le journal « sécurisé » pour qu’il n’écrive que ce que l’on décide.

Droit de contrôle de son ordinateur

On observe de nombreuses tentatives de s’emparer du contrôle d’au moins une partie des ordinateurs de la population. C’est le cas avec des systèmes de suppression d’applications ou de contenu à distance sans le consentement de l’utilisateur (je pense notamment à Apple et Google pour leur systèmes mobiles). C’est le cas maintenant avec des mouchards que la loi recommande.

Je pense qu’il serait intéressant de faire du « droit de contrôle de son ordinateur » (ou appelez ça comme vous voulez) un enjeu au même titre que la neutralité du net : si le filtrage est interdit au niveau du réseau, il va être chez l’utilisateur. Dans ce cas, la seule forme acceptable est qu’il soit sous son contrôle, et non sous le contrôle d’une entreprise privée ou d’une quelconque autre entité.

D’ailleurs, le document de spécifications du logiciel HADOPI laisse penser que l’installation d’applications dans les boitiers ADSL hors du contrôle de l’utilisateur est prévu (page 9) :

Pour le moment le parc des boitiers ADSL est très hétérogène, et les boitiers sont dimensionnés de telle manière qu’il est difficile de loger des applications supplémentaires dans ces boitiers. Pourtant, on peut réfléchir à ces solutions pour les futures générations de boitiers, dans le cadre du renouvellement général du parc.

Le 5 juillet (hier donc), France Télévisions a lancé son service de télévision de rattrapage, qui ne permet pas de lire les vidéos. À moins d’accepter d’installer un système d’exploitation particulier avec un logiciel particulier (propriétaires évidemment). C’est comme s’ils diffusaient leurs émissions uniquement pour les utilisateurs équipés d’une TV Sony ou Philips, et pas pour les autres… France Télévisions a simplement oublié que c’était un avant tout un service public.

Formats

La lecture des vidéos nécessite soit Windows Media Player, soit Silverlight. C’est dommage, il aurait été préférable que leur site soit du web, accessible à tous.

En plus de cela, les vidéos sont diffusées dans le format fermé WMV. Certaines contiennent même des DRM. Les DRM, pour rappel, c’est ce qui empêche les utilisateurs de lire le contenu proposé. Certains prétendent que ça permet d’empêcher la copie ; ce n’est pas totalement faux : quand on ne peut pas lire le contenu on ne peut pas le copier. Une autre technique plus efficace serait de ne pas le publier du tout.

En numérique, tout ce qui est lisible est copiable. Par contraposée, tout ce qui n’est pas copiable n’est pas lisible.

Outil d’accès

Comme France Télévisions n’a pas fait son boulot d’interopérabilité, et qu’a priori chacun a droit d’accéder à ce service (public!), nous sommes obligés de nous débrouiller par nous-mêmes.

J’ai donc écrit un petit script bash qui permet d’accéder relativement simplement à Pluzz à partir d’un système libre (où VLC doit être installé, testé sur Ubuntu 10.04). Pour l’utiliser, rendez-vous sur Pluzz.fr, cliquez sur l’émission de votre choix, et copier l’adresse de la page (par exemple http://www.pluzz.fr/jt-20h.html).

Ensuite, pour lire la vidéo, tapez :

pluzz play http://www.pluzz.fr/jt-20h.html

Pour l’enregistrer (bah oui, tout ce qui est lisible est enregistrable) :

pluzz record http://www.pluzz.fr/jt-20h.html

Si vous voulez simplement l’url du flux :

pluzz url http://www.pluzz.fr/jt-20h.html

Ceci ne fonctionnera que pour les vidéos sans DRM : les vidéos avec DRM ne sont pas lisibles.

Script

EDIT 11/07/2010 :
J’ai mis à jour le script avec une version 0.2, qui gère également les flux en mp4 (flvstreamer doit être installé).
L’historique des scripts est disponible ici (au cas où une régression poserait problème).

Voici le script (sous licence wtfpl), à sauvegarder en tant que fichier exécutable /usr/local/bin/pluzz (uniquement si vous comprenez ce que vous faites) :

#!/bin/bash
# Script pour utiliser pluzz.fr
# v0.2 (11 juillet 2010)

if [ $# != 2 ]
then
    printf "Syntaxe: $0 [url|play|record] http://www.pluzz.fr/...\n" >&2
    exit 1
fi
command="$1"
url="$2"

if [ "$command" != 'url' -a "$command" != 'play' -a "$command" != 'record' ]
then
    printf "Command must be 'url', 'play' or 'record', not '$command'\n" >&2
    exit 2
fi

video_page_url=$(wget -qO- "$url" | grep -o 'http://info.francetelevisions.fr/?id-video=[^"]\+')
stream_url_part2=$(wget -qO- "$video_page_url" | grep urls-url-video | sed 's/.*content="\(.*\)".*/\1/')
ext=${stream_url_part2##*.}

if [ "$ext" = 'wmv' ]
then
    stream_url_part1='mms://a988.v101995.c10199.e.vm.akamaistream.net/7/988/10199/3f97c7e6/ftvigrp.download.akamai.com/10199/cappuccino/production/publication'
elif [ "$ext" = 'mp4' ]
then
    stream_url_part1='rtmp://videozones-rtmp.francetv.fr/ondemand/mp4:cappuccino/publication'
else
    printf "Extension not managed : '$ext'\n" >&2
    exit 3
fi

stream_url="$stream_url_part1/$stream_url_part2"

if [ "$command" = "url" ]
then
    printf "$stream_url\n"
elif [ "$command" = "play" ]
then
    if [ "$ext" = 'wmv' ]
    then
        vlc "$stream_url"
    else
        flvstreamer -r "$stream_url" | vlc -
    fi
elif [ "$command" = "record" ]
then
    output_file=${stream_url##*/}
    printf "Recording to $output_file...\n"
    if [ "$ext" = 'wmv' ]
    then
        vlc "$stream_url" ":sout=#std{access=file,mux=asf,dst=$output_file}"
    else
        flvstreamer -r "$stream_url" -o "$output_file"
    fi
fi

EDIT 11/07/2010 : Le plus simple est de créer un fichier pluzz dans le dossier personnel, d’y recopier le script ci-dessus, et d’exécuter :

sudo install pluzz /usr/local/bin

Conclusion

Après s’être déjà fait remarqué par leur exclusivité avec Orange, j’espère que France Télévisions acceptera un jour de permettre l’accès à tous à la télévision de rattrapage.

Depuis la sortie de l’iPad d’Apple, de nombreux articles ont été écrits sur le sujet. Jusqu’ici je me contentais de donner mon point de vue dans les commentaires des articles, mais j’ai finalement décidé de regrouper certaines de mes interventions pour en faire un billet de blog, et ainsi rajouter mes 2 centimes à tout ce ramdam.

Liberté d’expression

Aussi bien l’iPhone que l’iPad portent atteinte à la liberté d’expression.

Un exemple est rapporté par Rue89 :

Mark Fiore s’est vu interdire son application iPhone, dont le but était de diffuser de petites animations. […] Son crime ? Apple considère que ces caricatures, « contiennent des éléments qui ridiculisent des personnages publics, en violation de la section 3.3.14 de l’iPhone Developer Program License Agreement. »

Voici ce que dit cette section :

« Une application peut être rejetée si elle diffuse un contenu (texte, graphique, dessin, photo, son) qu’Apple juge désobligeant, par exemple un contenu pornographique, obscène ou diffamant. »

Apple se fait juge à la place du juge, et décide arbitrairement de ce qui doit être censuré ou non.

Pourtant, l’article 11 de la déclaration des droits de l’Homme et du citoyen de 1789 dit :

« La libre communication des pensées et des opinions est un des droits les plus précieux de l’homme : tout citoyen peut donc parler, écrire, imprimer librement, sauf à répondre à l’abus de cette liberté dans les cas déterminés par la loi. »

Pour des raisons évidentes, le terme « application » n’est pas présent dans le texte de l’article 11, mais on sent bien qu’une application peut être une forme d’expression, au même titre qu’un texte ou qu’une parole. En particulier, celle de l’exemple permettait de diffuser des animations, et son retrait a été exclusivement motivé par le fait qu’Apple les jugeaient désobligeantes. Sans autre forme de procès.

Il s’agit clairement d’une restriction à la liberté d’expression (qui est une liberté fondamentale) sans intervention de l’autorité judiciaire. Et c’est justement sur ce point que la loi HADOPI 1 a été censurée par le Conseil Constitutionnel le 10 juin 2009, dans son considérant 12 :

« Considérant qu’aux termes de l’article 11 de la Déclaration des droits de l’homme et du citoyen de 1789 […] ; qu’en l’état actuel des moyens de communication et eu égard au développement généralisé des services de communication au public en ligne ainsi qu’à l’importance prise par ces services pour la participation à la vie démocratique et l’expression des idées et des opinions, ce droit implique la liberté d’accéder à ces services ; »

(c’est toujours un plaisir de le relire)

L’iPhone Developer Program License Agreement ne semble donc pas compatible avec la déclaration des droits de l’Homme et du citoyen de 1789. Rien que ça.

Cette restriction de la liberté d’expression a certes moins de conséquences que celle proposée par l’HADOPI, mais elle prend de l’importance avec le nombre d’appareils vendus. On ne peut donc pas la négliger.

C’est LEUR produit, mais…

Cette politique est pourtant ardemment défendue par de nombreux fans, avec l’argument massue « iPad, c’est le produit d’Apple, ils font ce qu’ils veulent, si t’es pas content, va voir ailleurs ».
Cet argument est bien sûr totalement fallacieux. Certes, c’est LEUR produit, mais qui est support de NOS données, de NOS accès, de NOS communications et d’une partie de NOTRE vie numérique… À partir de là, il est évident qu’ils n’ont pas la légitimité pour faire ce qu’ILS veulent.

De la même manière que si HP produit une imprimante, ils n’ont pas le droit de décider arbitrairement quels contenus NOUS avons le droit d’imprimer. Parce que c’est NOTRE contenu, pas le LEUR. Et ceci même si d’autres constructeurs produisent d’autres imprimantes.

Liberté d’utilisation

Les produits Apple sont souvent critiqués pour leur manque d’ouverture (c’est peu de le dire) et les restrictions à base de DRM intégrées à leur appareils. Ce qui leur vaut d’ailleurs le qualificatif de « défectueux par conception ». Pour répondre à ces critiques, l’argument du choix revient souvent : « si les utilisateurs l’achètent, c’est que cela ne les dérange pas, c’est leur choix ».

Certes, c’est leur choix. Mais d’une part, cela ne saurait interdire les critiques, et d’autre part, une question d’éducation est à prendre en compte. Pour expliciter ma pensée, je vais me risquer à une analogie avec Internet et les opérateurs. Dans les deux cas, le problème posé est celui de la neutralité.

Soit on a un accès Internet, auquel cas on a accès à tout (sauf dans certaines dictatures), soit on n’a pas d’accès Internet, auquel cas on n’a accès à rien. Une fois qu’on a un accès, ça ne coûte pas plus cher ni à l’utilisateur ni au fournisseur d’accès qu’on l’utilise pour faire du mail ou pour télécharger une page web. C’est LE fonctionnement intrinsèque d’Internet qui fait ça : le réseau ne différencie pas les contenus.

Mais pour un utilisateur lambda qui ne connaît pas Internet, si un opérateur lui propose un forfait mobile « Internet », mais où l’option mail est à 2€/mois, l’option Twitter est à 1€/mois et l’option Facebook est à 1€/mois, ça pourrait lui paraître « logique » : plus il paie, plus il a accès à des services. Nous, qui connaissons un peu Internet, comprenons bien que c’est inéquitable : l’opérateur a simplement mis en place un mécanisme qui permet de couper certains accès pour les revendre en plus en option, alors qu’aucune contrainte technique ni aucun investissement ne justifie cette facturation. Il s’agit ni plus ni moins d’une segmentation artificielle permettant de vendre plusieurs fois la même chose aux utilisateurs, cette pratique étant facilitée par l’ignorance d’une majorité de la population sur le fonctionnement d’Internet. Et ça mène à des dérives.

Là, c’est pareil, sur un ordinateur (au sens large), tout le monde a accès à tout, peut le bidouiller, y installer des programmes, ne pas être dépendant de tel ou tel éditeur, n’est pas contrôlé à distance par une entité maître. Chacun peut développer les applications et les mettre à la disposition des autres.

Sur un iPad, rien de tout cela. Seules les applications acceptées par le maître ont droit de vie, seulement si elles passent par le canal de distribution du maître (qui au passage force un monopole et permet une censure arbitraire). Le produit enferme les utilisateurs dans l’ensemble des technologies du maître (qui interdit d’utiliser autre chose). La liberté d’utilisation est donc sacrifiée.

Dire que si ça ne convenait pas aux gens ils n’achèteraient pas, c’est trop simpliste : combien de personnes ont conscience des enjeux qu’il y a derrière? Les journaux papier et télévisés ne parlent que de « ce merveilleux appareil qui va sauver la presse »… Le grand public ne saura pas qu’il est possible d’avoir le contrôle de son ordinateur. De la même manière que le grand public pourrait ne pas savoir qu’Internet, ça comprend le mail et que ça n’est pas une option, si la neutralité du net n’est pas défendue…

Conclusion

Voilà les points importants que j’avais en tête à propos de l’iPad, qui restreint à la fois la liberté d’expression et la liberté d’utilisation.
Il y aurait sans doute encore beaucoup de choses à dire sur le sujet…

Ubuntu permet d’activer le chiffrement du dossier personnel lors de l’installation, grâce à eCryptfs.

Pourquoi chiffrer son dossier personnel ?

Parce que les documents personnels sont… personnels.
La demande du mot de passe à la connexion ou lors de la sortie de mise en veille ne protège absolument pas les données : il suffit de booter sur un LiveCD pour récupérer les données en clair très simplement.

Ces données peuvent être de toutes sortes :

• des photos de vacances ;
• l’historique de comptes en banque ;
• les scans de documents administratifs ;
• des mails ;
• le contenu de discussions en messagerie instantanée ;
• l’historique de navigation ;
• les mots de passe enregistrés ;
• bien d’autres choses…

Quand on sait que certains se font voler leur identité pour bien moins que ça… Vous me direz, certains n’ont pas besoin de se faire voler leurs données, ils donnent volontairement tous leurs mails privés à Google et plein d’autres infos à Facebook, alors… </troll>

Stockage des mots de passe

Je souhaiterais faire une parenthèse sur le stockage des mots de passe (sur un disque dur non chiffré).

Sur un système GNU/Linux, a priori il y a un trousseau de clés. Les logiciels peuvent l’utiliser pour enregistrer les mots de passe de manière sûre, en les chiffrant par une passphrase (par défaut le mot de passe du compte). C’est le cas par exemple d’Evolution, d’Empathy, de Gwibber… Pour voir les mots de passe enregistrés, il suffit d’ouvrir Applications > Accessoires > Mots de passe et clés de chiffrement.

Mais il y a un grand absent dans la liste des logiciels qui le gèrent : Firefox. Firefox enregistre les mots de passe quasiment en clair ; c’est dommage, c’est à lui qu’on donne la majorité de nos mots de passe. Du coup, si j’accède à un disque dur non chiffré, je peux récupérer tous les mots de passe enregistrés dans Firefox. D’ailleurs, c’est très simple : Édition > Préférences > Sécurité > Mots de passe enregistrés… > Afficher les mots de passe (ça devrait inciter les gens à verrouiller leur session quand ils s’absentent plus de 5 secondes). Il y a bien une option « Utiliser un mot de passe principal », mais comme il n’est pas intégré au système, il faut le renseigner une fois par session Firefox (en plus du mot de passe système donc). Cela suffit à dissuader de l’activer.

Je ne sais pas si c’est prévu pour Firefox 4.0, mais je pense que la sécurité des mots de passe aurait été plus utile que des thèmes à la manière de WinAmp il y a 10 ans (pardon on dit des personas)…

Ceci donne un argument de plus pour chiffrer son dossier personnel… Parenthèse fermée.

Mise en place du chiffrement

Pour activer le chiffrement du dossier personnel lors de l’installation, il suffit de choisir la bonne option :

(je vous conseille aussi d’utiliser une partition séparée pour /home)

Et voilà, c’est tout.

Enfin, pas tout-à-fait, car quand on chiffre ses données, il est certes important qu’elles soient protégées, mais il y a quelque chose d’encore plus important, c’est qu’elles soient récupérables…

Nous allons donc voir comment ça fonctionne, comment récupérer les données, ce à quoi il faut faire attention, etc.

Principe

Le système utilise une clé (une passphrase) pour chiffrer toutes les données avant de les écrire sur le disque. Elle est générée automatiquement, et devra être notée quelque part (sur un bout de papier à garder précieusement). Cette clé est elle-même chiffrée par une passphrase, qui est le mot de passe du compte utilisateur. Ainsi, lors de la connexion de l’utilisateur, la clé pourra être déchiffrée et utilisée pour lire et écrire des données.

Il faut bien distinguer ces deux passphrases :

• la première est la passphrase de montage : c’est elle qui permet de monter et d’utiliser le répertoire chiffré ;
• la seconde est la passphrase de login : c’est elle qui permet de déchiffrer la première, lors de la connexion de l’utilisateur.

Tant que vous connaissez la passphrase de montage, vous pourrez récupérer vos données.
Si vous connaissez uniquement la passphrase de login, vous pourrez normalement récupérer la passphrase de montage (mais c’est plus sûr de garder dans un coin la passphrase de montage, car on peut effacer involontairement le fichier permettant de faire le lien).
Si vous ne connaissez aucune des deux, vos données sont définitivement perdues…

Physiquement, les dossiers chiffrés sont stockés dans /home/.ecryptfs/USER/.Private.
Les données servant au chiffrement et au déchiffrement sont dans /home/.ecryptfs/USER/.ecryptfs.
Le répertoire /home/USER, quant à lui, n’existe pas physiquement : c’est juste une « vue » déchiffrée du répertoire .Private.

Remarque : les noms de fichiers étant eux-aussi chiffrés, ils ne comportent physiquement pas le même nombre de caractères que le nom de fichier « en clair » (d’autant plus qu’ils contiennent un préfixe). Ceci a une conséquence : en EXT4 les noms de fichiers ne doivent pas dépasser 256 caractères, mais un nom de fichier « en clair » d’environ 140 caractères entraîne un nom de fichier chiffré de 256 caractères. Les noms de fichiers sont donc limités à environ 140 caractères sur un dossier chiffré…

Connaître la passphrase de montage

Une fois le système démarré, il est possible de connaître la passphrase de montage :

$ ecryptfs-unwrap-passphrase
Passphrase: (entrer ici la passphrase de login)
6ebf259226f1d0859e707eb4349a9476

D’ailleurs, lors du premier démarrage, Ubuntu vous demandera d’exécuter cette commande et de noter quelque part le résultat.

Pour récupérer cette passphrase sans que le système en question soit démarré (par exemple en accédant à la partition à partir d’un LiveCD), il faut préciser le fichier qui contient la passphrase de montage chiffrée :

$ ecryptfs-unwrap-passphrase /media/DISK/.ecryptfs/USER/.ecryptfs/wrapped-passphrase
Passphrase: (entrer ici la passphrase de login)
6ebf259226f1d0859e707eb4349a9476

Changer la passphrase de login

On ne peut pas changer facilement la passphrase de montage, car il faudrait alors rechiffrer toutes les données. Par contre, la passphrase de login peut être aisément changée (puisque seule la passphrase de montage sera à rechiffrer).

En pratique, ce changement est fait automatiquement lors d’un changement de mot de passe du compte utilisateur.

Pour la changer manuellement (attention, il ne sera plus possible de démarrer correctement si la passphrase de login ne correspond pas au mot de passe de connexion) :

$ ecryptfs-rewrap-passphrase /home/.ecryptfs/USER/.ecryptfs/wrapped-passphrase
Old wrapping passphrase: (entrer ici l'ancienne passphrase de login)
New wrapping passphrase: (entrer ici la nouvelle passphrase de login)

Réinstaller le système d’exploitation

Pour réinstaller le système d’exploitation (par exemple pour y mettre une nouvelle version d’Ubuntu) en conservant son dossier personnel chiffré, il faut bien sûr avoir le /home sur une partition séparée, ne pas la formater lors de la nouvelle installation, mais il faut aussi utiliser le même login et le même mot de passe de connexion. Si vous respectez cette règle, vous n’avez rien de particulier à faire, tout est transparent.

Si vous avez changé le mot de passe, l’installation se déroule normalement sans avertissement, mais une fois le système installé, vous ne pourrez pas vous connecter (car vous n’avez pas de /home accessible). Si cela vous arrive, ce n’est pas bien grave, allez dans un TTY (Ctrl+Alt+F1), connectez-vous et changez manuellement votre passphrase de login (comme expliqué dans la section ci-dessus) pour la faire correspondre à votre mot de passe de connexion. Votre ancienne passphrase de login vous sera demandée.

Si malheureusement vous ne vous souvenez plus de votre ancienne passphrase de login (vous le faites exprès ou quoi ?), mais que vous possédez votre passphrase de montage, vous pouvez vous en sortir :

$ ecryptfs-wrap-passphrase /home/.ecryptfs/USER/.ecryptfs/wrapped-passphrase
Passphrase to wrap: (entrez ici la passphrase de montage)
Wrapped passphrase: (entrez ici la nouvelle passphrase de login)

Redémarrez le système, et normalement tout fonctionne.

Chiffrer son dossier personnel après installation

Il est également possible de chiffrer son dossier personnel une fois le système installé. Cependant, il y a une limitation très contraignante : il faut avoir comme espace libre 2,5× la taille de l’espace occupé par le dossier personnel, c’est-à-dire que la partition contenant /home ne doit pas être remplie à plus de 28%.

Avant toute chose, faire une sauvegarde sur un disque externe ou sur une autre machine (un problème pourrait entraîner la perte de toutes les données).

Le paquet ecryptfs-utils doit être installé :

sudo apt-get install ecryptfs-utils

La commande qui permet de migrer son home est ecyptfs-migrate-home. Cependant, aucune ressource de l’utilisateur du dossier personnel à migrer ne doit être utilisée (pas même un shell). On a donc besoin d’un autre utilisateur, par exemple root (provisoirement).

On réactive donc le compte root et on lui affecte un mot de passe :

sudo passwd root

Ensuite, il faut redémarrer la machine (déconnecter son compte ne suffit pas). Lors de l’écran de login, passer en TTY (Ctrl+Alt+F1), se connecter avec root, et exécuter :

ecryptfs-migrate-home -u USER

(en remplaçant USER par le nom de l’utilisateur dont le dossier personnel doit être migré)

Un peu de patience, il faut attendre un certain temps (qui se compte en heures selon la quantité de données et la puissance du processeur)…

Une fois terminé, se connecter avec l’utilisateur (repasser en mode graphique avec Ctrl+Alt+F7). Normalement tout doit fonctionner.
L’ancien dossier personnel (non chiffré) est dans /home/USER.xxxxxx.

Si tout s’est bien passé ce dossier doit être supprimé, et le compte root peut être désactivé :

sudo passwd --lock root

Récupérer ses données chiffrées

C’est la partie indispensable pour accepter d’utiliser un dossier personnel chiffré : être sûr de pouvoir récupérer ses données. Je vous conseille de tester cette procédure une fois le chiffrement mis en place.

Pour accéder aux données, il suffit d’un LiveCD d’une distribution avec un noyau Linux supérieur ou égal à 2.6.26. J’ai donc utilisé le LiveCD d’Ubuntu Lucid Lynx (10.04) pour mes tests, en m’inspirant de cette doc.

Tout d’abord, il faut monter la partition contenant les dossiers chiffrés (ça se fait graphiquement en cliquant sur le disque correspondant dans le menu Raccourcis). J’utiliserai l’emplacement /media/DISK comme exemple.

Tout ce que nous allons faire à partir de maintenant nécessite d’être root, passons donc root :

sudo -s

La signature de la clé de chiffrement des noms de fichiers sera nécessaire pour la suite :

root@ubuntu:/~# ecryptfs-add-passphrase --fnek
Passphrase: (entrer la passphrase de montage)
Inserted auth tok with sig [514d1d3af1a232cd] into the user session keyring
Inserted auth tok with sig [7890544814a5865f] into the user session keyring

C’est le code entre crochets de la dernière ligne qui est important.

On va monter le répertoire chiffré dans un répertoire qu’on va appeler decrypted, créons-le :

root@ubuntu:/~# mkdir decrypted

Ensuite, on monte et on répond aux questions :

root@ubuntu:/~# mount -t ecryptfs /media/DISK/.ecryptfs/USER/.Private decrypted
Selection [aes]:
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [514d1d3af1a232cd]: 7890544814a5865f

(pour la FNEK, il faut bien préciser la signature qu’on a récupéré juste au-dessus)

Si tout s’est bien passé :

Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=7890544814a5865f
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=514d1d3af1a232d
Mounted eCryptfs

Les données sont maintenant accessibles:

root@ubuntu:~# ls decrypted
Bureau     examples.desktop  Modèles  Public           Vidéos
Documents  Images            Musique  Téléchargements

Pour démonter:

root@ubuntu:~# umount decrypted

Conclusion

Je pense qu’on a fait le tour de l’essentiel à savoir pour chiffrer son dossier personnel et pouvoir récupérer ses données. J’en ai profité pour chiffrer celui de mon ordinateur portable, tout fonctionne très bien.

Il faut cependant être conscient de deux choses.

Tout d’abord, les données personnelles ne sont pas présentes uniquement dans le répertoire /home, elles sont copiées dans /tmp, dans la RAM, dans le SWAP (il est également possible de chiffrer le SWAP, grâce à ecryptfs-setup-swap), etc. Le chiffrement est donc une étape essentielle dans la protection des données, mais il faut comprendre ce que ça protège (voir à ce sujet le guide d’autodéfense numérique).

Ensuite, ce chiffrement est là pour protéger la vie privée, pas pour cacher quelque chose à la justice. D’une part, le code pénal prévoit une peine de 3 ans et 45000€ d’amende pour refus de fournir la convention secrète de déchiffrement (autrement dit la clé). D’autre part, pour des sujets graves, nul doute que les États mettront les moyens pour casser la clé (qui est relativement faible, car proportionnée à l’objectif à atteindre, à savoir la protection de la vie privée).

Pour utiliser le chiffrement pour des communications plutôt que pour le stockage des données, vous pouvez consulter GnuPG : chiffrer et signer sous Ubuntu pour les nuls.

Amusez-vous bien.

Ubuntu utilise maintenant Plymouth pour le processus de démarrage graphique. C’est maintenant le noyau qui s’occupe de la configuration graphique à la place de Xorg : c’est plus joli, plus rapide…

Le problème, c’est que le logiciel propriétaire ne suit pas le rythme du logiciel libre. En particulier, le pilote NVIDIA propriétaire ne supporte pas encore cette fonctionnalité (alors que le pilote libre la gère correctement, mais ne supporte pas la 3D). Du coup, on se retrouve avec un splash screen très laid en basse résolution au démarrage.

Ce billet décrit comment avoir un logo à la bonne résolution (même si on n’obtiendra pas la fluidité possible actuellement avec le pilote libre). Une mise à jour sera peut-être disponible (espérons-le), avec un pilote NVIDIA propriétaire fonctionnant correctement. Si tel est le cas, merci de me prévenir, pour que je marque ce billet comme déprécié.

Contourner le problème

Attention : ces modifications modifient votre configuration graphique, elles pourraient empêcher votre système de fonctionner correctement.

Remplacez dans les étapes suivantes 1680x1050 par la définition de votre écran.

Tout d’abord, il faut prendre un post-it, un stylo, et écrire « ne plus acheter d’ordinateur avec une carte graphique nécessitant des pilotes propriétaires pour fonctionner ». Le coller ensuite bien en évidence pour s’en rappeler lors du prochain achat informatique.

Ensuite, installer le paquet v86d :

sudo apt-get install v86d

Puis éditer le fichier /etc/default/grub :

gksudo gedit /etc/default/grub

et remplacer la ligne :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

par :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset video=uvesafb:mode_option=1680x1050-24,mtrr=3,scroll=ywrap"

et la ligne :

#GRUB_GFXMODE=640x480

par :

GRUB_GFXMODE=1680x1050

Puis exécuter les commandes suivantes :

echo 'uvesafb mode_option=1680x1050-24 mtrr=3 scroll=ywrap' | sudo tee -a /etc/initramfs-tools/modules
echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash
sudo update-grub2
sudo update-initramfs -u

Il ne reste plus qu’à redémarrer le système, le logo est maintenant joli.

Merci à softpedia pour cette astuce.

Pour mes flux RSS, j’utilise l’outil tt-rss installé sur mon serveur, qui récupère régulièrement tous les flux auxquels je suis abonné.

Le but de ce billet est de mettre en place un mécanisme similaire qui s’applique aux sources de vidéo à la demande (pas forcément prévues pour être agrégées), et qui les convertit dans le format ouvert OGG/Theora (dans un répertoire rendu accessible par un serveur web tel qu’Apache), tout en parallélisant au maximum les différentes actions afin que le temps total de récupération soit minimal.

En particulier, il faut éviter de télécharger la première vidéo, puis de l’encoder, d’attendre que l’encodage soit terminé pour télécharger la seconde vidéo… Et si plusieurs CPU sont disponibles sur la machine, il faut donner un encodage à chaque processeur (l’encodeur theora ne sachant pas paralléliser l’encodage d’une seule vidéo).

Architecture

Pour cela, il y a donc 2 parties bien distinctes :

• un serveur d’encodage, qui s’occupe du démarrage et de la parallélisation des encodages ;
• des programmes de récupération brute pour chaque source de flux, qui demandent au serveur d’encodage de s’occuper de la conversion des fichiers récupérés.

Serveur d’encodage

Principe

Le serveur d’encodage gère plusieurs processus ouvriers (dans l’idéal, il faut configurer pour avoir autant de processus que de CPU sur la machine). Il attend de nouvelles tâches, et les transmets aux ouvriers disponibles, qui s’occupent de l’encodage. Si aucun ouvrier n’est disponible, il attend qu’un se libère.

Implémentation

Les demandes d’encodage se font grâce à un named pipe (aussi appelé FIFO), un fichier un peu spécial créé avec mkfifo. Chaque ligne représente une tâche. Concrètement, une tâche est décrite par les paramètres à passer à ffmpeg2theora (l’encodeur theora), séparés par un séparateur (j’ai choisi « | », qui a peu de chance d’être utilisé dans un nom de fichier). Pour les puristes, je vous mets au défi d’utiliser comme séparateur \0, tout en conservant le mécanisme de file d’attente dans un fichier.

Un démon récupère les nouvelles lignes ajoutées au fichier, et les transmet une à une aux ouvriers. Chaque ouvrier recrée le tableau des arguments en redécoupant la ligne suivant le séparateur choisi, et le passe en paramètre de ffmpeg2theora (en y ajoutant toujours --nice 19 pour n’utiliser que le CPU disponible, sans ralentir d’autres programmes en cours d’exécution).

Démon

Voici le programme démon (adapter le nombre de CPU) :
/usr/sbin/ffmpeg2theora-laterd

#!/bin/bash
CPU=2
TASKS=/tmp/ffmpeg2theora-tasks
[ -p "$TASKS" ] || mkfifo "$TASKS" -m 666
tail -f "$TASKS" | xargs -I{} -P "$CPU" ffmpeg2theora-later-job {}

Ce script fait donc exécuter par les ouvriers le programme ffmpeg2theora-later-job pour chacune des tâches, dont voici le code :
/usr/sbin/ffmpeg2theora-later-job

#!/bin/bash
IFS='|' read -a args <<< "$1"
echo "executing: ffmpeg2theora ${args[@]} --nice 19"
ffmpeg2theora "${args[@]}" --nice 19

Je vous conseille de prendre la dernière version de ffmpeg2theora, actuellement celle des dépôts est assez ancienne.

Le démon est à lancer une fois (et une seule !), au démarrage du système par exemple (une solution est de l’ajouter dans /etc/rc.local).

Client

Les clients (les programmes qui veulent demander un encodage) doivent appeler ffmpeg2theora-later, qui s’occupe d’écrire les paramètres séparés par « | » dans le FIFO :
/usr/bin/ffmpeg2theora-later

#!/bin/bash
printf '|%s' "$@" | cut -c2- > /tmp/ffmpeg2theora-tasks

Son utilisation est extrêmement proche de ffmpeg2theora (évidemment, puisqu’il se contente de lui transmettre ses paramètres), à ceci près que les chemins doivent être absolus (puisque le démon ne sait pas à partir de quel répertoire la demande d’encodage a été effectuée).

Ainsi, là où on aurait utilisé, à partir de /tmp :

ffmpeg2theora file.avi -o file.ogv -x 400 -y 300 -v 8 -a 3

on peut appeler :

ffmpeg2theora-later /tmp/file.avi -o /tmp/file.ogv -x 400 -y 300 -v 8 -a 3

Programmes de récupération

Principe

Les programmes de récupération font ce qui est nécessaire pour récupérer les vidéo à télécharger. Plusieurs outils sont bien utiles pour cela :

• wget si le fichier est disponible en HTTP (mais c’est rare) ;
• flvstreamer pour récupérer les vidéos diffusées en Flash avec des liens en rtmp:// (anciennement rtmpdump, je vous recommande le message adressé à Adobe de la part du développeur originel) ;
• mimms pour récupérer les vidéos diffusées en WMV avec des liens en mms://.

Pensez bien à ouvrir les ports nécessaires pour récupérer les vidéos (1935 par défaut pour les liens RTMP, 1755 pour MMS…).

Implémentation

Afin de rendre un peu indépendants les répertoires manipulés, j’ai décidé de créer un script vodget qui appelle les programmes de récupération avec 2 paramètres :

1. le répertoire de téléchargement ;
2. le répertoire destination.

/usr/bin/vodget

#!/bin/bash
scripts_dir=/var/lib/vodget
script="$scripts_dir/$1"
download_dir=/tmp/vodget
target_dir=/var/www/vod
$script "$download_dir" "$target_dir"

Les programmes de récupération sont stockés dans /var/lib/vodget.

Exemple

Voici un exemple qui récupère les guignols de l’info (Canal+) :
/var/lib/vodget/guignols

#!/bin/bash
category=guignols
download_dir="$1/$category"
target_dir="$2/$category"
mkdir -p "$download_dir"
mkdir -p "$target_dir"
wget -O- http://www.canalplus.fr/rest/bootstrap.php?/bigplayer/search/guignols | grep -o 'rtmp://[^<]\+.mp4' | while read url
do
    filename="$(echo "$url" | sed 's/.*\([0-9]\{2\}\)\([0-9]\{2\}\)\([0-9]\{2\}\).*/20\1-\2-\3/')"
    if [ ! -f "$target_dir/$filename.ogv" ]
    then
        flvstreamer -r "$url" -o "$download_dir/$filename.mp4"
        touch "$target_dir/$filename.ogv"
        ffmpeg2theora-later "$download_dir/$filename.mp4" -o "$target_dir/$filename.ogv" -v8 -a3
    fi
done

Cet exemple est une implémentation qui a l’avantage d’être très courte, vous pouvez aussi adapter des versions plus évoluées pour qu’elles utilisent ffmpeg2theora-later.

Un simple appel à :

vodget guignols

récupèrera les nouveaux épisodes et les encodera en OGG/Theora.

Il ne restera plus qu’à se rendre sur la page HTTP pointant sur le répertoire des vidéos avec un navigateur qui supporte le HTML5 et le codec OGG/Theora, pour pouvoir regarder les vidéos ainsi récupérées :

Bien sûr, les vidéos récupérées qui ne sont pas sous licence libre sont à usage personnel. Cela permet de regarder en VOD les épisodes dans un format ouvert, qui ne nécessite pas de programme propriétaire, ces vidéos ne doivent pas être placées sur un serveur public.

Démarrage programmé

Pour automatiser tout cela, il est possible de programmer périodiquement la récupération des nouvelles vidéos grâce à cron. Pour cela :

crontab -e

et ajouter la ligne qui-va-bien. Par exemple, pour récupérer les nouveaux épisodes des guignols tous les jours à 23 heures :

00 23 * * * vodget guignols

Améliorations

Techniquement, il faudrait gérer le démon par un script init.d, mais ça n’est pas si simple (si on arrête le service alors qu’une vidéo est en cours d’encodage et qu’on le redémarre, le nombre de CPU à utiliser ne sera plus respecté…).

Si vous êtes motivés, il est également possible de faire un beau site qui permette de regarder les vidéos en VOD, plutôt qu’une page qui liste simplement les fichiers récupérés.

Conclusion

Les différentes vidéos que je suis susceptible de regarder en VOD (que je ne regardais pas avant) sont maintenant disponibles sur mon serveur, lisible directement par mon navigateur.

On peut imaginer de nombreuses sources à agréger :

• les sites de VOD des chaînes de télévision (Canal+, France5, M6…) ;
• des bandes-annonces cinéma ;
• des chaînes enregistrées en direct avec la TV sur ADSL ;
• le flux de l’Assemblée Nationale ou du Sénat ;
• …

Bien sûr, on aimerait mieux que les différentes sources fournissent des flux RSS pointant vers leurs vidéos, qu’ils diffuseraient eux-même en OGG/Theora. Mais on peut toujours attendre…

Il y a tout juste un an, durant les débats sur Hadopi, la Quadrature du Net publiait un article Partager n’est pas voler ! (chronique d’un mensonge historique).

Le mois dernier, Jérémie Zimmermann, invité sur la RSR (Radio Suisse Romande), y expliquait pourquoi fondamentalement, et au-delà de son applicabilité, la « chasse aux pirates » est insensée. Après le #fail d’Hadopi, cette guerre au partage est plus que jamais d’actualité avec les négociations d’ACTA.

Vous pouvez écouter cette intervention de 15 minutes :

Pour ceux qui ne peuvent pas lire la piste audio directement, elle est disponible sur le mediakit de la Quadrature.

Ce billet est également l’occasion pour moi d’utiliser pour la première fois la balise <audio> d’HTML5. Malheureusement, pour l’instant, il est impossible d’avoir une page valide car WordPress écrit du XHTML 1.1 et cette fonctionnalité nécessite HTML5. Ça fonctionne quand même…

Tout le monde a entendu parler de la balise <video/>, la nouveauté la plus médiatisée d’HTML5. Le format vidéo à utiliser sur le web fait polémique (Theora ou H264) à cause de brevets logiciels, toujours bien présents dès il s’agit de freiner l’innovation. Une situation qu’à mon avis seul Google peut résoudre. Mais ce n’est pas l’objet de ce billet, pour l’instant, le format, c’est OGG Theora. Il suffit de placer un fichier ogv quelque part sur un serveur, et Firefox sait la lire.

Un problème survient cependant dès qu’on veut y accéder sur HTTPS plutôt qu’HTTP : on ne peut pas seeker dans la vidéo (c’est-à-dire qu’on ne peut pas déplacer le curseur pour se positionner à n’importe quel endroit), et on ne connaît pas sa durée totale.

Quelle différence entre l’accès en HTTP et HTTPS?

En HTTP, on reçoit la taille du fichier vidéo :

$ curl --compressed -I http://.../video.ogv
HTTP/1.1 200 OK
Server: Apache
…
Content-Length: 26959501
Content-Type: video/ogg

En HTTPS, on ne la reçoit pas, car le flux est compressé en gzip.

$ curl --compressed -k -I https://.../video.ogv
HTTP/1.1 200 OK
Server: Apache
…
Content-Encoding: gzip
Content-Type: video/ogg

(-k permet d’autoriser l’utilisation d’un certificat SSL non reconnu)

C’est la source du problème. Pourquoi ce comportement différent par défaut entre HTTP et HTTPS, je n’en sais rien (si quelqu’un peut m’éclairer…).

Par contre, il est très facile de désactiver la compression pour certains types de fichiers, comme les images ou les vidéos (compression qui n’a de toute façon aucun intérêt ces fichiers sont déjà compressés).

Pour cela, il suffit de rajouter une ligne dans /etc/apache2/mods-available/deflate.conf :

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ogg|oga|ogv)$ no-gzip dont-vary

et de recharger Apache :

sudo service apache reload

Et maintenant, ça fonctionne correctement sur HTTPS :

$ curl --compressed -k -I https://.../video.ogv
HTTP/1.1 200 OK
Server: Apache
…
Content-Length: 26959501
Content-Type: video/ogg

Pour continuer ma série d’articles sur l’auto-hébergement de ses mails, je vais présenter l’installation de SpamAssassin.

Pour mon serveur mail (et plus généralement pour les outils que j’utilise), j’essaie de mettre en place uniquement ce dont j’ai besoin. Et jusqu’ici, je n’avais pas l’utilité d’un anti-spams, ne recevant aucun courrier indésirable. Mais depuis peu, j’en reçois un de temps en temps… C’est donc l’occasion de m’y mettre.

Installation et configuration

Il existe plusieurs méthodes, j’ai choisi la plus simple : c’est procmail qui fournit les mails à SpamAssassin.

Tout d’abord, installer le paquet :

sudo apt-get install spamassassin

Ensuite, rajouter dans ~/.procmailrc la règle suivante (copiée de la doc) :

# Pipe the mail through spamassassin (replace 'spamassassin' with 'spamc'
# if you use the spamc/spamd combination)
#
# The condition line ensures that only messages smaller than 250 kB
# (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam
# isn't bigger than a few k and working with big messages can bring
# SpamAssassin to its knees.
#
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| spamassassin

Enfin, éditer /etc/spamassassin/local.cf.

Pour uniquement ajouter les en-têtes de spam (ce qui est suffisant pour filtrer), il faut changer la valeur de report_safe :

report_safe 0

Pour ajouter un tag dans le sujet d’un mail considéré comme un spam :

rewrite_header Subject *****SPAM*****

Il est également possible de configurer le score requis pour qu’un mail soit considéré comme un spam. Plus cette valeur est faible, plus le filtre est agressif.
La valeur par défaut (5.0) est un peu faible, je vous conseille d’augmenter un peu si vous voulez limiter les faux-positifs :

required_score 6.0

Rajouter éventuellement les lignes suivantes :

# Langues attendues (les autres auront un score plus élevé)
ok_languages fr

# Rapports en français
lang fr

Test

Pour tester, le plus simple est de mettre un filtre très sévère, par exemple avec un score négatif :

required_score -2

En m’envoyant un mail à moi-même qui contient comme sujet test, je constate à la réception que les en-têtes ont été modifiés :

Subject: *****SPAM***** test
Date: Thu, 25 Mar 2010 21:19:52 +0100
Message-Id: <1269548392.9798.9.camel@rom-laptop>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rom-eeebox
X-Spam-Level: ***
X-Spam-Status: Yes, score=3.9 required=-2.0 tests=ALL_TRUSTED,

Le mail a bien été détecté comme un spam. Ça fonctionne.

Filtrage

Maintenant que les spams sont détectés, il faut les traiter (les déplacer dans un dossier prévu à cet effet).

Il suffit pour cela de créer un dossier sur le serveur :

maildirmake.dovecot ~/Maildir/.Spams

et d’ajouter la règle suivante dans ~/.procmailrc (plus d’infos) :

:0
* ^X-Spam-Status: Yes
.Spams/

Conclusion

Les spams auront maintenant un peu plus de mal à se glisser dans ma boîte mail.

La configuration présentée ici est vraiment minimale. Selon son efficacité il faudra peut-être l’affiner.

Voir aussi

Mes précédents billets sur l’auto-hébergement des mails :
Hébergez vos mails sur Ubuntu Server (et libérez-vous)
Installer un webmail (RoundCube) sur Ubuntu Server
Ajouter l’authentification SMTP sur un serveur mail
Trier ses mails directement sur le serveur (procmail)

Mesdames et messieurs les députés,

Le projet LOPPSI a été planifié les 9, 10 et 11 février à l’Assemblée Nationale.

Je n’ai pas lu tout le projet de loi (n’étant pas compétent sur le contenu de tous les articles), mais j’ai lu avec attention ceux concernant Internet (2, 3, 4 et 23), que j’avais analysés l’année dernière : loppsi.pdf.

Je souhaiterais en particulier attirer votre attention sur le dispositif principal (l’article 4) qui prétend « protéger les internautes contre les images de pornographie enfantine ». Pour résumer mon analyse, j’en dénonce les fondements, la mise en œuvre, l’efficacité et les dangers. Je formule également des propositions pour répondre au problème posé.

Les fondements : pour combattre la pédopornographie, il faut attaquer « à la source », à savoir ordonner le retrait des contenus et arrêter les individus qui les créent. Ce texte fait le contraire : il propose de ne pas avoir à s’embêter à arrêter les criminels et fait en sorte de pouvoir les ignorer tranquillement.

La mise en œuvre : elle porte clairement atteinte à la neutralité du net, car le filtrage serait effectué en cœur de réseau. Elle tente d’aller à l’encontre de la structure même d’Internet, et provoquera à coup sûr des sur-blocages.

L’efficacité : toutes les technologies de filtrage sont inefficaces et facilement contournables.

Les dangers : la possibilité pour le ministère de l’intérieur d’ordonner le filtrage d’une liste gardée secrète de sites est, en soi, très contestable. Cela mènera inévitablement à des dérives, comme on peut le constater dans les pays ayant mis en place un tel dispositif.

Cet article de loi présente un objectif peu pertinent (bloquer l’accès à ceux qui tomberaient sur des contenus criminels « par hasard ») plutôt que de s’attaquer au problème réel de la pédopornographie, mais en plus il y répond de manière inappropriée.

Pour contrer les réseaux de pédopornographie, il faudrait mettre plus de moyens pour remonter aux sources et arrêter les personnes concernées. Il faudrait également ordonner le retrait des images sur les serveurs, beaucoup plus efficace que le filtrage, et sans risque de sur-blocage, ce qui fonctionne très bien contrairement à ce qui est sous-entendu dans le projet de loi (voir la conclusion de mon analyse détaillée).

En plus de ces réelles mesures, on peut bien sûr envisager, en complément, de « protéger » les quelques internautes qui tomberaient malencontreusement sur des images douteuses. Pour cela, il existe une solution très simple, concrète et respectueuse des libertés : proposer aux utilisateurs un logiciel de type « contrôle parental » qui bloquerait ces contenus. Pour des non-spécialistes, la différence avec le filtrage proposé peut paraître subtile, elle est pourtant FONDAMENTALE : l’utilisateur a le contrôle sur ce qui est bloqué, les risques de sur-blocage et de dérives démocratiques sont évités, la neutralité du réseau n’est pas attaquée et l’objectif est parfaitement atteint.

N’hésitez pas à consulter également l’analyse que je fais des articles 2, 3 et 23, que je ne résume pas dans cette lettre.

En tant que citoyen, je vous invite à prendre en compte ces arguments. Si vous y adhérez, je vous propose de formuler des amendements pour les défendre. Si vous avez des doutes ou souhaitez des précisions, n’hésitez pas à me contacter. Si vous êtes en désaccord, merci de m’en indiquer les raisons.

J’espère que vous écouterez l’ensemble des personnes qui s’expriment sur le sujet (qui n’ont pas forcément le même avis que moi) afin d’agir dans l’intérêt général.

Cordialement,