PROJET AUTOBLOG


®om's blog

Site original : ®om's blog

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Chiffrer son dossier personnel (/home) sous Ubuntu

dimanche 16 mai 2010 à 15:12

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 :

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 :

ubuntu-install-ecryptfs

(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 :

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éer :

$ 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.

EDIT : Désormais, la commande ecryptfs-recover-private permet d’automatiser tout le processus manuel qui suit.

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

updatedb

updatedb indexe régulièrement les fichiers pour pouvoir les rechercher rapidement avec locate. Il faut lui indiquer de ne pas indexer les répertoires .Private afin de ne pas perdre du temps, de la place, et surtout éviter d’obtenir des résultats insignifiants lors d’une recherche avec locate.

Pour cela, ouvrir /etc/updatedb.conf, et éditer la ligne suivante pour y ajouter .Private (la décommenter si elle commençait par un #) :

PRUNENAMES=".git .bzr .hg .svn .Private"

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.

Addendum

À l’utilisation, j’ai remarqué que cette méthode de chiffrement entraînait des problèmes de performance, notamment pour les dossiers contenant beaucoup de fichiers.

Je recommande donc plutôt LUKS+LVM.

Splash screen Ubuntu Lucid Lynx (10.04) et pilote NVIDIA propriétaire

jeudi 13 mai 2010 à 14:26

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.

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 :

sudo editor /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.

Agréger différentes sources de VOD en OGG/Theora

samedi 24 avril 2010 à 18:58

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 :

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 transmet 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 :

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 /usr/bin/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.
#!/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 :

vod-guignols

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 à aggréger :

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…

Partager n'est pas voler !

lundi 29 mars 2010 à 21:32

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).

lqdn

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…

EDIT 20/05/2011 : À voir également le documentaire Copier n’est pas voler.

Vidéo OGG Theora sur HTTPS (dans Firefox) : configurer Apache

samedi 27 mars 2010 à 22:43

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
Error happened! 0 - Call to undefined function simplexml_load_string() In: /var/www/Projet-Autoblog/autoblogs/autoblog.php:364 http://www.couturat.fr/Projet-Autoblog/autoblogs/blogrom1vcom_4af8d17d34d978843ff2ff40339aa5760e6458bc/?17 #0 /var/www/Projet-Autoblog/autoblogs/autoblog.php(932): VroumVroum_Blog->update() #1 /var/www/Projet-Autoblog/autoblogs/blogrom1vcom_4af8d17d34d978843ff2ff40339aa5760e6458bc/index.php(1): require_once('/var/www/Projet...') #2 {main}