htg-content/content/posts/protegez-vos-flux-stunnel.md

title	date	author	template	tags
Protégez vos flux : stunnel	2017-03-14	raspbeguy	post	Auto-hébergement,planet libre,Tutoriels

On ne vous le répétera jamais assez, mais il est indispensable de prendre conscience des enjeux des communications électroniques en clair. En effet, vous n'avez sûrement pas envie qu'un malandrin s'approprie vos messages et actions privées, comme votre correspondance avec votre médecin et vos opérations bancaires, données qu'ils pourrait retourner contre vous pour vous faire chanter, vous voler, ou tout bonnement vous faire du mal d'une manière quelconque. Il faut à tout prix préférer les communications chiffrées, et ce pour n'importe quel protocole.

Fort heureusement, aujourd'hui le chiffrement des flux est devenu en quelques sortes un standard grâce à l'essor des implémentation du protocole TLS et de ses variantes. Les protocoles anciens se sont pour la plupart dotés d'une surcouche sécurisée (HTTP, IMAP, SMTP, IRC) et les protocoles naissants sont aujourd'hui regardés de travers s'ils omettent la sécurité dans leurs cahiers des charges.

Malheureusement il existe encore des protocoles/programmes irréductibles qui continuent sans répit à laisser se balader à poil des paquets sur la toile. Ne leur jetons pas tout de suite la pierre, ou du moins pas trop fort, ce choix n'est pas toujours dénué de sens comme nous le verrons par la suite.

Ici comme dans pas mal d'articles sur Hashtagueule, il y a un déclencheur personnel du besoin qui fait l'objet du tutoriel en question. On est pas des hommes politiques, nous on vous parle de choses qu'on connaît. On a l'idée de parler de certaines choses en se frottant à des problèmes et en y trouvent des solutions. Je vais donc vous parler de l'outil Bitlbee, qui agit comme une passerelle entre divers messageries comme Jabber, Twitter, MSN et Yahoo d'un côté, et IRC de l'autre côté, ce qui permet de centraliser toutes ses messageries sur un simple client IRC. Pour ce faire, il simule un serveur IRC sur lequel se connectent les client qui veulent accéder aux services agrégé. Seulement, alors que la plupart des serveurs IRC proposent une connexion sécurisée, Bitlbee n'implante pas cette couche TLS. En partie parce que le serveur est destiné à être exécuté en local (donc pas grand risque d'intercepter les communications). Mais n'empêche que ça semble bizarre et qu'à priori ça bride pas mal les utilisations.

En réalisant ça, j'étais d'abord outré, et ça a même remis en question mon utilisation du programme. Cependant, j'ai trouvé une solution, qui est par ailleurs proposée par les développeurs. J'ai découvert un outil magique qui s'appelle stunnel, qui permet de transformer n'importe quel flux en clair par un flux chiffré à travers un certificat TLS. Pour ceux qui s'y connaissent un peu en serveur web, il s'agit du même principe qu'un reverse proxy comme le ferait un nginx ou un HAproxy, mais pour n'importe quel flux TCP (même si HAproxy est capable de gérer les flux TCP mais c'est moins marrant).

Du coup, il suffit de posséder un certificat adapté au nom de domaine qui pointe vers votre serveur (chose très facile en utilisant Let's Encrypt, pour peu que vous ayez un serveur web qui sert ce nom de domaine) et il vous est possible d'envelopper ce flux dans un tunnel TLS. Voici ce que j'ai ajouté dans ma configuration stunnel :

[bitlbee]
accept = 6697
connect = 6667
cert = /etc/letsencrypt/live/mon.domaine.tld/fullchain.pem
key = /etc/letsencrypt/live/mon.domaine.tld/privkey.pem

Le port 6667 est le port non sécurisé, et le port 6697 est le port sécurisé. Elle est pas belle la vie ?

De plus stunnel peut fonctionner dans l'autre sens, c'est à dire servir du contenu en clair à partir d'un canal sécurisé, ce qui est pratique quand derrière on a pas de client compatible avec TLS.

Bon, revenons sur les raisons qui poussent un programme à ne pas adopter la sécurisation des flux. Dans le cas de bitlbee, comme je l'ai dit plus tôt, c'est un serveur destiné à être atteint en local. De plus, certains projets choisissent de ne pas implémenter le chiffrement et de recommander explicitement des solutions comme stunnel pour ne pas être responsables d'une éventuelle faille dans leur implémentation. Et aussi parce que c'est gonflant de faire de la sécu quand le projet à l'origine n'a absolument pas de rapport, il faut le reconnaître.