Les notes d'Ailothaen

Les conteneurs, une nouvelle fonctionnalité très intéressante de Firefox

⋅ Commentaires fermés

On le sait déjà, Firefox est un excellent navigateur : très personnalisable, simple d'utilisation et plutôt rapide, et qui a une bonne éthique sur le pistage des internautes (contrairement à Chrome)

Dans cet article, j'aimerais parler d'une nouveauté dans Firefox, qui est encore actuellement en bêta, mais qui mérite selon moi un petit coup de projecteur tellement elle peut parfois être utile.
Il s'agit de la possibilité d'ouvrir des « conteneurs », c'est-à-dire d'ouvrir des onglets qui sont totalement indépendants les uns des autres (c'est-à-dire, qui ne partagent pas leurs cookies, leur webStorage...)

Comment activer cela ?

Comme elle est encore en bêta, la fonctionnalité n'est pas encore activée nativement. Cependant, si vous avez Firefox 50 (ou plus), elle est incluse dans le navigateur (c'est juste qu'elle n'est pas activée)

Pour l'activer, il faut se rendre dans le about:config (c'est là où toutes les variables paramètres de Firefox sont accessibles) et de passer les variables privacy.userContext.enabled et privacy.userContext.ui.enabled à true :

Activation

Après cela, vous aurez normalement une icône "Onglet conteneurs" qui va apparaître dans le menu de personnalisation. Vous pouvez la faire glisser où vous voulez (dans le menu, ou quelque part dans l'interface)

i

Il y aura aussi dans le menu du clic-droit, lorsque vous cliquez sur un lien, la possibilité d'ouvrir ce lien dans un conteneur.

Mais à quoi ça sert en fait ?

Lorsque vous naviguez sur Internet, beaucoup de sites stockent des informations sur votre navigateur, comme les cookies, les sessions ou le webStorage. En eux-mêmes, ces moyens ne sont pas « dangereux ».
Le problème est que certains sites et régies publicitaires peuvent les exploiter pour des objectifs publicitaires ou de tracking (par exemple, sur toutes les pages qui intègrent un bouton Like de Facebook, il y a un tracker Facebook, donc ce dernier sait que vous êtes allé sur cette page et peut donc retenir ça).

De plus, sans forcément parler de tracking, il est parfois bon pour une quelconque raison d'avoir à connecter deux comptes différents sur le même site, mais ce n'est normalement pas possible car la session est « partagée » par tout le navigateur, et se connecter dans un 2ème compte dans le même navigateur déconnectera forcément le 1er compte.

Pour contrer ce problème, il est possible de passer en navigation privée. Cependant, ce n'est pas toujours très pratique : les sessions ne sont pas stockés, ce qui veut dire qu'on doit se reconnecter aux sites à chaque fois qu'on ouvre une session (d'autant plus qu'il n'y a pas de complétion automatique des champs, étant donné qu'ils ne sont pas mémorisés en navigation privée). L'historique n'est aussi pas enregistré, ce qui est dommage car on peut parfois avoir envie de retrouver un site intéressant.

C'est pour cela que les conteneurs sont très utiles : ils permettent de faire tout cela. C'est un peu comme si on avait plusieurs navigateurs différents.

Comment ça s'utilise ?

Voici un exemple : je vais ouvrir ici un conteneur « Personnel » (il n'y en a actuellement que 4, qui ont des noms fixés, mais il sera sûrement possible de créer ses propres conteneurs avec couleur/nom/icône personnalisés à l'avenir - EDIT : c'est maintenant le cas depuis Firefox 52) :

Ouverture

Un nouvel onglet conteneur va alors s'ouvrir ; celui ci sera différenciable des autres par le fait qu'il aura une petite bande bleue au dessus de l'onglet. L'intitulé du conteneur (« Personnel ») est aussi marquée à droite dans la barre d'adresses.
Nous allons tester cela : dans mon onglet conteneur, je vais aller sur danstonchat.com et me connecter sur mon compte.

i

L'icône des messages qui apparaît en haut à droite de la barre du site permet de voir que je suis bien connecté.

Maintenant, pour une raison quelconque, je veux avoir un onglet où mon compte est déconnecté, mais je veux tout de même garder mon compte connecté dans mon onglet conteneur.
Pour cela, il suffit donc tout simplement d'ouvrir un autre onglet normal (ou un conteneur d'un autre type) : comme les sessions et cookies sont séparés, le site ne me reconnaîtra pas.

i

Sur mon onglet normal, je ne suis pas connecté : l'icône des messages n'apparaît pas. Mais je reste quand même connecté dans mon onglet bleu d'à côté !

Ce système est donc vraiment sympa à utiliser. Toutefois attention, ce n'est pas une protection absolue : votre adresse IP et la « signature » de votre navigateur (extensions installées, numéro de version, système d'exploitation utilisés...) restent les mêmes ; cependant, à ma conaissance, ces éléments sont beaucoup moins utilisés que les cookies et le tracking car ils sont moins précis et moins pratiques à utiliser. (Et puis, on cherche juste à échapper au tracking ici, si c'est pour passer inaperçu aux yeux de la CIA ce n'est pas cela qu'il faut utiliser 😉 )

Si vous être intéressé, vous pouvez lire la page wiki dédiée de Firefox et suivre les évolutions de la fonctionnalité. (Un autre article également intéressant)

Mise en place de HTTPS sur Apache avec Let's Encrypt

⋅ Commentaires fermés

Le HTTPS est aujourd'hui très utilisé sur Internet, notamment sur les sites « sensibles », mais pas seulement : son usage se généralise aujourd'hui à tous types de sites. (dont le mien :p )
C'est une très bonne chose, car si le HTTPS sert surtout à chiffrer les communications entre un site et vous pour les rendre illisibles (on ne pourra pas lire les mots de passe que vous envoyez, par exemple), ce n'est pas sa seule fonction : il permet par exemple aussi de s'assurer de l'authenticité d'un site (c'est-à-dire vérifier que le site est bien celui-là et pas un frauduleux qui se fait passer pour lui)

Pour fonctionner, le HTTPS se base sur des certificats : pour faire très simple, ils permettent de signer l'échange entre deux parties afin de garantir la sécurité de la communication. Le protocole qui définit les règles pour tout cela s'appelle TLS (anciennement SSL).
(Si vous désirez en apprendre beaucoup plus, je vous renvoie vers cet article qui explique précisément son fonctionnement)

Les certificats sont délivrés par des autorités de certifications. Obtenir un certificat pour son site n'a cependant pas toujours été très facile, car ils sont en général coûteux (quelques centaines d'euros par an) et les démarches sont parfois complexes.

Il y a quelques temps, une nouvelle autorité de certification est apparue : nommée Let's Encrypt, elle a la particularité de délivrer des certificats gratuitement sur demande, qui sont voués à être reconnus partout.
Soutenue par de grands noms (Mozilla, EFF, Cisco), elle est aujourd'hui beaucoup utilisée sur les petits et moyens sites, et a permis une démocratisation du HTTPS. C'est donc celle-là que nous allons utiliser :)

Pour obtenir des certificats de Let's Encrypt, il existe plusieurs manières : certbot, acme-tiny... Nous allons, de notre côté, utiliser le script « acme.sh » qui est facile d'utilisation et bien fourni.

Installation de acme.sh

Le script s'installera dans le /home de l'utilisateur actuel (dans mon cas, il sera installé dans /home/ailothaen/.acme.sh/* ).
Je recommande de passer en root pour éviter d'éventuels problèmes de permission pendant que l'on va taper les commandes.

La procédure d'installation est très simple, il suffit juste de télécharger le script et de l'exécuter, ce qui lancera son installation :

root@ailoserv:~ # curl https://get.acme.sh | sh

Si vous n'avez pas curl (probable sur certains systèmes minimalistes) la commande classique wget marche aussi :

root@ailoserv:~ # wget -O -  https://get.acme.sh | sh

Une fois que tout cela est installé, nous avons donc dans notre dossier le script (que l'on va utiliser), ainsi que d'autres fichiers utiles.

root@ailoserv:~ # ls .acme.sh
account.conf acme.sh acme.sh.env deploy dnsapi

Vous pouvez déplacer le dossier si vous voulez le placer dans un dossier plus approprié. Pour ma part, je mets les scripts dans /etc/scripts, donc je l'ai placé dans /etc/scripts/acme.sh/*.

Générer un certificat

Comme le dit le readme du projet, il y a plusieurs méthodes pour générer des certificats : chacune a ses avantages et inconvénients.
Comme nous avons un serveur Apache, nous allons utiliser l'option --apache pour interagir avec le serveur Apache, et ainsi éviter d'écrire des fichiers un peu partout (l'option par défaut doit en effet écrire des dossiers à la racine du site web)

La commande pour générer notre certificat est la suivante :

root@ailoserv:/etc/scripts/acme.sh # ./acme.sh --issue --apache -d system42.fr -k 4096

où l'option -d est le nom de domaine du site, et où -k est le nombre de bits pour la clé RSA. (Aujourd'hui, les tailles généralement utilisées sont 2048, 3072 et 4096. Plus le nombre est élevé, plus la sécurité est élevée mais plus les échanges en seront ralentis. À savoir que l'ANSSI déconseille aujourd'hui l'usage du 2048 bits et conseille au moins du 3072.)
Il est possible de spécifier plusieurs noms de domaine en mettant plusieurs options -d à la suite. Cependant, à l'heure actuelle, Let's Encrypt ne supporte pas les wildcards (impossible donc de demander un seul certificat pour tous les *.exemple.fr...)

Notre certificat est donc généré, mais pour l'instant il se situe dans les dossiers de acme.sh. Pour le déplacer dans un dossier approprié (j'ai pour ma part fait un dossier /etc/apache2/sslcerts pour stocker les certificats, et chaque site a son dossier), il faut taper cette commande :

root@ailoserv:/etc/scripts/acme.sh # ./acme.sh --installcert -d system42.fr --certpath /etc/apache2/sslcerts/system42.fr/cert.pem --keypath /etc/apache2/sslcerts/system42.fr/key.pem --fullchainpath /etc/apache2/sslcerts/system42.fr/fullchain.pem --reloadcmd "service apache2 reload"

Trois fichiers seront dans notre répertoire :

  • cert.pem est le certificat ;
  • key.pem est la clé privée ;
  • fullchain.pem est un fichier qui inclut le certificat et la chaîne complète des autorités de certification.

Une petite précision sur ce dernier point : une autorité de certification, comme nous l'avons dit, sert à générer des certificats qui prouvent que le site avec lequel vous tentez de communiquer est bien le bon (cela évite les attaques de l'homme du milieu).
Mais l'autorité de certification peut également se faire compromettre : elle se fait donc à son tour approuver par une "grande" autorité de certification, appellée autorité racine.

Let's Encrypt étant une autorité relativement récente, son certificat n'est pas très répandu, et tous les navigateurs ne la connaissent pas. Par conséquent, si un navigateur qui ne connaît pas Let's Encrypt reçoit un certificat de Let's Encrypt, il ne lui fera pas confiance.

Il est cependant possible de fournir le certificat de Let's Encrypt et le certificat de son autorité racine (qui est largement reconnu partout) afin d'éviter ce genre de problème et d'avoir un certificat plus organisé. C'est ce que nous allons faire.

Activer le certificat dans son site

La configuration de HTTPS sur son site se fait au niveau du fichier de configuration du site, qui sur Debian se trouve dans /etc/apache2/sites-available.

Le fichier de notre site devrait ressembler à ça :

<VirtualHost *:80>
ServerName system42.fr
(autres directives...)
</VirtualHost>

Le port standard pour HTTPS étant le 443, il faut faire un copier/coller du bloc, où l'on mettra en plus les directives relatives au HTTPS. (C'est la seule chose qui changera).
N'oubliez pas de vérifier dans votre config Apache globale que Apache écoute bien sur le port 443 (normalement c'est déjà le cas)

<VirtualHost *:80>
ServerName system42.fr
(autres directives...)
</VirtualHost>

<VirtualHost *:443>
ServerName system42.fr
(autres directives...)

SSLEngine on
SSLCertificateFile /etc/apache2/sslcerts/system42.fr/fullchain.pem
SSLCertificateKeyFile /etc/apache2/sslcerts/system42.fr/key.pem
</VirtualHost>

Pour la directive SSLCertificateFile, nous écrivons ici le chemin complet (ou relatif, mais je ne vous le conseille pas) vers notre fichier qui contient la chaîne complète de certification. Quant à SSLCertificateKeyFile, nous précisons le fichier qui contient notre clé privée.

Le même bloc de configuration doit donc être répété deux fois, une fois pour la version HTTP et une autre pour la version HTTPS. Cependant, sachez qu'il est possible de faire des includes dans les fichiers de configuration : on peut inclure dans les deux blocs un fichier général qui contient toutes les directives non relatives à HTTPS, afin d'éviter de les dupliquer.

Faites un petit

root@ailoserv:/etc/apache2/sites-available # service apache2 reload

et normalement, c'est bon : votre site devrait maintenant implémenter HTTPS !

Il est possible de voir les détails de son certificat. On retrouve ici la chaîne de certification :

Automatiser le renouvellement du certificat

Le certificat que nous venons d'installer sera valide pour une durée de trois mois. Passé ce délai, il ne sera plus valide, et la connexion ne sera plus considérée comme sécurisée.
Nous allons donc faire un petit script qui s'exécutera tous les deux mois et qui lancera automatiquement les commandes pour le renouvellement des certificats.

Voilà le script que j'ai personnellement fait :

#!/bin/bash

# Renouvellement automatique des certificats ssl
# Doit être appellé avec un argument $1 (qui est le nom de domaine)

/bin/sh ./acme.sh/acme.sh --issue --apache -d $1 -k 4096 --force

/bin/sh ./acme.sh/acme.sh --installcert -d $1 \
--certpath /etc/apache2/sslcerts/$1/cert.pem \
--keypath /etc/apache2/sslcerts/$1/key.pem \
--fullchainpath /etc/apache2/sslcerts/$1/fullchain.pem \
--reloadcmd "service apache2 reload"

La variable $1 est le nom de domaine du site. Comme nous pouvons le voir, ce script exécute les commandes que nous avons tapées plus tôt...
L'option --force permet de générer le certificat même si le précédent n'est pas expiré (ce qui sera toujours le cas). Il remplacera le certificat actuel.

Une fois que le script a été écrit et placé au bon endroit, nous allons ajouter une tâche CRON (en tant que root) pour l'exécuter tous les deux mois :

30 0 1 2,4,6,8,10,12 * bash /etc/scripts/sslrenew.sh system42.fr

Pour cet exemple, le script s'exécutera à 00:30 tous les 1er février, avril, juin...

Pour aller plus loin

Et voilà ! HTTPS est maintenant utilisable sur votre site et est "maintenu" automatiquement.
Vous pouvez tester la "qualité" de votre connexion HTTPS sur ces deux sites : (1) (2).

Si je parle de cela, c'est car le petit cadenas vert que l'on peut voir, et qui témoigne que la connexion est sécurisée, n'est que la surface de l'iceberg : HTTPS fonctionne sur des algorithmes et protocoles cryptographiques qui évoluent avec le temps. Des algorithmes de chiffrement sont fréquemment cassés et connaissent des failles.

Par conséquent, il faudra vérifier de temps en temps sur un site ci-dessus que vos connexions HTTPS sont toujours de bonne qualité et non vulnérables aux récentes failles. Si vous obtenez une mauvaise note, il vous faudra sûrement mettre à jour votre serveur web et/ou modifier ses configurations afin de retirer ce qui peut causer des problèmes. (N'hésitez pas à regarder cet article dont j'ai déjà mis le lien plus haut pour en savoir plus)

« Les notes d'Ailothaen »

⋅ Commentaires fermés

Et c'est parti...

Mon ancien site perso étant très peu maintenu et difficile à maintenir, j'ai décidé de créer un petit blog qui servira de support pour écrire toutes les astuces et tutos que je pourrai donner sur tout ce qui touche de près ou de loin à l'informatique.
Mais bien sûr, je ne parlerai pas que de ça ici... J'écrirai parfois des petits dossiers sur des sujets intéressants.

Les outils qui étaient avant sur mon site (générateur de QR-Code, par exemple) restent accessibles via le menu en haut.

Vive le nouveau site !