Documentation IRC · Débutant
Sécurité IRC : identité, confidentialité et bons réflexes
Une connexion IRC sûre combine un transport vérifié, une identité correctement authentifiée et des permissions limitées. Aucun de ces éléments ne remplace les autres. Un salon ou un message dit privé n’est pas automatiquement chiffré de bout en bout.
Équipe Dialova · Vérifié le
Vérifier la liaison TLS #
Utilisez les paramètres TLS publiés par le réseau et conservez la vérification du certificat. Le nom du serveur doit correspondre au certificat et sa chaîne doit être valide. Un avertissement ne se résout pas en désactivant durablement les contrôles ; vérifiez l’adresse, la date de l’appareil et la documentation officielle.
6697 est le port couramment utilisé pour IRC sur TLS, documenté par la RFC 7194. Un numéro de port ne suffit pas à prouver le chiffrement : le client doit effectivement établir TLS. Le chiffrement de la liaison ne cache pas le contenu au serveur IRC.
Authentification, pseudo et services #
Préférez SASL lorsque le réseau le permet, avec un mécanisme adapté et TLS pour protéger les secrets. NickServ est un service dont les commandes et politiques varient. Ne saisissez pas une commande d’identification copiée dans un message non sollicité sans vérifier le réseau et le service.
Un pseudo ressemblant à celui d’un administrateur n’est pas une preuve d’autorité. Pour un bot, utilisez les informations d’identité fournies par le serveur, telles que account-tag, puis vérifiez les droits. Sur Dialova, la clé IRC dédiée se gère dans les paramètres et doit être révoquée si elle est divulguée.
Adresse IP, hostmask et masquage #
Un hostmask peut montrer un identifiant et un hôte technique. Un cloak ou un vhost change ce que certains autres utilisateurs voient, selon les règles du réseau ; cela ne rend pas l’IP inconnue du serveur ni de tous ses opérateurs.
WHOIS ne donne pas universellement l’IP réelle. Les informations affichées dépendent du serveur et des permissions. Un VPN ne remplace pas la vérification de l’identité, la protection du compte ou l’attention portée aux liens ; chaque réseau conserve sa politique d’accès.
Liens, phishing et transferts directs #
Un message amical, une NOTICE ou une invitation peut contenir un lien trompeur. Vérifiez le domaine avant de saisir un secret. Refusez les demandes inattendues de clé IRC, de code de confirmation ou de paiement présenté comme urgent.
DCC peut établir une connexion directe entre clients et révéler des informations réseau. N’acceptez pas automatiquement un fichier et n’exécutez pas un script reçu sur IRC. Les photos et vocaux hébergés par Dialova ne sont pas des transferts DCC : leurs contrôles d’accès relèvent du site.
Pour les responsables de salons et de serveurs #
- Limiter les droits de bots et comptes d’exploitation aux besoins réels.
- Tenir IRCd, services et dépendances à jour, en suivant leurs avis de sécurité.
- Définir des limites de connexions, de débit et d’actions coûteuses.
- Protéger les accès d’administration et éviter les secrets dans les logs ou sauvegardes publiques.
- Documenter les politiques de modération et de conservation sans promettre un anonymat absolu.
Sources et vérification
Les exemples utilisent des pseudos et domaines fictifs, sauf les points de connexion explicitement documentés. Les extensions et réglages propres à un réseau sont signalés dans le texte.
- Modern IRC — spécification du protocole client ↗Source de spécification · consultée le 2026-10-29
- IRCv3 — SASL Authentication 3.1 ↗Source de spécification · consultée le 2026-10-29
- RFC 4616 — SASL PLAIN ↗Source de spécification · consultée le 2026-10-29
- RFC 7194 — port IRC sur TLS ↗Source de spécification · consultée le 2026-10-29
- mIRC — réglages de connexion ↗Source officielle · consultée le 2026-10-29
- Dialova — connexion depuis mIRC ↗Source Dialova · consultée le 2026-10-29