Table des matières

Ceci est la traduction de la FAQ du protocole SILC. La traduction est terminée, mais elle a besoin d'une relecture, alors n'hésitez pas à corriger les éventuelles erreurs et fautes que vous relèverez en éditant cette page.

Questions sur le protocole SILC

1. Quel est le statut du protocole SILC dans l'IETF ?

Les spécifications du protocole SILC ont été soumises en tant que soumissions individuelles. Il n'existe à l'heure actuelle pas de groupe de travail pour ce type de projet. Notre but est de complètement standardiser SILC et de l'envoyer ainsi plus tard à l'IETF en tant que RFC. Ceci n'est possible qu'après avoir demandé à l'IETF d'accepter SILC en tant que RFC. A ce jour, nous ne l'avons même pas encore demandé à l'IETF. Nous voulons laisser le protocole mûrir un peu plus.

2. A quel point le protocole SILC est-il basé sur d'IRC ?

SILC n'est pas basé sur IRC. SILC Client ressemble en surface à un client IRC, mais tout ce qu'il a sous le capot n'a rien à voir avec IRC. SILC ne pourra *jamais* supporter IRC car la topologie du réseau entier est différente (plus évolutive et plus puissante). Donc non, le protocole SILC (client ou serveur) n'est pas basé sur IRC. Nous avons pris les bons points d'IRC (et d'autres protocoles) et laissé de côté les mauvais, et nous n'avons pas essayé d'alourdir SILC avec les problèmes d'IRC, qui l'alourdissent déjà et continueront éternellement d'alourdir les futurs projets d'IRC. SILC Client ressemble à un client IRC parce qu'il est plus simple pour les nouveaux utilisateurs de débuter avec SILC quand ils en connaissent déjà toutes les commandes.

3. Pourquoi utiliser SILC ? Pourquoi pas IRC avec SSL ?

Bien entendu, c'est toujours possible, mais cela sécurise-t-il le réseau IRC tout entier ? Et cela améliore-t-il ou empire-t-il les temps de latence et les déconnexions de serveurs sur le réseau IRC ? Cela fournit-il une sécurité basée sur l'utilisateur où certains messages privés précis sont sécurisés ? Cela fournit-il une sécurité où certains messages de canal précis sont sécurisés ? Et je sais que vous pouvez répondre oui à certaines de ces questions. Mais la sécurité ne consiste pas à simplement appliquer un chiffrement du trafic, et SILC ne se borne pas simplement à “chiffrer le trafic”. Vous ne pouvez pas transformer soudainement un protocole faillible en protocole sécurisé en vous contentant de simplement chiffrer le trafic. SILC n'est pas conçu pour devenir un remplacement d'IRC. IRC est bon pour certaines choses, SILC est bon pour les mêmes choses et d'autres encore. Lisez également la FAQ Crypto de SILC pour plus d'informations.

4. Puis-je discuter depuis un réseau SILC sur un réseau IRC, ICQ, Jabber, etc. ?

La réponse est simple : non. Les protocoles ne sont pas compatibles, ce qui rend impossible de discuter directement depuis un réseau SILC vers un réseau IRC ou vice versa. Développer une passerelle entre ces réseaux serait techniquement possible, mais fortement déconseillé du point de vue de la sécurité. Nous n'avons aucune intention de développer une telle passerelle.

5. SILC supporte-t-il le transfert de fichier ?

Oui, le protocole SILC supporte SFTP en tant que protocole obligatoire pour le transfert de fichiers. Cela fournit un transfert de fichiers de client à client en toute simplicité, mais aussi la possibilité de manipuler des fichiers et des dossiers. Même si SFTP est le protocole de transfert de fichier, le support du transport de fichier a été réalisé de telle manière que n'importe quel protocole de transfert de fichier puisse être utilisé avec le protocole SILC.

6. SILC supporte-t-il le DCC ou quelque chose de similaire ?

SILC ne supporte pas le DCC habituellement utilisé sur IRC. Il n'en a pas besoin puisqu'il supporte d'origine les mêmes fonctions que celle de DCC. Vous pouvez transférer des fichiers de manière sûre et cryptée directement avec un autre client. Vous pouvez aussi échanger la clé secrète elle-même avec un autre client pour l'utiliser imméditement dans le cryptage des messages. Les messages privés ne sont cependant pas envoyé directement entre les clients. Le protocole, d'un autre côté n'interdit pas l'envoi de messages directement entre les clients, si l'implémentation peut le supporter. L'implémentation du client SILC actuel ne le supporte pas. Cela signifie que les messages privés voyagent à travers le réseau SILC. Le protocole SILC a aussi la capacité de supporter DCC et CTCP en tant que protocoles avec SILC. En revanche, aucun d'entre eux n'a été conçu pour être utilisé avec SILC au jour d'aujourd'hui.

7. Je suis derrière un pare-feu, puis-je utiliser SILC ?

Oui, si votre administrateur réseau peut ouvrir le port distant 706 (TCP), alors vous pouvez vous servir de SILC sans problème. Vous pouvez aussi compiler votre client SILC avec le support de SOCKS ce qui fera passer votre session SILC au travers du pare-feu.

8. SILC est-il vraiment sûr ?

Nous avons essayé de faire SILC aussi sûr que possible. Cependant, il n'existe aucun protocole ou logiciel de sécurité qui soit infaillible. Et SILC ne déroge pas à la règle. SILC est donc lui aussi soupçonné d'avoir des failles de sécurité. Celles-ci nécessitent juste d'être trouvées pour pouvoir être corrigées. Les caractéristiques de sécurité de SILC ont été développées du point de vue de l'attaquant; nous avons essayé de trouver toutes les attaques possibles et de protéger SILC contre elles.

Lisez la FAQ sur SILC CRYPTO pour de plus amples informations.

9. Est-ce-que SILC supporte la messagerie instantanée ?

SILC n'est pas officiellement un système de messagerie instantanée (MI) comme le pensent fréquemment les gens. Cependant, SILC supporte la plupart des fonctionnalités que l'on trouve dans les traditionnels systèmes de MI. SILC peut être implémententé soit dans un système de type IRC, soit dans un système de type MI. Les fonctionnalités que l'on trouve en général dans les systèmes de MI, comme les options de présences multiples, les sessions persistantes, etc, sont aussi présentes dans SILC.

Il fut considéré que cette information en tant que commande propre de SILC n'était pas nécessaire. Et qui plus est; la topologie du réseau peut être une information confidentielle bien que les serveurs et les routeurs du réseau ne soient pas toujours dissimulés. Nous estimons que les informations sur la topologie du réseau, s'il est voulu qu'elles soient publiques, et la liste des serveurs accessibles peuvent être rendues disponibles par d'autres moyens qu'en tapant une commande comme LINKS, qui montre les liens vers un serveur actif sous IRC.

11. Que signifie le détachement/la reprise d'une session ?

Le nouveau protocole SILC supporte une fonction appelée le détachement de session. Cela signifie qu'un client peut se détacher du serveur en tapant la commande DETACH, mais qu'il reste toujours un utilisateur valide sur le réseau. L'utilisateur peut alors reprendre sa session précédente la fois suivante en se connectant sur un serveur du réseau, et continuer comme si de rien n'était.

Cette fonctionnalité peut être facilement utilisée dans de nombreux cas. Par exemple, si vous voulez améliorer votre client SILC actuel, vous n'avez plus à quitter le réseau. Tapez juste la commande DETACH et vous resterez quand même sur le réseau. Améliorez alors votre client, reconnectez-vous au serveur et continuez le travail comme d'habitude. Si quelqu'un tape la commande WHOIS pour votre pseudo, il verra que vous êtes détaché. Les messages qui vous sont envoyés quand vous êtes détachés sont supprimés par le serveur. Une chsoe intéressante à propos de cette fonctionnalité est que vous pouvez aussi reprendre la session depuis n'importe quel serveur du réseau; vous n'êtes pas obligé de vous reconnecter au même serveur que celui que vous avez quitté auparavant.

12. Est-ce-que quelqu'un situé à l'extérieur du canal peut lire des messages de canal ?

La réponse courte est tout simplement non. Une plus longue réponse implique des suppositions à propos des conditions de sécurité. Initialement, les clés de canal sont générées par le serveur, donc, si le serveur devait être compromis, il serait possible pour un attaquant de voir les messages. Cependant, les utilisateurs sur le canal peuvent empêcher cela même dans ce cas-là. Il est possible d'activer les fameuses clés privées de canal que seuls les utilisateurs du canal connaissent. Les serveurs ne connaissent pas la clé, et par conséquent, ils ne peuvent pas voir les messages même s'ils devaient être compromis. Donc la réponse longue conduit au même résultat que la première : non.

13. Comment puis-je enregistrer mon canal dans SILC ?

Il n'existe pas de service d'enregistrement de canal dans SILC. Cependant, SILC supporte les canaux permanents. Qaund vous joignez un canal inexistant pour la première fois, vous deviendrez le fondateur du canal. Vous pouvez alors mettre un mode fondateur spécial sur le canal qui le fera devenir permanent. Quand le dernier utilisateur quittera le canal, lorsque ce mode est activé, le canal ne sera pas détruit. Si le mode fondateur n'est pas activé, alors les canaux vides seront automatiquement détruits. Quand ce mode est activé, et que vous quittez le canal, vous pourrez de nouveau réclamer les droits de fondateur du canal la prochaine fois que vous le joindrez. Vous appelez ceci une enregistrement de canal si vous le voulez.

14. Est-il vrai que tous les messages sur SILC sont cryptés ?

Disons le définitivement : OUI. Le protocole SILC rend impossible le décryptage des messages ou des paquets du réseau SILC. Tous les messages sont toujours cryptés, que ce soient en utilisant les clés de session, ou d'autres clés secrètes comme les clés de canal ou les clés de messages privés.

15. Est-ce-qu'un opérateur SILC ou un opérateur de serveur peut obtenir le mode opérateur sur un canal ?

Ils ne peuvent pas obtenir le statut d'opérateur ou de fondateur, joindre les canaux sur invitation seulement, échapper aux bannissements actifs, aux limites d'utilisateurs ou quoique ce soit de semblable, sans y être clairement autorisés. La seule manière d'obtenir le statut d'opérateur de canal est que quelqu'un vous Op. Les opérateurs SILC et les opérateurs de serveur sont des utilisateurs normaux sur le réseau, avec le privilège supplémentaire de pouvoir administrer leur serveur. Ils ne peuvent rien faire de plus qu'un utilisateur normal.

16. Les canaux doivent-ils ou pas posséder le caractère # ?

Le caractère # n'est pas une partie obligatoire d'un nom de canal, comme c'est le cas sur IRC. Cela signifie qu'en tapant la commande /JOIN #silc et /JOIN silc vous joindrez deux canaux différents. Ceci est volontaire, puisque que le caractère # est une particularité d'IRC, et n'a donc rien à voir avec SILC. Si vous voulez avoir ce caractère, vous n'avez qu'à joindre un canal avec un # dans son nom.

17. Est-ce-que SILC supporte les canaux modérés ?

Oui. un fondateur de canal peut modérer les utilisateurs normaux et les opérateurs de canal afin qu'ils ne puissent plus parler sur le canal. Il est aussi possible, si nécessaire, de faire taire un utilisateur du canal en particulier.

18. Que signifie la « surveillance » ?

Vous pouvez créer une liste de « surveillance » pour vous-même sur un serveur. Cela signifie que vous pouvez surveiller certains pseudonymes sur le réseau. Par exemple, si vous ajoutez le pseudonyme « foo » à la liste de surveillance, vous serez averti lorsque un foo se connectera au réseau, quittera celui-ci, changera son mode d'utilisateur ou encore son pseudonyme. De cette façon, vous pouvez ainsi surveiller, par exemple, quand vos amis se connectent sur le réseau.

19. Est-il possible de refuser la surveillance ?

Oui. Puisqu'il est clair que tout le monde ne désire pas être espionné, vous pouvez mettre un mode pour vous-même qui rejettera la surveillance des autres. Même si quelqu'un surveille votre pseudo, vos connexions, vos changements de mode ou de pseudo, il n'en sera pas averti.

20. Est-il possible de bloquer des messages privés ?

Oui. Vous pouvez bloquer l'arrivée de messages privés en activant un mode qui empêchera les messages privés non voulus. Seuls les messages privés qui sont sécurisés avec une clé de message privé vous seront envoyés. Cela implique que vous ayez déjà échangé la clé privée avec l'expéditeur du message, et, par conséquent, que vous voulez recevoir des messages de cet utilisateur. Les autres messages privés qui sont sécurisés avec les clés normales de session sont supprimés quand ce mode est activé.

21. Est-il possible de bloquer des messages de canal ?

Oui, en effet. En activant un mode qui effectue ceci, vous pouvez empêcher le serveur de vous envoyer des messages de canal. Il existe aussi un mode qui autorise le blocage des messages de canal venant des utilisateurs normaux. Cela signifie que vous pourrez recevoir des messages de canal seulement quand ils seront envoyés par un opérateur ou un fondateur de canal. Il est aussi possible de bloquer les messages de canal envoyés par des robots. Un utilisateur du canal peut avoir un mode robot activé (ce qui signifie que l'utilisateur est en fait un programme robot); les messages envoyés depuis cet utilisateur pourront alors être bloqués par ce mode.

22. Est-il possible de bloquer les invitations ?

Oui, bien sûr. Vous pouvez activer un mode qui empêche le serveur de vous envoyer les notifications d'invitation. Ceci peut, par exemple, empêcher le flood d'invitations. Le problème c'est que cela rend plus difficile l'accès à des canaux « sur invitations seulement ».

23. SILC supporte-t-il les messages multimédias, comme les flux de données audios ou vidéos ?

Oui, il le peut. La nouvelle version du protocole supporte les envois d'objets MIME en tant que messages. Puisque les objets MIME peuvent aisément représenter n'importe quel type de données, telles que des flux vidéos, des flux audios, des images, etc, il est facile d'envoyer ces messages multimédias dans SILC. Cela rend aussi la visioconférence possible avec SILC. Cela fonctionne en envoyant le(s) flux sur un canal, ainsi toutes les personnes qui joindront le canal pourront le(s) recevoir. Cette fonctionnalité du protocole rend tout à fait possible toutes sortes d'applications multimédias dans le futur.

24. Est-il possible d'envoyer des messages avec des images ou des dessins ?

Oui. Puisqu'il est possible d'envoyer n'importe quel type d'objet MIME comme un message, il est aussi possible d'envoyer des dessins ou des images en tant que messages. Il devrait, par exemple, être possible d'envoyer des messages écrits à la main ou à la souris.

25. Quels types de modes de présence SILC supporte-t-il ?

Par présence, nous entendons « indication de présence sur le réseau »; et SILC supporte de nombreux types de mode de présence. Ils peuvent être changés avec la commande UMODE qui change votre mode d'utilisateur sur le réseau. Actuellement, il existe les modes de présence suivants : GONE (je suis parti), INDISPOSED (je peux ne pas être là), BUSY (je suis occupé, ne me dérangez pas), PAGE (contactez-moi si vous voulez discuter), et HYPER (je suis hyper actif, parlez-moi). Quand aucun mode n'est activé, cela signifie que vous êtes présent sur le réseau. Il existe beaucoup d'autres modes d'utilisateur, mais ils ne sont pas directement liés à une indication de présence.

26. Que sont les Attributs Requis ?

Les Attributs Requis, ou attributs d'information et de présence en ligne de l'utilisateur (comme ils sont officiellement appelés), sont une extension de la commande WHOIS qui est utilisée pour demander des informations à propos d'autres utilisateurs sur le réseau. En utilisant ces attributs, il est possible de recevoir des informations plus détaillées à propos d'un utilisateur, comme sa carte de visite, ses images, ses clés publiques et ses certificats, son humeur d'utilisateur, ses messages et textes de statut, sa géolocalisation, et d'autres informations. En bref, les attributs requis sont utilisés pour délivrer des informations qui ne sont pas données par défaut par la commande WHOIS, et vous pouvez envoyer à peu près n'importe quoi avec les attributs.

27. Quel format la carte de visite utilise-t-elle ?

La carte de visite, qui peut être envoyée grâce aux Attributs Requis, est au format standard VCard.

28. Est-ce-que SILC supporte l'anonymat ?

Le protocole possède un mode d'utilisateur qui indique que celui-ci est un utilisateur anonyme. L'utilisateur ne peut pas activer ou désactiver ce mode lui-même, mais un serveur qui fournit ces services de discussion anonymes peut le faire pour un utilisateur se connectant au serveur. Les informations de noms d'hôtes et de noms d'utilisateur sont brouillées lorsque le mode est activé. Il y a beaucoup d'autres manières de devenir anonyme dans SILC mais se sont toutes des méthodes implémentielles, et le protocole ne les gère pas.

29. Est-ce-que SILC supporte les services ?

Oui. Il existe une commande appelée SERVICE qui peut être utilisée par des clients, et des serveurs, pour échanger un contrat de service avec un serveur distant. Le protocole ne définit cependant pour le moment aucun service.

30. Que sont en fait les services ?

Souvent les gens pensent que les services SILC doivent être similaires aux services IRC, mais ce n'est pas le cas. Les services SILC sont en fait des extensions de protocole qui augmentent les fonctionnalités du coeur du protocole. Habituellement, les services définissent leur propre protocole que toutes les parties du service supportent. Ce ne sont pas des des services comme les services de robots d'IRC, où vous communiquez avec les services par l'intermédiaire de messages.

31. Est-ce-que SILC supporte les messages hors-ligne ?

Les messages hors-ligne sont envoyés à des utilisateurs qui ne sont pas présents sur le réseau. Par défaut, SILC ne supporte pas les messages hors-ligne. Les messages envoyés à des utilisateurs détachés seront détruits par le serveur. Il devrait être possible de développer un service qui autorise le serveur à sauver les messages envoyés aux utilisateurs détachés, mais, il serait sage de rendre ceci configurable par l'utilisateur, afin que les messages soient sauvés seulement si l'utilisateur a demandé ce service au serveur. Les questions de sécurité relatives à un service de sauvegarde des messages auront besoin d'être résolues.

32. Est-ce-que SILC supporte l'UTF-8 ?

Tous les messages textuels privés, de canal et autre messages de texte son toujours encodés en UTF-8 dans SILC. Cependant, Il est aussi possible d'envoyer des messages textuels de canal avec un autre encodage, et de dire l'encodage dans le message, afin que le destinataire puisse le lire correctement. Cependant, par défaut, les messages textuels sont encodés en UTF-8.

33. Que sont les clés publiques de canal ?

Un mode clé publique de canal peut ête activé sur un canal afin d'autoriser son accès seulement aux utilisateurs dont la clé publique a été ajoutée à la liste des clés publiques du canal. Quand un utilisateur rejoint le canal, il doit founir une signature numérique qui est utilisée pour authentifier l'accès au canal. Si la clé publique n'est pas sur la liste des clés publiques du canal, alors l'utilisateur ne peut pas le rejoindre. Cette fonctionnalité est identique aux canaux à phrase de passe, mais fonctionne avec des signatures numériques.

34. J'ai des suggestions à propos du protocole SILC, que puis-je faire ?

Toutes suggestions et améliorations sont, bien entendu, les bienvenues. Vous devriez lire les spécifications du protocole pour vérifier si votre idée n'est pas couverte par celles-ci. La meilleure place pour rendre publique votre idée est la liste de diffusion du développement de SILC. Vous devriez aussi vérifier la list TODO du CVS.

documentations/faq/silc_protocol_faq.txt · Dernière modification: d/m/Y H:i:s (modification externe)