Wxcafé

les NUCs et le HDMI-CEC

Wxcafe — Sat, 22 Aug 2015 02:43:00 +0200

J’ai récemment récupéré une télé. Ce post ne se centrant pas sur cette télé, passons rapidement sur ce qui y est lié : ne souhaitant pas “profiter” du paysage audiovisuel français (ou PAF), et ayant nombre de films et séries acquis tout a fait légalement (hmm hmm) stockés sur mon serveur local, je souhaitais brancher sur ma télévision un système me permettant de regarder ces films et séries, et possiblement quelques sources de vidéos en ligne (Youtube, Netflix, etc…) simplement.

Ayant un Raspberry Pi 1 qui trainait, j’ai décidé d’installer OpenELEC dessus et de voir ce que ça donnait. Le résultat n’étant pas satisfaisant (a cause des difficultés du RPi a faire fonctionner tout ça), j’ai décidé d’upgrader le système.

J’ai donc acquis un NUC D34010WYK (attention, les nouveaux modèles ne fonctionnent pas pour ce qui suit), un adaptateur HDMI-CEC pour celui-ci, et un SSD mSATA, en me disant que je pourrais sans trop de problème faire tourner Kodi sur un debian, avec en plus Steam pour faire du streaming depuis mon desktop. L’autre avantage de tourner sur du Intel, c’est de pouvoir mater Netflix (puisque le plugin kodi approprié utilise chrome, et ne fonctionne (a ma connaissance) que sur x86).

J’ai donc reçu après un certain temps le matériel sus cité, que j’ai avidement monté, avant de me rendre compte que le manuel de l’adaptateur Pulse-Eight était [PDF]assez médiocre. J’ai donc cherché plusieurs heures, avant de trouver [DE]ce post expliquant comment brancher l’adaptateur. Je vais donc résumer ici le processus, ce qui devrait rendre la tache a la fois plus simple pour les autres personnes cherchant l’information, et pour moi si je dois remonter ce système.

Pour faire simple, le NUC présente trois headers séparés : un dual-USB, un dit “Front Panel”, et un appelé “Custom Solution Header”. Les trois sont utilisés ici. La première chose a faire est de brancher les fiches grises et rouges sur le Custom Solution Header: le branchement doit être fait ainsi :

Custom Solution
  ┌─┬─┬─┬─┬─┐
  │g│ │·│r│·│
  ├─┼─┼─┼─┼─┤
  │·│·│·│·│·│
  └─┴─┴─┴─┴─┘

  g ➔ fiche grise
  r ➔ fiche rouge
  · ➔ pin inutilisé
    ➔ espace vide (sans pin)

Une fois cela fait, il faut brancher le Front Panel. Heureusement, c’est plus facile, puisqu’il n’y a qu’une seule fiche a brancher ici : la orange.

  Front Panel
  ┌─┬─┬─┬─┬─┐
  │·│·│·│·│·│
  ├─┼─┼─┼─┼─┤
  │ │·│o│·│·│
  └─┴─┴─┴─┴─┘

  o ➔ fiche orange
  · ➔ pin inutilisé
    ➔ espace vide (sans pin)

Enfin, il faut encore brancher les fiches restantes sur le header dual-USB. Étant donné que ce header contient deux fois les pins nécessaires a un branchement USB, il est possible de brancher les cables de plusieurs façons.

   Dual-USB
  ┌─┬─┬─┬─┬─┐
  │b│B│v│n│·│
  ├─┼─┼─┼─┼─┤
  │·│·│·│·│ │
  └─┴─┴─┴─┴─┘

  b ➔ fiche bleue
  B ➔ fiche Blanche
  v ➔ fiche verte
  n ➔ fiche noire
  · ➔ pin inutilisé
    ➔ espace vide (sans pin)

Tous les branchements étant effectués, il faut maintenant remonter la bête (attention a ne pas déranger les branchements avec les antennes Wifi, par exemple), la brancher, et vérifier que tout démarre bien. Il faut aussi changer un paramètre dans le BIOS intel : dans Power➔Secondary Power Settings, il faut que “Deep S4/S5” soit désactivé. Ceci permettant a la connection HDMI-CEC de démarrer et le NUC.

Ne reste plus ensuite qu’a installer un système digne de ce nom dessus!

SSL - STARTTLS

Wxcafe — Sat, 16 May 2015 02:00:00 +0200

Le chiffrement SSL pour les services en ligne est un problème relativement récent, par rapport a l’histoire d’Internet. Sa mise en place pose problème : les protocoles existants ne s’accommodent qu’assez mal de recevoir soudainement un flot de données chiffrées, mais développer de nouveaux protocoles est complexe et n’apporte rien d’intéressant. Pour palier a ce problème, deux solutions sont apparues.

Le première consiste à faire écouter les services sur un autre port, dans un tunnel SSL. De cette façon, le service existant écoute normalement, mais il ne répond pas directement aux requêtes. A la place, un tunnel SSL est mis en place, et les requêtes et les réponses passent dans le tunnel (ou elles apparaissent donc chiffrées pour l’extérieur). Cela permet de proposer un service chiffré en modifiant de façon minimale le programme, au prix de devoir aussi changer tous les clients, et de devoir les orienter sur un autre port.

L’autre approche qui a été utilisée est une approche d’upgrade. La communication commence en mode non chiffré, puis le client demande l’upgrade de la connexion vers le mode chiffré s’il le supporte, les deux machines machines font un handshake SSL et la communication continue a travers le tunnel SSL. Le service peut continuer a écouter sur son port habituel, et seuls les clients capables de passer en SSL le feront, ce qui permet de faire la “mise a jour” en douceur.

Il est souvent demandé quelle est la meilleure méthode pour mettre en place un service – laisser un port pour le SSL et un pour le trafic non chiffré, ou bien un seul, avec STARTTLS, qui upgrade les connexions si nécessaire.
La réponse est que STARTTLS est plus interessant, pour plusieurs raisons. Tout d’abord, il permet de n’utiliser qu’un seul port : ça permet de simplifier la configuration du firewall. En plus de ça, il permet aux clients “anciens” (ceux qui ne supportent pas SSL, donc ceux qui devraient être changés) de toujours se connecter, même si cela signifie que leurs informations seront transmises en clair. Surtout, il permet d’éviter aux utilisateurs d’avoir a configurer leurs clients. Si le client supporte le chiffrement, il l’activera de lui même s’il voit qu’il est disponible.
Bref, mettez en place du STARTTLS, et pas du SSL. C’est mieux pour la sécurité de tout le monde.

Docker et les ebooks sur Twitter

Wxcafe — Sat, 28 Feb 2015 14:11:00 +0100

Vous avez peut être déjà entendu parler de Docker. Si ce n’est pas le cas, voila les bases : Docker est un système de containers. Les containers sont une forme particulière de virtualisation, ou le kernel n’est pas virtualisé, mais ou les processus du système hôte sont séparés de ceux des systèmes invités. Cela est possible depuis longtemps sous FreeBSD avec les Jails, mais n’est devenu possible sous linux que récemment grâce aux cgroups, qui permettent justement de séparer des groupes de processus. Le principe de Docker est donc d’avoir une machine hôte sur laquelle s’exécutent plusieurs conteneurs Dockers, chacun séparé des autres et de l’hôte, mais utilisant tous le même kernel. Cela pose quelques questions en terme de sécurités, puisque la séparation est bien plus fine qu’avec de la virtualisation classique. En effet, ici, en trouvant un exploit kernel, un attaquant aurait potentiellement la capacité de remonter jusqu’à l’hôte, puisqu’il n’est pas vraiment séparé des invités.

Quoi qu’il en soit, Docker permet donc de virtualiser a moindre coût des systèmes GNU/Linux. “Mais pourquoi utiliser Docker, dans ce cas”, vous demandez-vous peut être, “puisque Xen peut faire la même chose, et plus (notamment, Xen est capable de virtualiser autre chose que GNU/Linux)?”. Et bien c’est très simple : Docker apporte la simplicité de déploiement d’applications. Les conteneurs Dockers peuvent être décrit en un fichier, nommé Dockerfile, qui permet de répliquer un conteneur en quelques minutes sur un autre hôte, en une commande. Le Docker Hub permet aussi de récupérer rapidement et facilement un grand nombre d’images déjà configurées.

Maintenant que nous avons expliqué rapidement ce qu’était Docker, voyons le rapport avec les ebooks et Twitter.

Les comptes dits “ebooks” (le nom vient a l’origine de horse_ebooks, voir ici pourquoi) sont des bots twitter utilisant des Chaines de Markov, avec les tweets d’un utilisateur “source” comme corpus, pour produire des tweets ressemblant a ceux de l’utilisateur source. Nous allons voir maintenant comment en installer un.

C’est, comme disent certaines personnes, “fun”.

Il existe de nombreuses librairies écrites pour créer ce genre de bots, cependant dans ce cas nous nous concentrerons sur celle-ci, qui est une lib ruby créée par @m1sp, qui gère pour nous a la fois l’API twitter et la génération des messages.

Cependant, cela n’explique toujours pas le lien avec Docker. Ce lien est très simple : nous utilisons un container pour faire tourner les bots. Depuis la version 3, la gem twitter_ebooks permet de faire tourner plusieurs bots dans une seule instance. Cependant, il est toujours plus sûr d’isoler les bots, et les containers dockers permettent de les déployer sur n’importe quelle machine (celleux qui ont déjà tenté de mettre en place une application basée sur ruby sauront le problème que cela pose habituellement). Pour ce faire, j’ai créé un repo github qui contient toutes les pièces nécessaires pour mettre cela en place : le bot en lui même, les deux Dockerfiles, etc.

Le fonctionnement du bot est simple : après avoir installé la gem twitter_ebooks, vous archivez le corpus de l’utilisateur source avec ebooks archive <username> <filename> (c’est du json) , puis vous convertissez le json en fichier utilisable par le bot : ebooks consume <filename>. Cela fait, démarrer le bot revient a lancer le container : docker run -d <container name> Pour plus d’informations, allez voir la documentation Docker

Bien entendu, dans l’idéal il faudrait mettre a jour les corpus de chaque utilisateur régulièrement. Cela est très simple a mettre en place avec un simple script cron :

00 00 * * *    /usr/local/bin/ebooks archive username /usr/local/ebooks/main/corpus/username.json >> /var/log/ebooks/update.log 2>&1
00 05 * * *    cd /usr/local/ebooks/main/ && /usr/local/bin/ebooks consume corpus/username.json >> /var/log/ebooks/update.log 2>&1
00 10 * * *    docker rm -f bots >/dev/null 2>&1
00 15 * * *    docker rmi bots  > /dev/null 2>&1
00 20 * * *    cd /usr/local/ebooks/main/ && docker build --rm -t bots . >> /var/log/ebooks/build.log 2>&1
00 25 * * *    docker run -d --name bots bots >> /var/log/ebooks/run.log 2>&1

Les 5 minutes entre chaque commande sont laissées pour empécher que deux commandes ne s’executent en même temps.

Et voila, vous avez un container Docker qui fait tourner une application en ruby toute sale, et votre système hôte reste propre. Bien sûr, ce n’est qu’un exemple des possibilités de Docker : par exemple, on peut aussi faire tourner des applications “usuelles” dedans, puisque l’overhead de Docker est minimal, et beaucoup d’autres applications existent.

SSL ou la sécurité sur l'internet

Wxcafe — Fri, 30 May 2014 08:25:00 +0200

Disclaimer: Ce billet est écrit après le visionnage de la conférence de Moxie Marlinspike suivante: More Tricks for Defeating SSL, présentée a la DefCon 17 (en 2011), et la lecture du billet suivant: A Critique of Lavabit, ce qui peut avoir l’effet de rendre légèrement parano. Si vous considérez que c’est le cas ici, veuillez ne pas tenir compte de ce billet (et vous pouvez dès a présent dire coucou aux différentes personnes qui écoutent votre connection)

Si vous venez ici souvent (vous devriez), et que vous utilisez SSL pour vous connecter a ce site (vous devriez, vraiment, dans ce cas), vous avez peut être remarqué quelque chose récemment : il se trouve que le certificat qui permet de desservir ce site a changé.

Cela fait suite aux évènements évoqués dans le Disclaimer, mais aussi a des doigts sortis d’un endroit particulier du corps de l’admin/auteur de ce “blog”, qui a pris enfin les 5 minutes nécessaires a la compréhension superficielle du fonctionnement de SSL, et les 10 nécessaires a la mise en place d’un système fonctionnel utilisant cette compréhension récemment acquise.

Bref, le certificat a changé. Mais de quelle façon, vous demandez vous peut être (ou pas, mais bon, je vais expliquer de toute façon). Et bien c’est très simple : il existait auparavant un certificat pour wxcafe.net, un pour paste.wxcafe.net, un pour mail.wxcafe.net, etc… Bref, un certificat différent pour chaque sous-domaine.

Il s’avère que c’est a la fois très peu pratique a utiliser (les utilisateurs doivent ajouter chaque certificat a leur navigateur séparément, chaque changement de sous-domaine conduit a un message d’erreur, etc) et pas plus sécurisé que d’avoir un seul certificat wildcard. J’ai donc généré un certificat pour *.wxcafe.net hier, et il sera dorénavant utilisé pour tous les sous-domaine de wxcafe.net; et un certificat pour wxcafe.net, qui ne matche pas *.wxcafe.net, et qui sera donc utilisé… bah pour wxcafe.net.

Il serait préférable de faire des redirections automatiques des adresses http vers les adresses https, cependant, étant donné que le certificat est self-signed, il me semble préférable que l’arrivée sur le site ne commence pas par une page firefox disant “Something’s Wrong!”, et ces redirections ne seront donc pas mises en place.

De plus, après la lecture de l’article de blog sur Lavabit dont le lien est plus haut, il semble intéressant (et assez important) de faire en sorte que le serveur utilise en priorité (et si possible, uniquement) des ciphers supportant PFS, soit EDH et EECDH (Ephemeral Diffie-Helmann et la version Elliptic Curves de ce même algorithme). Cela permet de faire en sorte que toutes les communications avec ce serveur soient future-proof, c’est a dire que, même si quelqu’un récupérait la clé privée, elle ne serait pas utile pour déchiffrer les communications passées.

Bon, maintenant que les explications basiques sont faites, voyons l’implémentation :
Pour générer la clé, tout d’abord, il convient d’utiliser les commandes suivantes:

sudo openssl genrsa -out example.key 4096
# nous utilisons ici une clé de 4096 bits, la taille est laissée a votre appréciation
sudo openssl req -new -key example.key -out example.csr
# OpenSSL va ici vous demander de nombreuses informations, "Common Name" devant contenir le FQDN
sudo openssl X509 -req -days 1095 -in example.csr -signkey example.key -out example.crt
# enfin, nous générons la clé, d'une durée de vie de 3 ans

Bien entendu, si vous voulez utiliser une clé wildcard, il vous faut préciser *.example.com comme common name. Une fois la clé générée, il faut dire aux différents services de l’utiliser, et de n’utiliser que des ciphers PFS. La méthode dépend donc du service. Je vais lister ici les methodes pour quelques services que j’utilise :

apache :

# /etc/apache2/mods_enabled/ssl.conf
# [...]
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
  EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
# [...]
# /etc/apache2/sites-enabled/default-ssl
# [...]
SSLEngine on
SSLCertificateFile /etc/certs/example.com.crt
SSLCertificateKeyFile /etc/certs/example.com.key
# [...]

nginx :

# /etc/nginx/nginx.conf 
# [...]
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
  EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
# [...]
# /etc/nginx/sites-enabled/default-ssl
# [...]
ssl on;
ssl_certificate /etc/certs/example.com.crt
ssl_certificate_key /etc/certs/example.com.key
# [...]

prosody (jabber) :

# tout d'abord, lancez la commande suivante :
sudo openssl dhparam -out /etc/prosody/certs/dh-2048.pem 2048
# ensuite, pour chaque VirtualHost dans /etc/prosody/prosody.conf :
ssl = {
  dhparam = "/etc/prosody/certs/dh-2048.pem";
  key = "/etc/certs/example.com.key";
  certificate = "/etc/certs/example.com.crt";
}
# la cipher suite de prosody utilise par défaut EDH et EECDH

postfix (email) :

# /etc/postfix/main.cf
# [...]
smtpd_tls_cert_file = /etc/certs/example.com.crt
smtpd_tls_key_file = /etc/certs/example.com.key
tls_preempt_cipherlist = yes
smtpd_tls_eecdh_grade = strong
smtdp_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, MD5, LOW, 3DES, EXP, PSK, SRP, DSS
smtpd_tls_security_level = encrypt
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_use_tls = yes
# [...]

dovecot (imap) :

# /etc/dovecot/dovecot.conf 
# [...]
ssl_cert = </etc/certs/example.com.crt
ssl_key = </etc/certs/example.com.key
ssl_cipher_list = HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL

Voila. Pour d’autres protocoles/services, je vous invite a RTFM^W vous reporter au manuel approprié.

Cela étant dit, je conseille a tout le monde d’aller voir la conférence dans le disclaimer, et tant qu’a faire la conférence du même hacker SSL and the future of Authenticity qui parle de son implémentation d’une technologie “remplaçant” le système de CAs qui existe actuellement.

Redesign du blog, etc

wxcafe — Wed, 12 Jun 2013 19:14:00 +0200

Comme vous avez pu le remarquer, ce blog a “un peu” changé récemment.

Du coup, expliquons. J’ai récemment monté serverporn, et ai par la même occasion découvert pelican. J’ai tout de suite accroché a ce générateur de site statique en python, du fait de son efficacité, de sa facilité d’utilisation et de sa grande customisation. En gros, pelican est un logiciel qui prend des fichiers markdown ou reStructuredText, les passe a la moulinette d’un “thème” constitué de templates pour les fichiers html et l’organisation du projet et d’une partie “statique” contenant le css, et les autres fichiers nécessaires au projet, et en fait des pages html.

Globalement, un thème est constitué ainsi :

thème
├── static
│   ├─ css
│   │  └─ [css files]
│   ├─ img
│   │  └─ [image files]
│   └─ js
│      └─ [javascript files]
└── template
    ├─ base.html
    ├─ index.html
    ├─ page.html
    ├─ [...]
    └─ article.html

Sachant que les fichiers .html sont en réalité des fichiers suivant la syntaxe django, et utilisent des variables particulières telles {{ article.content }}, par exemple. La syntaxe complète est très bien documentée dans la doc de pelican.

L’un des grands avantages de pelican est aussi la facilité qu’il offre quand a la mise a jour du blog.
En effet, il offre un système de Makefiles permettant, grâce a de nombreuses cibles de compilation, de régénérer le site entier, de ne générer que les fichiers modifiés depuis la dernière génération, de générer uniquement les fichiers n’existant pas la dernière fois, etc… La gestion du projet en devient donc très simple, puisque après avoir écrit un article, il suffit de faire un make html pour mettre a jour le blog.

De plus, le système de wordpress commençait a ne plus me convenir, du fait du manque de customisation, du fait que ça soit du PHP (beurk), etc. La, avec pelican, je contrôle bien plus ce qui est mis sur le serveur (puisque c’est moi qui ait modifié les templates et le css), c’est lisible (puisque c’est du python, par opposition au PHP…), et c’est plus “efficace”. Le markdown est très pratique, je peux utiliser mon éditeur de texte de prédilection pour faire les articles, je n’ai pas besoin d’un accès continu au net, bref, c’est plus efficace.

En ce qui concerne les points négatifs :

Perte des commentaires: Je vous propose de vous référer a l’article de Gordontesos ici quand a mon avis sur ce sujet.
Perte du bouton flattr: Il va bientôt être remis, c’est juste un manque de temps de ma part, mais vu que toutes les pages passent par les mêmes templates, c’est assez facile a faire.
Perte du spam: Pourquoi c’est dans les points négatifs, ca?
Temps d’adaptation et d’appréhension du système: Oui, pendant encore un certain temps, il y aura des glitchs plus ou moins réguliers sur le blog, c’est parce que j’apprend a me servir de ce système et que j’apprend du css et du html. Ca arrive, ca passera, mais dans tous les cas ca me permet d’apprendre plein de choses, donc je mets plutôt ca dans la catëgorie positive.

Voila, c’est mon retour d’expérience sur pelican. A plus.

Update

Wxcafe — Sat, 05 Jan 2013 18:32:00 +0100

Juste une petite note pour annoncer le prochain article, consacré a la fabrication d’une PirateBox basée sur un Raspberry Pi. Voila, a bientôt sur le blog!