1 votes

Client IRC vers Bitlbee - chiffrement de bout en bout ?

Je suis un novice de Bitlbee, l'utilisant avec libpurple pour regrouper tous mes messages. C'est très cool, mais j'ai quelques préoccupations en matière de sécurité, que j'aimerais clarifier.

Lorsque je me connecte depuis un client IRC (j'utilise weechat.el sur emacs) à une passerelle Bitlbee locale, il semble que je ne puisse pas garder les informations chiffrées de bout en bout en raison de l'absence de prise en charge du SSL par Bitlbee?

Cela signifie que les informations sont transmises en clair :

weechat.el --SSL--> WeeChat(Relay) --PLAIN--> Bitlbee --SSL--> |Firewall| --> Skype/Facebook

Le seul conseil que je trouve concerne la sécurisation de la connexion à partir d'un réseau externe, en utilisant stunnel. Bien que ce soit un bon conseil, cela ne sert à rien localement car stunnel parlera finalement à bitlbee via une connexion non sécurisée, donc avoir un stunnel local est sûrement une perte de temps?

Je comprends qu'avoir une connexion locale non sécurisée est un risque relativement faible, mais cela signifie que l'identification de l'utilisateur sur le client et tout message envoyé peuvent techniquement être interceptés sur l'interface lo, par quelqu'un ayant un accès root au serveur?

Dans un monde idéal, ces informations n'apparaîtraient jamais sur une connexion en clair.

Quelques questions que je me pose

Est-il possible de fournir un cryptage SSL de bout en bout du client à Bitlbee?

Si non, quelles étapes sont recommandées en dehors de la colocalisation du client et du serveur sur le même serveur (ou l'utilisation de stunnel)? Évidemment, je peux bloquer tout le trafic entrant sur le port 6667, mais y a-t-il autre chose?

Quelqu'un peut-il clarifier le risque réel de l'interception de paquets sur les connexions localhost?

3voto

James Mertz Points 390

Est-il possible de fournir un cryptage SSL de bout en bout du client à Bitlbee ?

Non, Bitlbee ne prend pas en charge le SSL/TLS au niveau du serveur.

Bien que ce soit un bon conseil, cela ne sert à rien localement car stunnel finira toujours par parler à Bitlbee sur une connexion non sécurisée, donc avoir un stunnel local est sûrement une perte de temps ?

L'idée est que stunnel s'exécute sur le même hôte que Bitlbee, pas sur le même hôte que votre client.

Quelqu'un peut-il clarifier le risque réel d'interception de paquets sur les connexions localhost ?

Sous Linux et la plupart des autres systèmes d'exploitation de type Unix, cela n'est disponible que pour root, c'est-à-dire l'administrateur du serveur. Si vous ne faites pas confiance à root, vous ne pouvez pas faire confiance au serveur.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X