wxcafe/blog-source
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

long time no see

Browse Source
This commit is contained in:
Wxcafé (Clément Hertling) 2015-12-14 20:20:16 +01:00
parent 975c2f275b
commit 01cdaebdb4
4 changed files with 298 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

165
content/let's_encrypt.md Normal file
View File

@ -0,0 +1,165 @@
Title: Let's Encrypt, enfin
Date: 2015-12-13T18:48+0100
Author: Wxcafé
Category: Tutoriel
Slug: lets-encrypt-enfin
Vous avez peut être vu que ce blog, entre autres sites que j'administre, n'est
disponible depuis quelques jours qu'en HTTPS, et avec un certificat valide. Bon,
si vous êtes là, vous avez déjà entendu parler de Let's Encrypt, mais pour les
deux trois du fond on va résumer:
LE est une nouvelle autorité de certification (ceux qui valident les certificats
SSL), basée sur une organisation, et dont le but est de fournir des certificats
valides, automatiquement et gratuitement. Leur certificat racine est signé par
IdenTrust, et est donc considéré valide par tous les navigateurs modernes.
Bon, maintenant qu'on est tous au même point, voyons comment ça marche. Depuis
dix jours LE est ouvert en bêta publique, donc il n'est plus nécessaire de
préciser les domaines pour lesquels on veut un certificat sur un formulaire,
comme c'était le cas pendant la période de bêta fermée. Le système qui est
utilisé repose sur le protocole ACME (Automatic Certificate Management
Environment), qui automatise complètement la signature des certificats. Du coup,
les certificats que délivre LE ne sont valides que 90 jours, ce qui serait super
chiant avec une autorité de certification classique, mais qui la veut simplement
dire qu'il faut mettre un cron en place.
Bref, comment mettre en place vos certificats? On va faire ça sans trop modifier
vos sites, et en automatisant au maximum. LE utilise, dans son système par
défaut, un fichier sur le site web, dont le serveur de certification vérifie
l'existence lors de la requête (si le fichier est présent avec le bon contenu,
c'est que le client tourne bien sur ce domaine, et donc que la personne qui
a demandé le certificat contrôle bien le domaine). Ce fichier est situé dans un
dossier dans la racine, `.well-known`. Plutôt que de se faire chier a gérer ce
dossier pour tous nos vhosts nginx, on va simplement créer un alias vers un
dossier commun sur le système de fichier, que tous les vhosts partagerons, et
qui permettra aussi de valider tous les domaines pour lesquels on veut un
certificat à la fois (avec un AltName) (sur un seul serveur, par contre. Enfin
si vous voulez vraiment vous pouvez faire des mounts cross-serveurs (avec du
sshfs ou des trucs du genre), mais c'est un peu sale quand même. Et faudra quand
même distribuer le certificat après, donc bon...).
Donc, on va rajouter ça dans nos blocs `server` :
```shell
location /.well-known {
alias /srv/letsencrypt/.well-known;
}
```
(bien sûr il faut créer le dossier, hein.)
Après, on `git clone https://github.com/letsencrypt/letsencrypt`, dans `/opt/` ou
dans `/usr/local/`, peu importe, on le clone quelque part, et on cd dans le
dossier en question. Une fois là, on demande un certificat :
```shell
sudo ./letsencrypt-auto certonly \
-a webroot \
--webroot-path /srv/letsencrypt/ \
-d <domaine> \
-d <altName1> \
-d <altName2> \
--server https://acme-v01.api.letsencrypt.org/directory
```
Normalement, maintenant, on a un certificat valide dans
`/etc/letsencrypt/live/<domaine>/`. Reste à configurer nginx pour qu'il serve
nos sites en https en utilisant notre nouveau certificat. Perso, j'utilise une
template qui ressemble à ça :
```shell
server {
listen 80;
listen [::]:80;
server_name SERVERNAME;
return 302 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem;
ssl_dhparam /etc/nginx/dhparams.4096;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
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";
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload";
root SERVERROOT;
index index.html index.htm;
server_name SERVERNAME;
server_tokens off;
client_max_body_size 5m;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location /.well-known {
alias /srv/letsencrypt/.well-known;
}
location / {
try_files $uri $uri/ =404;
}
}
```
Alors c'est pas /tout à fait ça/ d'un point de vue parano du TLS (genre je
devrais désactiver TLS 1.0 et EECDH+aRSA+RC4, notamment) mais ça marche pas trop
mal et c'est plus compatible comme ça (mon telephone est sous Android 4.4, donc
je suis content d'avoir encore TLS 1.0 par exemple).
Vous pouvez ajouter votre domaine à la liste préloadée dans Chrome/ium, Firefox,
IE, Edge, Safari, le Tor Browser Bundle, etc...
[ici](https://hstspreload.appspot.com/) (oui ça fait clairement site de
phishing, mais apparemment c'est serieux...)
Enfin, il nous faut un renouvellement automatique, puisque notre certificat ne
sera valide que 90 jours. On va utiliser un cron tout con, avec un script :
```shell
00 01 */14 * * /usr/local/bin/cert-renew 2>&1 | mail -s "certificates renewal report" <votre email>
```
(oubliez pas que ça doit aller dans le crontab du root)
Et le script qui va bien :
```shell
#!/bin/bash
if [[ $UID != 0 ]]; then
echo "please run as root"
exit 1
fi
cd /opt/letsencrypt/
git pull 2>&1 >> /dev/null
# Renewing the cert
./letsencrypt-auto certonly \
-a webroot --webroot-path /srv/letsencrypt \
-d <domaine> \
-d <altName1> \
-d <altName2> \
--server https://acme-v01.api.letsencrypt.org/directory \
--renew \
2>&1
systemctl restart nginx
exit 0
```
Notez bien le `--renew` qui spécifie qu'on renouvelle le certificat, le `git pull`
qui met à jour le client, et le `systemctl restart nginx` qui prend en compte le
nouveau certificat automatiquement
Et puis voilà, normalement avec ça vous devriez pouvoir chopper des certificats
valides. C'est plutôt cool, en pratique.
Merci Let's Encrypt

132
content/openwrt-usbnet.md Normal file
View File

@ -0,0 +1,132 @@
Title: OpenWRT, l'USBNet, et l'histoire des 4Mo
Date: 2015-10-16 10:27
Author: Wxcafe
Category: Hacking
Slug: openwrt-usbnet
Donc, j'ai récemment obtenu un [TP-Link
TL-MR12U](http://www.dx.com/p/tp-link-tl-mr12u-portable-5200mah-mobile-battery-3g-router-white-231188),
qui est vendu comme "routeur 3G portable", mais qui est en réalité une grosse
batterie avec une antenne wifi, un port USB, et un port Ethernet. Perso, ça me
va, vu que je comptais de toute façon pas prendre un deuxième abonnement 3G
juste pour ce truc là (surtout vu la couverture 3G qu'on se tape en France...)
Bref, tout ça pour dire : quand j'ai reçu ce truc, j'ai tout de suite commencé
par y installer OpenWRT (parce que de 1, je parle pas chinois, et de 2, j'aime
bien avoir des firmwares corrects sur mes routeurs). Bon, c'est super simple, il
suffit de chopper ce fichier
\[binaire\] [la](http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/openwrt-15.05-ar71xx-generic-tl-mr12u-v1-squashfs-factory.bin),
et de trouver la page d'update (pas forcément super simple en chinois, mais avec
un peu de temps, ça se fait. C'est celle avec un bouton upload). Ensuite on
upload l'image sur le bouzin, et c'est parti. Pas de signatures, pas de
vérifications, osef total, mais bon pour le coup ça m'arrange.
Une fois ceci fait, je me trouva bien démuni de ne pas pouvoir utiliser le
partage de connexion USB de mon intelliphone android, car l'image OpenWRT par
defaut ne comprend pas USBNet, et ne peut donc pas créer de réseau sur de l'USB.
Qu'à cela ne tienne, me dis-je! Je vais l'installer!
Je courra donc installer le package grâce à `opkg`. Las! Le système n'avait plus
de place.
... Atta. Le système avait plus de place? J'ai encore rien mis dessus!
Eh bah ouais. Il se trouve que TP-Link, en 2015, trouve que 4Mo de flash sur un
routeur, c'est largement suffisant, et que de toute façon personne aura jamais
besoin de plus.
Serieux, mettre 8Mo c'était tellement plus cher? u_u
Bon, bref, je vais pas m'étendre la dessus. J'ai décidé de saisir mes petits
bras, et de tenter de pousser bien fort pour convaincre OpenWRT qu'il était tout
a fait possible de faire rentrer à la fois le système de base avec LuCi, uhttpd,
un serveur DHCP, etc; et USBNet, dans 4Mo. Ça à pas été vraiment facile, et j'ai
du virer pas mal de trucs, mais... ça fonctionne!
Bon, alors, comme je suis quelqu'un de sympa, je vais vous filer à la fois le
fichier de config et l'image finale. Si vous voulez pas utiliser une image qui
vient d'un mec que vous connaissez pas, vous pouvez toujours la rebuilder vous
même. Mais avant ça, je vais vite fait expliquer ce qui est dans l'image et ce
qui n'y est pas
Alors, pour faire rentrer tout ça, vous vous doutez que j'ai du faire quelques
concessions. J'ai donc viré tout ce qui a trait à *PPP*, *PPPoE*, le client
*DHCPv6*, tous les *outils de debug*, quelques *fonctionnalités de busybox*, et
bien sûr *opkg*. Dans ce qui à été ajouté, simplement ce qui est nécessaire au
fonctionnement de *l'USBNet*.
Une petite modification doit être effectuée pour que le tout fonctionne : le
fichier `package/feeds/luci/luci/Makefile` doit être modifié pour que la
dépendance sur `luci-proto-ppp` ne soit plus présente. Ainsi, on passe de
```makefile
LUCI_DEPENDS:= \
+uhttpd +uhttpd-mod-ubus +luci-mod-admin-full +luci-theme-bootstrap \
+luci-app-firewall +luci-proto-ppp +libiwinfo-lua +IPV6:luci-proto-ipv6
```
à
```makefile
LUCI_DEPENDS:= \
+uhttpd +uhttpd-mod-ubus +luci-mod-admin-full +luci-theme-bootstrap \
+luci-app-firewall +libiwinfo-lua +IPV6:luci-proto-ipv6
```
Une fois que c'est fait, ça devrait mieux marcher (et ça sauve un peu
d'espace...)
Bon. Le fichier de config est
[là](http://pub.wxcafe.net/static/openwrt/tl-mr12u/config), l'image finale est
[là](http://pub.wxcafe.net/static/openwrt/tl-mr12u/openwrt-15.05-wx-ar71xx-generic-tl-mr12u-v1-squashfs-factory.bin),
et j'ai une petite surprise.
Bien sûr, le switch situé sur le côté du TL-MR12U ne fonctionne pas sous
OpenWRT de base, parce que c'est un truc lié au hardware et que du coup c'est
assez compliqué à gérer sur une base de matos aussi grande que celle d'OpenWRT.
Bah j'ai à peu près trouvé comment le faire fonctionner.
Voilà le code :
```shell
#!/bin/sh
if [ $ACTION == "released" ]; then
if [ $BUTTON == "BTN_0" ]; then
# Position is 3G
logger "slider 3G"
elif [ $BUTTON == "BTN_1" ]; then
# Position is Router
logger "slider Router"
fi
elif [ $BUTTON == "BTN_1" ] || [ $BUTTON == "BTN_0" ]; then
if grep -qe "sw1.*in hi" /sys/kernel/debug/gpio\
&& grep -qe "sw2.*in hi" /sys/kernel/debug/gpio; then
# Position is AP
logger "slider AP"
fi
fi
```
Et ça va dans `/etc/hotplug.d/button/00-buttons` (créez le chemin, il existera
pas à la base). Du coup là comme ça ça fait rien, ça loggue juste les events.
Mais comme vous êtes pas cons vous avez peut être deviné qu'on pouvait très bien
activer l'USBNet que quand l'interrupteur est en position 3G, le wifi et
l'ethernet quand il est en position AP, et juste la batterie quand il est en
position Router. Par exemple.
Tiens, d'ailleurs. Pour activer le partage de connexion, suffit pas d'ajouter le
support USBNet. Il faut aussi configurer le système pour qu'il demande un lease
DHCP, toussa. Du coup vous pouvez (peut être, j'ai pas testé) le faire par LuCi,
mais sinon vous pouvez le faire en CLI :
```shell
uci del network.wan
uci set network.wan=interface
uci set network.wan.ifname=usb0
uci set network.wan.proto=dhcp
uci commit network
ifup wan
```
Et pouf, ça marche.
Voilà. Amusez vous bien avec votre grosse batterie portable, qui fait maintenant
point d'accès wifi/partage de connexion 3G/whatever.

16
themes/bootstrap2/templates/base.html
View File

@ -9,21 +9,7 @@
<!-- Le styles -->
<link rel="stylesheet" href="{{ SITEURL }}/theme/css/extra.css" type="text/css" />
<link rel="stylesheet" href="{{ SITEURL }}/theme/css/bootstrap.css" type="text/css" />
<link href='http://fonts.googleapis.com/css?family=Oswald&subset=latin,latin-ext' rel='stylesheet' type='text/css'>
<script type="text/javascript">
/* <![CDATA[ */
(function() {
var s = document.createElement('script');
var t = document.getElementsByTagName('script')[0];
s.type = 'text/javascript';
s.async = true;
s.src = '//api.flattr.com/js/0.6/load.js?'+
'mode=auto&uid=wxcafe&button=compact&popout=0';
t.parentNode.insertBefore(s, t);
})();
/* ]]> */
</script> <!-- flattr button loader -->
<link href='//fonts.googleapis.com/css?family=Oswald&subset=latin,latin-ext' rel='stylesheet' type='text/css'>
<style type="text/css">
body {
padding-top: 60px;

11
themes/bootstrap2/templates/sidebar.html
View File

@ -17,17 +17,6 @@
<!-- Social links -->
{% if SOCIAL %}
<li class="nav-header"><h4><i class="icon-exchange"></i> social</h4></li>
<a class="FlattrButton" style="display:none;"
title="{{ SITEURL }}"
style="padding-top: 10px;"
rel="flattr;
url:{{ SITEURL }};
title:{{ SITEURL }};
button:compact;
popout:0;
uid:wxcafe;
category:blog;"
href="{{ SITEURL }}">flattr</a>
{% for name, link, icon in SOCIAL %}
<li><a href="{{ link }}"><i class="icon-{{ icon }} icon-large"></i> {{ name }}</a></li>
{% endfor %}