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...