Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2017
    Messages : 14
    Points : 11
    Points
    11

    Par défaut Question sur l'envoi de donnée d'un serveur vers un client

    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 !

  2. #2
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 893
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 893
    Points : 26 067
    Points
    26 067

    Par défaut

    Salut,
    Citation Envoyé par dreadjunk Voir le message
    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.

    Citation Envoyé par dreadjunk Voir le 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é?
    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 ?

    Citation Envoyé par dreadjunk Voir le message
    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
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  3. #3
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 179
    Points
    4 179

    Par défaut

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

  4. #4
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2017
    Messages : 14
    Points : 11
    Points
    11

    Par défaut

    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.

  5. #5
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 179
    Points
    4 179

    Par défaut

    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.

  6. #6
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2017
    Messages : 14
    Points : 11
    Points
    11

    Par défaut

    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?

  7. #7
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 893
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 893
    Points : 26 067
    Points
    26 067

    Par défaut

    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é.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  8. #8
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 179
    Points
    4 179

    Par défaut

    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.

  9. #9
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2017
    Messages : 14
    Points : 11
    Points
    11

    Par défaut

    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?

  10. #10
    Membre expérimenté
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    mai 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : mai 2010
    Messages : 453
    Points : 1 608
    Points
    1 608

    Par défaut

    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.
    Celui qui peut, agit. Celui qui ne peut pas, enseigne.
    Il y a deux sortes de savants: les spécialistes, qui connaissent tout sur rien,
    et les philosophes, qui ne connaissent rien sur tout.
    George Bernard Shaw

  11. #11
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 179
    Points
    4 179

    Par défaut

    Citation Envoyé par sambia39 Voir le message
    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.


    Citation Envoyé par sambia39 Voir le message
    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..


    Citation Envoyé par sambia39 Voir le message
    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.

  12. #12
    Membre expérimenté
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    mai 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : mai 2010
    Messages : 453
    Points : 1 608
    Points
    1 608

    Par défaut

    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.

    Citation Envoyé par Matt_Houston Voir le message
    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.

    Citation Envoyé par Matt_Houston Voir 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
    Celui qui peut, agit. Celui qui ne peut pas, enseigne.
    Il y a deux sortes de savants: les spécialistes, qui connaissent tout sur rien,
    et les philosophes, qui ne connaissent rien sur tout.
    George Bernard Shaw

  13. #13
    Expert confirmé
    Inscrit en
    mars 2005
    Messages
    1 431
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 431
    Points : 4 179
    Points
    4 179

    Par défaut

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

    Citation Envoyé par sambia39 Voir le message
    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.

  14. #14
    Membre expérimenté
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    mai 2010
    Messages
    453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : mai 2010
    Messages : 453
    Points : 1 608
    Points
    1 608

    Par défaut

    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:
    Citation Envoyé par Matt_Houston Voir le message
    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
    Celui qui peut, agit. Celui qui ne peut pas, enseigne.
    Il y a deux sortes de savants: les spécialistes, qui connaissent tout sur rien,
    et les philosophes, qui ne connaissent rien sur tout.
    George Bernard Shaw

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Pousser des données depuis le serveur vers le client dans le header HTTP
    Par Barsy dans le forum Général Conception Web
    Réponses: 2
    Dernier message: 31/12/2010, 14h03
  2. Question sur l'envoi de données
    Par Kruggs dans le forum Syntaxe
    Réponses: 7
    Dernier message: 27/05/2009, 16h48
  3. [SQL 2000] Question sur les types de données
    Par Angath dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 03/11/2006, 14h05
  4. Question sur la sauvegarde de données
    Par petitprince dans le forum Delphi
    Réponses: 58
    Dernier message: 12/10/2006, 21h03
  5. question sur le rafraichissement des données dans la base
    Par vbcasimir dans le forum Bases de données
    Réponses: 8
    Dernier message: 06/06/2005, 12h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo