Discussion :

[dreadjunk]

Salut,

Je suis en train de faire un client serveur en C sur windows. Le client envoie des données sur le serveur qui s'occupe des les écrires sur une BDD. Quand le serveur a récupérer toute les données il renvoit au client la longueur des données reçu pour vérifier qu'il n'y est pas d'erreur.

Au niveau de la reception des données sur le serveur et l'écriture sur la BDD aucun problème. J'ai rajouté récemment la fonction pour le serveur de renvoyé le nombre de caractère au client pour vérifier si il y a des erreurs et depuis le serveur et le client restent bloqués sur la fonction recv, comme si chacun attendais de recevoir un message ...

Est ce qu'il y a une procédure particulière a mettre en place quand on souhaite que son serveur puisse réceptionner des données et en envoyé? Comme déconnecté la connexion et la remettre en place ensuite?

Voici le code :

Serveur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
static int read_client(SOCKET sock, char *buffer)
{
    int n = 0;
    int compteur = 0;
 
    do
    {
        printf("test 5 \n");
        if((n = recv(sock, buffer, MAX_SIZE - 1, 0)) < 0) //problème ici, le serveur s'attends a recevoir quelque chose mais il reçoit rien !
        {
            printf("test 1 \n");
            n = 0;
            if(compteur == 0)
            {
                perror("recv()");
                exit(errno);
            }
        }
        compteur += n;
        buffer[n] = 0;
        printf("Longueur message : %i \n", n);
        printf("buffer : %s \n", buffer);
        if(n != 0)
        {
            query_mysql(buffer);
        }
        printf("test 4 \n");
    }
    while( n != 0);
 
    printf("test 2 \n");
    printf("longueur total message : %i \n", compteur);
    char str_compteur[16];
    sprintf(str_compteur, "%i", compteur);
    printf("str_compteur : %s \n", str_compteur);
    write_client(sock, str_compteur); //envoie le nombre de caractère du message reçu pour effectuer un test dessus
 
    return compteur;
}

Client :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
static void read_and_send_file(SOCKET sock)
{
    FILE* fichier = NULL;
    char str[MAX_SIZE];
    int i = 0;
 
    fichier = fopen(PATH_TXT,"r");
    if(fichier != NULL)
    {
        while(fgets(str, MAX_SIZE, fichier) != NULL)
        {
            printf("nb boucle : %i \n", i);
            printf("str : %s \n", str);
            write_server(sock, str);
            i++;
        }
        fclose(fichier);
        char buffer[16];
        printf("test 1 \n");
        //recv_server(sock, buffer);
        printf("read_and_send_file buffer : %s \n", buffer);
    }
    else
    {
        perror("fopen");
    }
}

PS : le client stocke sur un fichier .txt les données avant de les envoyé.

Merci d'avance !

[Bousk]

Salut,

le serveur et le client restent bloqués sur la fonction recv, comme si chacun attendais de recevoir un message ...

Si c'est bloqué sur recv c'est exactement ce qu'il se passe oui.

Est ce qu'il y a une procédure particulière a mettre en place quand on souhaite que son serveur puisse réceptionner des données et en envoyé?

Il faut mettre en place une architecture du code cohérente. Si t'es bloqué sur recv c'est que tu ne devrais peut-être pas encore appeler recv ?

Comme déconnecté la connexion et la remettre en place ensuite?

Surtout pas, une connexion ça se maintient sinon.. ben t'es déconnecté.

Ton architecture du code est sûrement mauvaise. Le code client que tu montres ne montre pas grand chose. Ton code serveur n'a aucun send donc je vois pas bien où tu dis envoyer quelque chose ?
Tu peux aussi utiliser le mode non bloquant.
Et dans tous les cas, recv reçoit un maximum de données et rarement tout ce que tu attends : http://bousk.developpez.com/cours/re...-protocole/#LI

[Matt_Houston]

En TCP, renvoyer la quantité de données reçues est inutile : c'est déjà garanti par le protocole. Si tu cherches à doublement vérifier l'intégrité de ton message, joins-lui une clef de hachage (quelque chose de plus costaud qu'un CRC32, s'entend).

[dreadjunk]

Désolé Bousk j'ai oublié quelques bouts de programme, il est assez long ...

Matt_Houston, donc ca veut dire que a partir du moment ou les données sont envoyés en TCP on peut être sur qu'elles sont reçu ?
Je voulais mettre en place cette vérification pour pouvoir supprimer le fichier .txt qui contient toute les données après un envoie, mais si c'est le cas j'aurais juste a compter le nombre de fois ou l'envois s'effectue alors.

[Matt_Houston]

Le protocole te garantit que les paquets sont passés, oui, mais ne fait pas de vérification d'intégrité.

Tu as deux solutions pour mettre ça en place :

• l'implémenter a la mano dans la couche de ton application (bon courage) quitte à simplement calculer un hash ajouté en fin de message ;
• utiliser un protocole sécurisé (TLS) via une bibliothèque dédiée (GnuTLS, openssl..), qui t'apportera également le chiffrement et la résistance à la corruption volontaire (man-in-the-middle).

Si tu as ne serait-ce qu'une seule contrainte de sécurité pour ton application, seule la seconde solution est viable.

[dreadjunk]

Pas de problème de sécurité je vais alors essaye de vérifier un hash en fin de message ! Est ce qu'il existe des fonctions qui permettent de hasher des strings directement ou je dois créer moi même une table de hash?

Par contre, dans le cas ou la vérification est fausse, je vais devoir renvoyé un message a mon client pour lui demander de renvoyer le message, et donc j'en reviens a mon problème de base non?

[Bousk]

Oui TCP t'assure que les données vont être reçues, sans corruption et dans l'ordre, si tentée que la connexion n'est pas interrompue entre temps.
Si ton souci est juste ça, le serveur peut bien retourner n'importe quoi au client à la fin de son traitement. Si le client reçoit ça, il est sûr que le serveur a tout exécuté.

[Matt_Houston]

Je me suis mal exprimé dans mon précédent message : plusieurs vérifications d'intégrité sont réalisées par les différentes couches et l'ensemble est relativement robuste mais pas immunisé toutefois contre une corruption accidentelle. Les chances sont très faibles mais ça peut arriver, et d'ailleurs ça arrive. Tu peux implémenter une couche supplémentaire de hachage dans l'application pour encore augmenter la robustesse si tu as une contrainte d'absolue exactitude des données transmises.

En général cette contrainte accompagne une contrainte de sécurité. Si tu n'as la seconde tu peux probablement te limiter à ce que t'offre TCP, également oublier la première et gagner en simplicité.

Même pas besoin de confirmation IMHO, sauf si l'opération interne de traitement côté serveur peut échouer et nécessiter une mise à jour du message par le client.

[dreadjunk]

Ok parfait merci

Je n'ai pas d'obligation absolue d'exactitude des données.
Par contre j'ai une possibilité que internet coupe au niveau du client. Est ce que le TCP prend en compte ceci?

[sambia39]

Bonsoir
Attention TCP a bel et bien un contrôle d’intégrité qui est communément appelé "somme de contrôle" et qui garantit la réception fiable et intacte des données émises au client pas besoin d’une autre somme de contrôle en plus, car il garantie que vous aurez tel qu’il est le fichier émis et dans l’ordre. Pas besoin également de mettre en place quoi que ce soit et encore moins sécuriser une connexion sauf si les données qui vont être émises sont sensible et même étant sensibles avants toute envoie en s’assure de chiffrer les données puis établir une connexion sécuriser avec un protocole adéquat avants d’envoyer les data. De plus, dire que des protocole comme SSL (openssl) permet d’éviter des attaques du type MITM c’est pas si sûr; un attaquant qui se renseigne bien sûr la chose remarquera par exemple que SSL ne vérifie pas forcément les certificats il peut alors très bien rediriger le flux mieux encore, une attaque par force brute peut également très bien faire l’affaire sur des clefs en employant des techniques comme le rollback dans lesquelles l'attaquant essaye de modifier algorithme d'échanges des clés afin que les protagonistes n'utilisent pas le mêmes protocoles dans le but déchiffrer le message ou simplement implanté sur la machine cliente des rootkits permettant l’intercepter les requêtes clients pour ensuite se faire passer pour le client auprès du serveur ce qui lui donnerait un accès au différent contenu protégé. Cependant ce n’est pas le sujet ici.
Si les données qui vont être soumises a vos clients sont sensibles alors opté pour la sécurité cas contraire TCP fait très bien l’affaire même si je dois l’avoue TCP a quelque faiblesse que je ne vais pas aborder ici
à bientôt.

[Matt_Houston]

Attention TCP a bel et bien un contrôle d’intégrité qui est communément appelé "somme de contrôle" et qui garantit la réception fiable et intacte des données émises au client pas besoin d’une autre somme de contrôle en plus, car il garantie que vous aurez tel qu’il est le fichier émis et dans l’ordre.

Faux. Les chances d'obtenir une somme de contrôle TCP identique après corruption de plusieurs bits sont faibles, mais elles ne sont pas nulles et de tels cas se produisent.

Pas besoin également de mettre en place quoi que ce soit et encore moins sécuriser une connexion sauf si les données qui vont être émises sont sensible et même étant sensibles avants toute envoie en s’assure de chiffrer les données puis établir une connexion sécuriser avec un protocole adéquat avants d’envoyer les data.

Autrement dit : on n'a pas besoin de chiffrer sauf si on a besoin de chiffrer..

De plus, dire que des protocole comme SSL (openssl) permet d’éviter des attaques du type MITM c’est pas si sûr;

Si ça sert à rien on se demande pourquoi on l'utilise.. Personne n'a dit que les protocoles sécurisés étaient infaillibles, il existe plusieurs angles d'attaque nécessitant plus ou moins de ressources. Ah, et SSL est obsolète : on parle désormais uniquement de TLS.

[sambia39]

Bonjour,

Je vais essayer de faire simple, j’ai écrit :"Attention TCP à bel et bien un contrôle d’intégrité qui est communément appelée "somme de contrôle" et qui garantit la réception fiable et intacte des données émises au client pas besoin d’une autre somme de contrôle en plus, car il garantit que vous aurez tel qu’il est le fichier émis et dans l’ordre."

Et avant de répondre à ce que vous avez écrit "Faux. Les chances d'obtenir une somme de contrôle TCP identique après corruption de plusieurs bits sont faibles, mais elles ne sont pas nulles et de tels cas se produisent."
Je vais reste sur mon lancer en maintenant que TCP est bien un protocole fiable qui garantit l'ordre et la remise des paquets, vérifie l’intégrité l'en-tête des paquets et des données qu'ils contiennent. TCP est également responsable de la retransmission des paquets sous sa responsabilité si celle-ci a été corrompue ou perdue lors de leur transmission.

Vous avez parlé de corruption de plusieurs bits, mais ces corruptions en question vont apparaître dès lors ou en dépassent les 32 bits de séquence Ethernet « et encore… Techniquement cela veut dire que 4 giga de données peuvent être échangé entre l’émetteur des données et le récepteur (en l’occurrence le serveur et le client) sans qu’il ait d’erreur ou corruptions de séquences, mais au-delà ou l’envoie de plusieurs séquences de plus de 32 bits pourraient causer des corruptions des séquences.
Tout de même le FCS est capable de détecter ces erreurs. La correction de ces erreurs sera à la charge de TCP/IP (et non Ethernet). Les fameuses quelque ou plusieurs bits corrompus qui arriveraient à passer viennent ( et la plupart du temps) d’une mauvaise interprétation. Je m’explique chaque périphérique Ethernet doit recalculer les séquences FCS; ces calculs sont pour la plupart effectue soit par le pilote de la carte Ethernet ou par la puce de la carte elle-même et donc toute erreur au niveau de la carte (perte de connexion ou autres) et même au niveau supérieur (mémoire ou bus) entraînera la validation d’une séquence Ethernet valide. Tout comme fait cela sous-entend que Ethernet détecte les erreurs, mais ne déclenche pas le traitement de celle-ci; c’est au CRC (16 bits) TCP/IP de détecter l’erreur de données en question et ainsi déclencher une récupération d'erreur qui est le renvoi d’une nouvelle séquence, car la précédente a été considérer comme étant erroné ou alterné (je précise que le CRC TCP/IP est capable de détecter les erreurs et les corriger) plus simplement: Le champ FCS contient des séquences de nombres qui sont calculés avec la source émettrice et en fonction des données . Ces numéros seront par la suite associés aux données qui seront envoyées. Lorsque le destinataire reçoit la trame, le numéro FCS est recalculé et comparé au numéro FCS inclus dans la trame. Si les deux nombres sont différents, une erreur est supposée et la trame est rejetée. L’expéditeur des données va alors déclencher une séquence de vérification (CRC) sur l'ensemble des données puis le destinateur va alors recalculer et faire la vérification avec le CRC sur la trame en utilisant le même algorithme puis compare avec celui du FCS Ethernet de cette façon il peut d'alors détecter si des données ont été perdues ou modifiées pendant le transfert si c'est le cas il peut alors refuser l’acquisition de ces données et demander une retransmission du segment défaillant.

Aux finales les données corrompues en question surviennent à plus de 32 bits de données émie ou en envoie massifs contigus de plus de 32 bits. Les erreurs dites de corruption des données peuvent être également de plusieurs facteurs comme une mauvaise interprétation de séquence, coupure de connexion, etc. Sans oublier bien avants ça, le fichier ou la donnée en elle-même peut bien être avants leur envoie, être alterné ou corrompu. Ce qui justifie l’envoi d’une autre somme de contrôle pour le fichier en question. Une solution consisterait à compresser les donner dans un fichier zip et si le fichier zip ne peut être ouvert à coup sûr les données sont clairement alternés.
En ma connaissance aucune information ne pourrait affirmer qu’il est des corruptions de données sérieuses et c’est toujours un débat où les avis divergents, mais tous sont d’accord que le TCP garanti la transmission des données j’irais jusqu’à dire TCP/IP.

Autrement dit : on n'a pas besoin de chiffrer sauf si on a besoin de chiffrer..

Les données à envoyer au client sont-elles des données sensibles ? si non alors, pourquoi chiffré ? Si oui en chiffre puis en établie une connexion sécuriser pour empêcher que l’en interceptent les informations et même si on l’intercepte il sera plus difficile voire impossible à un attaquant de déchiffrer le message.

Si ça sert à rien on se demande pourquoi on l'utilise.. Personne n'a dit que les protocoles sécurisés étaient infaillibles, il existe plusieurs angles d'attaque nécessitant plus ou moins de ressources. Ah, et SSL est obsolète : on parle désormais uniquement de TLS.

Une chose importante. Je n’ai jamais écrit ou fait faire sous-entendre que ça ne servait à rien (ce n’est pas ce que j’ai écrit). J’ai écrit "Pas besoin également de mettre en place quoi que ce soit et encore moins sécuriser une connexion sauf si les données qui vont être émises sont sensibles et mêmes étant sensibles avants toute envoie en s’assure de chiffrer les données puis établir une connexion sécuriser avec un protocole adéquat avants d’envoyer les data. "
Et par la suite j’ai parlé de compromission qui peut y avoir sur les protocoles en citant comme exemple SSL (Openssl) avec certaines techniques.

Oui en parle de TLS d’accord ça va de soi. Chose peut-être que vous ne savez pas c’est que SSL 3.0 a servi de base à TLS qui, par conséquent, est parfois référé comme étant SSL 3.1. Les deux termes SSL et TLS sont souvent utilisés de manière interchangeable ou conjointe; ils utilisent tous deux des algorithmes de chiffrements similaires bien qu'il existe des algorithmes plus récents de meilleure qualité qui ne sont disponibles qu'avec des versions plus récentes de TLS. Pour informations même s’il est de meilleure qualité TLS il possède des vulnérabilités par exemple des attaques du type DROWN ou encore du type KCI qui exploite très bien MITM bref et toute bonne attaque ne nécessite pas plus ou moins de ressource elle nécessite la connaissance parfaite du protocole. L’exploitation de ces vulnérabilités peut alors par la suite être exploitée par des ressources conçues à cet effet tout comme les correctifs de ces vulnérabilités (outils d’exploitations de vulnérabilité ou correctifs).

Conclusion: je maintiens mon avis. Le TCP suffit et si c’est des données sensibles alors chiffrer vos données et établissez une connexion chiffrée ou optée pour des données compressées si vous être paranoïaque alors opter pour un chiffrement de bout en bout.

à bientôt

[Matt_Houston]

Bonjour le wall-of-text.. tu m'excuseras, mais je vais faire court plutôt que cours.

Les données à envoyer au client sont-elles des données sensibles ? si non alors, pourquoi chiffré ? Si oui en chiffre puis en établie une connexion sécuriser pour empêcher que l’en interceptent les informations et même si on l’intercepte il sera plus difficile voire impossible à un attaquant de déchiffrer le message.

Allôôô.. on est en 2017 : toutes données sont sensibles. Dans un monde où la surveillance de masse est une réalité et où de plus les régimes autoritaires forment majorité, ne pas chiffrer un message dont tout ou partie transite sur un réseau public relève - selon moi - de la faute professionnelle lourde.

[sambia39]

Bonsoir,

Vu votre réponse et ma réponse qui va suivre j’ai peur de faire du hors sujet et je m’en excuse d’avance auprès du modérateur et administrateur. Nous pourrions bien volontiers débattre du sujet de chiffrements dans un autre forum qui est dédié au chiffrement sur le site. Néanmoins je vais répondre car j’estime qu’il y a pour ma part des choses auxquels je ne suis pas d’accord et je me dois d’apporter mon point de vue et d’éclaircir certains points sur lequel j’ai évoqué ou pas encore évoqué.

Selon moi la politique paranoïaque du tout chiffrement peut être très utile pour vous ou pour d’autres qui on jugent que cela est très utile et fiable; mais à mon sens le tout chiffré n’est pas adapté pour l’ensemble des natures des données des infrastructures informatiques et du contexte sur lequel gravitent ces ensembles et surtout sur les menaces et vulnérabilité actuel je m’explique:

Personnellement j’opte non pas pour le tout chiffré, mais plutôt pour de la stratégie de chiffrements (référence a la précédente discussion) plus exactement de la stratégie de sécurité. On faisant la distinction de ce qui est de l’ordre du sensible, confidentiel, secret, très secret, légal ou illégal (si je pousse le bouchon plus loin) et ceux, tout simplement parce que l’on utilisera une ou un ensemble d’outils conçus que l’on configure et applique (politique de sécurité) en fonction du contexte et de l’activité que l’on exerce (dans une entreprise ou a titre personnelle l’égale ou illégale, etc.). Sans oublier les ressources employées à laquelle la politique de sécurité va être appliquée pour garantir la confidentialité de nos activité, donnée ou infrastructure.

Exemple: Quelle politique (dispositifs) de sécurité pourrais-je appliquer pour éviter un accès à mon ordinateur (où celui que je partage avec mon collègue) ? : Un dispositif d'authentification par mots de passe , reconnaissance vocale ou par empreinte digitale (Ici c’est définir qui peut avoir accès à la machine, quelle sont les droits qui lui sont définis, les ressources, donnée que l’utilisateur authentifié est en mesure d’exploité).

Quelle est la politique de sûreté que je peux établir quant à la confidentialité de mes données: Le chiffrement de celle-ci en utilisant diverses clefs de chiffrements forts par exemple AES.

Quelle politique de sûreté dois-je employer pour garantir mes communications ma navigation sur internet ?: Utiliser une connexion sécuriser avec un protocole sûr, un VPN, Proxy et éventuellement une connexion sécurisée chiffrée de bout en bout

Si je me trouve en Chine et que je souhaite correspondances avec un ami en lui soumettant par courriel un document secret dont le titre est "Le tibe une visite cachée", comment je peux envoyer le courriel sans que l’Unité 61398 chargée de conduire des opérations militaires dans le domaine des réseaux informatiques puisse lire le contenue de mon message : PGP par exemple
Etc..

Par ces quelques exemple et chose que vous ne savez peut-être pas . L’ensemble des outils ou dispositifs de sécurité et confidentialité que vous disposez peut-être en votre possession sont utilisé pour garantir la sûreté des infrastructures, communication, correspondance, donnée personnelle qu’à un certain niveau et domaine précis. (Antivirus pour la lutte contre les logiciels malveillants IDS, VPN , proxy pour le réseaux PGP pour les mails etc..)

Vous avez parlé de faute professionnelle et de réseaux publics que je cite ci-dessous:

Bonjour le wall-of-text.. tu m'excuseras, mais je vais faire court plutôt que cours.
Allôôô.. on est en 2017 : toutes données sont sensibles. Dans un monde où la surveillance de masse est une réalité et où de plus les régimes autoritaires forment majorité, ne pas chiffrer un message dont tout ou partie transite sur un réseau public relève - selon moi - de la faute professionnelle lourde.

Je ne vais pas vraiment rentrer dans les détails (Je ne vois pas vraiment pourquoi vous avez parlé de faute professionnelle ? ), cependant Je dirais ceci. Tout dispositif dans le but de sécuriser les infrastructures informatiques d’une entreprise doit être bien pensée, réfléchie et parfaitement établie et planifiée. Il ne suffit pas de mettre en place des stratégie de sécurité selon les besoins et cas puis basta non cela ne garantit en rien une sécurité forte. Une bonne stratégie sécuritaire ce doit d'être un processus en perpétuelle évolution et complexe sans préparations toute stratégie de sécurité mise en place échoueront. Tout simplement parce qu’elle présente des failles qui peuvent être simple ou plus complexe selon les vecteurs d’approche. Cela peux très bien venir des logiciels employer dite non sécurisé (une élévation de privilège peut avoir lieu ou compromission de protocole dans ce cas de figure en parle de compromission interne car elle se trouve en amont du dispositifs de sécurité externe exemple logiciel word non mise a jours) cela peut également être volontaire ou involontaire cas du facteur humain (corruptions du personnel, chantage, etc.).

Je ne dis pas non au chiffrement. Cependant, je pense qu’on n’est tout d’avis et ceux sans exception que de nos jours qu’il existe de nombreuses vulnérabilités et menaces pour nos données et notre vie privé. C’est un fait. Et à cela ont se doit de développer et mettre en place des protections adaptées à chacune de ces menaces. En fessant cela, on met en place une stratégie ou ensemble de règles de sûreté de nos données. Voilà ma vision des choses vous pouvez très bien ne pas être d’accord avec cela.

à bientôt