Survivre à une déconnexion

Lorsqu’on démarre une tâche sur un ordinateur distant, il faut s’assurer que la tâche est terminée avant de rompre la connexion. En effet, le comportement de Linux dans le cas où une communication est rompue est d’envoyer un signal SIGHUP aux programmes qui dépendent de cette connexion. Si rien n’a été fait pour le contrer, le comportement par défaut est d’arrêter brusquement la tâche.

Déléguer une tâche longue à une autre machine est courant dans le monde Unix/Linux. Mais il faut prendre certaines précautions pour éviter que notre tâche qui s’exécute sur le serveur ne soit avortée par le fait qu’on déconnecte notre portable pour l’amener à la maison.

Vérifions comment notre appli réagit à un signal SIGHUP:

kill -SIGHUP $(pidof appli)

ou

pkill -SIGHUP appli

Si l’application avorte et que ce comportement ne nous convient pas, on pourra utiliser l’une des approches suivantes:

Ajouter le traitement du SIGHUP à notre application

S’il s’agit d’un programme qu’on a écrit ou d’un logiciel libre dont on a le code source, il est facile d’ajouter du code pour traiter le signal SIGHUP.

Demander à bash d’ignorer le signal

Si la solution précédente n’est pas possible, on peut demander à bash d’ignorer le signal SIGHUP:

trap '' SIGHUP
./appli args
trap SIGHUP    # reprendre le comportement par défaut

Exemple d’un script qui ignore les SIGHUP (pour la durée du script):

trap '' SIGHUP
./appli args

On peut aussi utiliser le programme nohup qui déconnecte l’appli de ses canaux standards et envoie toute sortie vers le fichier nohup.out

nohup appli args

screen

screen a été conçu pour gérer plusieurs applications pour une même connexion. Un effet collatéral est que screen créée un lien virtuel entre une application et ses canaux standards (STDIN, STDOUT, STDERR).  Par conséquent, une déconnexion du lien de communication n’est pas perçue par l’application. La tâche continue à s’exécuter en arrière-plan et lorsqu’on rétablit la connexion, on peut refaire le lien avec l’application.

tmux

tmux est semblable à screen et réalise les mêmes fonctions. Sa principale différence est qu’il est de facture plus moderne. tmux se définit comme ‘multiplexeur de terminaux’. Il reprend les concepts de screen mais ajoute un gestionnaire de fenêtre qui partage la fenêtre en zones rectangulaires.

awesome

 

Déchiffrage d’une communication SSL/TLS

L’approche classique pour déchiffrer des paquets SSL est d’utiliser un proxy ou un logiciel MITM.
Depuis quelques temps, WireShark déchiffre les paquets SSL si on lui fournit les clés du chiffrage. Il y a 2 façons d’obtenir ces clés:

PrivateKey

C’est la clé privée utilisée par le serveur. La seule façon de l’obtenir est d’avoir accès aux fichiers du serveur et de la copier vers votre machine WireShark. Attention à bien la protéger; cette clé ne doit pas être connue du public.
La position du fichier de clé varie d’un serveur à l’autre; vous avez donc intérêt à bien connaître votre serveur ou d’en avoir la documentation technique.
Lorsque la clé est copiée sur votre machine, il suffit d’en informer WireShark:

Éditer /Préférences/Protocols/SSL/Edit(RSA key list)/

On peut y spécifier:

– adresse IP du serveur SSL qu’on veut décoder (0 pour toutes)
– port des messages à décoder (généralement 443, 0 pour tous)
– protocole (smtp, http, etc): vide indique tous les protocoles
– key file: le nom du fichier qui contient la clé importée
– password: mot de passe du fichier (si besoin est)

Il peut y avoir plusieurs de ces fichiers. Wireshark choisit le fichier approprié en fonction des adresseIP/port/protocole que vous avez spécifié plus haut.
Note: la méthode PrivateKey ne fonctionne qu’avec un chiffrage de type RSA. Les chiffrages DH (Diffie-Hellman) sont plus complexes et ne peuvent être décodés avec la méthode PrivateKey. Utilisez plutôt la seconde méthode (preMaster Secret).

preMaster Secret

Il ne s’agit pas vraiment d’une clé mais plutôt d’un résultat intermédiaire enregistré lors de la négociation SSL initiale entre le client et le serveur. Firefox et Chrome permettent d’enregistrer facilement ces résultats intermédiaires. Cette option porte le nom de SSLKEYLOGFILE.

Pour activer l’option SSLKEYLOGFILE

Il faut spécifier où seront déposés les secrets.
Dans une fenêtre bash:

export SSLKEYLOGFILE=/chemin/fichier; firefox (ou chrome)

Une autre façon est de l’activer de façon permanente. Ajoutez à la fin de votre fichier .bashrc:

export SSLKEYLOGFILE=/chemin/fichier

Redémarrez l’usager pour que cette commande prenne effet puis démarrez Firefox (ou Chrome)
Indiquer à Wireshark où est ce fichier:
Éditer/Préférences/Protocols/SSL
Entrez le chemin/fichier dans le champ (pre)Master-Secret log filename
Si les 2 étapes précédentes ont bien fonctionné, vous verrez dans Wireshark, pour chacun des paquets SSL, un nouvel onglet Decrypted SSL data au bas de la fenêtre de données.

Versions:

Méthode Outil Version Note
PrivateKey Wireshark >=1.6
PreMasterSecret
(SSLKEYLOGFILE)
Firefox <=48
Firefox > 48 Seulement dans la version pour développeurs
Chrome < 59
Chrome   59 Seule la version 59 a été testée
Chrome > 59
Wireshark >=1.8 PrivateKey et preMaster

Conclusion

Le déchiffrage des paquets SSL peut s’avérer très utile lorsque vous avez à régler un problème subtil avec un nouveau serveur (ou un objet Internet). Vous avez surement compris que la 2ième méthode (SSLKEYLOGFILE) est la plus facile.

Références:

fr.wikipedia.org/wiki/Transport_Layer_Security
fr.wikipedia.org/wiki/Échange_de_clés_Diffie-Hellman
jimshaver.net/2015/02/11/decrypting-tls-…
www.root9.net/2012/11/ssl-decryption-with-wireshark-private.html
www.m00nie.com/2015/05/decrypt-https-ssltls-with-wireshark/
certsimple.com/blog/ssl-wireshark-mac-osx
developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format