Discussion :

[Ceylo]

Bonjour,

J'essaie dans un but personnel de réaliser un serveur et client de chat via le réseau local du style canal IRC.

Pour les messages entre le client et le serveur, j'aimerais utiliser des données brutes, mais j'ai un problème pour trouver une façon de m'assurer que toutes les données ont bien été reçues.

En fait la façon classique consisterait à indiquer en en-tête la taille des données, suivie de ces données. Le problème que cela pose est que n'importe qui pourrait falsifier ces données. En donnant une taille trop petit à la limite le message du client serait "simplement" ininterprétable et donc perdu, dans le cas d'une taille plus grande en revanche, j'attendrais sur le réseau des données inexistantes et mon thread se retrouverait bloqué. Cela pose un problème d'autant plus conséquent que les différents clients sont gérés via un sélecteur, donc pas en parallèle.


Une autre technique aurait été de placer un marqueur à la fin de mon paquet de données. Là plus de problème de taille, par contre un client malveillant pourrait simplement omettre ce marqueur et donc bloquer le serveur.

Alors voilà, je cherche une technique pour que le client ne puisse PAS bloquer le serveur. Je n'ai pas vraiment d'autres idées...

Merci,
Spootnik

[JulienDuSud]

Déjà, la sécurité de ton serveur ne devrait pas dépendre de la taille des packets. Si je comprend bien, tu lis l'en-tête, et tu boucles jusqu'à ce que tu reçois toutes les données. Revois ta conception parce que là il y a un gros problème.

Ton thread qui se charge de la réception des données ne devrait pas avoir à voir ce qu'il y a dedans, ce n'est pas sa responsabilité. Au mieux il devrait les bazarder tous dans un conteneur qu'une autre procédure va traiter. C'est cette procédure qui va faire le tri entre les bon pak et les mauvais.

Pour ce qui est de l'intégrité des données, tu peux partir sur un checksum, ou mieux, un crc.

Si tu as peur des attaques du style MITM, alors c'est tout un autre problème, c'est un problème de cryptographie. Je te conseille là d'utiliser un cryptage asymétrique type RSA et d'associer ta clé publique à un certificat. De cette manière, les attaques du type MITM seront neutralisés.

Par contre, si quelqu'un s'amuse à décortiquer ton protocol et à connaître son fonctionnement, rien ne l'empêchera de simuler un client et d'envoyer des packets.

Si ton serveur peut être planté en lui envoyant des packets spécifiques, alors ton serveur n'est pas sécurisé à sa racine. Et il faut que tu revois ça avant d'attaquer le cryptage et d'autres choses qui ne vont que compliquer la chose.

[Ceylo]

Déjà, la sécurité de ton serveur ne devrait pas dépendre de la taille des packets. Si je comprend bien, tu lis l'en-tête, et tu boucles jusqu'à ce que tu reçois toutes les données. Revois ta conception parce que là il y a un gros problème.

Ben ui c'est l'objet même de ce topic !

Ton thread qui se charge de la réception des données ne devrait pas avoir à voir ce qu'il y a dedans, ce n'est pas sa responsabilité. Au mieux il devrait les bazarder tous dans un conteneur qu'une autre procédure va traiter. C'est cette procédure qui va faire le tri entre les bon pak et les mauvais.

Mais comment justement ? Je peux vérifier si ce que j'ai reçu est interprétable. Mais si ça ne l'est pas que faire ? Attendre une suite des données qui peut ne jamais arriver ? J'ai besoin de pouvoir déterminer s'il manque un bout au paquet et que je dois patienter un peu où si je dois laisser tomber le début du paquet.

Pour ce qui est de l'intégrité des données, tu peux partir sur un checksum, ou mieux, un crc.

Ben quand je parlais d'intégrité des données, c'est avant tout savoir si j'ai reçu l'objet en entier ou pas. Pour ce qui de protéger la modification des données envoyées c'est autre chose. Tant que je suis capable de détecter que j'ai reçu un objet entier et valide pour l'instant cela me suffit.

Si tu as peur des attaques du style MITM, alors c'est tout un autre problème, c'est un problème de cryptographie. Je te conseille là d'utiliser un cryptage asymétrique type RSA et d'associer ta clé publique à un certificat. De cette manière, les attaques du type MITM seront neutralisés.

Hum non ce n'est pas mon soucis du moment. Je suppose que pour ce cas le fait d'utiliser une connexion sécurisée via le protocole TLS peut suffire non ?

Par contre, si quelqu'un s'amuse à décortiquer ton protocol et à connaître son fonctionnement, rien ne l'empêchera de simuler un client et d'envoyer des packets.

Comme je l'ai dit, que le paquet soit mauvais ou pas pour l'instant n'est pas le problème. Il faut juste que je puisse savoir si j'ai reçu un objet entier.

Si ton serveur peut être planté en lui envoyant des packets spécifiques, alors ton serveur n'est pas sécurisé à sa racine. Et il faut que tu revois ça avant d'attaquer le cryptage et d'autres choses qui ne vont que compliquer la chose.

Ben oui pour ça que je poste là .

[Mac LAK]

Et tu dois / veux absolument refaire ça toi-même (ce que je peux comprendre), ou tu veux juste la fonctionnalité quitte à utiliser une librairie tierce ?

[Ceylo]

Tout dépend de la complexité du principe. Pour l'instant j'aimerais savoir quelles techniques existent pour répondre à mon problème. Ensuite si la solution est facile à mettre en oeuvre moi-même, je préfère éviter une dépendance et l'implémenter, sinon ça ne me pose pas de problème d'utiliser une bibliothèque tierce.

[Mac LAK]

Alors ICE : ça va te plaire, tu peux même l'adapter sur l'iPhone, Silverlight, etc.

Regarde notamment du côté de IceBox+IceGrid, IceStorm, Glacier2, IceSSL sur leur site. T'as même un patcheur automatique si besoin...

[Ceylo]

Ce que tu proposes m'a l'air un peu énorme vu mon problème. D'après ce que j'ai compris il s'agirait d'un implémentation de type SOAP trèèèès améliorée. Enfin je vais essayer de regarder plus en détail (note qu'il y a déjà une implémentation de type SOAP fournie avec la bibliothèque Cocoa que j'utilise sous Mac OS X, idem sous les autres OS avec GNUStep).

Cependant, quand bien même cela pourrait résoudre mon problème, cela ne m'explique toujours pas la technique utilisée pour m'assurer que j'ai reçu l'objet en entier, ou que je dois arrêter d'attendre la suite.

[JulienDuSud]

Euh... recv fait ce que tu veux, non ?

Tu mets une taille max par pak de 1024b (par exemple) et tu fait recv. Tu recevras des objets complets un à un, TCP (même UDP d'ailleurs) va déjà faire tout le travail d'acheminement / reconstruction du pak à partir des trames, à ta place...

Quand quelqu'un t'envoi un pak de 500b, tu vas pas recevoir un premier pak de 200b et ensuite un autre de 300b, hein... De la même manière que tu ne vas pas recevoir d'un coup 600b si 2 personnes t'envoient chacun des pak de 300b...

Maintenant, si tu as des pak de plus de 1024b à recevoir, il faudra que tu mettes en place un système de fragmentation des pak.

A savoir que tu crées ton pak, si sa taille est > à 1024b, tu le découpes en pak de maximum 1024b, et tu les envoies un à un, avec un header qui va bien (nombre total de fragment, taille total du pak, numéro du fragment courant).

De l'autre côté, lorsque tu récupères les pak, tu regardes l'en-tête pour voir si c'est un pak fragmenté. Si c'en est un, tu l'envoi sur une pile de traitement de pak fragmenté, avec le timeout qui va bien...

[Ceylo]

Maintenant, si tu as des pak de plus de 1024b à recevoir, il faudra que tu mettes en place un système de fragmentation des pak.

Justement c'est là que ça se corse et qu'est mon problème. Et le système d'en-tête que tu décris présente le même problème que j'ai expliqué précédemment, à savoir que quelqu'un peut très bien falsifier l'en-tête (pas dur de modifier les sources du client pour ça) et on se retrouve avec le problème de blocage que j'ai décrit. Alors comment faire ? J'ai moyennement envie de commencer à partir dans les sources fermées avec cryptage pour pas qu'on puisse déterminer mon en-tête :/ .

[gl]

Quand quelqu'un t'envoi un pak de 500b, tu vas pas recevoir un premier pak de 200b et ensuite un autre de 300b, hein...

Si c'est tout à fait possible. Il n'y a aucune garantie en TCP que l'envoi d'un message de 500 octets soit reçu en un seul bloc de 500 octets. Le premier appel a recv() peut tout à fait retourner que les 200 premiers octets et un second appel fournir le reste, ou tout autre combinaison imaginable.

Et le système d'en-tête que tu décris présente le même problème que j'ai expliqué précédemment, à savoir que quelqu'un peut très bien falsifier l'en-tête (pas dur de modifier les sources du client pour ça) et on se retrouve avec le problème de blocage que j'ai décrit.

Il existe plusieurs solutions envisageables, par exemple :

• Gestion d'un time-out afin de ne pas rester bloquer indéfiniment.
• Signature ou chiffrement de l'en-tête.
• Authentification préalable du client.

[Ceylo]

Il existe plusieurs solutions envisageables, par exemple :

• Gestion d'un time-out afin de ne pas rester bloquer indéfiniment.

Le problème avec ça c'est que même avec un time-out de 1 seconde, il suffit que le client malveillant envoie les mauvais message en continu pour perturber très fortement le serveur. Ou alors il faudrait que je traite chaque entrée dans un thread séparé, mais ça deviendrait vite très lourd (et inutilisable dans le cas de nombreux clients connectés).

• Signature ou chiffrement de l'en-tête.

Peux-tu développer davantage ce à quoi tu penses ? Je comprends mal sur quoi serait basée la signature (si c'est un simple code il suffit de le prendre dans les sources) et pour le chiffrement de l'en-tête on en revient au protocole TLS, mais là encore à partir du moment où la technique de chiffrement est explicitée dans les sources, on peut très bien chiffrer une mauvaise en tête. Ou alors je n'ai pas compris ce que tu veux dire.

• Authentification préalable du client.

Je ne comprends pas bien non plus. Sur quel moyen je me baserais pour authentifier le client ? S'il s'agit d'un compte de connexion, je ne vois pas ce qui empêcherait un faux client de l'utiliser, et si tu ne parles pas de ça, je ne vois pas comment tu veux faire.

En tout cas cela me fait plaisir de lire ta réponse, car même si je n'ai pas encore (compris) de solution à mon problème, je vois que tu as bien cerné ce que je voulais dire.

Et à tous merci tout de même pour l'aide apportée !

[JulienDuSud]

Si ton protocol est découvert ou publique, tu auras du mal à empêcher quelqu'un de faire son logiciel et de t'envoyer les pak qu'il veut.

Si tu veux éviter que quelqu'un intercepte et modifie les données, tu peux le faire avec un cryptage asymétrique dont la clé publique est associée à un certificat d'authentification (certificat que le client utilisera pour authentifier la clé publiée par le serveur).

Maintenant, rien n'empêche personne de t'envoyer des pak montés de toutes pièces, et là, aucun cryptage ne te servira à rien (car si ton client peut crypter, tout le monde le peut, c'est le principe de chiffrements à clé publique.

Rien ne peut empêcher une personne malveillante de simuler le comportement du client jusqu'à un certain temps (authentification), et ensuite de t'envoyer des pak malhonnêtes.

Cependant le cryptage/l'authentification doit venir bien après que ton protocole soit au point. Là à priori ton protocole n'est pas au point. (vu que ton serveur ne réagit pas correctement aux cas inattendus).

La solution est pourtant bien simple: tu ne dois pas "attendre". Tu dois traiter ce que tu as déjà reçu. Le reste (timeout, etc...) viendra naturellement et sans perturber le fonctionnement normal du serveur (qui n'est rien d'autre que "écouter" et "traiter" mais jamais "attendre").

Tu écoutes en perma ton socket et tu mets au fur et à mesure que tu reçois tes données dans une liste FIFO thread-safe.

De l'autre côté, tu vas piocher dans ce FIFO:

• Tu traites les données qui peuvent être traitées directement.
• Si les données sont incomplètes, tu les mets dans une autre liste (voir même liste de liste).
• Si jamais une liste de données incomplètes se complète, tu la traite.
• Si la dernière mise à jour d'une liste date de plus longtemps que ton timeout, tu supprimes cette liste sans la traiter (ou tu préviens le client que son packet a time out, ou qu'il est incorrect, ou qu'il est pas gentil de ne pas te raconter la suite de l'histoire).

Il n'y a aucune perturbation, tu n'attends rien de spécial, si ce n'est que des données (n'importe lesquels, tu t'en fous): tu traites les choses au fur et à mesure de ce que tu peux.

Le fonctionnement de ton serveur ne doit surtout pas dépendre de ce qu'envoit le client. En réalité, peu importe ce qu'on t'envoi, le serveur ne doit jamais s'attendre à recevoir de nouveaux trucs voir pire "bloquer jusqu'à ce qu'il recoive ce qu'il s'attend à recevoir".

Le serveur doit juste "écouter" et "traiter ce qu'il peut". Il ne doit jamais se trouver dans une situation "attend attend j'ai pas eu la fin, il va bien me l'envoyer un jour, j'attend !"

D'ailleurs la même chose s'applique du côté client, mais à moindre mesure (dans le sens où si un client plante, le serveur s'en fout, mais si le serveur plante, le client est un peu dans la merde)

[gl]

Concernant le time-out, oui ce n'est peut être suffisant, ne connaissant pas ton projet je ne saurais le dire.
Le choix d'une méthode dépends fortement de tes contraintes et besoins.

Concernant la signature de l'en-tête, on en arrive là encore à utiliser de la crypto. En gros chaque client signe l'en-tête avec sa clé privé et le serveur connait les clés publique des différents clients légitime et peut vérifier cette signature (par contre un tel système complexifie énormément le déploiement).
L'authentification préalable du client, c'est du même style.

Maintenant là encore, je ne sais pas à priori dire si cela convient à ton cas ou non (ce sont des mécanismes assez lourd à mettre en place qui sont peut être excessif par rapport au risque encouru).

[Ceylo]

Maintenant, rien n'empêche personne de t'envoyer des pak montés de toutes pièces, et là, aucun cryptage ne te servira à rien (car si ton client peut crypter, tout le monde le peut, c'est le principe de chiffrements à clé publique.

D'accord, bon j'écarte cette voie donc.

La solution est pourtant bien simple: tu ne dois pas "attendre". Tu dois traiter ce que tu as déjà reçu. Le reste (timeout, etc...) viendra naturellement et sans perturber le fonctionnement normal du serveur (qui n'est rien d'autre que "écouter" et "traiter" mais jamais "attendre").

Tu écoutes en perma ton socket et tu mets au fur et à mesure que tu reçois tes données dans une liste FIFO thread-safe.

De l'autre côté, tu vas piocher dans ce FIFO:

• Tu traites les données qui peuvent être traitées directement.
• Si les données sont incomplètes, tu les mets dans une autre liste (voir même liste de liste).
• Si jamais une liste de données incomplètes se complète, tu la traite.
• Si la dernière mise à jour d'une liste date de plus longtemps que ton timeout, tu supprimes cette liste sans la traiter (ou tu préviens le client que son packet a time out, ou qu'il est incorrect, ou qu'il est pas gentil de ne pas te raconter la suite de l'histoire).

Il n'y a aucune perturbation, tu n'attends rien de spécial, si ce n'est que des données (n'importe lesquels, tu t'en fous): tu traites les choses au fur et à mesure de ce que tu peux.

Le fonctionnement de ton serveur ne doit surtout pas dépendre de ce qu'envoit le client. En réalité, peu importe ce qu'on t'envoi, le serveur ne doit jamais s'attendre à recevoir de nouveaux trucs voir pire "bloquer jusqu'à ce qu'il recoive ce qu'il s'attend à recevoir".

Le serveur doit juste "écouter" et "traiter ce qu'il peut". Il ne doit jamais se trouver dans une situation "attend attend j'ai pas eu la fin, il va bien me l'envoyer un jour, j'attend !"

D'ailleurs la même chose s'applique du côté client, mais à moindre mesure (dans le sens où si un client plante, le serveur s'en fout, mais si le serveur plante, le client est un peu dans la merde)

Je pense que j'ai compris, maintenant reste à l'appliquer, mais effectivement cela résoudrait mon soucis .

Concernant le time-out, oui ce n'est peut être suffisant, ne connaissant pas ton projet je ne saurais le dire.
Le choix d'une méthode dépends fortement de tes contraintes et besoins.

Pour l'instant (je dis bien pour l'instant) le cadre est un IUT d'informatique avec... des étudiants, et des profs ! Ok bon trêve de plaisanterie, je suis d'accord qu'on n'est pas du tout dans un environnement critique, mais je m'attends tout de même à ce que certains petits vicieux s'amusent à mettre à l'épreuve le serveur .

Concernant la signature de l'en-tête, on en arrive là encore à utiliser de la crypto. En gros chaque client signe l'en-tête avec sa clé privé et le serveur connait les clés publique des différents clients légitime et peut vérifier cette signature (par contre un tel système complexifie énormément le déploiement).
L'authentification préalable du client, c'est du même style.

Maintenant là encore, je ne sais pas à priori dire si cela convient à ton cas ou non (ce sont des mécanismes assez lourd à mettre en place qui sont peut être excessif par rapport au risque encouru).

Oui comme tu dis niveau déploiement c'est assez complexe. Mon objectif est d'arriver au final à un client capable d'héberger des discussions ou de participer à des discussions hébergées sur un autre poste sans aucune autre configuration que... détecter les serveurs actuellement lancés sur le réseau local, se connecter à l'un, chatter; ou lancer un serveur et attendre que quelqu'un s'y connecte. Donc pour l'instant aucune nécessité de cryptage.

[gl]

Mon objectif est d'arriver au final à un client capable d'héberger des discussions ou de participer à des discussions hébergées sur un autre poste sans aucune autre configuration que... détecter les serveurs actuellement lancés sur le réseau local, se connecter à l'un, chatter; ou lancer un serveur et attendre que quelqu'un s'y connecte. Donc pour l'instant aucune nécessité de cryptage.

Pour les logiciels de discussion en ligne type IRC, c'est généralement assez simple : tout ce qui arrive est consommé et transféré et/ou affiché.
Pour ce genre de traitement, l'idée de JulienDuSud me semble plutôt bien adapté.

[Ceylo]

En fait en continuant de discuter du problème sur le forum d'origine (celui de la bibliothèque réseau que j'utilise), je me suis rendu compte que le fait que le début du paquet contienne la taille des données à suivre n'est pas vraiment le problème tant que la lecture qui suit ne bloque pas.

La solution consisterait donc à utiliser cette taille pour déterminer si l'objet est complet ou pas, mais à n'utiliser que des sockets non bloquants et à ajouter les données au fur et à mesure qu'elles arrivent pour compléter les paquets.

Je pourrais éventuellement fixer une limite à la taille de ces paquets pour empêcher un client malveillant de bouffer toute la mémoire vive du serveur en accumulant les données.

Quand j'ai dit type IRC c'est parce que le système de canaux y ressemble fortement, mais sinon je pense gérer les objets transmis uniquement une fois qu'ils le sont complètement (c'est beaucoup plus clair dans mon esprit de cette façon).

[Mac LAK]

Ce que tu proposes m'a l'air un peu énorme vu mon problème. D'après ce que j'ai compris il s'agirait d'un implémentation de type SOAP trèèèès améliorée.

Plutôt CORBA, en fait, mais réellement intéropérable. Contrairement à SOAP, les données transitent au format binaire et non pas XML, et la mise en oeuvre se fait directement par génération de code : tu définis l'interface, il pond le code client automatiquement et le proto du code serveur, tu n'as plus qu'à remplir les méthodes serveur.

Cependant, quand bien même cela pourrait résoudre mon problème, cela ne m'explique toujours pas la technique utilisée pour m'assurer que j'ai reçu l'objet en entier, ou que je dois arrêter d'attendre la suite.

Justement : tu n'as RIEN à faire, ICE s'en charge. Quand le message est complet, t'as une callback. Sinon, c'est géré automatiquement par les runtimes ICE.

C'est pas beau, la vie ?

[Ceylo]

Ben... c'est bien beau mais une bibliothèque comme celle que tu proposes ça met quand même un certain temps à apprendre.

Et quand j'ai dit que je veux bien prendre une bibliothèque tierce si la solution est trop complexe à implémenter, ça ne veut pas dire pour autant que je ne souhaite pas savoir comment mon problème a été résolu. Là en l'occurrence je ne sais pas comment ICE s'assure que personne ne falsifie les données, comme il sait que tout a été reçu , etc.

Petite remarque aussi, tu dis que les données transitent au format binaire et non pas XML, quel intérêt cela a-t-il ? Si c'est juste niveau taille il y a largement moyen de compresser les données XML, et ce langage me semble très largement adapté vu que je souhaite pouvoir envoyer des données (structurées).

Alors comme expliqué plus haut, je vais simplement rendre le socket non bloquant et ajouter une limite pour la taille des paquets. Avec la bibliothèque que j'utilise (SFML) cela nécessitera très peu de changements et résoudra très bien mon problème.

[Mac LAK]

Ben... c'est bien beau mais une bibliothèque comme celle que tu proposes ça met quand même un certain temps à apprendre.

Yep, environ une journée via les exemples fournis dans la doc, tant que tu utilises les fonctions de base (ce qui est ton cas).

Là en l'occurrence je ne sais pas comment ICE s'assure que personne ne falsifie les données, comme il sait que tout a été reçu , etc.

Par ses propres protocoles, de type RPC : il sait si un paquet ICE est intègre ou pas, et ne décode ça qu'après avoir déjà garanti l'arrivée intègre d'un paquet ICE. Pour ça, il utilise un peu le principe de la recombinaison des paquets fait par TCP/IP, mais encore un cran au dessus.

Petite remarque aussi, tu dis que les données transitent au format binaire et non pas XML, quel intérêt cela a-t-il ? Si c'est juste niveau taille il y a largement moyen de compresser les données XML, et ce langage me semble très largement adapté vu que je souhaite pouvoir envoyer des données (structurées).

Taille sur le réseau, vitesse de traitement, simplicité du code (et donc potentiellement moins de bugs), etc.
Traiter de l'XML, c'est "lent", s'il faut en plus le compresser de part et d'autre, c'est encore pire.


Après, tu peux prendre toute solution qui te convient bien entendu, c'est juste qu'établir une connexion réseau réellement fiable est relativement long et fastidieux : autant utiliser des bonnes librairies qui le font déjà, et ICE en fait partie.

[Ceylo]

Yep, environ une journée via les exemples fournis dans la doc, tant que tu utilises les fonctions de base (ce qui est ton cas).

Si tu le dis, mais ce n'est pas mon avis. J'ai regardé un peu la bibliothèque et c'est un sacré bazar. Alors si en plus j'ai une solution simple à mettre en oeuvre qui résout mon problème, je n'en vois pas l'intérêt.

Par ses propres protocoles, de type RPC : il sait si un paquet ICE est intègre ou pas, et ne décode ça qu'après avoir déjà garanti l'arrivée intègre d'un paquet ICE. Pour ça, il utilise un peu le principe de la recombinaison des paquets fait par TCP/IP, mais encore un cran au dessus.

Tu peux en dire un peu plus là dessus ? Comment est-ce que cela fonctionne plus exactement ?

Taille sur le réseau, vitesse de traitement, simplicité du code (et donc potentiellement moins de bugs), etc.
Traiter de l'XML, c'est "lent", s'il faut en plus le compresser de part et d'autre, c'est encore pire.

Je ne suis pas du tout d'accord sur la simplicité du code. C'est un gros point noir de la bibliothèque que tu proposes. Quant à la vitesse de traitement, c'est pas non plus comme s'il s'agissait une grille de calcul ! Je pense que dans mon cas c'est très largement négligeable et que XML convient parfaitement.

Après, tu peux prendre toute solution qui te convient bien entendu, c'est juste qu'établir une connexion réseau réellement fiable est relativement long et fastidieux : autant utiliser des bonnes librairies qui le font déjà, et ICE en fait partie.

Ben quand il faudra s'occuper de sécuriser la connexion via TLS peut-être, mais en attendant je préfère éliminer les sources inutiles de travail .