IRC en SSL et mode de connexion SASL

J'ai eu besoin aujourd'hui de me connecter sur IRC depuis mon ordinateur portable professionnel. J'avais déjà le logiciel Pidgin installé, il m'a donc suffit d'ajouter le serveur irc.freenode.net. Mais au détour d'une conversation s'est posée la question de l'encodage utilisé sur le canal de discussion. De mémoire il me semblait que Freenode utilisait l'ISO-8859-1. Je n'ai cependant retrouvé l'information nul part et mon client configuré par défaut en UTF-8 ne semblait pas poser de problème aux autres utilisateurs pour les accents. Mes recherches m'ayant amené à parcourir la documentation de Freenode, j'ai du coup pris le temps de tester la connexion SSL et l'option SASL.

La connexion SSL est ici la plus importante des deux options, puisqu'elle permet de sécuriser la communication entre le client et le serveur. Cela évite donc que son mot de passe transite en clair sur le réseau. Alors que la documentation indique que tous les serveurs écoutent en SSL sur les ports 6697, 7000 et 7070, seul le dernier à fonctionné dans mon cas. A noter aussi que le certificat n'est pas signé par une autorité de certification reconnue. Il faut donc soit ajouter les deux certificats nécessaire pour le chemin de certification, soit ajouter une exception pour le certificat du serveur.

L'option SASL permet quant à elle d'éviter d'afficher le canal de connexion au serveur. Cela met en place un système d'authentification qui nécessite d'être identifié avant d'afficher quoi que ce soit. L'avantage est donc de faire disparaitre cette fenêtre intermédiaire où les clients IRC comme Pidgin se connecte pour vous. Par contre cela nécessite d'avoir déjà un identifiant enregistré sur le serveur, c'est à dire protégé par un mot de passe. L'idéal si vous n'avez pas encore de compte enregistré est donc d'activer la connexion SSL (pensez à vous déconnecter et reconnecter), d'enregistrer votre compte, puis d'activer SASL. D'après ce que j'ai compris, cette méthode d'authentification a été initialement créée pour se prémunir des fauteurs de troubles qui se présentaient avec des adresses IP différentes et qui étaient donc difficilement bloquables.